Author: Matt Corallo 2017-05-26 22:44:44
Published on: 2017-05-26T22:44:44+00:00
The process of designing, coding, and testing a new hard fork in six months, let alone deploying it simultaneously with segwit, is believed to be a joke. However, further research into hard fork design may help. It would not be feasible to schedule any HF until one can be completely sure BIP141 is active due to activation/p2p codepath complexity. Mandatory signaling is the only way to lock in segwit with less than 95% hash power without a full redeployment, but it will still take months of development and testing. The fastest safe path forward would be to use BIP91 or similar to activate BIP141 via mandatory signaling as soon as possible. Then, develop HF code based on the assumption that BIP141 is active so that you only have to test the BIP141->HF upgrade/activation code path. Finally, deploy HF after BIP141 lock-in.Rolling out some features together makes sense, but a HF has required features that would conflict with features in the segwit rollout causing major complexity/testing issues. By doing a staged rollout of segwit and then a HF, we get a single testable upgrade path. Previous soft forks required similar if not more development time, not counting deployment and activation time. If the community is unable to form consensus around segwit alone for political reasons, further research into hard fork design may help, but even forks tied together would nearly certainly need to activate months apart.
Updated on: 2023-05-20T02:24:50.761031+00:00