Quote from: etotheipi on August 20, 2011, 12:54:39 AM

If enough nodes see one transaction first and enough other nodes see the other transaction first, then the vendor's node will actually see both conflicting transactions.

This assumes that if I send out my double-spend attempt immediately after the vendor has convinced themselves that no double-spend has been attempted so far, that my second transaction won't 'win'. The chances of this happening are a function of both the amount of delay between my initial transaction going out and the vendor accepting it at face value, and the average delay of transactions propogating through the network. I guess vendors could wait like 30 seconds (probably about as long as customers would tolerate waiting for their payment to be confirmed) and hope that this is enough of a "head start" for the first transaction to have a very, very high chance of beating any subsequent transactions into a block.

Also the vendor has to keep track of all outstanding transactions not yet in blocks to be sure that I didn't already spend the coin a few minutes before presenting the a transaction for the same coin to the vendor. This would be incredibly costly for vendors when bitcoin is very big, and I guess they'd have to consolidate their costs into a single data center, or buy that service from someone they trust, both of which add to the cost of processing transactions. Of course they wouldn't have to pay credit card fees either so that may be a wash.

I guess that's the only way I could see vendors trusting unconfirmed transactions; they could pay a third party to act as an insurer against double-spends. That third party would be heavily connected into the bitcoin network to try to minimize their chance of a double-spend occurring that they would have to pay the insurance on, and they would set a transaction fee that the vendor would then either eat (and if it's as low or lower than credit card transaction fees this should not be a problem) or directly charge the customer (unlikely once bitcoin was well-accepted enough to be an expected form of payment, just like vendors don't typically charge extra for credit card payments (although some very low-margin vendors do)).

Once all of that infrastructure is in place, it makes little or no sense to have this satoshi code idea. The customer would just submit their transaction to the vendor, who would submit it to the network and then ask their double-spend insurer to let them know when it can validate that the transaction is on the network and that it appears valid. The insurer might have an implicit delay before they will answer in the affirmative to give the transaction time to get the 'head start' that they believe improves its chance of being accepted without being a double-spend.

Quote

P.S. - Of course, this can also be resolved with third-parties. I wouldn't mind having a small quantity of money (5% of my BTC) in a third-party account that specifically guarantees immediate transaction validity, and linked to most major vendors for this purpose.

Having an account implies trust between you and the account holder. So far trust has not gone very far in the world of bitcoin. The only thing you can really trust with bitcoin is the validated transactions 6 or so blocks back in the block chain. Which is why the block chain exists and why trying to get around it kind of defeats the purpose of bitcoin ...