How Bitcoin Should Be Upgraded In The Future

One of the most contentious questions in Bitcoin over the last five years has been how to activate soft forks. 

There have been many different mechanisms used in the history of Bitcoin to activate new features on the network, the iteration of which has generally evolved with the goal of making feature deployment as safe and non-disruptive as was possible. 

Until 2017, there was general consensus and not much disagreement as activation mechanisms changed, but during the deployment of Segregated Witness (SegWit), this changed.

SegWit became the issue that drove disagreement and contention over how features should be activated on Bitcoin for the first time. 

After the initial BIP9 deployment, dependent on miner signaling to lock in enforcement rules, a large majority of miners and mining pools refused to signal for activation with their blocks. 

At the time, many users became furious that miners were delaying the activation of a new feature and holding it hostage with demands for a hard fork to increase the block size 

BIP148 and the user-activated soft fork (UASF) wound up pushing miners to activate SegWit, and one of the big block pushes was called off, leaving the other to fork and eventually crash into irrelevance.

But since then, Bitcoiners have generally avoided having the conversation about how new features should be deployed and activated. The topic has become contentious to the point of almost being a taboo.

I think it's worth going through a high-level tour of some of the past activation mechanisms proposed and used before getting into how I personally think upgrades should be handled going forward. 

Note that these mechanisms can be used for both hard forks or soft forks, the only difference is that a chain split is guaranteed with a hard fork, and only possible in a soft fork if things go wrong.

This is the infamous quote by Satoshi Nakamoto after they implemented the original block size limit, speaking to how it could eventually be increased in the future if users deemed it necessary. 

(It's worth noting as well that when people called for it early on, Nakamoto was against the idea, and specifically responded with the above quote as to why it shouldn't be done until needed. 

The last comment Nakamoto ever made on the issue of block size, found here, also explicitly acknowledged it was ultimately the choice of the users whether or not to do so.) 

This is a “flag day activation,” where a block height or timestamp is selected, and upgraded nodes simply start enforcing new rules at that point. 

There is no public signaling or visible coordination, people simply download the new client and everyone who has upgraded starts enforcing at the chosen time, and those who have not upgraded do not.

This is how pay to script hash (P2SH) was activated. Flag day activations are, technically speaking, a form of user-activated soft fork, given that it is the nodes on the network committing to activation of a new feature and enforcing its rules. 

The problem with flag days is that they provide no public signal indicating what percentage of miners claim to be enforcing new rules, so that everyone can gauge the potential risk and likelihood that a chain split will occur. Flag days have not been used in some time.

BIP9 was developed in order to further decrease the risk of chainsplits in the deployment of soft forks. The idea behind it was having miners include a signal in the blocks they mine, with new node software only triggering the activation of new features if a threshold (95%) of miners in a difficulty period are signaling to activate the feature. 

This would give a public indication of how many miners were enforcing the new feature before nodes began enforcing the new rule. Obviously, miners could lie and signal falsely, but the idea was that there is no economically-rational reason to do so. 

CheckLockTimeVerify and CheckSequenceVerify were both deployed using BIP9, and the original Segregated Witness implementation was deployed with it as well.

Post a Comment

Previous Post Next Post