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.
3 Likes
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.
1 Like
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.
1 Like
My opinion, as of right now, is that hardforks should be seen as extreme measures, as they are in Bitcoin. I’m not a fan of having them standardized. Breaking consensus should be seen as a doomsday measure.
Nevertheless, as david mentioned, softforks and hardforks must be discussed together. It’s practically the same discussion.
If there’s any community member who has a really good grasp of Bitcoin’s history regarding this subject of forks, please do join the dev meeting or comment here. There’s much to know and learn, and many conclusions to draw.
Anyway, why does the stance towards softforks lean negative currently? Was there already a discussion about it?
1 Like
How did you arrive to that conclusion?
Why do you write about hard forks if you can make soft forks?
I am against hard forks
please consider my opinion
Our stance towards soft-forks will significantly impact the ability to conduct upgrades without hard forks.
I figured this meant “our (negative) stance towards softforks will impede on our ability to upgrade without hardforking”.
Guess I was wrong.
1 Like
Consider your opinion considered.
Definitely want to take all opinions into consideration - is there a specific reason(s) why you prefer one over the other?
I think this is obvious hard fork is unacceptable it should only be done in critical situations.
If you can’t make a soft fork, then you should make the hard fork the first and last time, which will make the soft fork smoother.
You must strictly prescribe the rules for the soft fork and never return to the hard fork again.
It is easy to say “hard fork is unacceptable” but why exactly? Why one over the other?
The hard fork does not support older versions of wallets and cannot work with them all the time.
When you do a hard fork, people are required to update, or maybe I don’t want to update, and I don’t want to check your code and what you wrote there.
I want to sit on the old 2020 wallet until 2028
If you add + 1,000,000 coins to developers, my wallet will not support your left coins.
And I’m not going to check your new code, and I shouldn’t.
1 Like
IMO hard forks should be avoided at all costs. This is one of the things that Bitcoin got right. A Hardfork is like an attack on the protocol- If you keep forcing consensus changes then eventually enough people won’t agree and you’ll permanently split the chain. Soft forks cause the same issues, however, they are less intrusive since an upgrade is not mandatory.
The more immutable a coin is the more valuable it is.
6 Likes
if hard forks leads to older software getting broken after the hard fork, it should be strictly avoided if possible. One of the main and yet underestimated reasons for the worldwide dominance of windows as a OS is that Microsoft took great care in regards of backwards compatibility. Linus Torvalds addressed this topic when answering the question “how to get to the year of the linux desktop?” at a conference, why linux failed to be successful in this domain. It boils down to the simple rule: Never break userspace. (from 4:53 min in https://www.youtube.com/watch?v=5PmHRSeA2c8)
4 Likes