Scaling Bitcoin, Slowly but Surely

The first Scaling Bitcoin developer workshop took place in Montreal this September.

The “no exhibit booths, no distractions” two-day conference was actually the first major get-together of Bitcoin core developers and researchers, while a Phase II workshop has been scheduled for December 6-7, in Hong Kong so the Chinese miners can weigh in as well.

Beyond Block Size

The workshops were announced just after the block size debate between developers (if and how to increase the the block size to handle growing transaction volume) flared up, culminating with the Bitcoin XT attempt at a hard fork solution. Gavin Andresen, the most senior developer behind Bitcoin XT, attended and talked with other influential devs. Yet only a minority of the Montreal workshop was devoted to the block size issue, with only a rough consensus that the limit ought to be raised modestly.

However, no time frame was set for deploying any specific solution. In fact, the FAQ reads

Absolutely no decisions are made at workshops. The workshop is about raising awareness of issues and proposals, finding common ground, and encouraging public discussion within the existing mechanism of technical progress through the Bitcoin Improvement Proposal (BIP) process.

So instead of formalizing BIPs, the devs had a meeting of the minds about the bigger puzzle of enabling Bitcoin to scale. Topics ranged from handling the scheduled halving of the block reward in 2016 to unlikely edge-case threats, and from incremental improvements to brand new approaches, such as the Bitcoin NG proposal to add 10-second transaction-only blocks between the 10-minute reward blocks.

The schedule included expert presentations as well as over a dozen round table discussions followed by short and sweet wrap-ups. You can view videos of presentations and wrap-ups or listen to podcasts of the wrap-ups on LetsTalkBitcoin episodes 254 and 253.

Bit-Anthropology

Among the non-technical presenters was Gabriella Coleman, an anthropologist of how communities have been forming around open source projects (OSPs), starting with the Debian Linux in the 1990’s. Coleman pointed out that regular face-to-face meetings have been crucial for longevity and success of OSPs.

In the absence of a benevolent dictator who is usually also the founder, OSPs tend to govern themselves by reaching a general consensus, rather than by voting of committees or members. General consensus, in turn, is hard to reach without face-to-face meetings, as online forum discussions invariably get sidetracked, spammed, misunderstood, heated, and even vitriolic.

The founder of the Bitcoin project, Satoshi Nakamoto, was also its effective benevolent dictator until 2010, when he handed off the project to Gavin Andresen and went silent. As of 2015, however, no one developer has the skills, the peer support, and most importantly, the resolve to fill Satoshi’s shoes.

Unfortunately, decentralized consensus is not as smooth among people as it is among Bitcoin nodes, so the face-to-face forum was long overdue.

Such Controversy

One of the round tables was on why people are more touchy when it comes to modifying Bitcoin, compared to other OSPs. A few reasons were suggested in the wrap-up.

First, hard forks, the kind that require everyone to upgrade, are hard to swallow for many Bitcoiners. If a significant minority does not upgrade for some reason, the whole network becomes weaker or even forks.

Second, there are ideology differences on how decentralized and accessible the project and its infrastructure should be. Must changes always wait for overwhelming consensus, or is it time for a benevolent dictator? Can the network be scaled to handle every “cup of coffee” payment or should smaller transactions happen “off-chain”?

Third, even when sharing the same ideology, there’s disagreement about how a certain protocol tweak will impact the various parts and players of the Bitcoin ecosystem, and whether it’s worth the risk of introducing new bugs or vulnerabilities.

Technical Puzzles

Since tweaking Bitcoin involves many moving parts, the trade-offs are hard to optimize by thought experiment alone. One of the round tables brainstormed about computer-modeling the effects of a tweak, as well as finding ways to monitor the network beyond what can be gleaned from the blockchain itself, such as node configurations and node-to-node traffic statistics. This deeper kind of monitoring could also detect abnormal patterns and give early warning of an attack.

There was also a round table about privacy. Ironically, although Bitcoiners tend to value anonymity and plausible deniability, the current protocol makes maintaining those quite a challenge. In an environment of censorship, not only would some individuals have to fear retribution for making certain transactions, but the bitcoins used in those transactions would become tainted and less desirable for others. This is known as the fungibility issue. Miners might also be put under pressure to censor transactions. Several privacy enhancing solutions were offered, but the catch is any solution would have to be used by everyone, lest one careless user ruin the privacy of those he transacts with.

Help Needed

There were also discussions of the social challenges and opportunities of scaling Bitcoin. There is a shortage of full-stack developers, so companies ought to give back by bringing on interns who are passionate about Bitcoin to learn from the seasoned professionals. Meanwhile, if the core devs have a specific technical challenge, they should reach out to Bitcoin-agnostic experts, say, from the Linux or CDN communities, who should be glad to help just because of their personal love for specific technical challenges.

Moreover, the Bitcoin community should make friends with academia, like it already has at MIT. Lots more computer science and security academics could be working on their tenure while doing research for the benefit of Bitcoin. Also, the Bitcoin community has what to learn from the academic process, despite its stuffiness. Bitcoin projects need better documentation and more rigorous peer review, organized in the likes of academic journals, so a newcomer would not have to search across spammy or redundant mediums like bitcointalk.org, IRC, reddit, mailing lists, or even have to track down a specific developer to find out what’s happening with a project and how to contribute.

Photo by rawpixel.com on Unsplash