Bitcoin has gone through many upgrades during its history. Taproot is being proposed as the next improvement to the network. We won’t be going into what taproot is and what it enables in this blog, but you can expect some posts detailing this in the coming weeks. Instead, we will be diving into the different proposals for how to activate taproot on the Bitcoin network and what the pros and cons of these proposals are.
Before we get into the different proposals for how to activate taproot, I think it’s important to put into perspective the historical context of this upgrade and show the different kinds of upgrades that have been done in the past. There have been upgrades that have gone smoothly without a hitch, but there have also been attempted upgrades that have stalled the network and another that’s caused a civil war in the community. However, during all this Bitcoin remains intact and always backwards compatible.
Flag Day Upgrades:
One type of way to do an upgrade to the network is a flag day. A flag day is when a specific moment in time is set, after which the new rules will be applied. This can be a given unix time (eg Jan 3rd 2020 16:00 UTC), a block height (eg block 615,000), or a combination of the two (eg 6 blocks after Jan 3rd 2020 16:00 UTC).
A flag day has been used a few times in the earlier stages of bitcoin when the changes were less impactful and the network was much smaller making coordination between the network participants simpler. The most notable soft fork that was done using a flag day activation was adding the 1MB block size limit. This was added in v0.3.1 of Bitcoin Core. You can see on this line of code when the check was added it was made to only enforce the new rule after block 79,400, this is done so the previous blocks are not invalidated as well as giving a precise starting point for the new rules to be validated. So this soft fork’s flag day was on block 79,400 which ended up being on September 20th, 2010.
Flag days have been used for some other smaller upgrades that were done to fix small bugs or niche vulnerabilities. Some notables ones are disabling OP codes that resulted in anyone being able to spend anyone else’s coins, fixing the output-value-overflow bug that allowed someone to create 184.5 billion bitcoins, and fixing some DoS attack vectors from causing too many signature checks and using OP_LSHIFT.
Flag days offered an easy way to upgrade the network in the beginning of bitcoin while it was still in its infancy. They were used while it was still possible to coordinate such things but as Bitcoin has grown it has moved away from these activation methods for more socially scalable solutions.
Activation Threshold Upgrades:
Another way to activate changes is using an activation threshold. An activation threshold leverages the nVersion bits of the block header for miners to signal support for an upgrade or to signal readiness for an upgrade, depending on the context. Activation thresholds have been used for most of the recent soft forks. For example: BIP 16 (P2SH), BIP 34 (Height in Coinbase), BIP 66 (DER encoded signatures), BIP 65 (OP_CLTV), BIP 68, 112, 113 (OP_CSV), BIP 141, 143, 147 (Segwit), were all activated using a version of an activation threshold.
The most general way to do an upgrade using an activation threshold is to use BIP 9. What BIP 9 does is pick one of the available nVersion bits and will specify if that bit is set to a 1, then that block signals support for the current proposal, if it is set to a 0, then it is not signaling support. It should be noted that it is expected that these bits will be set to a 0 while there are no soft fork proposals, so any block with the version bit set to 0, is not explicitly signaling against the proposal. After picking a bit that will be used for signaling, we also need to pick a start time and a timeout. The start time and timeout will both be unix times, per BIP 9 it recommends the start time to be 1 month after the expected software release date to allow for release delays, and the timeout to be 1 year, but these can be whatever the community decides. Also, it should be noted that these parameters are generally not anything the user sets, but rather how the developer implements the BIP 9 activation in the software.
Now once we have passed the start time we will have started the activation process. Once the activation process has started there can be two outcomes, either the network will upgrade, or remain the same. For the network to upgrade there needs to be a difficulty adjustment period containing 95% or more blocks that signal support with their nVersion bits. If no difficulty adjustment period meets this criteria, then the upgrade will be considered failed, and the consensus rules will stay the same. This offers a safe way for the network to backout of the upgrade without any interruptions. For example, if this weren’t the case and the upgrade would happen irrespective of the miners signalling, then once the activation period had begun there would be no way to stop it besides having users change their node software thus leaving no way to safely backout the upgrade without having lots of users downgrade their software.
OP_CSV was activated using BIP 9 so we will use this as an example to show how it worked. The start time for this activation was midnight 1st May 2016 UTC (Epoch timestamp 1462060800) and it’s timeout was exactly one year after (Epoch timestamp 1493596800). Once it was May 2nd 2016, the activation process had started. With OP_CSV being a relatively small and trivial change it was activated quickly, by June 20, 2016 there had been a difficulty adjustment period that met the 95% threshold. So following that difficulty adjustment, OP_CSV was successfully soft forked in, right around two months after the start time.
Segwit
As you might know, the activation process for segwit was a long arduous battle between users, miners, and corporations. I’m only going to briefly summarize what happened because it is a very long story to get into, however, if you want to know more I recommend this article written by Aaron van Wirdum and this podcast done by Shinobi.
For this blog, you should know that segwit was originally planned to activate with BIP 9, however, miners did not activate segwit quickly, and many large miners, and bitcoin companies were positioning themselves to not activate segwit or instead go ahead with an incompatible hard fork that would activate segwit and increase the base block size by a factor of 2. Most bitcoin users were not in support of this so they challenged these entities and proposed a user activated soft fork (UASF). A UASF is essentially a flag day. In the context of segwit, the Bitcoin community wanted to force segwit activation in spite of the miners not wanting to. This threat eventually culminated into the UASF forcing miners having to activate segwit using the original BIP 9 method by signalling enough support to surpass the threshold.
After the fallout of this many bitcoiners (myself included) believe that BIP 9 gave too much power to the miners and allowed them to dictate if an upgrade will be activated, not when it will be upgraded.
Activation thresholds can serve as a good way to activate upgrades because they give users and miners time to be ready for an upgrade and safely allow software to be updated so no unexpected behavior happens and leaves a way for abort the upgrade safely. However, there is a history where they have been highly contentious and arguably changes the power dynamic to something not in accordance with Bitcoin’s ethos.
BIP 8:
We’ve detailed two different activation methods so far: flag days that will guarantee a change gets in but do not necessarily give time for users to be ready for the upgrade and can cause undo problems, and activation thresholds that gives time for users to be ready for the upgrade and should activate when people are ready, but can change the power structure in an unsavory way. Enter BIP 8. BIP 8 is a variation of BIP 9 but makes some fundamental changes that greatly improves it to give users the ability to still force activation as well as makes some nice tweaks that makes it compatible with similar activation methods (BIP 9, BIP 91).
So, BIP 8 sounds great, but how does it actually achieve this? It’s first change it makes to BIP 9 is that it has a new parameter, lockinontimeout. This new parameter is a boolean (true or false) option for whether or not the upgrade should be locked in if miner signaling never reaches the threshold. If it is set to true and the timeout is reached, it will force the next difficulty adjustment period to have 100% of the blocks signalling support to force activation for all parties, even if they have lockinontimeout set to false. Another, nice tweak it does is change the start time and time out from unix times to block heights, this makes much more sense because the threshold has to be done within a set of blocks, so it can just be a multiple of the difficulty adjustment interval, and doesn’t make hash rate fluctuations have an effect on network upgrade timings.
In my opinion, BIP 8 solves many of the problems that BIP 9 has, specifically relying on miners for the upgrade. With the addition of lockinontimeout it allows users to force miners to have upgrade by the end of the period while still keeping the ability to back out of the upgrade by having users set lockinontimeout to false if it is found to be largely unwanted by the community.
However, BIP 8 does have its fair share of criticisms. The main one being that it can be construed as a developer takeover of the network. This could be a very bad precedent to set if the developer community can set in irreversible changes to the network without a way to stop it once the activation process has passed. So, if a proposal is to use BIP 8 for an activation then it must be heavily reviewed and supported by the broader community.
Activating Taproot:
Finally, what we’ve been waiting for, Taproot! How do we activate it? There are a few proposals floating around IRC and mailing lists so let’s dive into them.
BIP 8 is being proposed to be used as an activation method for taproot. There are many different variations on how to set the parameters from, the standard `lockinontimeout = true` and having the timeout be 1 year, to more sophisticated setups like having a `lockinontimeout = false` with a 3 month timeout, and if that fails then do a new BIP 8 activation now with `lockinontimeout = true` and still a 3 month timeout.
AJ Towns is proposing a new BIP that is a variation of BIP 8, with the difference as the name suggests that the 95% activation threshold decreases over time to a floor of 60% so if there is a non-majority share apathetic miners, we can still activate without needing to UASF the change and every additional miner signaling support brings the activation timeline closer.
Modern Soft Fork Activation was suggested by Matt Corallo back in January of this year as a way to safely upgrade the network and to avoid the most conflict and prevent any large reorgs. What it entails is first a standard one year BIP 9 activation method, if that fails, then do a 6 month quieting period to discuss why it failed and if the community decides to go forward with the changes, a user opt-in parameter which was supported since the original deployment release would enable users to opt into a BIP 8 deployment with a two year timeout, thus completing 6 months after the quieting period. Obviously, this could take up to two years to activate but it makes sure the community is absolutely certain that it wants the upgrade and doesn’t subject miners to revolting users and an uncertain future.
These are the primary ways being discussed on how to activate taproot. If you want to voice your opinions consider joining the IRC channel ##taproot-activation on freenode, making a post in the bitcoin developer mailing list, or joining the soft fork activation telegram. This is Bitcoin and your words are judged based on their merit and your node is judged on the validity of the blocks it relays, so make sure to take action where you see fit.
If you’re interested in learning more, hit us up:
Contact us @Suredbits
Contact Ben @benthecarman or email at [email protected].
To discuss all things Bitcoin, Lightning, and DLCs, feel free to join our Suredbits Slack channel here.
All of our API services, for both Cryptocurrency APIs as well as Sports APIs, are built using Lightning technology and the Lightning Network. All API services are live on Bitcoin’s mainnet. Our fully customizable data service allows customers to stream as much or as little data as they wish and pay using bitcoin.
You can connect to our Lightning node at the url:
038bdb5538a4e415c42f8fb09750729752c1a1800d321f4bb056a9f582569fbf8e@ln.suredbits.com
To learn more about how our Lightning APIs work please visit our API documentation or checkout our Websocket Playground to start exploring fully customized data feeds.
If you are a company or cryptocurrency exchange interested in learning more about how Lightning can help grow your business, contact us at [email protected].