I’m all in for #1. That’s what we’ve been doing right? Y’all found a critical vulnerability before, and it didn’t fuck up the hard fork schedule, at least I don’t think so. Plus, we were due for a critical vulnerability, and we already found it, so we’re not due for another one of those in a long time, or maybe ever, hopefully never.
Also on a side note, when did successful hard forks become a flex? was that 2017? DAMN WE GOOD AT HARD FORKS.
We need to decide how to treat blocks with unknown header version,
and kernels with unknown features. Some soft-forking is possible by accepting either, but care must be taken that the latter is properly deserialized and that signatures are still verified as much as possible.
A critical vulnerability needs to be fixed one way or another, and if breaking consensus is the only way, then that clearly warrants a HF. In what way would it “not be possible to upgrade”?
I’d like to add one more option: Make Grin more softfork-ready. This isn’t foolproof, since it’s difficult to predict exactly what changes may be desired in the future. But there’s a few things we can do that will provide a decent bit of flexibility.
Making Grin mode softfork-ready is something that can be researched and proposed in parallel to this discussion. I think it would be important to understand what changes we would like to see there, regardless of the options above. Would you agree?
I’m all in for #1. That’s what we’ve been doing right? Y’all found a critical vulnerability before, and it didn’t fuck up the hard fork schedule, at least I don’t think so.
So if we go with option #1 as planned, and that vulnerability instead would had been discovered in 2021, there wouldn’t have been any scheduled soft forks to sneak the fix into. We would have needed to come up with a “community justification” for why a hard fork would be required, and hope there would be enough agreement for an upgrade. The RFC that proposed the fix was “enable faster sync”. Not sure that would have been a compelling enough of a use case for a hard fork on its own. And screaming “there’s a critical vulnerability!!” would have increased the likelihood of it being discovered and exploited before any fork.
Plus, we were due for a critical vulnerability, and we already found it, so we’re not due for another one of those in a long time, or maybe ever, hopefully never.
While I wish it worked this way, I’m not sure does. 
A critical vulnerability needs to be fixed one way or another, and if breaking consensus is the only way, then that clearly warrants a HF. In what way would it “not be possible to upgrade”?
See my reply to Grumpy above. I guess I was being imprecise - it would always be possible to upgrade, you release a binary and you run the upgraded software, and you have upgraded. The problem would be getting the rest of the network to upgrade with you.
Every 4 years counting down from launch (a part from the 4 first ones).
Like the Bitcoin halvings, and Olympic games
I would like to throw out option 4, inspired by the original PoW phaseout schedule.
Not saying that I’m in favor of this, but this schedule should appeal more to those who’d like to see Grin become increasingly consensus-immutable than proposals 2 and 3. Note the large 2-year gap after the final pre-planned HF4.
Interesting!
@Kurt & @tromp - both your proposals, they would run indefinitely? or is there some cap at some point?
That is an uncapped range to be sure…
Added proposal #4 & #5
I think #1 shouldn’t be limited to emergency HF and should be opened to significant major improvements that would require a HF. Obviously it would require its own schedule planning.
Would you agree?
Not entirely. Whether it’s a separate option or not, it should be part of this discussion since it would impact which option we choose. If we’re going to take the stance that softforks are hacks, and hardforks should be used when possible, then we’ll want to plan for more frequent hardforks. If instead we decide they’re a useful way to apply backward-compatible updates, we may choose to try avoiding hardforks at all costs.
I would suggest an yearly review of the actual situation and if no emergency HF is needed (can be shorter time span ) , stick to the #4 .
We need some real world experience so 4 years should be enough time to see how GRIN is adapting to the needs of users.
So our stance on soft forks may instruct our stance on scheduled hard forks. Thanks for clarifying, that now makes sense to me.
I’ve added a “soft fork” discussion point to Tuesday’s dev meeting to see if we can get some clarity / action points from that. Please join if you can!
In the meanwhile, how could the matter of soft-forks best be reflected in the table above? Should it be its own option? If so what would the contents of each cell be? Should it be a column? It’s own section? Something else?
Maybe just add it as a consideration to #1 & #5?
Cool - updated, let me know if it needs further clarification.
I like #5, with possibly some added possibility for softforks. However, in the end I trust the core team to evaluate the needs for a hard fork. So if after 4 years it is deemed desirable to have still more yearly hardforks and good arguments are provided, sure, go ahead with #1. In the end I do think it is more important to be flexible and realistic than to set these rules in stone (stone tablets can always be broken 
).
Is it accurate to call this “increasingly immutable”? The space between HFs increases but its not really any less mutable. I’m not sure that a stable period of 8 years followed by a HF is really any more immutable than a HF every 12 months?
Edit: Not trying to pick holes in this - just trying to wrap my head around what “immutable” looks like, short of zero HFs.
By the time it exceeds a lifetime, most people will consider it immutable…
They might only be used to remove technical debt acquired in intervening upgrades and soft forks.