Bitcoin should be upgraded in the future
Bitcoin should be upgraded in the future activation methods influences opinions on future protocol improvements.
Over the past five years, one of the most controversial issues in Bitcoin has been how to initiate soft forks. In the history of Bitcoin, numerous different procedures have been used to activate new features on the network, each iteration of which has typically progressed with the objective of making feature deployment as secure and non-disruptive as feasible. Until 2017, there was widespread agreement and little controversy as activation techniques changed, but this changed with the implementation of Segregated Witness (SegWit).
SegWit became the source of dispute and debate about how features should be enabled on Bitcoin for the first time. Following the original BIP9 deployment, which was reliant on miner signalling to lock in enforcement rules, the vast majority of miners and mining pools refused to indicate activation with their blocks. Many users were outraged at the time because miners were delaying the activation of a new feature and holding it hostage with demands for a hard fork to increase block size (when, I might add, SegWit accomplished a block size increase through a soft fork), and the entire ecosystem was filled with completely inaccurate information about SegWit in an attempt to drive opposition to the feature itself based on outright lies.
BIP148 and the user-activated soft fork (UASF) pushed miners to activate SegWit, and one of the huge block pushes was cancelled, leaving the other to fork and ultimately die. However, Bitcoiners have typically avoided discussing how new features should be delivered and enabled since then. The subject has gotten so heated that it is nearly a taboo.
Before getting into how I personally believe upgrades should be handled in the future, I think it’s interesting taking a high-level tour of some of the previous activation techniques suggested and deployed. It should be noted that similar procedures may be utilised for both hard forks and soft forks; the only difference is that a chain split is assured with a hard fork and only conceivable if anything goes wrong with a soft fork.
ACTIVITIES FOR FLAG DAY
“It may be introduced gradually, such as: if (blocknumber > 115000) maxblocksize = largerlimit It may begin in versions far in advance, such that by the time it reaches that block number and takes into effect, prior versions that do not include it are already outdated.”
This is the controversial comment by Satoshi Nakamoto after the implementation of the first block size restriction, implying that it may be expanded in the future if users felt it necessary. (It’s also worth mentioning that when individuals first asked for it, Nakamoto was opposed to the notion, and expressly answered with the above comment as to why it shouldn’t be done unless it was absolutely necessary.) The final remark Nakamoto ever made on the matter of block size, which can be seen here, also plainly stated that it was ultimately up to the users to do so or not.)
This is a “flag day activation,” in which a block height or timestamp is chosen, and upgraded nodes immediately begin enforcing new rules. There is no apparent coordination or public signalling; participants just download the new client, and everyone who has updated begins enforcing at the specified moment, while those who have not upgraded do not.
Pay to script hash (P2SH) was enabled in this manner. Flag day activations are theoretically a kind of user-activated soft fork, since it is the network nodes who commit to activating a new feature and implementing its regulations. The issue with flag days is that they do not send a public signal stating what proportion of miners claim to be implementing new rules, allowing everyone to assess the possible danger and probability of a chain split. Flag days haven’t been utilised in a while.
BIP9 was created to reduce the possibility of chain splits during the deployment of soft forks. The concept was for miners to add a signal in the blocks they mine, with new node software only activating new features if a certain percentage (95 percent) of miners in a difficulty period signalled to activate the feature. This would make public how many miners were enforcing the new feature before nodes started enforcing the new rule. Miners could obviously lie and fraudulently signal, but the concept was that there is no economically viable motive to do so. BIP9 was used to deploy CheckLockTimeVerify and CheckSequenceVerify, as well as the first Segregated Witness implementation.
The major disadvantage of a BIP9 deployment, as shown by SegWit, is that a small number of miners may impede feature activation by refusing to signal. BIP9 allows miners a de facto veto where they may block a new feature from activating on the network without releasing anything a second time via a different activation method. As a result of this activation process, miners have disproportionate power over what is added to Bitcoin; miners are service providers to users and HODLers, and should not have such disproportionate influence in feature activation.
UASF AND BIP148
BIP148 established a big precedent while also implementing a revolutionary activation technique never seen before; it was meant not only to activate a feature in its own deployment, but also to ensure the activation happened for the preceding BIP9 SegWit deployment. This was the impetus behind the August 1 deadline. Beginning August 1, the last two-week difficulty adjustment period for miner signalling before the SegWit activation window closed, BIP 148 clients enforced by consensus the requirement that all blocks in that final window signalled for SegWit activation.
This approach was an unique activation design that had not before been required or employed, and it was implemented in response to what was seen as a key flaw of BIP9: miners’ ability to block the activation of features that otherwise had consensus.
In addition to SegWit, BIP91 is a one-of-a-kind activation technique that was implemented in 2017. Miners were hesitant to accept BIP148’s ultimatum at the moment, but they were concerned about the ramifications to Bitcoin if BIP148 triggered without miners signalling, leading Bitcoin to split into two parallel blockchains. BIP91 was intended to establish a middle ground that would keep everyone on the same blockchain.
It set an 80 percent threshold, where if that many miners signalled to activate SegWit during a difficulty period, it would begin orphaning any blocks that were not signalling (similar to BIP148). The purpose was to ensure that if BIP91 was triggered, it would remain in sync and compatible with BIP148, triggering the initial BIP9 SegWit deployment and keeping everyone on the same chain. The whole point was to offer miners a reason to “be the ones to trigger activation.”
Due to the scenario that happened during SegWit activation, BIP8 was recommended to replace BIP9. The design aim was to develop a deployment process in which miners exceeding a threshold of signalling (90 percent) may activate the proposal at any moment in the activation window, but also to establish a system in which a fork could be guaranteed if enough miners refused to signal.
That is the “lockinontimeout” setting. If it is set to true, consensus rules will require that all blocks in the last signalling period signal for activation, exactly as BIP148, to ensure that the new feature activates.
Taproot was successfully activated thanks to Speedy Trial. To say the least, the choice of activation techniques was divisive. In the end, Speedy Trial works similarly to a BIP9 activation deployment, with the exception that the activation window is significantly shorter and the signalling threshold is the same as with BIP8 (90 percent ). The use of Speedy Trial was justified in part because if anything with consensus failed to activate, a BIP8 LOT=True deployment might be issued later.
Many people, including myself, saw Speedy Trial as a step backward in terms of improving feature activation methods.
The SegWit activation fiasco in 2017 demonstrated the ability of a small minority of miners to disrupt network consensus and feature deployment, which had to be corrected through an incredibly convoluted deployment of multiple different activation mechanisms at the same time, each with complicated incentive interactions. This was a very dangerous scenario that ultimately worked out in the end, but it might have gone horribly wrong.
The whole idea of going beyond BIP9, in my perspective, was to prevent re-creating the possibility of such a scenario. Some say that Speedy Trial does so since it has a significantly shorter duration before an activation window ends, but I disagree. It still poses the possibility of an activation failing owing to the maliciousness or lack of reaction from a minority of miners, and, more crucially, it creates the social image that miners are capable of “vetoing” agreement among other network players.
In the long run, I believe activation processes come down to this. As Bitcoin grows in popularity, more and more uninformed individuals will join the ecosystem. They will be watching everything that is going on and, most crucially, they will be looking at activation mechanisms through the lens of “What is going on here, who is choosing if anything activates or not?” Developers? Miners? Businesses? This is the question, and these are the answers, that I believe most new users will have when we go to install new network capabilities and updates.
In this aspect, the solutions individuals come up with will eventually become a self-fulfilling prophesy; if users consider miners as the decision makers, then most users will turn to miners. Users will seek to developers if they believe developers are the decision-makers. How Bit coiners tackle this question now will set the tone for how future users will manage it. There are many various perspectives on how activation should be handled, but in order to avoid putting words in other people’s lips, I’ll simply describe mine.
I do not believe Bitcoin Core or miners should be engaged in the activation process in the capacity of either deploying new activation releases or vetoing or delaying anything from activation. Going forward, I believe that any new features should be released using a UASF with BIP 8 LOT=True. I believe it is critical that the pattern we create for the future is one of grassroots organizing rather than an identifiable group being perceived as the arbiters of what features are or are not enabled in the Bitcoin protocol.
If we create the precedent of those outside of Core proposing activation in the future, we set the precedent of a greater degree of cynicism regarding change in general. We avoid giving younger users the social impression that developers select what happens and what does not happen. This would establish a very high bar for adopting new changes and guarantee that bar stays high rather than devolving into a dynamic in which consumers defer to specialists to determine what occurs. Activations may take place through external clients, with the following Core release activating new features that have been successfully activated via patched clients.
This allows each “activation client” to be utilized momentarily during a feature deployment, with everyone returning to Core following a successful activation, avoiding the need to maintain long-lived clients outside of Core while still separating the activation process from Core developers.
Some may argue that this increases the chance of chain splits at soft forks, however chain splits are always possible during soft forks. If LOT=True is set, the moment at which a fork will occur will be known ahead of time. If the chain splits, it will happen during the last signaling phase of the activation, when the first block that is not signaling for activation is mined. This sets a consistent and predictable time period within which it will occur if it occurs, as opposed to any random moment after activation when a miner who is not obeying the new rules mines a block that violates that rule.
If there is genuine agreement on a new feature, the majority of the economy will be running a client to enable it, and such a chain split will be a small interruption and annoyance. If there is no agreement on a new feature, a chain split should be nothing more than a little interruption and annoyance when a small minority forks off the network. They will be forced to choose between continuing to use a minority fork chain and returning to the Bitcoin network.
Bitcoin is, at its core, a market-driven system in which agreement is reached willingly. Attempts to keep that process from getting messy, in my opinion, are both erroneous and will ultimately lead to more centralized social control and the impression of top-down decision making if individuals repeatedly strive to eliminate the mess from reaching agreement. We should enjoy the process rather than attempt to control it.
At the end of the day, this is just my own perspective on how things should be done, and there are many more points of view. People should not be afraid to express their views on this issue. It’s past time we started having this talk instead of pushing it off and allowing the inertia of social dynamics make the choice for us.