Topic: Best practice for merchant automation - confirmation ? (Read 1042 times)

I've been coding my own Bitcoin payment verification system, www.bitcoinmonitor.net has been very useful thus far.

> I use the MtGox API to get the latest up-to-date buy prices for Bitcoins;
> Then generate unique addresses for specific users/transactions;
> Send a request to add that address to the bitcoinmonitor.net agent;
> When there has been a payment (with # confirmations) to an address you provided to the agent, it automatically sends a HTTP request (with a JSON body) to your callback address, in which you can code how to deal with those requests.

You can also set the verification count of transactions on the agent to ensure either a speedy or ensured payment.

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.  

Yes, pay a transaction fee that puts your transaction ahead of the competition.

Excellent explanation - thank you.

Agreed - just because you don't necessarily 'need' to adopt the practice now - you are setting yourself up for trouble later.


Hmm, so it seems it gets 'worse' (the time it takes to confirm that is).  Any idea how this could be handled at that point in the future ?

http://bitcoincharts.com/bitcoin/txlist/

All of those transactions have made it in to the Bitcoin network, but are waiting for confirmation. A few of them are from the beginning of the year! However, it's worth noting that, in the grand scheme of Bitcoin, this is a VERY low percentage of transactions.

In the future, if/when Bitcoin becomes more popular and transaction blocks are crammed full of transactions, it becomes possible that transactions will take forever to confirm and allow a user to double spend (and thus you run the risk of being deprived of those funds, which could cripple a business).

This is why, interest of best practices, it's good to wait for confirmation. It's better to learn it now, than have to learn it later.

I would think that common sense would dictate that a merchant using an automated system would not consider a transaction 'paid' until at least one confirmation ?

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 ?

I guess what I'm asking is the apparent trade-off:

0 confirms == very fast/ near instant processing
>0 confirms == variable time until 'paid' status, but safer ?