RockHound, I don't know if it exists today, but if there is some eWallet 2 of 2 multisig provider, and that you can identify them (for example, they have published public keys), then your problem is solved.
If customer A, have funds in such ewallet. Then you can confirm the purchase as soon as you get hold of the signed transaction by him and the provider, without having to wait any confirmation.
Why ? Because you can trust that the ewallet provider will never double spend.
You would then require customers to pay you from trusted 2-2 multi sig ewallet provider... Or wait 1H for confirmation.
Topic: # Confirmations Double Spending solutions (Read 708 times)
-We considered taking registered user accounts/KYC, and this is still a possibility. However, we wanted to make the site with simplicity in mind (end user experience).
Perhaps offer two levels of service.
Those willing to submit to user accounts/KYC, get the benefit of instant acceptance of transfers.
Those unwilling to submit to user accounts/KYC still get to use the site, but are forced to wait for a few confirmations.
Excellent progressive suggestion - Maybe the way forward for us!
I'll email/contact Jumio Identity Tech and similar service providers.
Will certainly help in minimizing fraud. I've just PM'ed you mate.
-We considered taking registered user accounts/KYC, and this is still a possibility. However, we wanted to make the site with simplicity in mind (end user experience).
Perhaps offer two levels of service.
Those willing to submit to user accounts/KYC, get the benefit of instant acceptance of transfers.
Those unwilling to submit to user accounts/KYC still get to use the site, but are forced to wait for a few confirmations.
It really depends on your business model.
If you accept the transfer, and then it is reversed, how significant of a problem is that? (For example, with a web hosting service, the provider can simply shut the service off if/when the payment is reversed).
Do you have any identifying information about your customers that would discourage fraud? (For example, if you are shipping them a product, you have their address).
Can you respond quickly enough to a significant increase in fraud to prevent problematic losses if the fraud rate suddenly increases? (For example, if you find that typically 1 out of every 10,000 transactions are reversed, and then suddenly 80 out of 100 transactions are reversed)
Without confirmations, there is always a risk that someone could get a conflicting transaction confirmed in place of the one they sent you. This is the reason that confirmations exist, and is one of the problems that Satoshi solved with this distributed consensus concept. You have to decide for yourself how significant that particular risk is to your business.
If you accept the transfer, and then it is reversed, how significant of a problem is that? (For example, with a web hosting service, the provider can simply shut the service off if/when the payment is reversed).
Do you have any identifying information about your customers that would discourage fraud? (For example, if you are shipping them a product, you have their address).
Can you respond quickly enough to a significant increase in fraud to prevent problematic losses if the fraud rate suddenly increases? (For example, if you find that typically 1 out of every 10,000 transactions are reversed, and then suddenly 80 out of 100 transactions are reversed)
Without confirmations, there is always a risk that someone could get a conflicting transaction confirmed in place of the one they sent you. This is the reason that confirmations exist, and is one of the problems that Satoshi solved with this distributed consensus concept. You have to decide for yourself how significant that particular risk is to your business.
Cheers Danny,
-Unfortunately, reversals would be a huge problem, rendering our model non-viable.
-We considered taking registered user accounts/KYC, and this is still a possibility. However, we wanted to make the site with simplicity in mind (end user experience).
-Our engineer(s) will write Safe Guards and Permissions to near best industry standards. But I want to negate the problem altogether.
Thanks again for your input mate : )
It really depends on your business model.
If you accept the transfer, and then it is reversed, how significant of a problem is that? (For example, with a web hosting service, the provider can simply shut the service off if/when the payment is reversed).
Do you have any identifying information about your customers that would discourage fraud? (For example, if you are shipping them a product, you have their address).
Can you respond quickly enough to a significant increase in fraud to prevent problematic losses if the fraud rate suddenly increases? (For example, if you find that typically 1 out of every 10,000 transactions are reversed, and then suddenly 80 out of 100 transactions are reversed)
Without confirmations, there is always a risk that someone could get a conflicting transaction confirmed in place of the one they sent you. This is the reason that confirmations exist, and is one of the problems that Satoshi solved with this distributed consensus concept. You have to decide for yourself how significant that particular risk is to your business.
If you accept the transfer, and then it is reversed, how significant of a problem is that? (For example, with a web hosting service, the provider can simply shut the service off if/when the payment is reversed).
Do you have any identifying information about your customers that would discourage fraud? (For example, if you are shipping them a product, you have their address).
Can you respond quickly enough to a significant increase in fraud to prevent problematic losses if the fraud rate suddenly increases? (For example, if you find that typically 1 out of every 10,000 transactions are reversed, and then suddenly 80 out of 100 transactions are reversed)
Without confirmations, there is always a risk that someone could get a conflicting transaction confirmed in place of the one they sent you. This is the reason that confirmations exist, and is one of the problems that Satoshi solved with this distributed consensus concept. You have to decide for yourself how significant that particular risk is to your business.
Hi,
I am currently developing a BTC online service which ideally will trigger our implementation upon receiving 1st Confirmation.
Interviewed several software engineers this week, one engineer brought up a point regarding Double Spending - Is there a secure way to validate a BTC transfer without waiting for xConfirmations?
Eg. Does using the BIP 70 protocol solve this?
Any suggestions from the Bitcointalk Braintrust would be greatly appreciated.
RH
I am currently developing a BTC online service which ideally will trigger our implementation upon receiving 1st Confirmation.
Interviewed several software engineers this week, one engineer brought up a point regarding Double Spending - Is there a secure way to validate a BTC transfer without waiting for xConfirmations?
Eg. Does using the BIP 70 protocol solve this?
Any suggestions from the Bitcointalk Braintrust would be greatly appreciated.
RH
Jump to: