Question about how miners treat unconfirmed double spend transactions

[barbarousrelic]

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?

[1713934051]

1713934051

[1713934051]

1713934051

[1713934051]

1713934051

[DannyHamilton]

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.

[barbarousrelic]

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.

[DannyHamilton]

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.

[barbarousrelic]

Great answers, thank you very much.

[Scoremaster]

miners will not allow double spends to happen. in the most rare circumstance and it will probably happen a few times, if everything arrives at the exact same smallest unit of time measurement used in the btc protocol, it could happen.

[DannyHamilton]

miners will not allow double spends to happen.

Correct.  A "true" double spend, where both transactions are confirmed in the blockchain is impossible.

in the most rare circumstance and it will probably happen a few times, if everything arrives at the exact same smallest unit of time measurement used in the btc protocol, it could happen.

What are you talking about?  It is not possible for both transactions to be confirmed.  It doesn't matter how close together they arrive.

[CIYAM]

Danny is correct - there is actually *no such thing as a double-spend* (check the entire blockchain history and you'll not find one).

There are only "double-spend attempts" which then the miners have to decide on *which* of the options to accept (but only one).

[wasserman99]

Danny is correct - there is actually *no such thing as a double-spend* (check the entire blockchain history and you'll not find one).

There are only "double-spend attempts" which then the miners have to decide on *which* of the options to accept (but only one).

I think this depends on your definition of "double spend"

If you would define a double spend as the exact same input being spent more then once then you are correct as the network would reject any found block that contains anything like this.

If you would define a double spend as a TX in which the same input(s) are part of a transaction that would prevent a separate, previously propagated TX that someone though was going to be confirmed, then this is very much possible. For example, if send a TX with inputs (a), (b), and (c) to a retailer and then later are able to get a separate TX to confirm that contains input (c) (the TX would likely be to an address that you control) then this would be a double spend under this definition. 

[bitcoinbeliever]

If you would define a double spend as a TX in which the same input(s) are part of a transaction that would prevent a separate, previously propagated TX that someone though was going to be confirmed, then this is very much possible.

0-conf respend attempts happen every day.  As was mentioned, the network actually tries to keep as nodes from seeing both.  This site tracks the ones it sees though: http://respends.thinlink.com

[Nrcewker]

double spend may be, but mustn't double fee.

[CIYAM]

I think this depends on your definition of "double spend"

Very true - but by saying that "double spend attempts" are "double spends" unfortunately leads those with less technical understanding of Bitcoin to think that "double spends" are a "problem with Bitcoin" (and thus to completely miss the fact that Bitcoin solves the Byzantine Generals problem which is the whole reason that we even use it).

[DannyHamilton]

I think this depends on your definition of "double spend"

Very true - but by saying that "double spend attempts" are "double spends" unfortunately leads those with less technical understanding of Bitcoin to think that "double spends" are a "problem with Bitcoin" (and thus to completely miss the fact that Bitcoin solves the Byzantine Generals problem which is the whole reason they we even use it).

And more importantly, it ignores the context of the statement:

Correct.  A "true" double spend, where both transactions are confirmed in the blockchain is impossible.

Furthermore, it ignores the fact that the post being responded to seems to imply that if two transactions arrive at a miner close enough together, they could somehow magically both be confirmed:

in the most rare circumstance and it will probably happen a few times, if everything arrives at the exact same smallest unit of time measurement used in the btc protocol, it could happen.

Read the thread, follow the context, and you'll see that the specific definition of "double spend" that was being discussed had already been established.