Double Spend Notification



Summary:

The current implementation of Bitcoin is vulnerable to double spend attacks for 0 confirmation payments, making it difficult to trust such transactions. The issue arises when there are two transactions in the unconfirmed pool, both with the same input but different outputs and fees. Miners have no way of knowing which transaction is real and which one is fraudulent. Therefore, a decision has been made to make 0-conf double spends trivial. If a later transaction appears with a larger fee, it will be considered the valid one, and the first one dropped, as long as the first one has not been confirmed.This decision has made secure 0-confs an impossible target in blockchain cryptocurrencies. Those needing 0-conf-like speed will have to make other arrangements, such as contracting with enough mining pool power to never drop their transactions unless confirmed multiple times. Any ideas on how to make them work are welcome.On May 21, 2013, Quinn Harris raised concerns about the vulnerability of the current BitCoin implementation to relatively easy double spend attacks for 0 confirmation payments. Implementing replace by fee would provide protection from non-trusted 0 confirmations transaction, but it would still be important to work towards more robust solutions, notably various forms of 3rd party trust. These could be tamper-resistant devices trusted to not duplicate spends, 3rd party certificates with proof the transaction was spent by the holder of the certificate, or multi-signature transactions on the block chain that must be signed by a trusted 3rd party to spend.If a BIP and pull request implementing a double spend notification as described are accepted, it would make double spends more costly than they are worth for most cases today where 0 confirmation acceptance is needed. However, it would still be important to work towards more robust solutions, and there are multiple counteracting forces that make predicting the future effectiveness of double spend notification uncertain.


Updated on: 2023-06-06T17:46:45.104060+00:00