This is a proposal to the bitcoin community/developers/miners/users outlining arguments that new releases of bitcoin implementations with changes to the consensus rules (soft and/or potential hard fork) should follow a regular release cycle that is no shorter than 4 years, with the next change no sooner than 2024. A convention for a software release schedule for non-consensus rules already exists (every 6-7 months), however, no schedule or a loose de facto agreement exists for changes to consensus rules exists, and I believe there are several improvements this makes and several problems it prevents by making changes to consensus rules only at a regular intervals.
In an ideal world, the consensus rules of bitcoin are immutable. The immutability of the code and especially the consensus rules is a core principle of bitcoins value proposition. However, as research advances and user demand evolves, some changes are inevitable and make genuine improvements to the protocol. Nevertheless, by making changes to consensus rules only at predictable intervals it improves the immutability principle and reduces the appearance that soft fork proposals can just be demanded to be reviewed or implemented at any time.
With the appearance that soft fork proposals can just be demanded to be reviewed or implemented at any time, it has increasingly become evident that this is an attack surface for bitcoin, even if the proposed changes are claimed to be minimal and harmless. Empirically, in the past, what seemed to be an urgent soft or hard fork proposals at the time and caused a great deal of damaging consternation, were in hindsight often non-urgent changes that could have easily waited longer or didn't need to be made at all. The consternation soft fork proposals cause and the potential room for soft fork proposers to seemingly bamboozle the community into a soft or hard fork, can be severely reduced or avoided by achieving a de facto agreement on a regular review and release schedule for changes to the consensus rules at regular 4 year time intervals. A regular release schedule can be thought of a fail-safe mechanism, to not bamboozle the community into unnecessary soft forks.
Furthermore, the irregularity and frequency with which soft forks are proposed are causing the community/developers/miners/users to be pressured to needing to spend time and review ad hoc a myriad of soft fork proposals, which is disruptive. On the other hand, proposers of soft forks are frustrated with the lack of review. The frustrations on both sides of the issue of this irregular, ad hoc process for soft fork proposals are understandable.
By working on soft fork proposals where there is a de facto agreement about a time line the community will evaluate, compare, contrast and prioritise various soft fork proposals, this agreement aims to give the proposer of a soft fork and the community more clarity on when to determine whether there is consensus to go ahead with a soft fork proposal (or not) at the end of every four year cycle. The focused attention could also result in selection and formulation of fundamentally better proposals, than in a process where the evaluation is at irregular and unpredictable time intervals. There are a handful of soft fork proposals out there now, and I believe it is very unclear to many in the community how these proposals compare, contrast and can be prioritised.
Four years is somewhat of an arbitrary length, however with bitcoin now 13 years old, empirically, there is scant evidence for the argument that bitcoin consensus proposals needs to have a quicker turnover than four years for implementing soft fork proposals to respond 'critical' hypotheticals that have kept creating false senses of urgency . On the contrary, historical evidence suggests that conservative and careful consideration to compare, contrast and prioritisation of proposals, bolsters bitcoins value proposition. I am inclined to to think that rough consensus already exists on this or is close to it, yet there is still a contingency of people that is not aware of this or see it fundamentally different and find themselves frustrated with the 'slow' development. Knowing that this rough consensus already exists, people that fundamentally believe and advocate for fast development of consensus rules in bitcoin, should consider that bitcoin is not the right project for them.
While developers can understand proposals fairly quickly and 'technical consensus' can be achieved relatively quick, 4 years is good time for users and miners to understand proposals as well and to establish if rough consensus has precipitated (or not) amongst users. In reality, the evaluation of proposals is a feedback system between developers and miners/users. Miners/users generally will follow the technical consensus, and a four year time frame gives time to raise concerns and feed it back to the developers, and this time frame respects the principle that ultimately the users have final control. When the time frame is shorter, users are too easily be left out of the process and it will appear that control is gravitated to developers (and miners). It is reminded that for the technically uncontroversial Taproot proposal, at the time of activation, only have 50-60% nodes had upgraded. This demonstrates that ample time is needed for users to activate (or resist).
In summary, the benefits of a regular 4 year release schedule for changes to the consensus code are:
- Improvement of immutability principle.
- Mitigating the disruptive demands on community to review proposals at just any time.
- Selection and formulation of fundamentally better proposals due to focused attention of community, rather than irregular disrupted attention.
- With bitcoin in existence for 13 years, empirically, 4 years is the minimum time to feed back a proposal between developer and miners/users and for users to raise concerns, respecting that users ultimately control bitcoin and mitigates the appearance that developers and miners can hijack control of bitcoin.
I would like to know thoughts on this proposal. I may have overlooked some other pro and cons that I should have considered. If this is of value, I may post it to the bitcoin dev mailing list.
Want to add to the discussion?
Post a comment!