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.
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?
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.
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.
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.
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)
I sit on the fence as to whether or not I want to use Grin. If there is another hard fork, I am out. I trust bitcoin because I know exactly what kind of money I am getting and the rules never change. I trust the Federal Reserve a lot less because they have been playing with the rules for decades. Make a promise on what the rules are and stick to them. Have respect for the miners who maintain the security of the network.
They do change, just through a softfork which is worse imo, read this for a better understanding
If someone were to develop bidirectional payment channels using the NRD kernels available on testnet, and NRD kernels would be validated through peer review and audits, then how would you argue against activating them on mainnet through a hardfork?