On the security of softforks [combined summary]

• On the security of softforks jl2012 2015-12-20 19:16:29+00:00
• On the security of softforks Rusty Russell 2015-12-20 04:14:25+00:00
• On the security of softforks Andrew 2015-12-19 17:46:02+00:00
• On the security of softforks Bryan Bishop 2015-12-19 15:48:09+00:00
• On the security of softforks Chris 2015-12-19 01:36:21+00:00
• On the security of softforks Peter Todd 2015-12-18 12:18:45+00:00
• On the security of softforks Anthony Towns 2015-12-18 06:12:23+00:00
• On the security of softforks Jorge Timón 2015-12-18 05:32:31+00:00
• On the security of softforks jl2012 2015-12-18 03:10:02+00:00
• On the security of softforks Eric Lombrozo 2015-12-18 03:02:36+00:00
• On the security of softforks Jonathan Toomim 2015-12-18 02:47:14+00:00
• On the security of softforks Pieter Wuille 2015-12-18 02:30:38+00:00

Published on: 2015-12-20T19:16:29+00:00

Summary:

In a discussion on the Bitcoin developers' forum, concerns were raised about the risk of old full node wallets accepting invalid transactions according to new rules. It was argued that this risk is not significant as the receiver wallet selects what address/script to accept coins on and will upgrade to the new rules before creating an address dependent on the softfork's features. However, a scenario was presented where Mallory defrauds Bob with an invalid SegWit transaction, exploiting the fact that Bob's wallet would be looking for a specific scriptSig. It was concluded that waiting for confirmations can mitigate this issue.The discussion also touched upon the topic of misinformation and lies being circulated regarding consensus rule changes. It was suggested that such discussions should be written up as BIPs (Bitcoin Improvement Proposals) to address the misinformation. The content of the discussed BIP was not mentioned.Another discussion highlighted the potential risks associated with non-upgraded nodes accepting invalid confirmations in the case of a consensus rule change. It was noted that if a large majority of hashing power supports the new rule, the number of invalid confirmations seen by non-upgraded nodes would be minimal. However, it was emphasized that caution should be exercised when dealing with low confirmation counts and that upgrading software regularly is necessary for security.A hypothetical scenario involving Mallory defrauding Bob with an invalid SegWit transaction was discussed, emphasizing the vulnerabilities of non-upgraded nodes. The importance of upgrading mining nodes and the risks associated with unconfirmed transactions were also highlighted.The author questioned the distinction between softforks and hardforks, suggesting that softforks should have a minimum median time deployment day rather than relying on header.nTime. The discussion also addressed potential fraud scenarios involving SegWit transactions, including one where Mallory defrauds Bob. It was mentioned that 0-conf and 1-conf transactions are not safe and that the scenario described is a variation of the Finney attack.The security of softforks in Bitcoin was a central theme throughout the discussions. Different failure modes and associated risks were analyzed, highlighting the potential vulnerabilities and advantages of soft forks. The importance of full node validation, upgrading software regularly, and caution with unconfirmed transactions were emphasized.

Updated on: 2023-08-01T17:11:58.682448+00:00