Why Roger Ver’s Mining Pool Lost 12.5 BTC because of a Bug in Bitcoin Unlimited
Bitcoin.com’s mining pool unintentionally built an invalid block and lost the block reward, down to a bug in the newest release of the Bitcoin Unlimited client. To the disappointment of some of the alternative clients, however, Unlimited did not lose popularity with miners due to this bug; in the voting of the hash power, it even surpassed Core’s SegWit for the first time.
It is not entirely free from the irony that Bitcoin Unlimited gave its newest release the number 1.0.0 and announced it January 27 as “a milestone of functionality, stability, and scalability.” Sure, nearly half a year of work and a lot of improvements have gone into this release; but it also had a bug that cost Bitcoin.com the block reward of 12.5 BTC.
The pool found a block on January 29, published it – and noticed that it was rejected, reason being was that the block exceeded the block size limit by 23 bytes. Instead of 1 million bytes it contained 1,000,023 bytes; this had not been an attempt to start a hard fork for ‘bigger blocks,’ as some have speculated, but an error that was the result of a minor change in the code of Bitcoin Unlimited.
What Exactly Happened?
To understand, we need to dig a bit deeper into the technology; every miner uses an algorithm which determines the size of the block they build by the rules of the network, which decide if a block is valid or not. Currently, the rules say that a block must not be bigger than 1MB or 1 million bytes. With Bitcoin Core and older versions of Bitcoin Unlimited, the algorithm reserves 1 kilobyte of space for the coinbase transaction with which the miner receives the block reward. With the aim of letting miners put more transactions in a block, Bitcoin Unlimited reduced this space to 100 bytes.
By itself, this is not a bad idea, as it helps to increase the transaction capacity of the network slightly. But after all 100 bytes is not always enough for the coinbase transactions, as Bitcoin.com had learned when they created a block that was oversized by 23 bytes.
It is remarkable what happened thereafter. As the pool operator of Bitcoin.com, Emil Oldenburg, reports, the invalid block was instantly rejected by Bitcoin.com itself. The algorithm building the block is independent of the algorithm deciding if a block is valid; and because the setup of Bitcoin.com limits the size of a block to 1MB or 1 million bytes, it was ironically the same software that built the block which rejected it in the first place.
But this did not prevent the pool from spreading the invalid block throughout the Bitcoin network, as it employs a network of nodes to propagate newly-found blocks quickly over the whole world, from California to Beijing. And because this network uses Bitcoin Unlimited with the configuration to accept blocks up to a size of 2MB, it shared the block with every other node with a similar configuration. The result was that some Bitcoin Unlimited nodes have been on the wrong chain for 10-20 minutes before they again followed the chain with the most work.
Interestingly, several other pools started to mine on the invalid block. For example ViaBTC, BTC.top, HaoBTC, BTCC, F2Pool, and BitClub. As Emil Oldenburg explains, “most pools either spy mine (listen directly on the other pools using Stratum), or do headers only mining (some people call this by the incorrect term ‘spv mining’) that only validates headers before starting mining.” That the pool stopped mining 30-40 seconds later is proof that “the pools have checks and balances in place to make sure they don’t build a block on top of an invalid one.” The network reacted to the invalid block exactly as it should have.
Activity and Gloat
Immediately after the propagation of the block, the Bitcoin world became very active. The pool operator informed the developers of Bitcoin Unlimited, which contacted the other miners, fixed the bug and released an update. The fans of Core, which are increasingly hostile against Unlimited, celebrated the error with barely concealed gloat. They used it to criticize Bitcoin Unlimited, sharply and fundamentally, exaggerating the impact of the bug. Blockstream CEO Adam Back went as far as to claim that it was just by luck that the network did not fork, while other took it as proof that Bitcoin Unlimited’s consensus model cannot work. Obviously, both are not true, at least not in this context.
Nevertheless, the incident raises questions; how could it be that the bug lurked deep in a mountain of other updates? Why has the change of the rules not been documented? Why did no one review it, why was it not found in tests? While the damage the bug caused has been rather small, it sparked the more fundamental question if the Bitcoin Unlimited team is ready to take the lead in the Bitcoin project and to act as a serious alternative to Core.
The swiftly published incident report of Bitcoin Unlimited shows that the developers are aware of these issues: “The Bitcoin Unlimited project intends to learn from this experience.” To prevent such an incident to happen again the developers promise to add new unit tests, to intensify code review and to improve both development processes as communication policies.
As a surprise and disappointment for the gloating community of Core fans the incident had no effect on Bitcoin Unlimited’s popularity with miners. On January 30, Unlimited even reached a new adoption peak.
The Election on Bitcoin’s Future
Since mid-November 2016, the miners have been engaged in a voting process with their hash power on Bitcoin’s future, on the question, if Core’s SegWit should be activated or if Bitcoin Unlimited’s emergent consensus should solve the block size issue.
Immediately after the start of SegWit signaling in mid November the pools BitFury, BitClub, BTCC and, partly, Slush, voted for SegWit, peaking at 30 to 35 percent of the hash rate. Meanwhile, Bitcoin Unlimited, already supported by ViaBTC and Bitcoin.com, won the support of the pools GBminers and BTC.top. And while the support for SegWit stagnates at around 25 percent and even fell on 20 beginning this week, the share of the network’s hash rate voting for Unlimited is constantly on the rise, reaching as much as 25 percent and surpassed SegWit.
At the same time, however, Unlimited is only used by around 10 percent of around 4,000 Bitcoin nodes. There is no exchange and no wallet which has publicly announced support for the alternative client, whereas SegWit is installed on around 50 percent of the nodes and there is a huge list of Bitcoin services which have announced their support. But as things currently are, it should not be expected the miners will find a decision in the short term. Thus the gloating and fighting of the communities goes on.
