<p>If a merchant accepts 0-confirmation transactions, he has to accept that the transaction can be reversed. So he only should do that if he trusts you for more than the amount you transferred to him. You won't get any bragging rights for doing that, since Bitcoin never promised to be secure without sufficient confirmations.</p>

<p>That trust may come from different sources. For example he might know your name, and will sue you for lack of payment. Or you put an amount that exceeds the payment into escrow.</p>

<p>Or perhaps he just doesn't care. For example for many digital goods(most software, movies, music,...), you have negligible marginal costs, and you're already relying on the user being honest enough to not download a copy from Pirate Bay without paying you.</p>

<hr>

<p>Personally I believe those attacks are irrelevant, since Bitcoin isn't well suited for small fast payments in the first place. I expect those to be handled by higher level protocols, with Bitcoin itself being used to handle larger balancing payments and as a secure value store.</p>

CC BY-SA 3.0
2012-03-29T10:39:47.347Z
Raw Bitcoin is applicable to small, fast transactions if used properly. Not to say additional layers can't help.
Meni Rosenfeld
CC BY-SA 3.0
2012-03-29T12:22:24.767Z
The other answer is good anyway, but this is **the correct one**.
o0'.
CC BY-SA 3.0
2012-03-29T12:32:26.937Z
@Lohoris: While I very much appreciate this answer (+1ed), the other is imho closer to the Q.
kermit
CC BY-SA 3.0
2012-03-29T09:38:27.780Z
2012-03-29T16:30:35.497Z
2012-03-29T16:30:35.497Z
CodesInChaos
<p>Bitcoin's security rests on the assumption that the majority of the hashing power follows the protocol. If instead miners/pools break protocol for a quick buck by switching to a conflicting transaction which is clearly a double-spend attempt, this assumption no longer fully holds.</p>

<p>One can only hope that the mining pool (or any block issuing agent) will refrain from this because they realize that supporting double-spends undermines the validity of their own stake in the Bitcoin ecosystem.</p>

CC BY-SA 3.0
2012-03-29T11:05:36.623Z
You're overly optimistic IMO, since even a relatively small minority of miners who take the larger transaction is enough to make 0-confs unreliable.
CodesInChaos
CC BY-SA 3.0
2012-03-29T11:48:00.330Z
Would be interesting to monitor pool and large miners for protocol breaks....
kermit
CC BY-SA 3.0
2012-03-29T12:07:59.033Z
@CodeInChaos: You have a point, it's not going to be an easy problem. This means that anonymous 0-conf (not from a split-key eWallet) will be used mostly for small in-person purchases, where the probability of even attempting a double-spend is small to begin with.
Meni Rosenfeld
CC BY-SA 3.0
2012-03-29T12:21:18.090Z
@CodeInChaos and that's fine, since they are what they are: 0 confirmation. You know you need at least 8 (6?) confirmations, and by definition 0 confirmations means, well, 0 confirmations. Of course you can't trust them.
o0'.
CC BY-SA 3.0
2012-03-29T12:59:41.840Z
@Lohoris: No, you can trust them if you know under what circumstances they can be trusted, and to what degree. 6 confirmations is overkill for almost all transactions, 2 is enough if you're not selling a car or something. Let's put it this way, 1-conf is comparable to accepting a cash note without verifying that all the anti-counterfeiting marks are valid.
Meni Rosenfeld
CC BY-SA 3.0
2012-03-29T10:38:38.110Z
2012-03-29T12:08:25.477Z
2012-03-29T12:08:25.477Z
Meni Rosenfeld
<p>The standard client prioritizes TXs by the time of receipt, e.g. a conflicting transaction will not be relayed. This is not enforced by the network, though. Is there anything that would prevent this scenario from happening with 0-confirmations?:</p>

<ul>
<li>Send 0.01btc fee TX to 0-confirmation accepting merchant.</li>
<li>Receive digital good.</li>
<li>Send 0.02btc fee TX directly to "all" the major pools/miners.</li>
<li>Miners will include the higher fee TX because they make more profit from it. (Not sure they currently do that but they could.)</li>
<li>brag about successful double spend</li>
</ul>

<p>Is there anything but worry about their reputation keeping pools/miners from dropping lower fee TXs in favor of higher fee TXs?</p>

CC BY-SA 3.0
2012-03-29T12:04:12.150Z
it would be possible for the merchant to create an even higher fee TX based on the original TX if he detects a double spend: https://bitcointalk.org/index.php?topic=62137.msg727644#msg727644
kermit
CC BY-SA 3.0
2012-03-29T12:31:21.197Z
Related http://bitcoin.stackexchange.com/a/1892/940
CodesInChaos
<transactions><doublespend><revert-transaction><zero-confirmation><transaction-selection>
Double spend attack by sending higher fee transaction directly to the pools possible?
kermit
# Double spend attack by sending higher fee transaction directly to the pools possible?

(Asked by: username_0 on 2012-03-29)

The standard client prioritizes TXs by the time of receipt, e.g. a conflicting transaction will not be relayed. This is not enforced by the network, though. Is there anything that would prevent this scenario from happening with 0-confirmations?:

* Send 0.01btc fee TX to 0-confirmation accepting merchant.
* Receive digital good.
* Send 0.02btc fee TX directly to "all" the major pools/miners.
* Miners will include the higher fee TX because they make more profit from it. (Not sure they currently do that but they could.)
* brag about successful double spend

Is there anything but worry about their reputation keeping pools/miners from dropping lower fee TXs in favor of higher fee TXs?

**Tags:** transactions, doublespend, revert-transaction, zero-confirmation, transaction-selection

> **Comments:**
> **username_0**: it would be possible for the merchant to create an even higher fee TX based on the original TX if he detects a double spend: https://bitcointalk.org/index.php?topic=62137.msg727644#msg727644  
> **username_1**: Related http://bitcoin.stackexchange.com/a/1892/940  

---

## 2 answers

### Answer by username_2 on 2012-03-29. Score: 7 | Accepted answer

Bitcoin's security rests on the assumption that the majority of the hashing power follows the protocol. If instead miners/pools break protocol for a quick buck by switching to a conflicting transaction which is clearly a double-spend attempt, this assumption no longer fully holds.

One can only hope that the mining pool (or any block issuing agent) will refrain from this because they realize that supporting double-spends undermines the validity of their own stake in the Bitcoin ecosystem.

> **Comments:**
> **username_1**: You're overly optimistic IMO, since even a relatively small minority of miners who take the larger transaction is enough to make 0-confs unreliable.  
> **username_0**: Would be interesting to monitor pool and large miners for protocol breaks....  
> **username_2**: @CodeInChaos: You have a point, it's not going to be an easy problem. This means that anonymous 0-conf (not from a split-key eWallet) will be used mostly for small in-person purchases, where the probability of even attempting a double-spend is small to begin with.  
> **username_3**: @CodeInChaos and that's fine, since they are what they are: 0 confirmation. You know you need at least 8 (6?) confirmations, and by definition 0 confirmations means, well, 0 confirmations. Of course you can't trust them.  
> **username_2**: @Lohoris: No, you can trust them if you know under what circumstances they can be trusted, and to what degree. 6 confirmations is overkill for almost all transactions, 2 is enough if you're not selling a car or something. Let's put it this way, 1-conf is comparable to accepting a cash note without verifying that all the anti-counterfeiting marks are valid.  

---

### Answer by username_1 on 2012-03-29. Score: 14

If a merchant accepts 0-confirmation transactions, he has to accept that the transaction can be reversed. So he only should do that if he trusts you for more than the amount you transferred to him. You won't get any bragging rights for doing that, since Bitcoin never promised to be secure without sufficient confirmations.

That trust may come from different sources. For example he might know your name, and will sue you for lack of payment. Or you put an amount that exceeds the payment into escrow.

Or perhaps he just doesn't care. For example for many digital goods(most software, movies, music,...), you have negligible marginal costs, and you're already relying on the user being honest enough to not download a copy from Pirate Bay without paying you.

---

Personally I believe those attacks are irrelevant, since Bitcoin isn't well suited for small fast payments in the first place. I expect those to be handled by higher level protocols, with Bitcoin itself being used to handle larger balancing payments and as a secure value store.

> **Comments:**
> **username_2**: Raw Bitcoin is applicable to small, fast transactions if used properly. Not to say additional layers can't help.  
> **username_3**: The other answer is good anyway, but this is **the correct one**.  
> **username_0**: @Lohoris: While I very much appreciate this answer (+1ed), the other is imho closer to the Q.  

---

