https://nostr.aeNostr notes by https://nostr.ae/npub18zpfny5rg862xszvk3d4hnna037cj0dem7dpg36azurwx99wpnfquu3jvuhttps://nostr.ae/nevent1qqsdfhh3ea4g4hx0eavx60hmvkmeu2lkutn00zmq8ugqazhwu388wjczyqug9xvjsdqlfg6qfj69kk7w0478mzfah80e59z8t5tsdcc54cxdywyjpwxđ Original date posted:2013-05-20 đ Original message:The ...
In reply to <a href='/nevent1qqsw9vx5e857lydum08jtqcqp60thraptme8azspcw8swukmm2qep2gjzk3uj'>nevent1qâŠk3uj</a><br/>_________________________<br/><br/>đ Original date posted:2013-05-20<br/>đ Original message:The current BitCoin implementation is subject to relatively easy double <br/>spend attack for 0 confirmation payments. Yet 0 confirmation payments <br/>are needed for typical in person transactions like most purchases at a <br/>local business.<br/><br/>Notably, it is easy to transmit two transactions from the same output at <br/>the same time to different sets of nodes on the network by using two <br/>instances of bitcoind with same wallet file and a spend on each daemon <br/>initiated by RPC by some easy to implement code. If the first attempt <br/>to pay the merchant doesn't go through because they received the "wrong" <br/>transaction it could be quickly followed up with another initiated spend <br/>from a different output switching which daemon sends the transaction the <br/>merchant is expecting. This means an unsophisticated attacker can <br/>reliably get away with this attack and it would be worth while for small <br/>transactions. Given this, I would be reluctant to trust 0 confirmation <br/>transactions at all though I think many do in practice. Someone could <br/>write and publish a special daemon to execute this attack further <br/>reducing the cost.<br/><br/>Right now a node will drop any second spend of the same output in the <br/>memory pool. After the first transaction has propagated through the <br/>network issuing a second double spend transaction isn't likely to be <br/>seen by a significant number of miners as most nodes especially non <br/>miner nodes will drop this transaction. Today, it is necessary to <br/>transmit both transactions on the network nearly simultaneously to <br/>reliably get away with this simple attack. If in this case, the <br/>receiving end is quickly notified of the double spend this attack <br/>becomes more more difficult to get away with.<br/><br/>If the second transaction is relayed instead of being dropped to notify <br/>the receiving party of the double spend, most miners will receive both <br/>transactions and it is possible that some or even many of the miners <br/>would replace the first transaction with the second if it has a higher <br/>fee as it would be in their short term interest. This can happen some <br/>time after the first transaction has propagated through the network so <br/>the receiving end wouldn't get a timely notification of the double <br/>spend. Depending on the choices of the miners, this approach to double <br/>spend notification could exacerbate the very problem it was attempting <br/>to fix compared to the current implementation. While miners might <br/>continue to drop the second spends, the easy availability of the second <br/>spends would increase the short term reward for changing this policy.<br/><br/>This problem can be fixed if instead of sending the second transaction a <br/>new double spend message is sent with proof of the double spend but not <br/>the complete transactions. This would allow the receiving end to be <br/>quickly notified of a double spend while in no way increase the chance <br/>over the current implementation that a double spend would be successful.<br/><br/>The proof of the double spend would include the scriptSig (input) from <br/>the original transactions and the hashes from the "simplified" <br/>transaction used by OP_CHECKSIG of the scriptPubKey (output) but not the <br/>entire transaction. This is the hash computed by the SignatureHash <br/>function in script.cpp. The double spend notification message should <br/>contain proofs of both signed transaction spending the same output <br/>ordered by hash to produce a canonical proof for a specific two <br/>transactions. To reduce DOS potential, the proof should not be relayed <br/>unless one of the original transactions has been received to ensure <br/>there is some commitment to the block chain and different double spend <br/>proofs of the same output should not be relayed. The forwarding of <br/>transactions should remain exactly the same as it is now where the <br/>second transaction is dropped but a double spend message is transmitted <br/>if appropriate.<br/><br/>The existing block chain needs to be checked to make sure the proof of <br/>double spend couldn't have been derived from the block chain and a <br/>single spend in the memory pool. This could happen if there was already <br/>an identical transaction in the block chain. This would typically only <br/>happen if someone was paying someone else the same amount they had <br/>before and neither side changed addresses. In this case double spend <br/>detection wouldn't be reliable as it could be generated by anyone, but <br/>both the sending and receiving client could detect this situation and <br/>warn the user.<br/><br/>It would still be possible for an attacker to send the second <br/>transaction directly to powerful miners but this is a distinctly less <br/>viable attack than the current double spend attack.<br/><br/>I would expect this double spend notification implementation to make <br/>double spends more costly than they are worth for most cases today that <br/>0 confirmation acceptance is needed. That said over time this provision <br/>might become less effective. As the reward for each block mined <br/>decreases, transactions fees will become a more significant part of the <br/>mining reward accordingly increasing the incentive to replace <br/>transactions with higher fees. Today most BitCoin participants have a <br/>high expectation of significant future appreciation of BitCoins and <br/>recognize anything that brings into question the integrity of the system <br/>is likely to reduce that future value so they have a long term self <br/>interest to keep up the impression of integrity. As BitCoin becomes <br/>more establish this incentive will decrease.<br/><br/>On the other hand, non mining nodes have no incentive to replace by <br/>fee. The continued increased capital costs of mining would likely <br/>increase the proportion of non mining nodes typically run by those with <br/>an incentive to assure integrity of the network such as merchants. But <br/>increasing transaction volume is likely to increase node costs which <br/>would push out non mining nodes with lower incentive more than mining <br/>nodes. Accordingly increasing block size would have a tendency to <br/>reduce the effectiveness of double spend notification. The primary <br/>point is there are multiple counteracting forces that make predicting <br/>the future effectiveness of double spend notification uncertain.<br/><br/>I don't believe this necessary warrants conceding that we can not <br/>provide any protection from non trusted 0 confirmations transaction as a <br/>replace by fee implementation would do. But it would still be important <br/>to work towards more robust solutions notably various forms of 3rd party <br/>trust. This could be tamper resistant devices trusted to not duplicate <br/>spends, 3rd party certificates with proof the transaction was spent by <br/>the holder of the certificate or multi signature transactions on the <br/>block chain that must be signed by a trusted 3rd party to spend. I <br/>would expect it would take significantly longer for the companies and <br/>technologies to be built to implement this on a wide scale than adding <br/>double spend proof messages to the current implementation. In addition, <br/>there will likely always be some use cases where a 3rd party <br/>(centralization) is not viable.<br/><br/>Should a BIP and pull request implementing a double spend notification <br/>as described be accepted?<br/><br/>- Quinn
2023-06-07T15:02:14Z