Author: Gregory Maxwell 2015-09-29 18:31:28
Published on: 2015-09-29T18:31:28+00:00
In a recent discussion on bitcoin-dev, Mike Hearn expressed his objection to using a soft fork for deploying BIP65. He pointed out that it would result in the same problems as all the other soft forks and SPV wallets will become less reliable during the rollout period. He suggested that making it a hard fork would be a better option. However, one of the participants in the discussion was surprised by this response and noted that BIP65 is a year old now and has had extensive discussion with no controversy exposed during its entire lifetime.The participant also added that miners are already enforcing the validity of CLTV, which is indistinguishable on the visible behavior. Additionally, he noted that the change in system rules proposed by BitcoinXT's 101 proposal is similarly "invisible" to existing SPV wallets. The participant believed that it would be reasonable to change BIP101 to be a real hard fork but acknowledged that soft forks and hard forks are not the same thing, technically or politically.The particular mechanism used in the proposal as-is has been used many times before and has considerable experience with it. The behavior is not truly invisible to non-upgraded participants as it is visible through the block version changing. Bitcoin Core responds by issuing a warning that the version is obsolete and requires upgrading. Users of the software are free to decide to take whatever policy action they wish to take, delay accepting transactions, patching software, etc. Although the participant believed that the versionbits mechanism will be superior, he noted that its deployment has been complicated by BitcoinXT deploying an incomplete approximation of it. He concluded that Versionbits' primary advantage is related to having multiple concurrent proposals in flight, which will be good to have, but isn't itself a reason not to pull a proposal up ahead of versionbits.
Updated on: 2023-05-19T22:01:31.852476+00:00