9

I realize that if somebody makes a transaction without any fees and there have not yet been any confirmations, then the transaction could be double spent by just spending the same inputs to a different address, but with a standard fee.

My question is, if somebody sends a transaction with a standard fee, and there have yet to be any confirmations, could that transaction be just as easily overridden by rewriting the transaction, but with a higher fee? If so, what would be the implications for a party that accepts zero confirmation transactions such as BitPay?

Mathias711
  • 1,426
  • 1
  • 13
  • 27
DJG
  • 441
  • 5
  • 11

2 Answers2

5

The original design assumes a common behavior of processing the incoming transaction on FIFO basis. That means the first transaction received by a miner wins and all conflicting transactions received after it will be ignored (no matter if the first one is already confirmed or not).

While this standard behavior is beneficial for the Network as a whole, some "smart" miners might employ a bit different approach: when building a block, always take the transaction with the highest fee, no matter the order in which it was received.

It might seem this is just a marginal misuse of the protocol and there won't be enough rogue miners doing this, so it doesn't matter. Well, unfortunately, there already is (at least) one mining pool that tries to build its business exploiting this idea. Should it prevail, services accepting zero-confirmation transactions will need to reconsider their policy.

knaperek
  • 1,424
  • 9
  • 22
  • 2
    Great answer, except for one thing: It doesn't need a lot of 'rogue miners' for this to become a problem. Even if it is just 5% of miners who do it, this could make accepting zero-confirmation transactions impossible.

    Here is how it would work: I spend 100 mBTC on a dinner in a regular transaction that the restaurant accept with no confirmations. I send another transaction returning 90 mBTC of the inputs to myself and paying 10 mBTC as a miner's fee. There is no risk for me! Worst case I paid for what I spent anyway. But with x% chance, I only have to pay 10% of the dinner!

     – Brian Fabian Crain Jul 07 '14 at 07:21
  • Sure, the phrasing "enough rogue miners" was in no way meant as a majority, but more like "enough for the chance being noticeable". 5% is a big number already. Anyway, it only highlights the risk in accepting zero-confirmation transactions if you cannot reclaim the service IRL. In your example with the restaurant, this could be considered as leaving-without-paying, which is already a risk anyway - and there are some ways to deal with this (including police). So, just be sure you consider the whole social aspect when evaluating your risk. – knaperek Jul 08 '14 at 17:05
  • From what I read, we've reached the point where zero-confirmation is no longer viable. If you are still in the loop on the topic, you could perhaps update your excellent answer. :) – Murch Jul 15 '15 at 08:59
  • Are you sure? I'm not aware about any significant situation change in the recent years; it is still possible to accept payments immediately when the transaction is spotted, especially with some reclaimable online services and it can be OK as long as it is taken into consideration and measures are implemented to further ensure the transaction gets confirmed properly. – knaperek Nov 28 '16 at 13:34
1

If a node receives a transactions it saves it. If you now send another transaction with the same input it rejects it, because there is already a transaction. So you cant double-spend this way.

If you would send the second transaction with fees to a miner which does not received your first transaction, he would perhaps include it faster and therefore it would override the first transactions, still the first transactions cant be included in a new block because the output was already used.

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.

Dennis Kriechel
  • 1,763
  • 4
  • 16
  • 34