With talk of possible hard forks to Bitcoin being all the rage these days, I thought it would be a good opportunity to share an idea I’ve been thinking about. It’s not an entirely new concept. Many people have been discussing aspects of it for a while, but I thought it might be helpful to share with others. It is a process for performing deliberate, safe and non-contentious upgrades to Bitcoin. If we can figure this out, it would be a huge accomplishment for the Bitcoin community.

One of the reasons I’m very bullish on Bitcoin is that it’s facing a lot of scaling and governance related challenges that other digital currencies won’t face for years, if ever. The huge and rising demand to use Bitcoin affords us the opportunity to face these challenges head on. It is not just theory for us. Many of us now depend on it for our livelihood. Bitcoin is no longer just an experiment.

(Click on image to enlarge)

“The huge and rising demand to use Bitcoin” — Source: Coindesk.com

I’m confident we will push through these challenges and that Bitcoin will benefit tremendously. Bitcoin will experience growth and adoption like never before. But that’s not to say we can just sit back and relax and expect everything to be OK. It’s hard work. It takes patience and perseverence. And, occasionally it takes swallowing your pride and admitting you were wrong. I’m not doing that now mind you…just saying it can happen. ;)

So, What’s the Problem?

One very important challenge we must resolve is how to successfully upgrade Bitcoin in a safe, deliberate and non-contentious manner. And we must be able to upgrade Bitcoin because no organism can live in its own waste products. I’m going to describe an approach that I think could accomplish this goal. I will keep it at a high level so that those with only a cursory knowledge of the Bitcoin block chain can follow.

Any new consensus rules can be implemented by attaching additional data to a bitcoin block (in the form of a hash), disseminating that data to various nodes in a network, and having those nodes validate the data according to the rules. If the data fails to validate, the nodes do not propagate the data. Nodes that are not equipped with the new rules simply ignore this extra data. Miners ignore it as well.

At some point it may become clear that most of the network is validating these new rules, and miners may wish to start building blocks that satisfy these new rules. When it becomes clear that the majority of blocks satisfy the new rules, nodes can safely begin rejecting blocks that don’t satisfy the new rules. This is, roughly speaking, how a soft fork works.

We can refer to this data as a secondary block. A secondary block can contain whatever data we want and be of any size we want.

A Safe, Non-Contentious Upgrade Process

So now that we have some working terminology, let’s walk through some steps to safely and non-contentiously upgrade Bitcoin. By the end, I hope to convince you that a hard fork need not ever be even slightly contentious. Hard forks will be so boring, you won’t mind catching a movie when they happen. We might have to rename them “Easy Forks.”

Phase 1. Soft Fork Adoption of New Rules

In the first of 3 phases, new consensus rules will implemented and adopted as a soft fork.

Step 1-a. Network Adoption

In this step, nodes begin upgrading to support the new rules. Nodes will validate and relay valid data that can be included in the secondary block (imagine some new form of transaction, but it could really be any kind of data). These nodes will not relay data considered invalid according to the new rules. These nodes will however accept Bitcoin blocks lacking secondary block data or with invalid secondary block data. Legacy Bitcoin consensus rules and data forms would be unaffected by these nodes, and nodes unaware of the new rules simply wouldn’t care about this extra hash. It isn’t necessary that miners pay much attention to this step, though they certainly can. They can be as involved or uninvolved as they wish.

Step 1-b. Miner Adoption

Upon seeing widespread adoption of the new rules in the network, miners begin an activation process. This step is, more or less, what is followed for a “BIP-9” soft fork. Initially, miners start creating blocks that enforce the new rules, but they will still accept blocks that fully obey the legacy rules but are invalid under the new rules. At some point a threshold is reached and miners and nodes begin rejecting blocks that aren’t valid under the new rules.

At this point, the new rules are in full effect. It is important to understand that literally any new consensus rules could be adopted and implemented in a secondary block. You could stuff 14Gb of data in these blocks, you could adopt a new quantum resistant signature algorithm, or you could pay the miner a billion new bitcoins as a reward (technically these would be “secondary bitcoins”). All of this capability can be accomplished in an opt-in, purely voluntary, non-divergent soft fork. Miners and pools would need to determine whether the burden of the additional data and validation is economical. If they can earn a profit doing so, they will enforce the new rules.

It’s also important to understand that really bad ideas could be adopted and enforced by miners. That’s OK. The market will determine whether the ideas reflected in a new set of consensus rules are valuable. Miners might initially think it’s a great idea to get rewarded with a billion new bitcoins every time they find a block and start enforcing the rules for a secondary block that does so. But once they realize that this pile of secondary bitcoin they are sitting on has little value, they will reach the conclusion that they are just wasting money enforcing this new secondary block. It would be good to define an orderly deactivation process (though it’s not strictly necessary).

Finally, a secondary block does not need to be intended to replace the functionality of the primary block. It might be intended to permanently remain a secondary block. To the extent miners find it profitable to enforce the rules of these secondary blocks, they will do so. We can do all sorts of crazy stuff in these secondary blocks, but the remainder of these steps assumes our intention is to actually upgrade the primary block. And, by the way, we need to stop calling this process a “soft fork” because it’s not a fork at all.

Phase 2. Deprecation

In phase 2 we perform a second soft fork in an identical fashion to phase 1, but instead of introducing new consensus rules, we are deprecating use of the old block. Assuming that the new secondary block can carry the same or equivalent payload as the old block, we can simply stop allowing transactions in the old block. For really old nodes, this would appear as empty blocks (but by this time, practically all nodes would have been upgraded).

Phase 3. A Very Boring Hard Fork

After the soft fork that deprecates use of the original block has activated, all transactions and data will be in the new secondary block. At this point we can schedule a hard fork that simply drops the old block and adopts the secondary block as the primary block structure. Any nodes that have still not upgraded by this point wouldn’t be doing any useful work. But those nodes would still have plenty of warning by way of a signaling and activation process.

Removing an old and unused data structure should be about the safest non-contentious hard fork possible. And it should be the only type of hard fork that Bitcoin ever needs. We can also use it to finally get rid of some of Bitcoin’s waste products - otherwise known as technical debt.