The Minimalist approach to Scaling Bitcoin
The divided houses of Bitcoin users are often convinced by loudmouths and trolls that they no longer have much in common, and many Bitcoiners today would even like to fork off into a separate coin. But as several bright minds have pointed out, splitting Bitcoin up could be extremely damaging, if not fatal, to Bitcoin’s price and adoption.
In fact, all cryptocurrencies could suffer greatly at the loss of trust that would result at the fallout from the public seeing 42 million bitcoins! Satoshi would have lied to them about digital scarcity.
Since not scaling bitcoin is a certain way to ensure other altcoins overtake Bitcoin’s network effect, and big packages like SegWit, which have lots of needed, if not crucial, upgrades in them, will never see 75% (much less 95%) of the mining power vote for them again, what options do we have to scale at all?
Bitcoin’s Bay of Pigs Imminent
Bitcoin Unlimited has lost its steam, bcoin never took off, and many Core supporters are pushing for a miner-ignoring fork called UASF, which sounds good on the surface but is not as neat and tidy as they’d have you believe.
Several core developers have explained the dangers of going up against majority hashing power, and Bitcoin Unlimited developer Peter Rizun has outrageously already suggested using this nuclear tactic. In a nutshell, pissed-off miners can attack and even destroy your blockchain if they have enough hashes.
It’s just a matter of piling on enough orphaned, empty blocks onto your chain.
UASF is a major threat to miners like Jihan Wu today, and the threat is made impossible to ignore by them when we announce the date and time that all nodes are supposed to sync together and upgrade on. (Flag day.) It’s best to think of UASF as holding up a big sign that says to the opposing team:
‘On day X we are going to deploy nukes on you. So you‘d be an idiot not to nuke us first.’
The Proposition
Meanwhile, our current situation kinda sucks too. We lose new Bitcoin users and businesses every day when we should be attracting them at a record pace. But if we cannot use UASF to fix this, what option does that leave? The strong controversy between the two sides seems to make all options we have today useless. There is one way to bypass controversy, however.
Allow me to make a humble suggestion:
In an effort to eliminate all controversy from blocking non-controversial upgrades, I propose developers break up SegWit and all future upgrades into their component parts. Small chunks of code, singular in purpose, each to be upgraded one at a time… Minimalist packing.
We would see close to zero controversy to reach consensus on a single-feature-basis. For example, take a recent feature in 0.14.0, such as Improved Block Downloading (IBD). Compare deploying only that feature in Bitcoin to the controversy around getting SegWit upgraded with it’s many functionalities packed inside.
Everyone wants their blocks to download faster, right? They couldn’t put up much of a fight against getting faster block downloads if they have no reason to suspect something else that they don’t want is included in the upgrade. It’s that simple.
The current process reminds me a lot of riders on a Bill in the legislative process of many countries, in fact… Who wants to have a Bill made up of mostly riders? Is Bitcoin run by it’s lobbyists too?
Developers can create and review code far faster when it is nice, neat little packages of one. Arguing against code that is simple is much harder, too.
Another positive side effect is that it should greatly help to destroy the unfounded ideology of Bitcoin Core as being a monolithic thing… As the layman sees it today, Core might as well be a corporation with a president… But if every little upgrade came with different developer’s names attached, Core’s role is lessened and the developer’s role is highlighted.
The Drawback
Of course the flipside of breaking up the functionality into single chunks means that we have to upgrade Bitcoin far more often to meaningfully scale. A six-month upgrade period is probably too long now, and running a node will indeed become more of a hassle with all of the smaller upgrades.
If node operators have to review the terms and upgrade their code twenty times over the course of the next 3 years just to upgrade the alternative of SegWit, however, then so be it. At least Bitcoin avoids certain destruction. It will, at the very least, be able to improve itself slowly. We’ll still have Bitcoin, we’ll still be in the lead of the network effect, and we will indeed be able to reach consensus on most of these individual parts.
The unfortunate parts that do not reach consensus will simply have to be upgraded off-chain, where it is permissionless to do so. I’d be thrilled to see networks a thousand layers deep running on top of Bitcoin. Talk about decentralization! Imagine your government trying to track your payment across one of a thousand different lightning networks or sidechains… Or a hundred of them.
Onwards
One excellent step towards compartmentalizing these functionalities would be adding the Consuensus Rules that Core Developer Nicolas Dorier’s planned last month. This would make it so that we don’t have to wait for each of the tiny upgrades to be fully passed before starting the next.
In closing, I’d like to point out that there are currently zero options on the table that appeal to both sides of the debate, and I hope this plan offers something closer to a real compromise. It still needs work, and I need your help to convince developers to start working in this direction at all.
If you like the proposal you’ve seen here today, please tell your local bitcoin developer to check out Nicolas’ Consensus Rules and maybe even this post too. Thanks for your consideration.
