Topic: Faster payments should be priority #1 (Read 1268 times)

Please don't downplay the finney attack.

It's a non-issue in this case because— as mentioned— they can just cancel the service if the payment doesn't go through. This would let them get instant turnon and security against all kinds of attack. For the purpose of this thread it's really the end of the discussion.

But the finney attack is not terribly uneconomical now that there are services where you can buy hashpower from dimwitted greedy miners for small premiums over their value.  The finney attack is also not the only relevant concern for 0/confirmed:  conflicted transactions are not broadcast (and simply broadcasting them has serious DOS risks) so there may be a substantial portion of the network that prefers a conflicting transaction and yet you won't hear about it.  Moreover, AFAIK no existing node software does anything _useful_ even if it does hear a conflict such as expose it to the user. Again, in this kind of case it doesn't matter, but I strongly disagree with downplaying it generally.

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_vectors

Now, 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.  

Transaction fees create an incentive for a miner to include your transaction in their next block.  Blocks are still created on average every 10 minutes. Because the successful creation of a block is entirely random, it could take an hour or more for the next block, or it could be a few seconds.  Transaction fees do not generally decrease the amount of time until the next block is found.

If you don't include a fee, you are simply hoping that some miner will be kind enough to choose to include your transaction in their next block out of an interest in keeping the bitcoin system popular.  When you do include a fee, the first miner to include your transaction in a block will receive that fee as payment for doing so, as such most miners will want to include your transaction.

The transaction itself is created and generally shows up on the network within a few seconds.  After that it is up to the merchant/service provider to decide if they require confirmations in the blockchain before they will accept payment.  If you don't like how long they are waiting, you have to take that up with them.

In certain special circumstances a fee may be required for the transaction to be relayed by the network, but the standard "Satoshi" client lets you know up front if your transaction meets the conditions of those special circumstances.

This is the problem with the service provider and nothing to do with bitcoin. They can cancel your service if you revoke your payment (difficult for you to do anyway).
99.99% of the time you will end up paying. They stand to lose 15 minutes of free vpn service if they provide it upfront. To avoid a 0.01% risk of providing 15 mins of free service, they chose to make you wait 15 mins.
Complain to customer service and/or find another VPN provider.

[That said I pay for my VPN with VISA and also have to wait 15+ minutes. My service provider sucks too.]

 I just went to buy VPN access online. Had to wait 15mins. This is a big problem. A deal breaker I think.

Where can I find more info on ideas on speeding this up?

 I know we had the idea of green addresses and also this was part of the push with litecoin. What other discussion has there been? Or rather, what would you search for on the forum to find more info?

 Also, what is the relationship of the transaction fee to speed? I mean... how much do we add and what can we expect back?
https://en.bitcoin.it/wiki/Transaction_fees#Rules_for_calculating_minimum_fees