Just when Bitcoin’s long-lasting scalability dispute appeared to have reached a deadlock, a pseudonymous mailing-list contributor may have presented a way out.
Segregated Witness (SegWit), the Bitcoin protocol upgrade proposed by the Bitcoin Core development team, would roughly double Bitcoin’s block size limit, while laying the groundwork for further scaling solutions. But this proposal that requires 95 percent of hash power support to activate has been slow to gain miner adoption. And there is little indication this will change anytime soon.
Now, there may be an alternative route to activation.
“[T]he signaling methodology is widely misinterpreted to mean the hash power is voting on a proposal and it seems difficult to correct this misunderstanding in the wider community,” a so-far unknown person under the pseudonym “shaolinfry” noted on the Bitcoin-development mailing list and the BitcoinTalk forum last weekend.
And:
“The alternative discussed here is ‘flag day activation’ where nodes begin enforcement at a predetermined time in the future.”
This alternative is called a “user activated soft fork” or “UASF.”
Hash Power Activated Soft Forks
Soft forks are changes to the Bitcoin protocol that tighten up the rules. Transactions or blocks that would have been valid under the old rules become invalid under the new rules.
An interesting property of soft forks is that some users can upgrade to the new set of rules, while other users do not, or at least, not yet. They would all remain part of the same network, use the same blockchain and transact in the same currency; it’s just that some users may be looking at slightly different data.
“Soft forks are backwards compatible and opt-in,” shaolinfry argued in a follow-up email. “So long as they are well written and bug free, users should, at worst, be agnostic towards them because they have a choice whether to safely use the new feature or not, without preventing others’ enjoyment of the feature.”
Over the past couple of years, soft forks were mostly implemented by hash power activation. This utilizes the fact that miners decide which valid transactions they include in blocks anyway. A majority of miners can reject certain types of transactions and blocks from the blockchain if they violate the new soft fork rules, even transactions that “old nodes” would still consider valid.
Segregated Witness as proposed by the Bitcoin Core development team is a soft fork. But with this soft fork proposal in particular, hash power activation seems to be approached as something akin to an election.
Which, shaolinfry argued, it is not:
“[A] problem with supermajority hash power signaling is it draws unnecessary attention to miners which can become unnecessarily political. Already misunderstood as a vote, miners may feel pressure to ‘make a decision’ on behalf of the community: who is and isn’t signaling becomes a huge public focus and may put pressures onto miners they are unprepared for.”
The alternative, shaolinfry therefore proposed, is to introduce UASFs as an activation method.
UASF
The concept of a UASF is actually even more straightforward than a hash power activated soft fork.
Rather than miners, it’s the Bitcoin economy — individual users, merchants, exchanges, wallet providers and other economic actors — that activates the soft fork with the software they run. At a specific point in time, the Bitcoin economy tightens up the rules of the system, activating the soft fork. From that point on, everyone simply rejects transactions and blocks that break the new rules.
Realistically, the miners would then have to follow the new rules as well, or at least take certain safety precautions to avoid accepting invalid blocks and transactions. If they don’t, they risk producing blocks the economy deems invalid and rejects. The miners would not be able spend the coins they earned in the block reward, deposit them at an exchange nor otherwise use them. For all intents and purposes, they would not have earned bitcoins at all, and instead wasted resources producing a worthless block.
To earn a block reward that has actual value, miners will therefore need to do what the economy wants them to do, shaolinfry argued:
“The hash powers’ role is to select valid transactions, and to extend the blockchain with valid blocks. Fully validating economic nodes ensure that blocks are valid. Nodes therefore define validity according to the software they run, but miners decide what already valid transactions get included in the [blockchain].”
Like all soft forks, a UASF would still be an opt-in proposition for regular users, assuming it activates smoothly. If some users don’t like SegWit, for example, they can choose not to upgrade. Meanwhile, other users can enjoy the benefits SegWit offers.
Drawbacks
While the concept of a UASF is straightforward, that doesn’t necessarily mean it’s easy to pull off. Compared to hash power activated soft forks, UASFs introduce two increased risks. And not unlike hard forks, if things go badly, Bitcoin can split into two incompatible networks, blockchains and currencies.
The first risk is that coordination can be difficult. Most important, it’s hard to know for sure whether a UASF is really backed, and will be enforced, by the economy. Support from centralized services — exchanges, wallet providers, payment processors — can perhaps be gauged, but individual Bitcoin nodes are trivially spoofed. And if only a minority of the economy enforces the new rules and a majority enforces the original rules, Bitcoin would split in two.
Second, even if a significant majority of the economy does enforce the soft fork, a determined (or perhaps very lazy) majority of miners can still frustrate the upgrade. If these miners are willing and able to waste energy mining the “old” chain, any non-upgraded user would follow this “miner chain,” rather than the valuable “economy chain.” This user would be susceptible to double-spends, at least for as long as these miners are willing and able to waste resources.
That said, these risks are bigger with hard forks, and similar problems can occur even with hash power activated soft forks, as the BIP66 blockchain split showed.
As noted by shaolinfry:
“Validation has always had a strong requirement.”
Thanks to BitGo engineer Jameson Lopp for feedback. For more on the topic of UASFs, follow the discussion on the Bitcoin-development mailing list.
