Published on: 2016-10-17T13:13:25+00:00
On the bitcoin-dev mailing list, there was a discussion between Matt Corallo and Tom Zander regarding flexible transactions (FT) and their safety compared to the current codebase. Corallo expressed concerns about the security holes in the current codebase and questioned why Zander considered FT to be safer. Zander welcomed feedback on his code and explained that FT is simpler and changes fewer concepts than SegWit. Corallo provided an example of exploitable memory accesses in Zander's code if FT were turned on, but Zander claimed that his unit test did not encounter those issues. He asked Corallo to report any specific problems to him offline or on Github. Corallo also mentioned that any proposed alternative to the current codebase should not take too long to complete with a large team of qualified developers. Zander encouraged Corallo to explore the rest of the code to see its simplicity.Tom Zander responded to Matt Corallo's criticisms of Bitcoin's flexible transactions (FT), stating that FT is safer due to only changing two concepts compared to SegWit's ten. Zander welcomed feedback on his code and noted that unit tests did not encounter any exploitable issues. Valgrind reported similar issues in other parts of the code, such as secp256k and CKey::MakeNewKey. Zander encouraged Corallo to examine the rest of the code to understand its straightforward and simple approach.The current codebase of Bitcoin Classic was criticized for its security holes, including out-of-bound and exploitable memory accesses in the deserialize method. While flexible transactions have been called "safer", there is still a need for fixes in the community. A proposed alternative would take at least a year to complete with a large team of developers. There have been objections to the implementation of SegWit, and some wallets are taking a cautious approach. The majority of wallets are not ready to support SegWit, and it would take time for them to roll out updates. Flexible Transactions may be a safer alternative, but its effectiveness can only be determined once it is implemented. To ensure a safe upgrade, it is recommended that users wait at least two months after the lock-in of SegWit before upgrading.In another email conversation, Melvin Carvalho suggested separating "rule change" fixes and "bug fix" releases for Bitcoin to address client default policies. Luke-Jr pointed out the consensus nature of Bitcoin, stating that clients with different rules cannot run on the same network. Carvalho emphasized the significance of default policies on user behavior and cited research showing that most users tend to accept defaults. Luke-Jr advised using backports for bug fixes and rule changes without new features or policy default changes. However, he stressed that these are short-term solutions and users should aim to achieve the desired behavior from the current release. If that is not possible, users should report a bug explaining the capabilities of the older version.Zooko Wilcox-O'Hearn initiated a discussion on "rule changes" in Bitcoin, seeking clarification on what constitutes a rule change and how to suggest changes for future merges or hardforks. He proposed forking bitcoin.git on Github as a possible solution and separating "rule change" fixes and "bug fix" releases. The topic of rule changes was also discussed in an email exchange between Zooko and jgarzik, with jgarzik expressing disinterest in rule changes with economic impact. Zooko highlighted the importance of these rules being unchangeable for Bitcoin's stability. The conversation also included a link to the Hardfork Wishlist on the Bitcoin Wiki.Overall, these discussions revolved around the safety and security of Bitcoin's codebase, the potential risks and benefits of flexible transactions, the need for fixes and upgrades, and the consideration of rule changes in the Bitcoin ecosystem.
Updated on: 2023-08-01T05:01:33.099019+00:00