Author: Peter R 2015-10-05 17:33:55
Published on: 2015-10-05T17:33:55+00:00
Peter has expressed his agreement with Mike's opinion that CLTV (CheckLockTimeVerify) should be done through a hard fork instead of a soft fork. He believes that controversial changes to the consensus rules should not happen, and if Core Dev thinks the same, then CLTV should not happen in its current form. Peter also agrees with Mike that Core's requirement for unanimous consensus results in development gridlock and should be revisited. He suggests that instead of unanimity, the longest chain composed of valid transactions should be considered the correct chain. Peter proposes that multiple forkwise-compatible implementations of the protocol should be fostered to return power to the Bitcoin community. These implementations could have their governance model and design objectives and use techniques like BIP101's 750/1000 signaling mechanism to activate changes desired by the community. If a supermajority does not support the change, it won't be activated. He suggests visualizing one possibility of how multiple protocol implementations might emerge over time. Nodes would express their acceptance of a block by mining on top of it, and consensus would be determined by the code chosen to run.Peter's idea of decentralizing development and supporting multiple forkwise-compatible implementations of the protocol is a worthwhile goal that will make Bitcoin more robust and responsive to the market's will.
Updated on: 2023-06-10T23:52:12.639874+00:00