Quote from: kalus on January 02, 2014, 11:27:40 AM

would the customer have to wait until the vendor received x confirmations?

Hard to say in general, but I think for small value transactions it would be fine to proceed without confirmations, although some additional double spend detection heuristic still needs to be added. Some comments from the blog post:

Quote

The common wisdom so far has been, that for small in person payments the risk of accepting zero-confirmation transactions is minimal. I agree that this is probably true. Although it is only true, if the merchant receives the transaction via the Bitcoin network and therefore has some indication that it has been broadcasted widely.

In this setting the merchant receives the transaction directly from the customer, which makes it much easier for the customer to trick the merchant, by sending a conflicting transaction simultaneously to the rest of the Bitcoin network. So this is still one of the pieces missing from this solution, before it is ready for real world usage. The merchant should wait a few extra seconds (unfortunately adding extra delay) and then check with a number of highly connected Bitcoin nodes whether there are any known double spends (feature request for Blockchain.info: return the double spend info that you are collecting already via your JSON api. It would be great if the data returned for a transaction would have an extra field called "known_double_spends" or "known_conflicts" which would be simply "true" or "false" or maybe a list of conflicting transaction ids). This would, I believe, be a reasonably secure heuristic for small amounts.

[...]

As an aside: The demo above employs green addresses. Bridgewalker transactions can be recognized by their use of coins from 1MAxx46Dp3tFw933PxPwEYYGCpxYda2pyH which is why the backend displays "Verified by Bridgewalker" after receiving the transaction. So in this case the merchant knows where to complain, if anything murky should happen with the transaction afterwards.