Author: Nick ODell 2015-07-18 19:48:32
Published on: 2015-07-18T19:48:32+00:00
The Block validity section of BIP62 references version 3 blocks, which is already used by the BIP66 soft fork. However, this issue will be fixed. There is no deployment timeline for BIP62 as it is currently a low priority in the soft-fork logjam. The uncontroversial aspects of BIP62 were hurriedly pushed out as BIP66 after an undisclosed vulnerability was discovered. BIP65: CHECKLOCKTIMEVERIFY has higher deployment priority than BIP62, and there is consensus on that. Although multiple soft forks can be upgraded signaling at a time, it is not considered a vote because if miners do not upgrade, there is no easy way to recover. Peter Todd co-authored a mechanism called nVersion bits that is closer to a vote because a failed soft fork has a clear and non-coercive outcome. If BIP65 had been accepted into v0.11.0, miners who had upgraded to v0.10.x/0.9.5 would have signaled that they supported BIP66 while miners running v0.11.0 would be signaling that they supported both BIP66 and BIP65. As adoption increased, BIP66 would trigger first, followed by BIP65. However, there would have been no mechanism to implement BIP65 if miners had decided they disliked BIP66 but wanted to implement BIP65. In such a case, there would likely have been a hard-fork in Bitcoin.
Updated on: 2023-05-23T18:32:04.872042+00:00