Author: Peter Todd 2015-07-18 16:50:24
Published on: 2015-07-18T16:50:24+00:00
In this email thread, Mark Friedenbach explains that there is no deployment timeline for BIP62 due to a soft-fork logjam. However, he clarifies that the Bitcoin development team has the capability to push out more than one soft-fork upgrade signaling at a time, but it is not considered a vote because if miners decide not to upgrade, there is no easy way to recover. Friedenbach co-authored nVersion bits mechanism with Pieter Wuille and Gregory Maxwell which is closer to a vote because failed soft-forks have a clear and non-coercive outcome. For instance, if BIP65 had been accepted into v0.11.0, miners who had upgraded to v0.10.x/0.9.5 would have been signaling that they supported BIP66, while miners running v0.11.0 would be signaling support for both BIP66 and BIP65. As adoption increased, BIP66 would trigger first, followed by BIP65. However, if miners decided they didn't like BIP66 but wanted to implement BIP65, there would be no mechanism to do that, and it could potentially hard-fork Bitcoin in the process of stopping the failed soft-fork.
Updated on: 2023-05-23T18:31:30.583200+00:00