Last week saw the release of the 0.16.3 version of the Bitcoin Core client, an update which repaired a bug known as CVE-2018-17144. The bug is widely considered one of the most serious ever discovered in the bitcoin code; it could have allowed not just the malicious shutdown of major portions of the network, but the creation of new bitcoin out of thin air. That gave it the potential to fundamentally undermine both the value of every bitcoin in existence, and faith in the integrity of the bitcoin network as a whole.
According to the Core team, the vulnerability had by last Thursday already been patched on more than 50 percent of all bitcoin nodes, and there’s no evidence it was ever exploited. But that doesn’t mean the threat has passed. The discovery of the bug has triggered a round of soul-searching and recrimination among developers and the broader bitcoin community, in part because it demands a question with no easy answer: Who’s actually responsible for making sure bitcoin doesn’t break?
The bug appears to have been introduced in an optimization update to the Bitcoin Core client software made on November 10, 2016. The code was originally proposed by Matt Corallo, one of the longest-serving active bitcoin developers. As with most team projects, especially open-source software, that doesn’t mean Corallo is is to blame for the bug’s introduction or endurance: These sorts of updates are supposed to be subject to a rigorous public review process, both when introduced and on an ongoing basis. In this case, those processes apparently failed repeatedly for nearly two years.
If something is everybody's responsibility, then it's nobody's responsibility.
That was the ultimate point of a startling declaration made Sunday by John Newberry, a Core contributor employed at Chaincode Labs. “I am responsible for the CVE-2018-17144 bug,” he wrote on Twitter. “I spend my days reading the Bitcoin Core codebase. [The flawed code] should have jumped out at me . . . Instead of verifying for myself, I trusted that people smarter and wiser than I am had it covered. I took it for granted that someone else had done the work.”
Newberry’s point is rhetorical. He’s not saying he’s specifically responsible for the potentially catastrophic problem, but that every member of the bitcoin development community should shoulder some blame. Newberry was, significantly, piggybacking on comments made by Wladimir van der Laan, lead maintainer for the Bitcoin Core development team: “The whole community screwed up by not reviewing consensus changes thoroughly enough,” Van der Laan wrote. “More developers need to pay attention! It’s your all responsibility.”
This is theoretically correct. The name “Bitcoin Core” might lead you to think a certain group of people are responsible for maintaining and developing bitcoin itself, but Core is just the most enduring and trusted of many “clients” that interact with the bitcoin blockchain. Core itself is an open-source project guided by an open-access system of discussion, proposals, review, and approvals, now conducted largely on Github. Anyone can participate in the process. Furthermore, anyone who disagrees with the Core group’s collective decisions can create an alternate client, which in some cases will create a new currency via fork—that’s how Bitcoin Cash was born.
But there is a serious flaw in that loose structure, rooted in a psychological phenomenon known as “diffusion of responsibility.” The phenomenon can be summed up by the dictum that “If something is everybody’s responsibility, then it’s nobody’s responsibility.” It’s the very tendency that Newberry confessed to—the assumption that, in a group effort, “people smarter and wiser than I am had it covered.” It’s why so many of us wait for our roommates to clean the dishes, and why groups of people sometimes ignore individuals in distress (known as the “bystander effect”).
Exhortations that “the whole community” of developers take responsibility for bitcoin’s integrity are welcome, but they don’t fundamentally change that psychological reality. One long-term solution would be to create a true locus of responsibility in the system—but that would certainly also involve an unacceptable concentration of power. And of course, centralized organizations are far from immune to error.
A more palatable alternative would simply be to increase the amount of developer talent focused on the underlying bitcoin protocol, but that’s easier said than done. When bitcoin was created, developers were basically hobbyists, and many contributors to Core and other cryptocurrency projects still donate their time.
The flood of money into the ecosystem in recent years, however, has created major competition for skilled blockchain engineers, and efforts to pay devs to focus on bitcoin have been spotty. The most notorious example is the Bitcoin Foundation, which was launched partly to support bitcoin developers but has been in major trouble almost since its inception. In 2015, the Foundation nearly ran out of money, and three Core developers it had been supporting—including Van der Laan—were taken under the wing of MIT’s Digital Currency Initiative.
Individual companies in the crypto ecosystem have also encouraged their staff to contribute to Core, and occasionally assigned individuals to the task more or less full-time. But that comes with its own issues, including conflict of interest. For instance, in the run-up to the Bitcoin Cash split, critics questioned Blockstream employees’ large role in Core development, since Blockstream, a for-profit entity, might benefit from a small-block vision of bitcoin’s future.
Of course, the problem of diffuse responsibility hasn’t stopped a large array of open-source projects from being very successful. I’m typing this, for instance, using LibreOffice, an excellent open-source word processor. But there is little precedent for an open-source project with as much on the line as bitcoin—a bug in my word processor wouldn’t endanger a $115 billion global financial network.
This is arguably the core (zing) puzzle at the heart of cryptocurrency development. True decentralization means that no one has true responsibility. In theory, public review processes invite widespread, democratic scrutiny of code, but in practice, human energy and expertise are limited, and competing interests can undermine the integrity of those processes. Sounder nonprofit support—perhaps from the B Foundation recently proposed by Alena Vravona and Giacomo Zucco—could mitigate the conundrum. Alternately, blockchains including Decred and EOS have built-in developer funds that will (in theory) be democratically distributed.
Of course, even those solutions don’t guarantee we won’t see another major bitcoin bug, or that such a bug would be caught before it caused major havoc. And, of course, bitcoin’s open, community-driven structure has worked fairly well for nearly a decade. Maybe we can all just cross our fingers and hope things continue peacefully on toward the moon.