Dr Paul Ennis is a research assistant at The Centre for Innovation, Technology & Organization at University College Dublin, specializing in bitcoin and blockchain studies.
In this opinion piece, Dr Ennis discusses how bitcoin’s scaling debate has thus far evolved, examining the various competing efforts, their processes and what the differences say about the developer community and its culture.
Bitcoin’s scaling debate is clearly one of its defining moments.
It has pitted the user bases sharply against one another whether through endless Reddit debates, digital media or even at the “top” tier of the development teams. It also raised significant issues around centralization and bitcoin’s somewhat awkward relationship with the mostly China-based mining industry.
In this post, I will attempt to document different parts of the debate as it played out from different perspectives. I do not consider myself beholden to any specific strand and have attempted to be as neutral as is feasible. Corrections are always welcome.
The debate concerned a central technical issue that also had significant implications for how bitcoin is governed. For the Bitcoin Classic team, this meant, in essence, finding a solution that solved the filling of blocks due to high transaction volumes while also finding a way to move governance away from the Bitcoin Core development team and toward the mining community.
One of the first attempts to address this problem came from Mike Hearn, at the time a Bitcoin Core developer, in the form of BIP 64. BIP 64 was announced in June 2014, but the client Bitcoin XT (the “precursor” to Classic) emerged in December 2014.
Bitcoin XT never took off, but it indicated Hearn’s early belief in the necessity of a new approach to the scaling problem. However, there was support for XT from one notable group of the bitcoin network: namely the payment and wallet communities.
This is likely because the smaller the blocks, the more users have to pay in transactions fees and the slower the network becomes. Since these services are oriented toward people who want to make speedy transactions an expensive and slow network has negative effects on wider adoption.
Hard fork issue emerges
In June 2015, then chief scientist of the Bitcoin Foundation Gavin Andresen announced BIP 101. BIP 101 was rolled out in XT in August 2015, but it never really gained traction among the mining community.
However, the fact that such notable bitcoin developers were actively seeking to introduce a hard fork started a fierce debate over not just this technical issue, but also how changes in bitcoin should occur going into the future.
Since Bitcoin XT was not gaining support, a less drastic proposal to raise the block size was put forward through a hard fork that would increase the limit to 2 megabytes. Known as Bitcoin Classic, this fork was developed by crucial players in the wider bitcoin community, specifically Gavin Andresen and Jeff Garzik (founder of Bloq). The other developers were Pedro Pinheiro (Blockchain), Tom Zander and Jon Rumion.
There are discrepancies between the original release and Classic’s website on this front. On the site Peter Rizun is listed as a developer, but on the release as an external advisor. However, it is the names that appear on the release and not on the site that are most interesting for understanding the backstory of Classic.
The Classic release states that mining will come under Marshall Long, current CTO of cloud-mining service FinalHash. There is not much information beyond his name on the release as to his role with Classic (though he is well-connected enough to have attended the Satoshi Roundtable). Another interesting name is Jonathon Toomim, listed as an external advisor, who worked on Classic quite a lot before handing the reigns over to Andresen (who seems to have not wanted to develop it at first according to Guy Corem here).
Finally, Olivier Janssens is listed as a facilitator on the release (and a “user” on the Classic site). Janssens is a pretty influential player since he, along with Long, secured Toomim as the original developer for Classic. Janssens’ presence is important because, during his term as a board member of the Bitcoin Foundation, he leaked damaging details about the incompetent way it was run.
In many ways, then, Classic can be seen as an attempt to challenge the governance structure of the Bitcoin Foundation, currently not involved in development, but also, more importantly, the Bitcoin Core development team as such.
The two motivations for Classic can broadly be seen in Garzik’s BIP 100, which essentially would see the miners decide on the appropriate block size and his compromise BIP 102, which would have increased the block size to 2MB as a compromise to ensure blocks did not become too full (aimed at solving the problem of slow and expensive transactions in the immediate term).
How this played out will go down in bitcoin folklore for sparking one of the most contentious, but also fascinating, debates about what bitcoin should be and next time we will turn to how the miners reacted to the introduction of Classic into the ecosystem.
Bitcoin Core
In this section, I need to do some legwork regarding the Bitcoin Core development team and their development process.
This is required because bitcoin is unusual in organisational terms because it is, by design, a nominally decentralised network (with no leader or an “absent” one). Nonetheless, there are quasi-hierarchies operative. Chiefly between the developers and the mostly Chinese miners. How is consensus arrived at? The question is immensely complex when we are referring to the wider bitcoin ecosystem, but the straight-up development process is much more direct.
Bitcoin development is open to any developer interested in the project.
Most of its activity occurs at the Bitcoin GitHub repository. The software that is developed is known as Bitcoin Core; and it is open-source. It is important to note that although this is the dominant venue, discussion also occurs on a mailing list known as bitcoin-dev. There is also an IRC (Internet Relay Chat) channel that is more informal and that is logged (irc.freenode.net #bitcoin-dev).
Generally, the process involves users suggesting “pull requests” that are akin to suggestions that have been put up for review by other developers. Their purpose is to patch or improve the codebase.
It’s not uncommon to see some proposals, suggestions or debates turn up in the bitcoin reddit communities or dedicated bitcoin forums.
How Core works
A large number of the Bitcoin Core developers listed have contributed once to the repository.
Another subset have contributed between two and 10 times. From there, the numbers thin out until we arrive at what can be termed the core, in the normal sense, development team who exist because ‘some hierarchy is necessary for practical purposes.
As such there are repository “maintainers” who are responsible for merging pull requests as well as a “lead maintainer” who is responsible for the release cycle, overall merging, moderation and appointment of maintainers.
In other words, there is no official Core developer team, but there are maintainers and a lead maintainer. It is these individuals who have the final say on whether a patch becomes a part of Bitcoin Core. If the patch fixes a relatively minor issue, the process follows the broad criteria that ‘a patch is in line with the general principles of the project; meets the minimum standards for inclusion; and will judge the general consensus of contributors.’
For the academically inclined this process is akin to peer-review, but less formalised.
More interesting is when the patch relates to consensus rules since these are fundamental to the nature of bitcoin.
They require a far more rigorous process and such suggestions will tend to be listened to only when they come from lead developers. The scaling debate is one area where this became quite clear to even those looking at bitcoin from outside.
It is important to make a quick distinction here.
It is possible in bitcoin to implement a “soft fork” that might, for instance, improve or fix a relatively minor issue. Users will not be required to update their software, but would be encouraged to do so. With a hard fork, everyone needs to upgrade to the new implementation. Since a hard fork “breaks” or discards an old rule essential to the current protocol, it is possible for two distinct blockchains to emerge with rules that are in contradiction to one another.
Hard forks are, then, unsurprisingly contentious since they introduce the possibility of a split. That technical split can always lead to the possibility of a community split.
Minor notes
A few other small notes are worth mentioning: many people may have come believe BIPs (Bitcoin Implementation Proposals) refer to some kind of platform for suggestions that require a hard fork.
This is very much an effect of the scaling debate where competing BIPs were, in fact, often being produced as simply competing ideas for how best to scale (or not). Indeed, some BIPs simply provide information. Many BIPs have been applied, but many have not. Some have been withdrawn and some are in stasis.
They are complicated, but in the scaling debate they did emerge as a clear means for competing visions of how to proceed with bitcoin in general.
Now it is important to remember that sometimes developers become dormant or are presumed to be completely inactive. For instance, the inventor of the BIP system, Amir Taaki, was once highly visible in the world of bitcoin, but has ceased to actively engage in it.
There are also, I must stress, a huge number of people I will be overlooking in what follows and they include very important (albeit less vocal) contributors to Bitcoin Core. Some developers are simply quiet and plug away in the background.
For those who have no discernible stake in the public debates, I have left them aside.
The Core team
Now, technically those who worked on Classic never stopped working on Core per se.
For example Gavin Andresen (BIP 101) has always been seen as central to Core. He was also famously the Chief Scientist at the Bitcoin Foundation (paid) and now is funded by the MIT Media Lab Digital Currency Initiative. Jeff Garzik (BIP 100/102) will always be an important figure. Mike Hearn is no longer engaged with bitcoin at all and has moved to R3CEV.
It is, of course, Hearn’s dramatic exit from bitcoin that really heated things up with the scaling debate.
Now, alongside Andresen at the MIT Media Lab initiative we find Cory Fields who has never been too vocal. Then we have Wladimir J van der Laan with the MIT initiative as well (both were also funded by the Bitcoin Foundation).
Van der Laan is also the lead maintainer and often appears to be the more senior of the other two maintainers, namely Jonas Schnelli and Marco Falke. Neither of these played an especially vocal role in the scaling debate, although Schnelli is a far more visible figure. Those who are not maintainers, but did have more to say about the scaling debate include Eric Lombrozo, CEO of Ciphrex.
There are a few more members of Bitcoin Core we need to focus on.
First let me focus on the relationship of Core to Blockstream (founded, 2015).
Blockstream is a distinct entity from Core in as much as it is a funded venture (see here and here). Core developers such as Jorge Timón and Matt Corallo are amongst a concentration of Core developers under the Blockstream banner. In other words, it’s really Blockstream that funds the highest number of Core developers.
Therefore it’s essential to understand what Blockstream is actually attempting to do. We’ve not yet covered everybody we want to at Core, but first we need to take a quick diversion.
Blockstream is oriented toward the development of sidechains and was originally announced by hashcash inventor Adam Back and Austin Hill (neither of whom are Core developers). Sidechains are useful for a number of reasons, but not least that they offer a way to innovate without introducing a hard fork.
Such an alteration in the consensus rules takes time. For those committed to the decentralist perspective, and for whom technical shifts in Bitcoin ought to be handled with extreme care sidechains offer a solution. To be precise, we are discussing pegged sidechains which are, more or less, custom blockchains to the “side” of the bitcoin blockchain.
In many ways, a company like Coinbase is basically a quasi-sidechain. When you send bitcoins there they are going off the usual peer-to-peer grid. Coinbase will likely have a pool of bitcoins, a reserve (liquidity) and what you move out might not be the same coins. So it acts as a quasi-sidechain in as much as it unsettles the usual ethos of Bitcoin where each person is demonstrating they own the private key to spend some coins.
But the bonus is that you can do things pretty fast with Coinbase. And, of course, this was a crucial argument made during the scaling debate: namely that we should focus on improving transaction speed along these lines as the most important concern for a digital currency.
Overall, sidechains basically follow the “sandboxed” model. By isolating the sidechain from the main chain – while allowing for transferability of the asset – it becomes possible to take more risks. You don’t want to set out to break your sidechain, but you won’t lose everything if you do.
It works in much the same way that sandboxing your browser means a browser bug won’t end destroying your entire operating system. Furthermore, your bitcoins are never at risk since they are merely acting as tokens on or for the sidechain. Pretty quickly, perhaps due to a lack of adoption, Sidechain Elements was announced.
Elements was more functional, making life easier for adopters, but it contained a subtle feature known as Segregated Witness. Segwit was the idea of Gregory Maxwell, Core developer, and also a member of Blockstream. The original outline of segwit would require a hard fork, but, fortunately, Luke Dashjr came to the rescue (details here) with a method that would allow it to be a soft fork.
Segwit was, after Maxwell’s conceptualisation and Dashjr’s fix, coded by the final member we should name, the brilliant coder Dr Pieter Wiuelle (of Blockstream) – with input, as with most bitcoin endeavours from fellow developers.
Segwit is now moving forward, though an exact timeline for its release has not been indicated.
This is post is part one and two of a series by Dr Ennis, republished here with his permission. For future posts, follow Dr Ennis on Medium.
Skeleton image via Shutterstock