Please login or register.

A formal approach towards better hard fork management

Seeing as how there are going to be things that will have to be introduced via a hard fork in future it stands to reason that we have to look at better ways of doing this than the current "fork and pray" approach. The scheme outlined below does not force miners / nodes to adopt a fork if we add something stupid in, but it creates a more fluid network that can robustly handle changes.

Basic bottom line: every 6 months there's a hard fork. You get 1 hard fork's grace before you have to update or be left behind.

Details

Every 6 months, either on March 15 + September 15 or on April 15 + October 15, the Monero network will have a hard fork. 30 days before the fork we will have a code freeze + tag + release, and if there are no major changes we'll have an increase in the protocol version (ie. that's at a minimum). A similar fork system to Bitcoin will apply, whereby a rollover to the new code after the trigger block will only occur if a sufficient number of miners are running the new code.

Anything that is more of a soft fork will kick in immediately (as long as it doesn't drop pre-fork clients off the network). Anything on the p2p layer (ie. hard forkable) will be kept in the wings until the next fork date (as roughly estimated from block height) and then is enabled.

The upshot of this is that you can run a client that is a year old, but pretty much after that 1 year anniversary you'll be dropped off the network (even if there have been no "real" changes in that year).

There is no goal or aim to continue to support clients running older versions of Monero, and just like you have to update your OS security software we have to create an environment where people are "forced" to update their full node.

Discuss

Thoughts? Suggestions? Changes? Let's discuss them before we make this indelible.

Replies: 46
Reply to: ArticMine fluffypony ArticMine
fluffypony posted 8 years ago Weight: -124 | Link [ - ]

Yes - fork date will stay the same, we'll just code freeze a little later than expected. We can take a bit of a shorter freeze period on this first fork because EVERYONE will want to update anyway:)