The block-size limit debate has taken a turn now that some of Bitcoin’s biggest mining pools are publicly endorsing BIP 100 (Bitcoin Improvement Proposal 100) instead of backing a Bitcoin XT blockchain fork. So far, F2Pool, BTCChina, BitFury, KnCMiner, 21 Inc. and several smaller pools have come out in support of this alternative proposal. Combined, this represents well over half of all hashing power on the Bitcoin network.
While these endorsements are just a show of support, and do not trigger a change of the block-size limit or a blockchain hard fork as Bitcoin XT is programmed to do, the mining endorsements do mandate a closer look at BIP 100.
What is BIP 100?
Over the past weeks most of the attention regarding the block-size issue has gone to BIP 101 and the Bitcoin XT fork, but BIP 100 was really the first BIP to offer a solution for the block-size limit. Drafted and published as a PDF by Bitcoin Core developer and BitPay employee Jeff Garzik in June, BIP 100 does not set any specific block-size limit or program in any sort of predetermined growth. Instead, Garzik’s proposal – which does not exist as code quite yet – allows miners to vote what the limit should be.
The intended purpose of BIP 100, as described by Garzik, is to take the power to set the block-size limit away from the Bitcoin developer community and, instead, hand it to the free market. The Core developer does not believe such a responsibility over the Bitcoin protocol belongs to any select group of people, and argues that the only sensible solution would be to let the broader mining community decide.
In the BIP 100 draft, Garzik writes:
“Economic actors that wish to see the speed limit [block-size limit] at X or Y – thus dictating the free market – will lobby the Chief Scientist and other ‘core’ developers, individually, in private, in public, with carrots, and with sticks. When [the] Bitcoin market cap [grows 10 times] or more, the lobbying [will be] even more intense. Yet there is no single human or commitment on the planet capable of picking a good speed limit.”
Voting procedure
While the details of the voting process are not set in stone yet, the PDF as well as Garzik’s comments suggest it works as follows: First, 90 percent of hashing power on the Bitcoin network needs to accept BIP 100 for it to activate. This is a one-time thing that will trigger a hard fork. Once BIP 100 is activated, miners can include a public message in a newly mined block indicating how big (or small) they want the block size limit to be. For every 12,000 blocks (some three months’ worth), the bottom 20 percent of all votes is discarded, after which the minimum is chosen.
Importantly, however, the block-size limit can be only doubled or halved at most. Thus, if more than 20 percent of blocks vote to lower the limit, the maximum block size is decreased to whatever is the lowest suggestion – apart from the bottom 20 percent. If more than 80 percent votes to raise the limit, the maximum block size is also raised to the lowest suggestion – again disregarding the bottom 20 percent. But miners cannot vote the block-size limit up indefinitely. BIP100 has a hard limit of 32 megabytes, meaning the maximum can be reached in five doublings from 1 megabyte. Whether Garzik’s proposal includes a minimum block-size limit remains unclear for now.
‘21% attack’
While relatively simple, some say that the voting procedure as described above has some flaws. (But note that it is not yet completely certain that this is how BIP 100 will actually function.) One issue that was raised on Reddit is the so-called “21% attack.” This refers to the ability of 21 percent of miners (possibly a single pool) to vote the block-size limit down as much as they want.
There is some logic behind Garzik’s rule, however. It is generally believed that bigger blocks are disadvantageous for smaller pools. Most Bitcoin developers worry, therefore, that left to their own devices, big pools could keep voting the limit upward – indirectly putting smaller pools out of business and further centralizing mining. This is why Garzik proposed the threshold; he believes the block size should be raised only if a supermajority of miners (81 percent) agree. Or put differently: he believes that smaller mining pools representing 21 percent of hashing power should have “veto power” to keep the limit low.
Whether a “21% attack” is really a feature or a bug, therefore, is a matter of perspective. While “block-size conservatives” consider it an important restraint on the power of big mining pools, proponents of bigger blocks – such as Mike Hearn – feel that a minority of miners can hold the rest of the network back.
One last option that should be mentioned, and which is probably why the option has been dubbed a “21% attack,” is that the voting process could allow any entity that controls more than 20 percent of hashing power to decrease the block size so much that is essentially destroys Bitcoin. While this would not be in the self-interest of this entity from a bitcoin-profit maximizing perspective, it does mean the Bitcoin network would be less resilient against outside attacks.
‘51% voting attack’
But, at the same time, the significance of the “21% attack” (or “21% veto”) has been questioned by Bitcoin developers for wholly different reasons. This is because colluding miners can simply ignore any opposition as long as they control any majority of hashing power.
“It would be trivial for any majority of miners to skew the vote,” Bitcoin Core developer Peter Todd told Bitcoin Magazine. “Once a group of miners is convinced they control at least 51 percent of hashing power on the network, they could simply refuse to mine on top of any block that doesn’t vote along with them. They can do that in subtle ways, for instance by just discarding – orphaning – a subset of blocks, something that naturally happens in the protocol anyways. In reality, therefore, miners controlling 51 percent of hashing power would have complete control over the block size under BIP 100.”
Furthermore, Todd argued that a miner vote could – and probably would – be bought by non-mining entities. Payment processors could, for instance, enter into contracts with pools to vote for bigger blocks. And since this would add overhead costs to the equation – lawyers need to be paid – Todd believes it would, again, disadvantage smaller pools, particularly in non-U.S. jurisdictions.
Todd himself offered a solution for this problem:
“If we ever get to the point that BIP 100 does get implemented, these contracts should be programmed onto the blockchain. This would both reduce overhead costs for everyone, creating a more level playing field, and make the vote-buying transparent at the same time.”
32MB Issues
Another point of critique on BIP 100 is that the 32-megabyte limit might be too small in the long run. Proponents of a bigger block size in particular – including Bitcoin XT developers Gavin Andresen and Hearn – believe this is much too low. If Bitcoin becomes widely used, a 32-megabyte limit is expected to be reached sooner or later, which probably means the block-size debate would need to be held all over again – not something they look forward to.
Garzik, on the other hand, believes this upper limit would be a good safety net.
“The 32-megabyte limit is a check-and-balance, to ensure that the system does not ‘go off the rails,'” Garzik said. “It would require a second user ‘vote’ – a second hard fork – to ensure everybody is on board with the levels of decentralization so far, and comfortable with increasing it further. My personal preference is to remove all upper limits, as the system and the free market will naturally find an equilibrium size based on individual miner choices. The 32-megabyte limit is a compromise.”
On the opposite side of the debate, developers who favor a conservative block-size approach worry that the block-size limit could actually be increased much too fast under BIP 100. From the moment of activation, it could take as little as a year and three months to reach the maximum of 32 megabytes. This is much faster than other BIPs would allow, and too fast according to several Core developers.
“BIP100 is somewhat ambiguous, and perhaps the details are still subject to change, but as-is the text allows for up to four doublings per year,” Bitcoin Core developer Pieter Wuille told Bitcoin Magazine. “It’s hard to predict the future, but the ecosystem should not allow such near-unbounded growth.”
Economics
Another problem is that BIP 100 might hand over too much economic power to Bitcoin miners. This issue was first raised by Israeli mathematician and Bitcoin expert Meni Rosenfeld, and later echoed by Hearn.
“The Bitcoin economy is composed of several groups, and no single group should be given complete power over the protocol. Miner interests are not completely aligned with those of users and node operators,” Rosenfeld told Bitcoin Magazine. “Users want transactions to be cheap and plentiful, nodes want blocks to be small and manageable, and miners could want either big or small blocks – whatever maximizes profits. If given the power to vote on the block-size limit, miners are likely to abuse it, disregarding the other groups. In every single market, giving producers the power to artificially limit supply and competition can lead to disastrous consequences, and Bitcoin is no different. ”
Garzik, however, contends that miners will ultimately have an interest to keep Bitcoin users content. The Core developer argues that the mining community would be unwise to abuse its powers, as it would effectively mean that the market would respond. In other words: Users would sell their bitcoin.
“Miner income is in the long-run aligned with users in a cooperative market relationship, even if short-term counter-incentives exist,” Garzik writes. “Users signal economically via the market – or directly via email and social media! – their views on miner behavior, which must be signaled up front, months in advance of any change. While imperfect, miner voting works; it has been field tested.”
Rosenfeld, however, is not convinced.
“Committees and discussions where all groups are represented, though slow and inefficient, are much more likely to result in a decision that is good for the Bitcoin economy as a whole,” Rosenfeld said.
