The War of Implementations or The Bitcoin Gatekeepers – Trustnodes

The War of Implementations or The Bitcoin Gatekeepers


All was peaceful yesterday until suddenly the Breaking Bitcoin conference stood up to its name and Christopher Jeffrey, a bitcoin developer and CTO at Purse, revealed a vulnerability.

He apparently randomly stumbled upon it in the process of re-implementing bitcoin in a different coding language than C++. He says he told all implementations about the vulnerability, all had fixed it, except for Bitcoin Core, the client that currently has some 90% network use.

Blockstream’s CTO, Gregory Maxwell, says Bitcoin Core had a fix for it all the way back in April, it was merged in June, but not released. Why not, remains a bit of a puzzle.

The public is told because it needed testing, but of course that’s not credible considering the many months. They’re also told the release process takes time, but again, considering the damage that could have potentially been done by a black hatter, that excuse is not credible either.

Regardless, Jeffrey seemingly thought its public disclosure was important because it shows just how dangerous one implementation, upon which the entire network relies, can be. Either due to its developers oversight, incompetence, lack of resources, lack of good judgment on priorities, or whatever else.

That gives the episode a political dimension, which explains the contradictory over-reaction of some Bitcoin Core developers who on one hand say the bug takes months to exploit so there was no urgency and on the other hand publicly argue about responsible disclosure, but are in practice attacking this very idea of multiple-implementations.

Despite claims of decentralization and a Bitcoin Core team with hundreds of developers, the way open source works can be very centralized. There is only one man, for example, the maintainer, who ultimately decides what exactly goes into the code.

Gavin Andresen, the first bitcoin maintainer after Nakamoto, tried to make this process a bit more decentralized in bitcoin. There are five committers in total who act as sort of gatekeepers with decision power over what to merge. One of them is Pieter Wuille, a Blockstream employee. He is the one Jeffrey told about the bug. Why him and not the current maintainer, Wladimir van der Laan, is not clear.

Wuille reports to Maxwell at Blockstream. Maxwell is closely connected to Peter Todd, if in nothing else but in worldview as far as bitcoin is concerned. The latter had this e-mail exchange with John Dillon, who tells him:

“Every time anyone tried mining with [an alternative implementation], I’d use my knowledge of all the ways they are incompatible to fork them, making it clear they can’t be trusted for mining. Then I’d go a step further and “for the good of Bitcoin” create a process by which regular soft-forks and hard-forks happened so that Bitcoin can be “improved” in various ways, maybe every six months. Of course, I’d involve those alternate implementations in some IETF-like standards process for show, but all I would have to do to keep them marginalized and the majority of hashing power using the approved official implementation is slip the odd consensus bug into their code.”

Adam Back, Blockstream’s CEO, has occasionally proposed an “IETF-like standards process.” Moreover, when Bitcoin Unlimited nodes were sent down crashing, the reason was found to be an odd use of asserts in live production. That has led to a theory that Bitcoin Core developers may intentionally be placing or leaving bugs in the code as a way to discredit other teams or implementations.

What Jeffrey did, undermines that practice if it is indeed being practiced. The over-reaction, therefore, may have been more aimed at making an example of those who reveal such vulnerabilities as that may undermine a potential strategy for their exploitation for political means.

As there would be no direct monetary profit, an exploitation of the bug Jeffrey revealed would be of no interest to a talented black hater. But to a politically inclined coder, who may have aims of inserting himself as the gatekeeper of bitcoin by attempting to force the network to only use his implementation, the bug Jeffrey revealed can be very valuable.

Sending nodes crashing can sound scary to the general public, even though you just restart it with the bug fixed in two three hours. Once they are scared, you can tell them to trust you, the experts, who have maintained bitcoin bug free – even though bitcoin has had plenty of bugs. Dillon lays it out very well, he says:

“Gavin and the Bitcoin Foundation’s ability to control the core Bitcoin protocol is entirely based on the fact that almost all the hashing power uses the source code at”

The Bitcoin Foundation has long ceased and Gavin is no longer involved in Bitcoin Core coding. Dillon’s statement, however, is probably true, but Gavin, for unknown reasons, voluntarily gave up the power he was entrusted with by Nakamoto himself and went on to launch another implementation, in effect starting from scratch, so weakening himself considerably.

That power is now entrusted to other Bitcoin Core developers, the most vocal of whom are strongly against multiple implementations. Dillon explains why well:

“If even just a quarter of the hashing power used the Dark Wallet node implementation, and could trust it because the !@#$ thing actually implemented the Satoshi protocol properly by using that protocol’s source code, changing that protocol in fundemental ways would be far harder – Dark Wallet would have a lot more genuine political weight.”

Dark Wallet can be replaced here for whatever other alternative implementation. If mining was more diverse in its use of bitcoin clients, there could not be one man, nor one group, that decides what code goes live.

There would, instead, need to be co-operation between multiple teams, and if something is unreasonable, then it would not be able to go anywhere.

As things currently stand in bitcoin, the entire network trusts a small number of people not to act in their own self interest, but in a beneficial manner to all. A proposition that experience has long shown to not hold.

We have to trust they won’t slip an odd bug here or there, or that they won’t collude for their own gain, either directly or indirectly, in the short term or long term.

In effect, a one implementation currency is a centralized currency. There is always the option of forking, but that option creates a new currency. Within each currency, if there is only one implementation used by 90%, then whoever codes that implementation has considerable power to which even miners can not stand as we saw with UASF.

The only solution to avoid centralization, therefore, is multiple implementation. A solution Bitcoin Core will most likely strongly resist, but they have no say. All that is needed is a development team and miners who voluntarily choose to run their code.

Multiple implementations is not a perfect solution because it could give rise to inadvertent consensus failures. However, with the release of each new bitcoin client, there become, in effect, two implementations. The old and the new, which has led to consensus failures in bitcoin a number of times.

That argument, therefore, does not apply any more than it does currently. And, in our view, is far weaker in disadvantage than the considerable benefit of a trustless development team.


Comments (1)

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>