Bitcoin Unlimited, one of the Bitcoin Core software forks introduced in late 2015, garnered much attention in recent months. The project gained hash power support from several new Bitcoin mining pools, including ViaBTC, GBMiners and BTC.TOP, while node adoption appears to be on the rise as well.
The central idea behind Bitcoin Unlimited — specified in “Bitcoin Unlimited Improvement Proposal 001” (BUIP001) — is to hand control of Bitcoin’s block size limit to users and miners. Or perhaps more accurately: to make this control more explicit and easier to handle.
But as explained in “How Bitcoin Unlimited Users May End Up on Different Blockchains,” BUIP001 does not include a technical consensus mechanism as reliable as in Bitcoin’s current consensus rules.
Instead, Bitcoin Unlimited relies on a philosophy often referred to as “Emergent Consensus.”
(Note: If you are not sure how Bitcoin Unlimited works, or what the technical weaknesses of BUIP001 are, make sure to first read “A Closer Look at Bitcoin Unlimited’s Configurable Block Size Proposal” and “How Bitcoin Unlimited Users May End Up on Different Blockchains.”)
“Emergent Consensus”
BUIP001 does not ensure machine consensus; users can configure their nodes to split into different blockchains, either intentionally or unintentionally. Instead, Bitcoin Unlimited relies on “Emergent Consensus.” This is a conviction that participants in the Bitcoin ecosystem have a strong enough economic incentive to converge on a single blockchain, such that they will converge on a single blockchain. If their software does not automatically realize this, users are expected to configure their settings to make it happen. After all, it benefits everyone to be on the same blockchain and to be able to transact with one another.
How this Emergent Consensus should form is not really documented, however. While some have made analogies — with flocks of birds, for example — it’s not clear how these apply to Bitcoin, exactly.
That said, it is possible to draw out a scenario that many Bitcoin Unlimited proponents roughly envisage. As a first step, users should signal what size of blocks they will accept with the Excessive Block Size (EB) setting. Then, miners — incentivized to satisfy market demand — should increase (or decrease) the block size limit accordingly. Finally, if these new blocks exceed some users’ EB, these users are expected to follow regardless, either because their Excessive Acceptance Depth (AD) setting is triggered, or maybe because they’ll reconfigure their nodes manually.
As explained in “How Bitcoin Unlimited Users May End Up on Different Blockchains,” this scenario does present some problems. For one, if a user’s EB signaling is trivially spoofed by an adversary, miners can be tricked into thinking a block size limit increase has more support than it does — or perhaps malicious miners can themselves trick users.
And for the (remaining) users, this scenario presents an odd choice: Either they set their AD settings low to remain in consensus, but essentially give up much of their autonomy to miners; or they set their AD settings high to protect their autonomy, but risk splitting the network.
Off-Chain Coordination
To counter some of the problems described, Emergent Consensus can also be established through debate on forums, blog posts, chat rooms and other media. Realistically, it may even require this kind of off-chain coordination, to some extent.
For example, while mining pool ViaBTC wants to hard fork to a two-megabyte block size limit, that is not what the pool is currently signaling with its EB settings. If it did, that could be abused to split the network. Instead, ViaBTC signals support for one megabyte and in their “miner guide” proposes to hard fork to two megabytes once at least 75 percent of hash power acknowledges support.
However, this kind of off-chain coordination is not unique. Groups of people have coordinated and achieved consensus through discourse for a long time. But such systems often either have a leader or tend to break down and split into factions once the number of participants reaches a certain size. Other popular open-source projects, for example, sometimes consist of hundreds of incompatible forks.
And this is probably even more true under adversarial conditions. If the people in these groups don’t really know or trust one another, they have no way of knowing whether the other people are telling the truth or lying. Even a single adversary can pretend to be many users and communicate many false preferences. This makes coordination and reaching consensus a very difficult problem to solve.
In fact, this is the Byzantine Generals’ Problem. That is exactly the problem Satoshi Nakamoto attempted to address.
With a track record of about eight years, Bitcoin’s main technological achievement is a math-based protocol that realizes strong, fast, scalable and automated machine consensus for large groups of people who do not necessarily know or trust one another. Bitcoin is reasonably “Byzantine Fault tolerant.”
Bitcoin Unlimited proponents believe that Bitcoin’s economic incentives — the incentive for users to all remain part of the same Bitcoin blockchain — is in itself sufficiently Byzantine Fault tolerant. But that is, so far, largely unproven. No altcoin relies on similar assumptions, nor is there a publicly available testnet where the BUIP001 configurations are actively used.
What Bitcoin Unlimited Changes
That said, part of the same Bitcoin Unlimited philosophy is that Bitcoin relies on a sort of Emergent Consensus anyway.
Rather than merely relying on math, code or protocol, many really see Bitcoin as a consensus between people first and foremost. People choose to partake in the system, people give it value, and sometimes — like during the August 2010 and March 2013 blockchain forks — people have to coordinate “off-chain” to determine which chain is valid.
As such, BUIP001 doesn’t fundamentally change anything. Users choose to run Bitcoin Unlimited. Node software can already be (re-)compiled. And a social consensus may have to form “off-chain” either way.
But by making this control more explicit and easier to handle, and assuming users actually use these options, Bitcoin Unlimited does rely on the human consensus aspect to a much larger extent. Rather than opting into a protocol once and relying on machine consensus from then on, users need to take on a much more proactive role. As one Bitcoin Unlimited proponent noted, shortly after miners had to reconfigure their nodes in response to a bug that briefly forked the network earlier this week: “This IS part of how Bitcoin works. It’s not meant for people sleeping at the wheel.”
It is true that BUIP001 doesn’t introduce anything that wasn’t possible before. As an open-source project, users and miners could always recompile their Bitcoin software to do anything that Bitcoin Unlimited allows. But of course, that in itself is not an argument in favor of BUIP001. Just because users could, that does not mean they should.
So far, Bitcoin has had several forks that lasted for several blocks, caused by technical failures. The August 2010 blockchain fork was needed to revert the creation of billions of bitcoins out of thin air, which required orphaning an hour-long chain. The only reason that the event wasn’t catastrophic is that bitcoin was hardly used as money back then. During the March 2013 blockchain fork, however, the network was unreliable for real users, and at least one person was double-spent, while several miners wasted valuable resources mining an orphaned chain. The same is true for the July 2015 blockchain fork, where miners were urged to switch to fully validating mining pools, and many have learned from that mistake.
Indeed, developers, miners and the rest of the Bitcoin community have generally tried to avoid these types of crisis events as much as they possibly can.
In contrast, Bitcoin Unlimited seems to embrace them as an upgrade mechanism.
“Jonny1000” contributed to this article.
Author's note: An earlier version of this article suggested there is no testnet for BUIP001 at all. Since publication, it was pointed out there actually is such a testnet, dubbed "nolnet". This testnet is not really publicly available, however, and seems to be used only by a small group of developers close to the Bitcoin Unlimited project. And of course, by definition a testnet does not test economic incentives either way, so these remain unproven.