Quote from: barbarousrelic on August 27, 2014, 02:31:52 PM

Quote from: DannyHamilton on August 27, 2014, 02:21:14 PM

Quote from: barbarousrelic on August 27, 2014, 12:55:39 PM

Bitcoin address X contains 1.06 bitcoin.

Let's say a miner sees two unconfirmed transactions broadcasted - the first one says to send 1 bitcoin from address X to address Y. The second transaction says to send 1 bitcoin from address X to address Z. Both transactions cannot be completed. This is a double spend.

My understanding is that Bitcoin miners can write their own miner software to choose which transaction to process in any way they wish. They could include in the next block whichever transaction has the higher fee, they could go with whichever transaction they received first, they could go with whichever one has more of the letter 'Q' in the destination address because they like the letter Q.

But in practice, how would this normally be handled by most miners' software?

In practice, most miners will only see one of the two transactions. The nodes of the network will accept and relay the first transaction that they see. They will refuse to relay the second one, so it won't propagate across the network.

If, on the other hand, you specifically connect directly to the larger mining pools, and send your transactions directly to them, then most mining pools will accept which ever transaction they receive first. They will ignore the one they receive second.

Thank you for your answer.

One more question though. How reliable is it in practice that miners will receive transactions in the same order they occur?

Let's say one person has a habit of going out and making small Bitcoin purchases ten times a day, and receiving his goods with zero confirmations. And let's say every time he broadcasts his purchase transaction, he immediately broadcasts a second double spend transaction. Roughly how often will the second double spend transaction be confirmed in a block?

I wonder if the policy of not relaying duplicate transactions ever backfires, and one node receives the second one first, and that node relays it to numerous other nodes, and now the doublespend transaction blocks out the legitimate one.

This would be considered fraud, and should be treated the same as any other form of fraud. In other words, the person would likely be caught eventually and prosecuted. Given the small chance of success, it is probably an acceptable risk for most retailers. Given the small chance of such a small reward, it is probably not an acceptable risk for most attackers. It would be more profitable and easier to just put the small purchase items in their pocket and walk out without paying.

Transactions relay across the entire network in just a second or two, so the malicious user would need to send both transactions nearly simultaneously in order for the double spend transaction to have a chance to propagate. This means that if the doublespend transaction is the one that propagates, instead of the transaction that pays the merchant, then the merchant won't see a payment arriving in their wallet in the first place. Therefore the merchant won't consider the bill paid.

To overcome this problem, the attacker needs to isolate the merchant's nodes so that they can't see transactions from the rest of the network. Then the attacker needs to broadcast 1 transaction directly to the merchant's nodes while simultaneously broadcasting a doublespend transaction to the rest of the network. Identifying and isolating the merchant's nodes isn't likely to be an easy task, and isn't something an attacker is likely to be able to do for "small Bitcoin purchases ten times a day".

As a defense against such an attack, a merchant could maintain a connection directly to a few of the largest mining pools. If their connection to the mining pools is disrupted, the system could be designed to refuse to accept any transactions until the connection to the mining pools is restored. As long as they see the transaction relayed from mining pools with enough hashpower, the merchant could feel confident that the transaction is likely to confirm.