Quote from: a654bdff on May 27, 2012, 02:37:38 AM

Is there really a big risk in seeing the transaction with 0 confirms and acting on it ? I've read the high level info on unconfirmed, confirmed transactions, but I don't think I fully understand the risk. Could someone provide a real example of a transaction 'showing up', but never getting a confirmation ?

Here's a scenario:

Let's say you run BitFare and are going to sell pre-loaded transit cards for bitcoins from a cart near the subway entrance. One of the products you offer is a card pre-loaded with $100 worth of transit credit, and you price the card at 20 BTC:
- http://bitfare.org

Evil solo miner plans to defraud you so always includes a special 20 BTC transaction when hashing. This transaction is a 20 BTC payment sent to another address in evil miner's own wallet but evil miner purposely does not broadcast the transaction to the Bitcoin network.

Immediately upon solving a block evil miner contacts his buddy who is near the cart and is standing by. The buddy then uses the Blockchain mobile app to purchase the $100 transit card. The mobile app's wallet was configured with the same private key as the one solo miner used in creating the original 20 BTC transaction. A spend transaction using that private key has not yet been seen previously on the network, so it is seen as a valid transaction and is relayed by all nodes.

You as the merchant see the payment arrive and hand over the fare card to the buddy who then heads for the subway tunnel. The buddy notifies evil miner that the transaction is complete and evil miner publishes the block that was previously solved and includes the original spend of the 20 BTC.

Your client gets this new block but the transaction from the buddy still shows 0/unconfirmed. That transaction will never confirm because it is now invalid. It uses an input that now shows as having already been spent thanks to evil miner.

This is called the Finney attack.

There is an even easier attack known as the race attack but in the example of your subway transit card business there are protections to effectively eliminate the race attack from being successful. There is little that can be done to prevent a Finney attack though other than to make it so that there is no profit for the attacker. For instance, with the Finney attack, each second the solved block is held costs the miner about $0.40 (on average, when the BTC/USD is $5) as some attempts will fail when other miners solve the block before evil miner's plan could be concluded.

To counter this threat the merchant simplly holds onto the goods for 60 seconds (and monitors for double spends) after payment is received. This will make it so that any fraudulent purchase of $24 or less using cannot be done at a profit (on average) to the fraudster.

The subway transit card cart store example (which sells a high-dollar, low-margin product in a fast transaction to a complete stranger among a sea of people) is among the worst case scenarios and selling on 0/unconfirmed would be a bad idea for that merchant. A vending machine that sells prepaid debit cards would be another example where 0/unconfirmed sales are not recommended. An ecommerce site that sells print-at-home tickets is another where accepting payment on 0/unconfirmed would not be a good idea.

For most typical point of sale scenarios though, a proper configuration (with double spend detection) will nearly eliminate the risk of getting defrauded.

ZipConf is a commercial service that claims to solve this problem so that its merchant customers can accept payment on 0/unconfirmed without incurring the loss if a double spend were to occur.