For the past month Reddheads.com has been reporting on the scaling crisis that threatens to overwhelm Bitcoin. It is becoming increasingly apparent that the integrity of the Bitcoin blockchain is at stake. A split in the Bitcoin blockchain to create two currencies from the original chain – something that has been unthinkable ever since the first block was mined in 2009 – is now looking distinctly possible, even probable.
The past several days saw a whirlwind of speculation and forum activity as the rate of blocks signalling for Bitcoin Unlimited increased dramatically to around 35%, while Segwit continued to languish in the range of 25% (95% is needed for activation).
And then, two days ago, an exploit that crashed Bitcoin Unlimited nodes was put to use by an unknown entity. In the space of minutes 70% of Bitcoin Unlimited nodes went offline. Bitcoin Core supporters blame Bitcoin Unlimited devs and community for running unstable software while the Unlimited community laments what they see as a brazen attack.
As the debate rages on, figures from the Bitcoin and cryptocurrency community are openly beginning to speculate and even plan for an upcoming split in Bitcoin. Investor and entrepreneur Vinny Lingham, who recently speculated success for Bitcoin in 2017, yesterday published a revised forecast based on a possible split or “hard fork” as he puts it, on his blog: A Fork in the Road.
Steve Sokolowski, the owner of the cryptocurrency mining pool Prohashing, has been writing for months about the implications of a battle for Bitcoin between Bitcoin Core and Bitcoin Unlimited. Today he published an article on his blog entitled Investment planning for the hard fork.
As concern continues to grow in the community, some radical ideas about how to enforce the adoption of Segwit below the threshold of 95% are being proposed by Core supporters. The latest idea to be put forward is that of a “User Activated Soft Fork”.
A User Activated Soft Fork is a way to implement a soft fork without having to rely on a threshold of miner support. Rather, the power to initiate the fork is put in the hands of users. In this context the “users” are deemed to be the economic majority of the community.
The proposal was posted to the Bitcoin dev mailing list last month. In the post, the author (shaolinfry) makes the case for user-activation, arguing that activation by hashrate (mining power) gives an undesirable veto quality to miners and leads to an increasing threat of upgrade inertia:
“Miner signalling has a natural veto which allows a small percentage of hashrate to veto node activation of the upgrade for everyone. To date, soft forks have taken advantage of the relatively centralised mining landscape where there are relatively few mining pools building valid blocks; as we move towards more hashrate decentralization, it’s likely that we will suffer more and more from “upgrade inertia” which will veto most upgrades. Upgrade inertia in inevitable for widely deployed software and can be seen for example, with Microsoft Windows. At the time of writing 5.72% of all Microsoft Windows installations are still running Windows XP, despite mainstream support ending in 2009 and being superseded by 4 software generations, Vista, 7, 8 and 10.”
Later in his post, shaolinfry makes the point that:
“Since miners already have the protocol level right to select whatever transaction they prefer (and not mine those they don’t), it would be better if a miner could chose to not participate in triggering activation of something they won’t use, but, without being a veto to the process (and all the ire they may have to experience as a consequence).”
Ultimately, the idea behind a UASF is to code a “flag day” into the soft fork, so that no matter how much support the fork has, it will activate on a certain day among upgraded users. This activation method could be combined with hashrate-based activation, so that it would be possible to activate the fork before flag day based on a threshold of hashrate support.
In order for such a soft fork to be viable it would have to be based on the BIP9 (Versionbits) method rather than the IsSuperMajority method of activation, which would essentially mean that blocks from miners who have not upgraded are not orphaned, allowing the miners to continue mining. The IsSuperMajority method prevents all blocks created by non-upgraded miners from being included in the blockchain.
Such a “permissive” activation method is not without security problems. Notably, Bitcoin dev luke-jr criticised the proposal by reply, writing that:
“Without at least a majority hashrate validating blocks, it is possible just a single invalid block could split the chain such that the majority continue building a most-work on that invalid block. This failure to validate a softfork is similar in some respects to a hardfork, but with one critical difference: the default behaviour of old nodes will be to follow the chain with the most-work that was valid under the pre-softfork rules. This actually *inverts* the benefit of the softfork over a hardfork, and makes a softfork deployed in such a manner de facto behave as if it had been a hardfork, IF someone ever mines a single malicious block.”
Given the level of distrust and animosity between the two sides of the scaling debate, and the potential for market manipulation, it would appear prudent to consider the possibility of a miner maliciously creating an invalid block as likely, making a UASF a bad choice… unless significant hashrate complements the activation method.
In which case, as noted by luke-jr, why not maintain the requirement for a hashrate threshold, but simply reduce it from the current 95% to 75%?