Published on: 2015-10-13T00:08:49+00:00
The email thread discusses the potential risks associated with a soft fork in the Bitcoin network. The effectiveness of an attack depends on the percentage of hash power that did not upgrade. Even with just 5% hash power and ~30% of nodes running the old version, a "damaging soft fork" still poses a high risk to someone receiving payments via an SPV client. The original emailer questions the significance of the risks posed by such an attack, as executing a double spend maliciously would be difficult due to the unpredictability of when a block would occur.There is a proposal to introduce a new flag in Core, called --scriptchecks=[all,standardonly,none], which would prioritize correctness by default and allow nodes to opt into pseudo-SPV behavior of a soft fork if desired. The advantages and disadvantages of hard forks and soft forks are discussed, with some arguing for a hard fork to avoid problems with SPV wallets during the rollout period. However, others believe that soft forks have a demonstrated track record of delivering new features with minimal problems.The deployment of BIP65 CHECKLOCKTIMEVERIFY in Bitcoin is also discussed. Mike Hearn expresses concerns about using a soft fork to implement this feature, suggesting that it should be a hard fork instead. Other participants emphasize the need for consensus before making any decisions. The conversation delves into the issues of miner adoption, the vulnerability of a soft fork, and the potential for double-spending attacks.The discussion highlights the complexities and trade-offs involved in implementing changes to the Bitcoin network, particularly in the context of soft forks and hard forks. The importance of upgrading full nodes and the risks associated with not doing so are emphasized. The conversations also touch on topics such as SPV wallets, the implementation of P2SH, and the advantages of communication and mitigation strategies.Overall, the discussions provide insights into different perspectives on the deployment of BIP65 CHECKLOCKTIMEVERIFY, the advantages and risks of soft forks versus hard forks, and the challenges faced in implementing changes in Bitcoin software. The email exchanges between Bitcoin developers touch on various topics related to upgrading Bitcoin software, the concept of consensus, and potential risks and solutions for SPV clients during soft forks. In addition, there are references to other email exchanges discussing topics such as the definition of a "working" full node, the risks and benefits of soft forks and hard forks, and the implications for SPV clients. The discussions highlight the need for refinement and adjustment of proposed changes, as well as the importance of developer consensus in the Bitcoin community.In a bitcoin-dev mailing list, Peter Todd expressed concerns about the delay in deploying CheckLockTimeVerify (CLTV) due to waiting for nVersion bits and CHECKSEQUENCEVERIFY. He suggested rolling out CLTV+CSV (CheckSequenceVerify) together by the 0.12 release if possible. However, if CSV is not ready, they would proceed with CLTV alone. The related pull requests for CSV are now ready for final review, and if that happens soon, CLTV+CSV would be rolled out together before 0.12.On September 27th, 2015, in an email exchange, a user named jl2012 expressed support for the deployment of BIP65 (CLTV) and asked about the possibility of backporting it to version 0.9. Peter Todd stated that he could backport it to 0.9 but wanted to hear from miners as to why they were still on v0.9.x.There was agreement with Peter's points, stating that BIP65 should be deployed immediately instead of waiting for the 0.12 schedule, as it would take too long. Some mining pools hinted at adopting BitcoinXT by the end of 2015, and earlier deployment of BIP65 would provide them with a patched version ready when they switch. Gavin also agreed to support BIP65 in XT. There was a question about backporting BIP65 to 0.9, similar to what happened during the deployment of BIP66.Peter Todd argued that CLTV should be deployed on v0.10.3 and IsSuperMajority() soft-fork on v0.11.1. He highlighted the benefits of CLTV for payment channels, making implementations simpler and more secure by removing malleability vulnerability. Todd emphasized that the implementation of the opcode has been peer-reviewed and thoroughly tested, and the deployment code has been copied from the successful BIP66. He believed that the risk of CLTV failing to get miner adoption is low and waiting for nVersion bits and CHECKSEQUENCEVERIFY would significantly delay deployment.Overall, the emails discuss various perspectives on the addition of CLTV to the Bitcoin protocol, the use of soft forks versus hard forks, and the concerns and solutions related to SPV wallets and node preparation for the upcoming soft fork.
Updated on: 2023-08-01T16:21:21.415012+00:00