Quote from: BlueMatt on April 21, 2011, 10:12:18 AM

Quote from: ffe on April 09, 2011, 03:49:38 AM

Clients publish transactions to each other within seconds. If a new transaction is not a copy of the short term list of new transactions and is not a copy of something in the block chain it is probably ok to believe it will be accepted and you can proceed with the transactions.

The risk is that your client hasnt seen the duplicate and the other transaction gets incorporated in the chain. I believe the chances of that happening for a normal transaction are low. The double spender would have to actively attack your client network connection to accomplish a double spend and for normal transactions a wait of a few seconds is perfectly fine. We would need the window to be large enough that we are very confident most clients have seen the transaction yet short enough that the selling merchant can wait without burdening normal customers. 15 seconds for example.

For high value transactions (like paying for a car) waiting for a few confirmations seems acceptable.

I think the merchant's client could be modified to let the merchant know there are no conflicting transactions in the active list after 15-30 seconds.

NO, unconfirmed transactions with no special attempts to ensure finding double-spend transactions are not acceptable for any automated system. In the standard client, even if your client does hear about a double spend, it doesn't mark the double-spent transaction of notify you in any way. If an attacker created to transactions, sending one to the largest miners (not hard to figure out their IPs) and one to you (depending on the way you structure it, also probably not hard to find your IP) and you would be none the wiser. Even if you purposefully modify your client to mark double-spent transactions, you have to make sure you have a direct connection between you and the miners attacked to ensure the nodes in between don't drop the double-spend you want to know about.

The regular client doesn't perform a check of the live transaction queue, but it could be done. I'd be willing to bet that it will be a standard check on POS systems long before Wal-Mart starts accepting Bitcoin at their registers. And a slick POS client could also send the transaction to all of it's peers except one, and if that peer offers back that same transaction then it's safe to assume that the transaction is good. Even if there is a double spend attempt underway, if your own POS system has a decent spread of peers and your last peer then sends you the correct transaction, odds are high enough that your transaction was first (and therefore most likely to come away with the actual bitcoins) and therefore acceptable. This would be acceptable risks for sales values under $50, and is similar to how credit card companies handle charges under $50.

Such a check wouldn't take nearly 15 seconds under normal network loading conditions, but a 15 second timeout would be reasonable.