Although some individuals in the Bitcoin community believed that nothing would come out of the recent Scaling Bitcoin workshop in Montreal, it seems that some progress was made in finding a compromise between the small-block decentralists and the big-block progressives.
Multiple discussions between some of the key minds in the Bitcoin Core development community took place at the event this past weekend, and it seems the overall goal was to find the key areas of agreement between all of the contributors’ wide-ranging points of view. Rumors were originally swirling around a possible implementation of Adam Back’s 2-4-8 block-size limit increase proposal, but it appears that the area of agreement is more general than that.
A Short-term Bump in the Block-size Limit
Instead of implementing a long-term solution as soon as possible, the majority of Bitcoin Core contributors are interested in a short-term fix. When reaching out to Blockstream co-founder and President Adam Back to clarify some of the rumors that were swirling around the Montreal workshop, the longtime applied cryptographer pointed to a short summary of the discussions between Bitcoin Core contributors posted to the bitcoin-dev mailing list by Bitcoin Core Developer Jeff Garzik. In his summary, Garzik noted:
“Many [are] interested or at least willing to accept a ‘short term bump,’ a hard fork to modify block size limit regime to be cost-based via ‘net-utxo’ rather than a simple static hard limit. 2-4-8 and 17%/year were debated and seemed ‘in range’ with what might work as a short term bump – net after applying the new cost metric.”
The 2-4-8 plan is Adam Back’s simple fallback plan of increasing the block-size limit to 2 megabytes now, 4MB in two years, and 8MB in four years. This is similar to Garzik’s BIP 102, which simply increases the block-size limit to 2MB on November 11, 2015. The 17 percent per year plan is in reference to Bitcoin Core Developer Pieter Wuille’s plan to increase the block-size limit in accordance with technological advancements. The 17 percent per year number is based on data publicly released by Cisco on an annual basis.
Avoiding an Endless Block-size Increase
Blockstream co-founder and Bitcoin Core Contributor Matt Corallo also chimed in in regard to the Scaling Bitcoin discussions on the bitcoin-dev mailing list. He noted that there does not seem to be widespread consensus on the idea of a block size that continues to grow over time. He noted:
“Still, the ‘greatest common denominator’ agreement did not seem to be agreeing to an increase which continues over time, but which instead limits itself to a set, smooth increase for X time and then requires a second hardfork if there is agreement on a need for more blocksize at that point.”
More Work to Be Done in Hong Kong
There are bound to be more discussions before the next Scaling Bitcoin event in Hong Kong, but that’s where real proposals can be presented alongside test results based on the guidelines for scaling outlined in the Montreal event. Although some view a small block-size limit increase as nothing more than “kicking the can down the road,” the reality is that more time is needed to fully develop long-term solutions, such as the Lightning Network or flexcap, that could help Bitcoin scale to millions (or even billions) of users over time. For now, it seems that a simple block-size limit increase to 2MB or 4MB is an area where many notable Bitcoin Core developers and contributors have found some common ground.
Kyle Torpey is a freelance journalist who has been following Bitcoin since 2011. His work has been featured on VICE Motherboard, Business Insider, RT’s Keiser Report, and many other media outlets. You can follow @kyletorpey on Twitter.
The block-size limit debate has dominated Bitcoin blogs, forums, chat rooms and meet-ups for months on end, while many of Bitcoin’s brightest minds are gathering in Montreal to discuss the issue face-to-face at the Scaling Bitcoin Workshop this weekend.
So far, however, the two sides of the debate have made little progress coming to a consensus. At least for some part, this seems to result from a difference of visions – visions that are based on a different set of priorities.
One of these visions – represented by Bitcoin XT developers Gavin Andresen and Mike Hearn – is straightforward and clear. For Bitcoin to succeed, they believe it needs to grow, preferably fast. And for Bitcoin to grow fast, it needs to be cheap, accessible and easy to use. This, in turn, means that the block-size limit needs to increase in order for more transactions to fit on Bitcoin’s blockchain, for fees to remain low, and without having to rely on complicated and far-off alternative solutions. This could mean that some aspects of the Bitcoin ecosystem need to specialize further, but that was always to be expected.
On the other end of the spectrum, a majority of Bitcoin’s most active developers think it’s not that simple. For them, Bitcoin’s decentralized nature is sacrosanct, and they believe that an increase of the block-size limit represents a trade-off with this core feature. Some of these developers – perhaps best described as Bitcoin’s “decentralists” – even warn that too big an increase could destroy the system as a whole.
But for many outside this select group developers it still seems unclear why, exactly, big blocks could pose such a grave threat. To find out, Bitcoin Magazine spoke with four of the most prominent of these decentralists: Bitcoin Core developer Dr. Pieter Wuille, Bitcoin Core developer and long-term block-size conservative Peter Todd, hashcash inventor and Blockstream founder and president Dr. Adam Back, and well-known cryptographer and digital currency veteran Nick Szabo.
Mining Centralization
According to decentralists, the problem of big blocks is essentially twofold. On one hand there is the basic assumption that bigger blocks favor bigger miners – presumably mining pools. On the other hand is the fact that bigger blocks complicate mining anonymously.
The main (though not only) reason bigger blocks favor bigger miners has to do with latency. As the block size increases, so does the time it takes for a newfound block to transmit through the Bitcoin network. That is disadvantageous to all miners, except for the miner that found the block. During the time it takes a new block to make its way through the network, the miner who found the block gets a head start mining on top of the new block, while other miners are still busy mining on top of an older block. So as a miner find more blocks, it gets more head starts. And as a miner gets more head starts, it finds more blocks. Meanwhile on the other end of the equation, smaller miners find fewer blocks and, as a result, have more trouble turning a profit, ultimately causing them to drop off the network. Bigger blocks tend to centralize mining.
This problem is worsened, moreover, if a miner wishes to remain anonymous, and wants to use Tor. Since latency on the Tor network is always higher, the problem as described above is simply magnified. If smaller miners are disadvantaged by bigger blocks to the point where it’s hard to remain profitable on a regular connection, miners using Tor don’t even stand a chance.
Neither of these arguments against bigger blocks is controversial in itself. The controversy lies in the question how big is too big. Andresen and Hearn believe an increase to 8 megabytes or even 20 megabytes should be OK, and assume that it’s fine to grow this limit to 8 gigabytes over a 20-year time period.
Speaking to Bitcoin Magazine, Bitcoin Core developer and Blockstream co-founder Dr. Pieter Wuille explained why this assumption is not shared by decentralists.
“It is obvious that block propagation is too slow already,” Wuille said. “A recent software update revealed that several mining pools maintain arrangements where they share block headers – the minimal required part of an actual block – the moment they find a new block. All miners in on the deal then start mining on top of that block header instead of waiting for the full block to propagate over the network – waiting would cut into their profits too much.”
Explaining why this is a problem, Wuille continued:
“This practice is harmful for Bitcoin, as it requires a lot of trust among miners. They no longer verify the validity of blocks individually, and instead just rely on their peers. But validating blocks is supposed to be a miner’s main task on the Bitcoin network…”
Moreover, decentralists warn there might be no turning back once bitcoin mining has become too centralized. At that point, the remaining miners could have created a deadlock on the mining market, essentially preventing newcomers to compete profitably.
Core developer and long-time block-size conservative Peter Todd told Bitcoin Magazine:
“The big concern we have here is, as we reduce these security margins, we’ll see the already worryingly small number of pools decrease even further. Even more concerning though, is that while currently it’s pretty easy to start a new pool if an existing one ‘goes rogue,’ bigger blocks can make it much more difficult to do so, because from the beginning you’ll be much less profitable than the big pools.”
And while it has been suggested that miners can connect to a VPS if they prefer to remain anonymous rather than connect through Tor, this is not quite satisfying for decentralists either. Speaking to Bitcoin Magazine, hashcash inventor and Blockstream CEO Dr. Adam Back explained why.
“It is technically possible to mine using a VPS (Virtual Private Server), but miners who do so are not choosing their own transactions,” Back emphasized. “Instead, they connect to a server that does this for them. It’s another form of centralization, at the extreme. And we already see this happening due to bad connectivity in some countries, where miners use VPS services set up in another country to win some time and increase profits…”
Regulation
Decentralization – and anonymity – might be sacrosanct for decentralists, but that does not mean they are goals in and of themselves. Instead, decentralists cling to these properties because they believe the health of the Bitcoin network relies on them. It’s only through decentralization and anonymity that the system can remain free from outside influence, such as government regulation.
“Bitcoin achieves policy neutrality by decentralization of mining,” Back explained. “If one miner won’t mine your transaction, another will. It’s an additional benefit if miners are many, geographically dispersed and anonymous, since it’s complex to coordinate a policy imposition on many small geographically dispersed miners. And it’s even more complex to impose policy on someone who is anonymous.”
If, on the other hand, Bitcoin reaches the point where only a handful of professional miners will be able to profitably partake in the process of Bitcoin mining, and if these miners are no longer able to do so anonymously, decentralists worry that Bitcoin’s fundamental properties might be at risk.
“It is pretty clear that forcing the Bitcoin protocol to implement anti-money laundering policy and blacklisting of funds is a long-term goal of governments, which can be done by pressuring mining pools,” Todd explained. “Being able to tell regulators that pressure will simply cause pools to leave regulated jurisdictions is important, but without anonymity, there really aren’t that many jurisdictions to run to.”
Furthermore, once more that half of all hashing power is effectively regulated, authorities could even demand a complete freeze of certain funds, Back explained:
“If more than 50 percent of mining is subject to policy, it can actually censor any transaction by ignoring – orphaning – blocks made by other miners. We don’t know if that would happen or not, but given the fact that it would be within their technical power to do it, it should be expected that regulators demand their regulations achieve an effect.”
Moreover, once this sort of regulation does set in, decentralists believe it will probably be too late to fix. Bitcoin would be caught in a regulatory trap without even noticing it – until the trap closed.
Back continued:
“If Bitcoin is already at high policy risk – sort of effectively centralized but not experiencing the side-effects of that yet – and then the policy problem arises, the properties of Bitcoin are lost or eroded. How can you fix it at that point? Suddenly decentralize it? It’s uncertain that the parties who are at that point under central control over the Bitcoin network have the free choice to work to decentralize it. They would have been regulatory captured.”
Full-Node Centralization
But even mining centralization and regulation might not be the end of it, decentralists warn. Ultimately, over-sized blocks bear with it another – perhaps even bigger – risk: full-node centralization.
Full-node centralization could be an even bigger risk than mining centralization, decentralists argue, as full nodes effectively verify the consensus rules Bitcoin plays by. These consensus rules enforce that Bitcoin has a 1MB block-size limit, but also that the block reward halves every four years, or that the total supply of bitcoin will not exceed 21 million. And – importantly – being able to verify these rules is what makes Bitcoin a trustless solution. In essence, full nodes allow users to check that Bitcoin does as promised.
But as it becomes expensive to run a full node, decentralists worry that verifying the consensus rules could become reserved to a small elite. This could have several consequences.
An obvious consequence would be that it injects trust in the system. Instead of using trustless full nodes, users would, for instance, use web-wallets – which obviously require a lot of trust in the service. But even solutions such as Simplified Payments Verification (SPV) nodes are no better in this regard, as they do not verify the consensus rules either.
Peter Todd explained:
“SPV nodes and wallets are not a trustless solution. They explicitly trust miners, and do no verification of the protocol rules at all. For instance, from the perspective of an SPV node there is no such thing as inflation schedule or a 21 million bitcoin cap; miners are free to create bitcoins out of thin air if they want to.”
And while the cheating of SPV nodes could be seen as a short-term problem, some decentralists argue that a drop in full nodes might even have more severe consequences in the longer term.
According to Wuille:
“If lots companies run a full node, it means they all need to be convinced to implement a different rule set. In other words: the decentralization of block validation is what gives consensus rules their weight. But if full node count would drop very low, for instance because everyone uses the same web-wallets, exchanges and SPV or mobile wallets, regulation could become a reality. And if authorities can regulate the consensus rules, it means they can change anything that makes Bitcoin Bitcoin. Even the 21 million bitcoin limit.”
It is of vital importance for the health of the Bitcoin network, therefore, that it remains possible to run full node anonymously, Todd urged:
“Like mining, having the option to run full nodes totally ‘underground’ helps change the discussion and gives us a lot of leverage with governments: try to ban us and you’ll have even less control. But if we don’t have that option, it starts looking like regulation efforts have a decent chance of actually working, and gives governments incentives to attempt them.”
Commenting on the block size limit debate itself, Back added:
“I believe that the unstated different assumption – the point at which views diverge – is the importance of economically dependent full nodes. It seems that Gavin thinks a world where economically dependent full nodes retreat to data-centers and commercial operation – and basically all users can only get SPV security – is an OK trade-off and cost of getting to higher transaction volume a year early. But most of Bitcoin’s technical experts strongly disagree and say this risks exposing Bitcoin to erosion of its main differentiating features.”
Trade-Offs
So what if decentralists are right? Bitcoin mining, and perhaps even running a full node, is reserved to specialists working from data centers. Anti-Money Laundering and Know Your Customer policy might be imposed, and perhaps the protocol rules are regulated to a certain extent. Sure, it would be a blow for drug dealers, CryptoLocker distributors and extortionists, but Bitcoin would still be a global, instant and cheap payments system. In a way, Bitcoin might actually be better of without these outlaws. Right?
Well, not according to decentralists.
Most decentralists maintain that Bitcoin’s distinguishing features are not its global reach, its instant transactions, or its low costs of use. Instead, they argue, Bitcoin’s single most important distinguishing feature is its decentralized nature. Without it, there would be no reason for Bitcoin to even exist.
Well-known cryptographer and digital currency veteran Nick Szabo explained:
“In computer science there are fundamental trade-offs between security and performance. Bitcoin’s automated integrity necessarily comes at high costs in its performance and resource usage. Compared to existing financial IT, Satoshi made radical trade-offs in favor of security and against performance. The seemingly wasteful process of mining is the most obvious of these trade-offs, but it also makes others. Among them is that it requires high redundancy in its messaging. Mathematically provable integrity would require full broadcast between all nodes. Bitcoin can’t achieve that, but to even get anywhere close to a good approximation of it requires a very high level of redundancy. So a 1MB block takes vastly more resources than a 1MB web page, for example, because it has to be transmitted, processed and stored with such high redundancy for Bitcoin to achieve its automated integrity.”
The crucial importance of this trade-off, was seconded by Wuille:
“If we were to allow centralization of mining, we simply wouldn’t need a blockchain in the first place. We could just let a central bank sign transactions. That would allow us much bigger and faster blocks without any capacity problems. No variable block times. No wasted electricity. No need for an inflation subsidy. It would be better in every sense, except that it would involve some trust. Really, if we don’t consider centralization of mining a problem, we might as well get rid of it altogether.”
Szabo added:
“These necessary trade-offs, sacrificing performance in order to achieve the security necessary for independent and seamlessly global automated integrity, mean that Bitcoin cannot possibly come anywhere near Visa transaction-per-second numbers and maintain the automated integrity that creates its distinctive advantages versus these traditional financial systems.”
Bitcoin versus bitcoin
This leaves us with one last question. If “Bitcoin cannot possibly come anywhere near Visa transaction-per-second numbers” as decentralists claim, then what is the point of it all? Why even bother building software, investing in startups, and spend time evangelizing Bitcoin, if it inherently doesn’t scale?
The point of it all, for decentralists, lies in a classic distinction: the distinction between Bitcoin the network and bitcoin the currency.
Bitcoin the network, decentralists argue, is fundamentally designed as a settlement system, not as a network for fast and cheap payments. While maybe not the most typical decentralist himself, a recent contribution to the Bitcoin developer mailing list by Core developer Jeff Garzik perhaps explains the decentralist perspective best.
Garzik wrote:
“Bitcoin is a settlement system, by design. The process of consensus ‘settles’ upon a timeline of transactions, and this process – by design – is necessarily far from instant. … As such, the blockchain can never support All The Transactions, even if block size increases beyond 20MB. Further layers are – by design – necessary if we want to achieve the goal of a decentralized payment network capable of supporting full global traffic.”
But, importantly, this vision of Bitcoin as a limited settlement network, does not mean that bitcoin the currency cannot flourish beyond these built-in limits.
As explained by Szabo:
“When it comes to small-b bitcoin, the currency, there is nothing impossible about paying retail with bitcoin the way you’d pay with a fiat currency – bitcoin-denominated credit and debit cards, for example, with all the chargeback and transactions-per-second capabilities of a credit or debit card. And there are clever trust-minimizing ways to do retail payments in the works. Capital-B Bitcoin, the blockchain, is going to evolve into a high-value settlement layer, and we will see other layers being used for small-b bitcoin retail transactions.”
Or as Garzik elaborated:
“Bitcoin payments are like IP packets – one way, irreversible. The world’s citizens en masse will not speak to each other with bitcoin (IP packets), but rather with multiple layers (HTTP/TCP/IP) that enable safe and secure value transfer or added features such as instant transactions.”
Moreover, decentralists contend that even these upper layers could include most of the advantages that the Bitcoin network introduced. Once fully developed, technological innovations such as the Lightning Network and tree-chains should allow users to transact in a decentralized, trustless, and even instant fashion – while ultimately settling on the Bitcoin blockchain. While it is true that on-chain transactions will cost more as room in blocks becomes scarce, decentralists maintain that it is the only way to keep that chain decentralized and trustless – and that that does not need to be a problem.
“Yes, on-chain transaction fees will rise,” Todd acknowledged. “But that changes what you use Bitcoin’s underlying blockchain layer for, and how often – not whether or not you can transact at all. A world where you can send anyone on the planet money directly on the blockchain for five dollars – or for near zero via caching techniques like Lightning – is a very good option, and it will buy us time to develop techniques to make blockchains themselves scalable …”
Reaching consensus is a terribly difficult task when there are so many different individuals involved in a distributed system, such as Bitcoin, which is why Epicenter Bitcoin co-host Brian Fabian Crain asked Andresen about who should have a say in changes made to the protocol.
Everybody Should Have a Say
Andresen believes that everyone should be able to have their say through the various communication channels available to them. During the interview, he noted:
“I think everybody should have a say. It’s hard to balance letting everybody speak and not just being drowned out by the noise. If you look on Reddit, anybody can speak there and talk about whatever issue about Bitcoin they care about. It’s hard to find a signal above all the noise. I don’t think it’s impossible, and I think it is fairly clear what the consensus on Reddit is about the blocksize issue. But it’s hard to find more than a high-level, ‘We think something should be done about this issue.’ When it gets down into the details of exactly what should be done, I think then it gets even harder.”
While allowing everyone to participate in the debate is nice in theory, it becomes difficult to find a solution on a social media platform that is well-known for jumping to conclusions and quickly pulling out pitchforks. In reality, there is a smaller subset of Bitcoin companies, miners and developers who have more pull in the Bitcoin network than the average user. As Andresen explained:
“Who should have the influence? It really comes down to what code are people running and how influential are the people running the code?”
Some Bitcoin Users are More Equal Than Others
After explaining that some Bitcoin users are more influential than others, Andresen began to describe the roles those users play in the Bitcoin ecosystem. He started with exchanges:
“Exchanges are incredibly influential at this stage of Bitcoin’s life. Exchanges are a place where a lot of trading is done. Right now, there’s a lot of speculation; exchanges are where that speculation happens. So what the exchanges want to do matters a lot.”
Speculative trading is still one of the main use cases for bitcoin right now, and anyone who uses an exchange, such as Bitfinex or Coinbase, is subject to the code that the exchange chooses to run on their own servers (as long as the user keeps his or her coin on the trading platform). Of course, users still have the ability to switch to another provider if they don’t agree with the codebase chosen by a particular exchange, but many users of bitcoin banks are also not overly interested in the code running on the server.
Andresen also pointed to the importance of mining pools:
“Miners are also very influential — and more than miners, the mining pools that pool together miners are very influential. So I think they have a big influence and a big voice in what happens.”
Miners control the security of the network, but they’ll also want to run the code that will be the most profitable option for them. If a hypothetical hard fork were to take place and split Bitcoin into two different networks, miners would be incentivized to mine on the blockchain with the more valuable coin. This is one of the reasons that the Satoshi Nakamoto Institute’s Daniel Krawiszbelieves investors are ultimately in charge of Bitcoin.
When it comes to the average user, Andresen conceded, “It’s harder for them to have a huge influence.”
Who Does Andresen Listen To?
Gavin Andresen also described his own thinking process when it comes to figuring out what he should work on next. The Bitcoin Foundation chief scientist explained that he tries to keep the desires of all bitcoin stakeholders in mind before deciding on his next move:
“The people who have the biggest voices right now are the developers, the exchanges and the mining pools. Those are the three biggest players. I like to think that, as a developer, I try to listen to all the stakeholders. I try to listen to what long-term bitcoin holders want, what people who are actually transacting with Bitcoin want, [and] what the companies like BitPay who are supporting merchants want. And try to balance all those things when I think about what am I personally going to be working on as I write code, as I submit pull requests, [or] as I decide what pull requests I’m going to review? I try to channel everybody to prioritize what I work on, and I think all of the other developers do that, too. We probably have different opinions on what’s important to work on next.”
Andresen is on the technical advisory board of a few exchanges and merchant processors, so that’s how he keeps in touch with the concerns at those companies. He also mentioned bitcointalk.org and Reddit as the two best channels for discussion on changes to Bitcoin by ordinary users — at least for now.
“There’s a deep rift amongst bitcoin core devs regarding what the purpose of Bitcoin should be,” said Eric Lombrozo, Bitcoin developer and CEO of Ciphrex. “Unfortunately, the fundamental underlying disagreements aren’t being properly addressed … and most of the discussion has instead focused on the differing conclusions rather than on the real causes of disagreement.”
On August 15, Bitcoin Magazine reported that the first of two Scaling Bitcoin workshops would be held in Montreal on September 12 and 13. This first phase of proposals and presentations is intent on setting the stage for further discussions in phase two, which is planned for December 6-7 in Hong Kong, all with the goal of generating the sort of discussion that Lombrozo is referring to.
“This conference represents a communitywide effort to understand and characterize the plethora of factors that must be considered before coming to any conclusion about how to best scale Bitcoin,” Eric Martindale told Bitcoin Magazine on behalf of Scaling Bitcoin. “Our goal with this first event is to increase awareness of the research that has gone into the scaling problem over the past few years, and encourage a more open dialogue across the entire community.”
The debate over the future of Bitcoin and scalability has ramped up over the past few weeks as proponents of one solution or another have taken to social media, discussion boards and blogs to argue various cases.
On September 1, in an open letter to the Bitcoin community, 32 developers collectively asked people “to not prejudge and instead work collaboratively to reach the best outcome through the existing process and the supporting workshops.”
“There are a lot of things we’ve learned about Bitcoin that were unknown a few years ago that change many of the underlying assumptions about how the network functions,” said Lombrozo, who has since become a signatory to the open letter. “There’s been a lot of progress in ideas … but, unfortunately, there’s also a lot of confusion surrounding how Bitcoin can evolve. I hope we can really take a step back and look at what we can do given what we know now … rather than focusing too much on the way we thought the system should have worked but doesn’t.”
Lombrozo argues that the larger underlying issue is “the lack of a process that allows us to make progress in situations where we lack near-unanimous agreement for hard forks. Until now, the policy has been to not make these kinds of changes unless everyone agrees.” He adds that while he is looking forward to attending the workshops and seeing what the engineers have to offer, he is also “working on some proposals to address the consensus-building process between developers more generally.”
Chinese mining pool BW, which provides approximately 8 percent of global mining power, will also be keeping a close eye on what comes out of the two workshops.
“We would like this to be an opportunity for everyone to get together and sit down to discuss this important issue,” representatives from the company told Bitcoin Magazine. “We are in agreement with the spirit of the open letter and look forward to meeting our colleagues from around the world.”
BW will be sending Mianhuan Li, the manager of their mining farm in Inner Mongolia, to the Montreal workshop. Qingchun Shentu, their resident expert on cryptography and Bitcoin, and doctoral candidate in Signal and Information Processing, will attend the second workshop in Hong Kong.
On the other hand, core developer Mike Hearn, who implemented the BitcoinXT fork along with Gavin Andreson, is skeptical about the Scaling Bitcoin workshops.
“If you look at how the Bitcoin Core devs and Blockstream have acted so far, this fits their modus operandi perfectly — stall for as long as possible whilst claiming that we just need more time for the ‘experts’ to think and debate. But don’t define any way to actually come to conclusions, thus ensuring the debate never ends.”
The workshops, which Hearn will sit out while Andresen attends, have explicitly stated that there will be academic and scientific presentations, but no debate. Furthermore, no decisions or pronouncements on scalability will be made during the workshops.
Core developer and one of the signatories on the open letter, Peter Todd, expressed some skepticism, in correspondence with Bitcoin Magazine, that the workshops will be able meet all the demands of the companies attending.
“If the data supports raising the blocksize to some level safely, and we can agree on what ‘safely’ means, that won’t be a hard thing to get consensus on. It’s just unlikely the amount we can safely raise it to will make people happy.”
He pointed out that what Andersen and Hearn appear to want — “zero or near zero fees forever with most transactions being on chain” — appears to be fundamentally impossible by simply changing a constant.
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, is probably the reason it has been dubbed a “21% attack”. The voting process could allow any entity controlling more than 20 percent of hashing power to decrease the block size so much that it 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 firstraised 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.
It has been little over a week since Mike Hearn and Gavin Andresen included Bitcoin Improvement Proposal 101 (BIP 101) into the alternative Bitcoin implementation Bitcoin XT. BIP 101 is designed to create a hard fork in the blockchain to allow for blocks of up to 8 megabytes, doubling every two years.
Despite a major uproar on forums, chat rooms and in the media, not to mention a significant drop in bitcoin’s exchange rate, support among miners is minimal. Bitcoin XT will need 75 percent of newly mined Bitcoin blocks to trigger a maximum block-size increase, but only some 1 percent of new blocks so far included such a message – all mined by Slush Pool.
Moreover, it seems unlikely that the 75 percent threshold will be reached any time soon. A significant chunk of mining pools have taken a fierce stand against Bitcoin XT, while others are very hesitant to make such a switch.
Furthermore, a rapidly growing amount of hash power is now publicly backing BIP 100, the proposal by Jeff Garzik that grants miners the right to vote the block-size limit up or down. Both F2Pool and BTCChina, as well as several smaller pools, have come out in support of BIP 100 in the past few days.
Below is an overview of all known mining pools that had at least 1 percent of hashing power on the Bitcoin network over the past week, and their stance on the block-size issue.
F2Pool (~21%): BIP 100 / 8MB
The mining pool that is perhaps most outspoken against Bitcoin XT is also the one representing the largest amount of hashing power on the Bitcoin network: 21 percent. Instead of BIP 101, F2Pool currently supports BIP 100, which, of course, makes it the biggest mining pool to do so.
Speaking to Bitcoin Magazine, F2Pool administrator Wang Chun explained that the Chinese mining pool is open to other suggestions on raising the block size as well. Chun does maintain, however, that consensus among the Core development team is a requirement, and made it abundantly clear that switching to Bitcoin XT is not an option at all.
“We do support big blocks if it is implemented in Bitcoin Core. But we believe the whole ‘Bitcoin’ XT thing is manipulation,” Chun said. “While the question whether and how to increase the block-size limit is a technical one, the Bitcoin Core and ‘Bitcoin’ XT issue is political. By introducing ‘Bitcoin’ XT, Gavin Andresen and Mike Hearn are splitting the community. Totalitarianism and dictators cannot co-exist with the free and open-source software spirit.”
Chun’s opposition wasn’t subtle.
“Boycott ‘Bitcoin’ XT. Bitcoin Core forever. Gavin Andresen and Mike Hearn should resign,” he said.
Earlier this year, F2Pool agreed on a block-size limit increase to 8 megabytes, in accordance with other Chinese mining pools. This did not, however, include a doubling of the block-size limit every other year, as implemented in BIP 101 and Bitcoin XT.
AntPool (~18%): 8MB
AntPool, the second-largest ming pool on the Bitcoin network with 18 percent of hashing power, is also part of the conglomerate of Chinese mining pools that proposed a raise of the block-size limit to 8 megabytes in June of this year. Additionally, AntPool includes a message in support for an 8 megabyte limit in their blocks. As opposed to messages that trigger a switch in Bitcoin XT, however, the message merely broadcasts an opinion. Whether the message should be interpreted as support for BIP 101, which apart from a bump to 8 megabytes is also set to double the limit every two years, is not entirely clear.
AntPool does seem a bit more willing to potentially make a switch to Bitcoin XT in the future, compared to most other mining pools. Somewhat confusingly, CEO of AntPool’s mother company Bitmain, Jihan Wu, tweeted that AntPool is willing to make a switch to Bitcoin XT if “a majority” has switched. It is unclear, however, exactly what majority Wu was referring to.
Speaking to CoinTelegraph in June, AntPool indicated support for bigger blocks as well, although the pool also voiced concern about a contentious hard fork:
“We like the idea of increasing the maximum block size, but if Bitcoin XT is too contentious, we also don’t want the community to be divided. Doubling the block size every two years may be too arbitrary, we’d like to see the block size grow according to the real needs of the network.”
Bitcoin Magazine reached out to AntPool, but received no response at time of publication.
BitFury (~14%)
BitFury is the biggest non-Chinese mining pool on the Bitcoin network, with 14 percent of hashing power. While the pool supports an increase of the block-size limit as well, it is currently not prepared to run Bitcoin XT and vote for bigger blocks. Despite a conservative approach, however, BitFury does not completely exclude the possibility of switching to Bitcoin XT at some point in the future – but only after careful analysis and consideration.
BitFury CEO Valery Vavilov told Bitcoin Magazine: “The Bitcoin Blockchain is not an amateur project anymore – it is becoming a platform for the Global Economy of Things. Changing the base rules can affect a lot of things, thus, any changes should be done very carefully, gradually, and with with tests.”
He added: “The proposed transition to the alternative client raises some concerns about its security: It is well known that key parts of the default Bitcoin Core client were thoroughly checked and sometimes formally verified, which cannot be said about alternative clients – including Bitcoin XT.”
BTCChina (~13%): BIP 100 / 8MB
BTCChina is part of the conglomerate of Chinese mining pools that proposed a raise of the block-size limit to 8 megabytes in June of this year as well. Since today, moreover, BTCChina has started to sign their blocks in support of BIP 100.
Speaking to Bitcoin Magazine, BTCChina’s Mikael Wang made it clear that his mining pool is not prepared to make a switch to Bitcoin XT. The Chinese pool that contributes 13 percent of hashing power to the network maintains that a consensus should be found among Bitcoin Core developers on how and when to raise the block-size limit.
“We will not support Bitcoin XT,” Wang said. “What the Bitcoin community needs now is stability and growth, and we will not do anything to jeopardize this further.”
BW Pool (~7%): 8MB
BW Pool has not mined any blocks in support of a hard fork switch to BIP 101. The Chinese mining pool that controls 7 percent of all hashing power on the Bitcoin network does, however, include messages in support of 8 megabytes in their blocks. Additionally, BW Pool was also part of the conglomerate of Chinese mining pools that agreed to an 8-megabyte maximum block-size limit in June of this year.
Whether BW Pool’s support for an increase to 8-megabyte blocks includes support for a doubling every other year, as programmed into BIP 101, remains unclear.
Bitcoin Magazine has not been able to reach BW Pool for comment.
Eligius (~5%)
U.S.-based Eligius, accounting for 5 percent of hashing power on the Bitcoin network, is another fierce opponent of Bitcoin XT and has no plans to make a switch. Much like F2Pool, Eligius’ owner who goes by the pseudonym “wizkid057” does not even consider Bitcoin XT a Bitcoin implementation – rather an altcoin.
Speaking to Bitcoin Magazine, wizkid057 said, “I see no reason to mine yet another altcoin: ‘Bitcoin XT’ is not Bitcoin.”
Wizkid057 does agree that the block-size limit should be raised at some point, somehow, but said he prefers a careful approach, and contends that such a step should be taken only when widespread consensus is reached.
“Something should – and will – be done about the block-size limit eventually, but based on real-world data,” Wizkid057 said. “It is definitely not a dire thing to try to force people into today. When a technically sound solution gets at least the most basic of consensus from users, developers, experts, miners and services, then I’ll consider moving in that direction. At this time I see nothing that fits the bill.”
KnCMiner (~5%): BIP 101
Sweden-based KnCMiner – controlling 5 percent of hashing power – is in favor of raising the block-size limit, and endorses BIP 101 in particular. Through a letter signed by seven of Bitcoin’s leading companies – including KnCMiner – CEO Sam Cole has expressed his support for the implementation of bigger blocks on the Bitcoin network. The letter did not explicitly state that this would entail running Bitcoin XT, but it did indicate that KnCMiner will run software in support of bigger blocks by December of this year.
Earlier this year, expressing his support for bigger blocks, Cole told CoinTelegraph: “We would like to see millions of people using bitcoin. To do that we need transaction fees that everyone can afford and is willing to pay. Putting it simply, that means many more paying transactions in each block, not less paying a higher fee.”
He added: “If bitcoin transactions end up costing the same as regular transfers then most of the world won’t see any advantages at all. Add to the fact that MasterCard’s main argument against bitcoin is the seven transactions per second limit … The sooner we fix it the better.”
KnCMiner has so far not mined any blocks that would trigger a raise of the block-size limit in Bitcoin XT.
Bitcoin Magazine reached out to KnCMiner, but received no response at time of publication.
Slush (~5%): optional
The only mining pool that has come out in support of Bitcoin XT so far is Slush Pool, controlling 5 percent of hashing power. While the Czech-based mining pool does not automatically sign new blocks in support of a block-size increase, it does allow its users to choose to do so individually. Currently, some 10 percent of hashing power on Slush is devoted to mining blocks in support of Bitcoin XT, and these numbers are slowly growing. Additionally, Slush is working to inform miners connected to its pool on the pro’s and cons of Bitcoin XT.
Speaking to Bitcoin Magazine, Slush Pool operator Marek “slush” Palatinus said: “At this moment we’re preparing some online materials and articles to explain for our users what exactly BIP 101 is and why they should vote for or vote against this proposal.”
He added: “The hash-rate is rising, and I expect more to come after we publish our articles on the topic. I see there’s lot of misunderstanding and fears about a hard fork, but I’m sure Bitcoin will resolve it smoothly in any way – even if we’ll continue with 1 megabyte blocks or switch to BIP 101 on the first day of 2016.”
21 Inc. (~4%): 8MB
21 Inc, which controls 4 percent of hashing power on the Bitcoin network, has not been mining blocks in favor of a hard fork switch to Bitcoin XT. However, the American mining pool that received a record investment for the Bitcoin industry worth $116 million earlier this year, has been mining blocks supporting an increase to 8 megabytes. Whether this includes support for a yearly growing block size as included in BIP 101 remains unclear.
Bitcoin Magazine reached out to 21 Inc., but received no response at time of publication.
Telco 214 (~2%)
Bitcoin Magazine has not been able to reach Telco 2014, which controls 2 percent of hashing power on the Bitcoin network. The mining pool has not been mining blocks in favor of a block-size increase.
Ghash.IO (~2%)
At time of publication, Bitcoin Magazine has not received a response from Ghash.IO, which also controls 2 percent of hashing power on the Bitcoin network. The mining pool has not been mining blocks in favor of a block-size increase.
Leading bitcoin startups including BitPay, Blockchain.info, Circle, KnCMiner, Bitnet, Xapo and BitGo have come to a consensus to implement Gavin Andresen’s BIP 101, and to expand the current block size to 8 megabytes, after a long discussion with core developers, miners and the companies’ technical teams. A statement of their support was posted on the Blockchain.info blog today signed by Stephen Pair, Peter Smith, Jeremy Allaire, Sean Neville, Sam Cole, John McDonnell, Wences Casares and Mike Belshe.
“We support the implementation of BIP101,” the companies say in the letter. “We have found Gavin’s arguments on both the need for larger blocks and the feasibility of their implementation – while safeguarding Bitcoin’s decentralization – to be convincing. BIP101 and 8MB blocks are already supported by a majority of the miners and we feel it is time for the industry to unite behind this proposal.”
This announcement follows a similar statement released in June by five leading Chinese bitcoin companies, F2Pool, AntPool, BW, BTCChina and Huobi. In this statement, the companies explain their support for 8 megabyte blocks but raise concerns about any larger sizes. These mining pools currently represent over 60 percent of the entire Bitcoin network.
This letter of support follows last week’s announcement by Stephen Pair, co-founder and CEO of BitPay, that the company supports the “Increase maximum block size” or the BIP 101 proposal by Andresen and the merger of BIP 101 into Bitcoin Core.
“Currently, the block size limit is hard-coded to 1mb, which constrains overall transaction throughput. BIP101 proposes to increase that limit to 8mb after January of 2016 when a supermajority (>75%) of the blocks being mined indicate they support the increase. The limit on block size will double every two years after that until it reaches 8gb in 2036,” Pair wrote on Medium.
The post continues, “We believe BIP 101 will safeguard Bitcoin’s decentralized nature while providing a reliable, immediate path toward greater network throughput, and we would like to express our support for merging BIP 101 into Bitcoin Core.”
Bitcoin has entered into a new phase of its existence. Prominent developers Mike Hearn and Gavin Andresen have made changes to the alternative Bitcoin implementation Bitcoin XT, designed to fork Bitcoin’s blockchain in order to allow for bigger blocks.
Bitcoin users and – in particular – miners are, therefore, faced with a choice. Will they support Bitcoin XT and vote for an 8 megabyte block-size limit – doubling every other year? Or will they stick to Bitcoin Core with 1 megabyte blocks, limiting the Bitcoin network to a maximum of seven transactions per second?
Or at least that is the choice as it is often presented. In reality, the possibilities are not binary. At the time of publication of this article, two other Core developers have proposed three more Bitcoin Improvement Proposals (BIPs) to increase the block-size limit, and an even wider spectrum of ideas has been suggested on the development mailing list, forums, chat rooms and other media. This article presents an – undoubtedly incomplete – overview of these ideas, categorized in six types of solutions.
Solution 1: No Cap on Block Size
A first option is a full removal of the block-size limit. Such a cap on the block size, after all, constricts the number of transactions on the Bitcoin network, which could become a barrier to adoption or utility at scale.
Satoshi Nakamoto originally implemented the block-size limit as a quick fix to avoid denial-of-service (D0S) attacks on the Bitcoin network. But since Bitcoin’s creator has gone silent, most of Bitcoin’s developers have come to believe that the block-size limit might actually serve more purposes than just the prevention of DoS attacks. The arguments to keep a block-size limit today are diverse, but can be divided into two main categories.
First, a block-size limit might be needed to avoid centralization of the Bitcoin network, and, in particular, further centralization of mining. Perhaps most importantly, bigger blocks would take longer to propagate to other miners when first found. A longer propagation time should lead to a higher orphan rate, as more miners would be mining on older blocks, while newer blocks are still finding their way through the network. That would, in turn, incentivize miners to join larger miner pools, as they find blocks more often, and therefore don’t need to wait for the propagation of new blocks as often.
Second, facing a diminishing block reward, and barring radical alternative solutions, scarcity in the blocks might actually be needed to secure a long-term income for bitcoin miners. After all, miners effectively sell the space in blocks to fill them with transactions. But if the space in these blocks is not scarce, competing miners could always undercut other miner’s fees in a race to the bottom, until fees reach a near-zero level and miners earn close to nothing to reinvest in hashing power. The end result could be an insecure network.
Solution 2: A Fixed Cap on Block Size
The simplest and current solution to solve this problem is the implementation of a fixed cap; a block-size limit set by Bitcoin’s core development team and embedded in the Bitcoin protocol. This fixed cap is currently still 1 megabyte, as set by Satoshi Nakamoto, but is slowly coming within reach as the number of transactions on the Bitcoin network continues to increase.
In order to prevent blocks from filling up, several other limits have been proposed. As a last-ditch effort before shifting his efforts to Bitcoin XT, Andresen suggested raising the block-size limit to megabytes– although this was never formalized into a BIP. A conglomerate of Chinese mining pools later indicated that 20 megabytes might be problematic, as “the great firewall of China” could limit the propagation of Bitcoin blocks over the network, and instead proposed a compromise to 8 megabytes. And since consensus was still not reached, Core developer Jeff Garzik recently submitted BIP102 to double the maximum block size to 2 megabytes in order to buy time to come up with better solutions. Naturally, every other size could be picked as a possible limit as well, whether it’s 4 megabytes or 400 gigabytes, or even a decrease in size as Core developer Luke Dashjr suggested.
A slight variation to this idea, as recently proposed by Core developer Sergio Lerner, is to hold onto the 1 megabyte limit, but speed up the block interval. If 1 megabyte blocks are found every five minutes instead of 10, that would allow for double the amount of transactions on the network while also decreasing confirmation times.
Solution 3: A Growing Cap
Arguably the biggest problem with a fixed cap – any fixed cap – is that it is hard to change. A change of the block-size limit requires a hard fork, meaning all users need to make the switch in order to not be left behind on the old blockchain. This is no easy feat on a decentralized network, especially if different participants of that network vary in their preferences. Furthermore, since the number of transactions on the Bitcoin network is optimistically expected to keep rising, while the cost of bandwidth and hardware is optimistically expected to keep falling, it is broadly assumed that the block size should grow over time.
This is why Andresen proposed a growing block-size limit. Based on Moore’s Law and Nielsen’s Law, his first public suggestion was to automatically increase the limit by 50 percent per year, which he later readjusted to 41 percent per year – or 100 percent per two years. Combined with an initial bump to 8 megabytes (a number picked in accordance with Chinese mining pools), he formalized this proposal in BIP101. Since it was not adopted by the Bitcoin Core development team, Andresen has programmed BIP101 into Bitcoin XT, to be triggered once 75 percent of hashing power has expressed support.
Another Core developer, Pieter Wuille, thinks Andresen’s preferred growth rate is much too progressive. Based on research by Blockstream colleague Rusty Russell, Wuille believes average internet connection speed will not be able to keep up with Andresen’s proposal. Wuille has, therefore, proposed to increase the block size limit by 17.7 percent per year starting in 2017, which he formalized in BIP103.
But much like the fixed cap, any set growth rate can theoretically be picked. Perhaps Russell’s revised figures – he now suggests 30 percent yearly growth should be OK – will lead to another BIP in the near future?
Solution 4: A Dynamic Cap
Regardless of the preferred figures, a set growth rate has its own problems. Most importantly, it typically includes predictions about the future – and no one can reliably predict the future. The growth of Bitcoin usage has proved to be rather unpredictable over the past years, and historic technological improvement rates defined by Moore’s Law or Nielsen’s Law are in reality not laws at all – rather, trends.
This is why some suggest that Bitcoin might need a dynamic cap instead of a fixed cap or a cap based on a set growth rate. A dynamic block-size limit would, much like the mining difficulty, readjust itself automatically, based on a pre-defined rule set. And again, there have been multiple ideas on how to define this rule set.
Another of Andresen’s suggestions is to readjust the block-size limit on the basis of the size of recent blocks. This in itself can be done in multiple ways, and Andresen agreed to take the average size of the last 144 blocks (about a day’s worth), and double it to represent the new limit. If the blocks of the past day were an average of 1 megabyte in size, the limit would automatically be set on 2 megabytes.
A similar proposal entailed to adjust the maximum block size once a certain threshold is reached. For instance, when a series of blocks would on average reach 90 percent capacity, the block size limit could automatically readjust upward. Or, if a series of blocks would not even reach 50 percent of the maximum allowed block size, the limit could automatically readjust downward.
But it’s also possible to use parameters not even directly related to the block size. The block-size limit could, for example, be linked to the total amount of fees in a block. Or it could be based on the mining difficulty, as proposed by Core developer Gregory Maxwell. As long as it’s an internal parameter, Bitcoin’s block size limit can be tied to it.
Solution 5: A Cap Chosen Through Voting
Almost all interesting dynamic cap suggestions, however, seem to have one common weakness: The data that informs the new dynamic cap on the block-size limit can often be manipulated. For instance, miners could send transactions to themselves in order to fill up blocks or to increase fees.
Therefore, a more transparent solution could be a direct vote, possibly on some kind of regular interval. This solution begs another question: Who gets to vote? An obvious option would be to allow all Bitcoin users a vote. But unfortunately, it’s not really possible to determine who Bitcoin’s users are, while it’s easy to game elections by posing as multiple entities.
However, it is possible to vote with bitcoin. This could easily be done by setting up burn-addresses as voting booths. Anyone could partake in the elections, though it would cost money to do so, as the bitcoin used to vote would be lost forever. This way, the side of the debate that is prepared to spend most bitcoin on its desired solution wins. Elections would literally, and intentionally, be up for sale.
It’s also possible to organize a one-bitcoin-one-vote election without the need to burn bitcoin. As endorsed by Core developer Peter Todd, bitcoin holders could vote on the block size with the bitcoin they control, meaning the biggest stakeholders in the Bitcoin economy would have most of the influence on the block-size limit.
And lastly, of course, there is the voting method that is already used to determine consensus within the Bitcoin network: hashing power. Hashing power currently gets to determine what the longest chain is, and it also could be used to vote on the block-size limit. This idea was formalized by Core developer Jeff Garzik in BIP100. BIP100 transfers the power to set the block-size limit from the Core development team to the Bitcoin miners by allowing miners to include a message into freshly mined blocks indicating they want to mine bigger – or smaller – blocks. If 90 percent of hashing power endorses either bigger or smaller blocks, the block-size limit will double or halve each 90 days.
As a possible downside of BIP100, miners – and especially large mining pools – would of course gain even more power over the network than what they have today. But at least it would be transparent.
Solution 6: Extension Blocks
A completely different solution is conceived by hashcash inventor and Blockstream CEO Adam Back. In what is perhaps the most advanced idea to date, Back proposed allowing so-called “extension blocks” on the Bitcoin network. In essence, extension blocks would be an opt-in solution. The 1 megabyte limit could remain intact, while users and miners who’d be willing to handle bigger blocks – say 10 megabytes in size – could run software to process these as well. This would introduce a new dimension to Bitcoin usage, as it would essentially create multiple blockchains with the same bitcoin – the 1 megabyte blockchain would simply be more secure than the 10 megabyte blockchain.
Furthermore, it would still be possible to accept, store and spend bitcoin on the 10 megabyte blockchain, while running only a full node for the 1 megabyte blockchain – or even no full node at all. Users could, for instance, run a full node for the 1 megabyte blockchain on which they store the bulk of their money, while using an SPV wallet for the 10 megabyte blockchain for day-to-day payments. Bitcoin would, of course, be transferable from the 10 megabyte to the 1 megabyte blockchain, though the decreased security on the 10 megabyte blockchain would suggest to wait for some extra confirmations before trusting the payment on the 1 megabyte blockchain.
Bonus Solution: Flexible cap
Finally, flexible caps deserve a mention. While not really a complete solution to the block-size issue as a whole – some type of limit still needs to be set somehow – flexible caps could relieve the Bitcoin network from a lot of stress. Separately proposed by Core developers Meni Rosenfeld and Gregory Maxwell, flexible caps don’t really have a hard limit on the maximum block size, but, instead, penalize miners for producing bigger blocks. As such, a sudden influx of new users, or a surge in transaction volume, would not lead to a severe backlog of transactions that could potentially crash the network. Instead, flexible caps would allow room for growth, while at the same time indicating the limit should be adjusted to improve network performance.
The Good News and the Bad News
The good news is that the block-size issue is being widely discussed by smart people coming up with inventive solutions. A number of new ideas have been proposed, while it’s also possible to combine different solutions into new proposals. A dynamic cap, for instance, could easily be combined with a voted cap. Or a flexible cap could be attached to a fixed cap. Or an extension block joined with set growth. It’s even possible to mix three or more solutions to construct a completely unique approach. And, who knows, maybe some genius mathematician or programmer will come up with an entirely novel long-term solution for the block-size issue.
The bad news, however, is that this long-term solution has probably not yet been conceived; every single possibility so far seems to effectively “kick the can down the road.” All sides of the debate acknowledge that Bitcoin will ultimately need additional scaling solutions built on top of the protocol layer, and possibly a revision of the funding structure to reward miners. Bitcoin is still an experimental work-in-progress, with no clear-cut solutions. In an often heated debate, that is the one thing practically everyone agrees upon.
Since its release on August 6th, Bitcoin XT, a patch set on top of the existing Bitcoin Core, has focused the bitcoin community’s attention on the block size debate. Core maintainers and highly influential CEOs alike, like Peter Smith of Blockchain and Steven Pair of BitPay, have entered the online fray, fueling passion-laden discussions across Reddit, Twitter, Medium, and GitHub.
Multiple solutions have been proposed to alleviate the block size debate, like 8MB blocks, 20MB blocks, and dynamic block size limits, among others. However, Bitcoin XT is gaining traction as a viable solution as it would create a hard fork in the protocol by permanently splitting the blockchain into two different ledgers. This fork will occur if 75% of miners adopt the new patch after January of 2016, and at that time, nodes running outdated versions of the software will not accept the valid larger blocks. One of the chief criticisms leveled at Bitcoin XT is the low threshold for adoption, with many core devs suggesting that 90% or 95% threshold for adoption would optimal. As of August 16th, 7.2% of all nodes were running Bitcoin XT, with the count growing steadily. Current statistics are available, updated hourly.
Gavin Andresen, Chief Scientist at the Bitcoin Foundation, and Mike Hearn, the creator of Bitcoin XT are the chief proponents and the public faces of the patch, actively engaging with those who do not support an increase to the block size limit. Andresen developed the current patch to Bitcoin XT, which implements his BIP101 proposal. Under BIP101, the maximum block size will increase from the current 1MB to 8MB, and will double every 2 years after that until it reaches 8,192MB.
In addition to an increased block size limit, Bitcoin XT includes several other changes to Bitcoin Core such as double spend relaying, anti-DOS measures, support for new apps that use partial transactions such as the Lighthouse crowdfunding app, and DNS seed changes.
Since Bitcoin XT is a patch to the current infrastructure, Core users will not be forced to redownload the entire blockchain. It is also important to note that at this time, running Bitcoin XT is equivalent to running Core. Bitcoin XT will create a hard fork from the current Core implementation only if a 75% majority is achieved.
Critics of Bitcoin XT often point to the inherent technical risks of a hard fork. In addition, many experts, including three out of the five Core developers, believe that an increased block size limit would cause significant problems for bitcoin’s infrastructure down the road. The larger blockchain, they argue, would force certain nodes to shut down as storage space requirements become unfeasible for privately owned nodes. As nodes close due to climbing costs, the network could shrink towards centralization.
“I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favored change on behalf of a special interest group, or working for bad actor” said Bitcoin Core developer Adam Back in an email.
Current attempts to debate Bitcoin XT’s feasibility, unfortunately, have been censored in many discussion forums. A single moderator on the Bitcoin subbreddit has been caught deleting “hundreds of, what appear to me, to be perfectly valid comments,” according to /u/jratcliff63367, another moderator. Since Bitcoin XT would create an alternative blockchain that’s incompatible with the current bitcoin blockchain, several moderators have called Bitcoin XT an alternative cryptocurrency and removed posts discussing the changes on the Bitcoin subreddit, instructing users to discuss the topic in alternative forums.
Despite the passionate conflicts, rational heads seem to have prevailed. As core developer Mark Friedenbach commented in a post, “[T]he block size limit should be raised, but only in step with what can reasonably be accomplished with engineering improvements to ensure a decentralized, policy neutral network. There are many in this space working to identify criteria for that, and a couple of different proposals for actually raising the limit in a way that would be more sensitive to these issues. All that we ask for is the time for due process, not ultimatums and hostile forks.”
