I just went to buy VPN access online. Had to wait 15mins.
That doesn't give enough information to say what caused the delay.
The transaction for a payment made with Bitcoin propagates globally within seconds, so it probably isn't that the merchant couldn't know that your payment was made promptly.
If it is because the merchant doesn't have an automated system and it takes human confirmation to process payments, then the delay is on their end.
If the delay is because the merchant isn't giving credit for payment on 0/unconfirmed, then that is a business decision they've made but probably not a smart one.
If they run their own node, then they can configure it properly so that a type of double spending attack known as a race attack becomes very difficult to pull off. The merchant's node is configured simply to not listen and then an outgoing connection is explicitly made to connect only to a well-connected node. With that configuration, the merchant has eliminated most risk from a race attack.
There still is a potential for another double spending attack called the Finney attack, but that is very uneconomical, as it is very expensive to carry out and is simply uneconomical for a thief to try to use it for low value transactions like a VPN subscription.
-
http://en.bitcoin.it/wiki/Double-spending#Attack_vectorsNow, does this same merchant accept PayPal or credit card? If so, what do they do when the payment is later reversed due to a chargeback (hours, days or weeks later)? They likely simply suspend service, even though service for some part of the month had already been provided. With a properly configured client node, the chances of a Bitcoin payment being reversed are fantastically smaller than with credit card. And with Bitcoin, if a reversal hasn't occurred within the first hour or so (when it reaches six confirmations) it will never be reversed at a later time.
There are some situations where a merchant wouldn't want to recognize payment until the transaction has confirmed, but for a VPN whose service is delivered over time, the exposure to losses from a Bitcoin double spend are so trivially low it just doesn't make business sense to not accept payment as soon as the customer's payment transaction is seen (on 0/unconfirmed), and then revoke service later should a double spend be discovered.
If this becomes complex for the merchant, a payment processor can help. BitPay, for example, sends out notifications to the merchant when it determines that a payment was a double spend. (or the merchant will know of the problem when the transaction appears on the merchant's settlement report.)
So the problem isn't that bitcoin takes 10 minutes for a Bitcoin transaction to confirm. The problem is that this risk is communicated incorrectly.
Bitcoin payment notifications are delivered in just a few seconds. That is about all that most merchants should be concerned with.
A merchant that is properly configured has just a tiny risk of a "chargeback" occurring, and that risk extends for about ten minutes. After that, a dramatically smaller risk (i.e., mathematically possible but highly unlikely) risk can continue for about an hour.
It is not easy for the thief to take advantage of any of these methods to execute any of these "chargeback" (double spend) methods though. Due to this, most merchants who accept Bitcoin will never see a successful Bitcoin double spend.
This compares to credit card transactions whose chargeback risk is high and remains fairly high for sixty days, and then there is a smaller risk of chargeback for yet another four months after that.
A merchant weighs the risks and proceeds with whichever method maximizes profit. Cash is still accepted even though a counterfeit $20 might end up in the til some day, for instance.
Show Posts
