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?


2 Answers 2


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.

  • 2
    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. Mar 29, 2012 at 11:05
  • 1
    Would be interesting to monitor pool and large miners for protocol breaks....
    – kermit
    Mar 29, 2012 at 11:48
  • @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. Mar 29, 2012 at 12:07
  • @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'.
    Mar 29, 2012 at 12:21
  • @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. Mar 29, 2012 at 12:59

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.

  • Raw Bitcoin is applicable to small, fast transactions if used properly. Not to say additional layers can't help. Mar 29, 2012 at 10:39
  • The other answer is good anyway, but this is the correct one.
    – o0'.
    Mar 29, 2012 at 12:22
  • @Lohoris: While I very much appreciate this answer (+1ed), the other is imho closer to the Q.
    – kermit
    Mar 29, 2012 at 12:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.