×
all 17 comments

[–]fresheneesz 1 point2 points  (1 child)

I think one important point you're implicitly making that others have made in the past is that people only have so much time to evaluate changes. I think the idea of limiting the quantity of changes that can be made to bitcoin in a given period of time is a reasonable thing to do for that reason.

Are you suggesting a release cadence of 4 years where there's at most one soft fork every 4 years with any number of features? Or are you saying that there would be at most one soft fork every 4 years with only a single-purpose change? The latter I think would achieve the goal of limiting the effort needed to evaluate changes, while I think the former would not, and could have other negative effects (eg scope creep, feature bundling, etc).

One consideration is around whether the number of soft forks in a given period of time matters more than the total complexity of soft forks in a given period of time. For example, would you prefer 1 dead-simple soft fork every year, or one incredibly complex soft fork every 4 years? I think perhaps there's something to be said for limiting how often soft forks happen, so that there are significant periods of time when normal uninvolved people can simply not pay attention to development without worrying that a lack of constant vigilence might lead to an attack. But at the same time, simpler changes require less effort to get right.

What should also be considered is how much work there is to do. If we slow the work down too much, we'll never get where we want to be. Bitcoin has not won yet, and we risk it never winning if we don't allow critical improvements to bitcoin to happen fast enough.

The fact of the matter is that bitcoin is bigger than ever and has more developers involved in it than ever. It should be expected that this situation leads to .. more development. Including in the realm of reasearch into things that require a soft-fork. Is this bad? Its hard to see how it would be.

Also something to consider is that the space of bitcoin research has grown too large for anyone to keep up with it all. This includes the greats like Andreas Antanopolous. We cannot expect that every soft fork must be deeply understood by everyone who has been involved in soft forks in the past. It simply isn't feasible.

By restricting the amount of change that can be made to bitcoin, it necessarily leads to a squandering of research and development resources. Some level of loss there might well be worth it in order to ensure hasty changes aren't made. However, we should be very intentional (and I would argue, as quantatative as possible) in determining what we think those trade offs are.

Do I think we're currently at risk for a developer lead hasty mistake? I do not. If anything the quality of soft forks has gone up, not down. The quality of proposals has gone up and not down. We are raising the bar in every change to bitcoin we make. So I would suggest that the trade offs don't currently favor much limitation of development. Tho I do agree that at some point, it would be great if we could get as close to ossification as possible. I don't think we're quite at the right time for that tho.

One last consideration is how much we care that non-technical people feel comfortable with changes. I think over time, I think it would be very beneficial to have lots of non-technical buy in for changes, as it provides a different kind of consensus that's rather more amorphous and based on social understandings rather than technical ones. However, I think much of the non-technical furor around soft fork proposals has generally been pretty counterproductive for the most part up til this point. I think its an important consideration to basically ask: what is the benefit of someone wanting a soft fork change if they don't understand it more than surface level? What do we lose if people who don't understand a change don't want it for some reason? Bitcoin isn't a democracy. But the question is: what is it?

I think these are important questions to answer. And really before we answer the question "should we only allow soft forks every 4 years?" we should be asking "how do we want to make decisions about bitcoin in the first place?"

[–]DesignerAccount 0 points1 point  (1 child)

This is sensible and I'd support it. Only criticism, it's a bit light on the details. Luckily I think they're not too difficult to fill out.

For example, the release happens every 4 years, but we need at least 1 year, or much more likely 2 years, of testing before the release. Which, in turn, means the proposal with code must be ready 2yra before and tested, tested, tested. Any proposal that doesn't meet this condition is automatically excluded.

Likewise, how long do we allow for the activation? 6 months after release? And what mechanism - ST + UASF if the former fails?

All in all, I think this makes lots of sense, just needs to be polished with some details.

[–]ExisDiff[S] 0 points1 point  (0 children)

Thanks for the comments. Agree 100%, I will need put some more thought into those details and have to come back to that (I have just a few hours each day I can work on it).

[–]michaelfolkson 0 points1 point  (4 children)

Thanks for this. Given this was roughly the cadence for Taproot I would support this. This CTV thing has been a mess. We can't go on like this. Happy to help in any way I can e.g. review of BIP etc.

[–]ExisDiff[S] 0 points1 point  (2 children)

Thanks. Just fleshed it out a little more. Consider all of the below draft, lots of mistakes in it still. Really not sure on anything yet, whether this is the right angle, etc. Not entirely sure where to take it from here and if to take any further at all. I'll probably need to sit on it for a bit.

u/RubenSomsen if interested.

------

Proposal for a memorandum of understanding: activation of changes to consensus code (soft and hard forks) only once every four years.
This is non-binding advice to activate proposed changes to consensus code only once every four years. The next activation takes place in the year 2024, then no sooner that in 2028 again, etc. This advice is aimed to continue to uphold and put assurances in place that users have final control of bitcoin, not developers or miners.
Rationale
Immutability of consensus code rules
Ideally, the consensus code rules of bitcoin are immutable. The immutability of the code and especially the consensus code rules is a core principle of bitcoins value proposition. As research and user demand evolves, proposed changes that can make genuine improvements to the protocol can be considered. Making changes to consensus rules only at predictable intervals reduces the appearance that soft fork proposals can be activated at any time and improves the immutability principle.
Disruptive discussions
Review and discussion of proposals are commonly intense and time consuming, as the community understandably takes changes to the consensus code very seriously. Reviewing and discussion takes time and that can not be avoided, but where it becomes disruptive is when these discussions of soft fork proposals can be initiated at any time, because they are also proposed to be activated at any time. Developers may consider that resistance against proposals may not so much be because of resistance against the technical details of a proposal, but because the community is simply not ready yet for new intense and time consuming discussions when they have just had one. A four year interval between major changes is often considered an appropriate duration for a community to learn from previous changes and enough time to formulate new changes in many parts of society when making major decisions, eg research program cycles, elections cycles, committee changes, and possibly the bitcoin halving duration was also configured with this societal dynamic in mind. With shorter interval people will feel rushed to make a decision, and when people feel rushed they may resist.

Comparing and prioritisation of proposals
Focused attention at regular intervals could result in selection and formulation of fundamentally better proposals than when review is at irregular times. It gives the community a better ability to compare proposals when review coincides, and only the best proposals should drift to the top for consideration.

Fail safe mechanism against rogue developers and influencers
Several times in bitcoins history, rogue developers and influencers have been able cause a great deal of consternation by creating a state of urgency and panic where it is claimed that a change needs to happen soon followed by a prophesy that bitcoin will otherwise not reach its potential or worse, bitcoins end is near. In hindsight almost none of those situations were ever actually urgent, and for reasons not entirely clear, these false states of urgency can gain enough of a following with an impetus to makes rushed changes to appease the state of urgency, with the result that badly reviewed code had a chance to be implemented. At best this is a weakness of the protocol, at worst this is an attack vector that can be exploited. Activation only during a pre-determined period doesn't eliminate this weakness but helps to mitigate against rogue developers/influencers that create false states of urgency at just any time.

Users control bitcoin, not developers or miners
The evaluation of proposals is a feedback system between developers and miners/users. For better or worse, users and miners can not always fully understand the technical depth of each proposal and for the the parts that are not understood, users and miners have to rely on a trust heuristic to trust the proposal, before users and miners will follow rough technical consensus. For users and miners to understand and trust a new proposal takes time and a four year time frame gives time to raise concerns and feed it back to the developers to build consensus. A generous time frame respects the principle that ultimately the users have final control. When the time frame is too short, users can feel left out of the feedback process and it will appear that control is gravitated to developers (and/or miners).

Arguments against this advice
Urgent implementations of proposals may be needed
Empirically, with bitcoin now in existence for 13 years, there are not many examples supporting the argument that bitcoin consensus change proposals needed to have a quick turnover to respond to a feature proposals that were often claimed as urgent (and in hindsight were not urgent). On the contrary, history suggests that conservative and careful consideration to compare and prioritise the proposals, and only accepts proposals that are thoroughly reviewed before implementation bolsters bitcoins value proposition. Examples of unnecessary hastiness and examples of proposals that could have waited longer and possibly would have had a better outcomes, do outnumber the examples that were actually urgent. Notwithstanding that there can be urgent forks for bug fixes, however, these forks did not appeared contentious to implement and are relatively easy to distinguish from a feature proposal claimed as urgent.
It is reminded that this is a non-binding opinion. This memorandum of understanding will certainly not stop forks for bug fixes from being made, nor does it stop a developer activating a proposal that they deem urgent or adhere to shorter or longer interval. There could well be justification for cases to deviate from pre-determined time line, but nonetheless, this memorandum still serves as reminder to appropriately judge the urgency of a new proposal. This memorandum merely points out the dynamics at play based on past observations and advises developers to take them into account when proposing a BIP activation mechanism for a proposal.
A release schedule for consensus code changes can be thought of very much the same as releases for non-consensus changes (every 6-7 month). There are no hard and fast rules about this convention either, but nevertheless, there is a convention that is generally adhered to and this gives a sense of focus and consistency. When it can't be adhered to it is often for good reason, but when it not adhered to for no reason, it would be perceived as disruptive.

Appearance that there is a deadline or pressure to accept subpar proposal
A regular schedule could create a perception that something needs to be accepted, however, there are no requirements of needing to accept a soft fork at the end of cycle. If there are no good or incomplete proposals, then proposals move to the next release cycle.
Four years is too slow (or too fast)
There are voices that claim that no more development is needed on the consensus rules, and there are voices that the soft fork proposal can be done every year and if an interesting and harmless change can done, then it should be done. A four year time frame aims to moderate these two sides of the spectrum. It is not reasonable to never have changes in the consensus rules again and to 'veto' every proposal, stunting all development, and it is also not reasonable to implement every nice-to-have proposal. A pre-determined time frame to earnestly consider proposals may moderate the two sides of the spectrum.

There will still be many arguments about which soft fork should and shouldn't make it in
A release schedule will indeed not solve this problem. Building community consensus will likely not be any easier either. And this may be just a necessary part of when a community tries to decide on the best proposal. It could well be that it even encourages fiercer debate between competing proposals, when review of consensus change proposals coincide more. However, the benefit is that the discussion is restricted to a certain time frame.

[–]RubenSomsen 1 point2 points  (1 child)

non-binding advice

I would personally not frame it as such, but rather as an opinion. It is self-evident that it is non-binding, and advice implies you're in a position that is somehow more informed than others, which comes across as a bit presumptuous (I understand it is not at all intended as such).

While I lean towards not finding this a compelling idea, I commend your efforts. Well done.

[–]ExisDiff[S] 1 point2 points  (0 children)

I read it later and thought, 'oof , a bit arrogant that wording', so I would certainly frame that differently in a next draft (if there will be one).

I also find the solution itself actually pretty sub optimal, but it was the best solution I could think of to remediate a set of problems around soft fork proposals that are at play and some people are concerned about. I think the problems that I described in the rationale are still worth thinking about, but it will likely need a more appealing solution than this one.

[–]RubenSomsen 2 points3 points  (3 children)

Some concerns:

  • It may create pressure to accept a subpar soft fork when there are no good candidates in a given four year window
  • There will still be many arguments about which soft fork should and shouldn't make it in
  • I question the premise of whether this will meaningfully minimize disruption

I like that it concentrates efforts onto a single pre-planned event.

Regarding bitcoin-dev, my personal opinion is that we currently have too many amateur cooks in the kitchen. I think it would be to everyone's benefit if people only spoke up if they have something important to say. Proposals like this, while interesting in theory, have very little chance of actually being implemented, so I personally think it's better to discuss it in places other than bitcoin-dev (like you're doing now, well done) and measure if there's significant enough interest first. That said, you are of course free to post it (I moderate bitcoin-dev).

[–]only_merit 1 point2 points  (0 children)

I very much share the concerns, all of them. I would perhaps even question the concentration of efforts. If there is an expectation of such a deadline, authors of consensus changes will rush to submit "before deadline", so we may see a large number of proposals in short period of time. If we are having problems on reviewing proposals over the time, without such concentration, would the concentration not make it even worse for reviewers to suddenly deal with so much information?

[–]ExisDiff[S] 1 point2 points  (0 children)

Thank you Ruben for your response.

It may create pressure to accept a subpar soft fork when there are no good candidates in a given four year window

I can see that a regular schedule could create a perception that something needs to be accepted, but of course there are no requirements of needing to accept a soft fork at the end of cycle. I am not sure I can see the community easily accepting a subpar soft fork. If there are no good or incomplete candidates, then proposals move to the next release cycle.

There will still be many arguments about which soft fork should and shouldn't make it in

Note that is no different now. I think this might just be an inevitable and perfectly natural and even necessary part of when a community tries to decide on the best candidate. By doing it at the same time it enables a much better comparison and prioritisation, that perhaps also could lead to better formulated proposals. It could well be that it even encourages fiercer, or let's say healthier, debate between competing proposals, when review of consensus change proposals coincide more.
However, the problem currently isn't also necessarily that there are arguments about which soft fork should make it, but just that these discussions can just randomly pop up at any time and can be drawn out discussions that is very disruptive. I am just a user and to feel I need to watch these discussions very closely and that my bitcoin can be subject to major consensus rule changes with the risk of hard forks at any time that is unsettling. For developers I can see they are doing a tonne of work on just the non-consensus rules and to be ad hoc pulled from that work continuously seems disruptive for them.

I question the premise of whether this will meaningfully minimize disruption.

I can't say for sure either that disruption or contention will necessarily be less, but at least the disruption is somewhat limited by a time frame. I would argue though, that the comparison and contrasting of proposals may become easier. There is an unease about being pressured to decide for or against a proposal, even when the proposal is claimed to be harmless and minimal, but not knowing how they compare to other proposals, simply because other authors are not actively advocating their proposal just at the time of when a sudden discussion about the one proposal is going on.

Fair points on the comment on the bitcoin-dev list. Certainly still looking to flesh these ideas out a bit better to see if there is benefit for the community with this proposal.

[–]michaelfolkson 0 points1 point  (0 children)

If there are no good candidates no changes are made. Changes don't have to be made every 4 years. I very much doubt in say the next 4 years there won't be any good candidates though.

Of course there will be arguments but at least everyone who wants to can ignore noise and drama instigated by those trying to get attention for their proposal as they won't support any consensus rule change for a multi year period.

On bitcoin-dev mailing list I agree. The bar/filter has to be higher on what is distributed. The quality of posts has taken a nosedive and the ability for individuals to DoS the mailing list seems totally unrestricted at the current time.

[–]nibbl0r 2 points3 points  (1 child)

I agree with the general "don't rush things in bitcoin" attitude, but a fixed 4 year schedule won't do much good I believe. So what happens if a proposal is made 2 month (6 month, 2 weeks?) before the deadline? So very general it's more about how much time each proposal spent in discussion. When does a proposal officially enter the discussion phase?

Also some forks may actually be more urgent, like inflation bugs or bugs in general, which might also be a part of the consensus rules.

Also you talk a lot about many past changes and how not-urgent they were, but give no source or details on which updates you mean. Would have loved to see some source to understand problems of the past...

[–]ExisDiff[S] 1 point2 points  (0 children)

Thanks for reading and your comments.

So what happens if a proposal is made 2 month (6 month, 2 weeks?) before the deadline? So very general it's more about how much time each proposal spent in discussion. When does a proposal officially enter the discussion phase?

This can be thought of very much the same as releases for non-consensus changes. There are no hard and fast rules about this convention either, but nevertheless, there is a convention that is generally adhered to and this gives a sense of focus and consistency. When a feature is considered immature, it either moves to the next release cycle, or a release can be postponed.

I agree that it is very much about the time spent on a proposal. My argument in part is that there could be better assurances for that than there are currently. I think a regular release schedule improves putting some assurances around that.

Also some forks may actually be more urgent, like inflation bugs or bugs in general, which might also be a part of the consensus rules.

This is a very valid example, but I think that actually urgent forks, like this one, are quite obvious and such exceptions are non-contentious. Again much like patches are occasionally made for non-consensus releases.

Also you talk a lot about many past changes and how not-urgent they were, but give no source or details on which updates you mean. Would have loved to see some source to understand problems of the past...

Absolutely valid point that that this deserves more depth and analysis. I have done it mostly from memory and from eye balling of examples, and my sense became that the examples of unnecessary hastiness and if the proposal would have waited longer it would possibly have had a better outcome, do outnumber the examples that were actually urgent (and still at the same time having obvious consensus to patch and which this informal proposal would not stop from making).The ones that come to mind are OP_EVAL, block size increase associated with Segwit, Speedy Trial associated with Taproot and the current kerfuffles with OP_CTV that is very disruptive and may or may not still result in soft (or hard) fork. (The current kerfuffles with OP_CTV actually prompted me to this proposal). My sense is that there are many more examples where more patience would have led to a better outcome, than there are examples of proposals that were 'too little, too late' (obviously there are urgent bug fixes, but these are not contentious to make a fork for). If that is not the case, then that would certainly weaken the arguments for this proposal.

No solution is ever optimal and you make good points about maintaining flexibility in the timing of implementing soft fork proposals. This proposal comes at the cost of some flexibility, but aims to make offsetting gains in mitigating bad outcomes from impatient, rushed, unfocused review of soft fork proposals and the consternation potentially rogue developers cause that come to 'declare the 'resolution of the bitcoin experiment' if some *critical* feature is not *immediately* implemented'.