The block size dispute, perhaps the first ever real political controversy within the Bitcoin community, has raged for years, with no clear long-term solution in sight.
Seven relevant BIPs (Bitcoin Improvement Proposals) have been submitted that could increase the maximum block size in order to allow for more transactions on the Bitcoin network, and alternative Bitcoin implementation Bitcoin XT is even attempting a blockchain fork to increase the limit.
But none of the proposed solutions seem to be gathering enough support to establish a new consensus. And even if a consensus is to be found before the end of the year, as desired by prominent industry leaders, it will most likely be a temporary solution designed to win some time.
However, there is some light at the end of the tunnel as far as long-term solutions go. So-called flexcaps, in particular, are favored by a significant segment of the development community. And at least one such a solution is submitted for consideration at the Scaling Bitcoin workshop in Hong Kong next month.
What are flexcaps and why are they needed?
Flexcaps are, as the name suggests, flexible caps on the block size. As opposed to hard limits – 1MB, 8MB, programmed growth, a voted maximum, etc. – flexcaps allow each block to vary in size, determined by the miner who mines the block.
Explaining why this might be a useful, Bitcoin Core developer and one of the flexcap
auctor intellectualis'
Gregory Maxwell told
Bitcoin Magazine:
Specific limits are almost always politically unstable. No one loves the particular number, whether it's maximum immigration numbers, or limits on rent, or minimum wages... Even if people agree on the fundamentals of the trade-off, very few agree on the particular number that is set. The number stays where it is only because of constant political battling. In the case of Bitcoin, moreover, strict limits on the maximum block size don't handle boost activity well. Short periods of time where for whatever reason the number of transactions on the Bitcoin network rises significantly, might cause problems at each pre-set limit.
In a post on Bitcointalk, mathematician and Bitcoin expert Meni Rosenfeld explained that he – like Bitcoin XT developer Mike Hearn – expects the Bitcoin network to crash if transactions systematically fill up blocks. But unlike Hearn, Rosenfeld believes the main problem is not so much the size of blocks themselves. Instead, Rosenfeld sees the fact that the Bitcoin network cannot handle full blocks all too well as the real problem, which is why he suggested a flexcap (“elastic cap”), too.
“[I]f Bitcoin can't gracefully degrade in the face of rising transaction volume, we will have problems no matter what the current block size limit is,” Rosenfeld explained. “We should instead focus on fixing
that
problem.”
The proposed solution, therefore, is to allow miners to increase the limit on blocks they mine – but at a cost. By effectively charging miners for the creation of bigger blocks, there is an incentive for these miners to keep blocks smaller. Meanwhile, miners have the option to scrape up additional mining fees by (temporarily) creating bigger blocks. If the additional fees are worth more that the additional cost, it makes sense to increase size of a particular block.
These opposing incentives should result in a balance, a block size that is acceptable to developers, miners, users, and other network participants – at least in theory.
How does it work?
Flexcaps can be realized in several ways, with no fundamental difference between the different approaches. Whether to use one or the other is mostly a matter of personal preference, and it seems unlikely to cause great controversy.
The most basic type of flexcap was proposed by Rosenfeld. In Rosenfeld's design, miners will need to pay a “fine” if they increase the size of their block. More specifically, a cut is taken out of their block reward. Instead of 25 freshly minted bitcoin, for example, they would receive only 24, or 20, or whatever the protocol dictates depending on the size of that block. And to prevent that the remaining bitcoin are lost forever, they are paid to the miner who finds the next block; a “rollover fee.”
Maxwell's flexcap design has a similar goal as Rosenfeld's: increasing the cost of creating bigger blocks – but achieves it in a different manner. Rather than cutting into the block reward, Maxwell's flexcap design requires miners to mine at a higher difficulty level. If a miner wants to a create block 10 percent bigger than the norm, it needs to “pay” for that by mining the block at an increased difficulty, in effect needing to invest more energy (hence, money) on hashing.
It should be noted that neither solution would really solve the problem of over-sized blocks. They would, however, counter one possible attack on the Bitcoin network. Since bigger blocks favor bigger miners (presumably pools), any block size policy that allows miners to increase the block size incentivises big miners to do so; in effect centralizing the mining ecosystem. This includes any policy where the block size is adjusted on the basis of previous blocks, since miners can send themselves transactions for free, allowing them to create artifically big blocks and game the system.
Because flexcaps include a cost to increase the block size, the system cannot be gamed for free. After all, even if miners send themselves transactions, they still need to pay the flexcap “fine” for increasing the block size.
“The problem [of big blocks] remains, but users would have to pay fees to support it, Maxwell explained. “Miners can't drive other miners off the network without actual activity in it. Miners can pay fees to themselves, but the cost they can't pay to themselves is the higher difficulty of decreased block reward. They have to do more work to produce a block.”
It should be noted, however, that one remaining attack would be an “investment attack.” Big miners with deep enough pockets could pay the price for increasing the block size over a long period of time, simply to get rid of smaller competitors in order to gain a larger profit later on. While unlikely, this might still be a profitable strategy.
Limits and parameters
Flexcaps will not completely remove the need for limits on the block size. Most importantly, they still require a default maximum, above which a miner is “fined” one way or another. So how are these limits set?
In short: Setting default limits is not a problem flexcaps solve in and of themselves. But flexcaps can be combined with all sorts of other block increase proposals. Whether these are hard limits, or growing limits, or voted limits of any sort, a flexcap can typically be added “on top.”
One such solution is submitted to be presented at the Scaling Bitcoin workshop in Hong Kong by Bitcoin Core developer Mark Friedenbach. Friedenbach's proposal uses a play on Rosenfeld's rollover fee system, but with an added advantage for miners who prefer to create smaller blocks – which, among other advantages, could counter an investment attack.
Speaking to Bitcoin Magazine, Friedenbach explained:
Rather than simply gift the foregone subsidy to some future miner, the flexcap proposal I am working on would require the future miner to constrain the block they are working on to a smaller size in order to claim the held funds. If a miner creates a slightly larger block by claiming only 24 bitcoin, the next miner can create a slightly smaller block and claim 26 bitcoin.
In Friedenbach’s proposal, the default block limit is based on the size of previous blocks. While the parameters of this proposal are not set in stone yet, the network might take the median block size of the past two weeks, and set that number as the default limit for the next two weeks.
“By allowing and providing incentive for the block size to adjust both up and down as demand requires, we can ensure that the block size remains tied to the demands of users via the fee market,” Friedenbach explained. “This is really about making the fee market set the block size. It
is the users who are voting with their money. Since there is a cost to raising the block size, rational miners will only do so if they are compensated with fees. So users who are willing to pay a sufficient fee, are in effect voting for a higher block size.”
The End of Politics?
In an ideal scenario, the limits and – perhaps more importantly – parameters used in a flexcap solution follow more or less naturally from experimentation and testing. However, the fact that limits or parameters need to be selected by humans means it still involves some level of politics.
Rather than removing politics completely, flexcap proponents hope that this solution could allow the Bitcoin network to release some steam when under pressure. This could solve the problem of oversaturation to great extent, which in turn might prevent the debate itself from overheating as much as it did in the past.
“The flexcap should be combined with a hard limit, but we can be much more giving with these hard limits,” Maxwell said. “They can be bigger, allowed to grow faster, and made easier to change. Flexcaps make the situation more politically stable.”
“With [flexcaps] in place, we no longer run the risk of a crash landing, only rising fees – giving us an indication that something should be changed,” Rosenfeld said. “And then, we can go back to arguing what the block size should be, given the trade-off above.”