Author: Billy Tetrud 2022-01-18 16:00:06
Published on: 2022-01-18T16:00:06+00:00
The discussion on the Bitcoin-dev mailing list focuses on the implementation of soft forks, which are changes to the Bitcoin protocol that are backwards compatible. The community agrees that the risks of soft forks should be minimized, and there should be a minimum time between a soft fork implementation finalization and determining community consensus. This gives everyone enough time to look at it and raise objections if needed. The suggested minimum time between soft forks is around five years, and if there isn't sufficient consensus or people bring up objections, it should further delay the deployment.The email thread also discusses compromise bundles, which incentivize some people to accept something they don't want to receive something they do want. However, consensus change proposals should go through a community vetting process that determines widespread supermajority support before being merged into the code. They should have a final implementation that has been tested at all levels before merging it to master, and only then should it potentially be bundled.One solution proposed to solve the problem of miners voting during signaling is to be more direct about how decisions are made. Users could sign a petition saying they support a particular consensus change, with actual signatures by keys connected to UTXOs so we can see the economic weight of the petition. This could make it very clear how much of the Bitcoin world supports a particular change without needing to put anything extra on-chain.The discussion also highlights the difference between soft forks, lowering the block subsidy, and changing the semantics of an OP_NOP. Soft fork features can be tested thoroughly on testnet, signet, custom signets, sidechains, etc., on a standalone basis and a bundled basis. Any consensus changes should not be bundled, especially when it comes to activation parameters. Bundling them will inevitably degenerate into political horse trading, and everyone will be worse off for it.Consensus changes should be sequenced so that people can decide which sides of the forks they want to follow. The community must agree on the parameters of each fork, and if one of the new rules is contentious, the break can happen cleanly. It is quite likely less damaging to consensus to have frequent but strictly sequenced soft forks. Finally, putting too many features together in one shot can make things harder to debug in production if something very unexpected happens, which is a basic principle of software engineering.Overall, the discussion emphasizes that security critical software like the Bitcoin protocol requires careful consideration and testing before implementation to avoid significant issues. Decentralized security critical consensus changes cannot be treated like any other software project. Bugs can easily be reverted in a new social media app, but a consensus change in the Bitcoin protocol requires a hard fork, which involves central coordination and speed of deployment that is generally avoided.
Updated on: 2023-06-15T02:38:07.042392+00:00