One of the foundational principles of Nakamotoan cryptocurrencies is the faith in Open Source Software. Specifically, open source communities, especially cryptography and security communities, build trust in software by publishing and sharing the source code. The idea is that many eyeballs assure both quality and authenticity. In addition, you always have the option to build it yourself, so you can know exactly what you are getting, in principle. (There is also a psychological benefit in this transparency: we’re all in it together, and everybody knows everything.)
Bitcoin and many cryptocurrencies use this approach, too. The idea is that you know that there aren’t any secret gotchas hidden in the code, and also, you hope that lots of people have checked for bugs.
In other words, open source is a crucial mechanism for creating “trust” in the software and protocols, without having to trust a single centralized source. “Trustless trust” is the essence of Nakamotoism.
Problem solved, right?
Software depends on a massive web of dependencies (it’s much more complex than the conventional term, “stack”), and you are essentially trusting everything that your software depends on. Even if you build the software yourself, you are trusting software libraries, the operating system, and the build tools (and see  about “trusting trust”). Frankly, Ii’s hard to even know what you are trusting, because it’s hard to know what these dependencies are.
In the case of Bitcoin, you might decide to download the source code, check it, and build your own copy. (Note that you might well need other software, such as a wallet, or and API, which is yet more code to trust.) Doing such a build is, well, quite an experience. I remember building a very early alpha version of gnu C++ from source. It took a week. The last step was to rebuild the compiler using the version of the compiler you just built with another compiler….
Nevertheless, this build process gives you a certain trust that you know what the code really does. At least theoretically.
However, even this build requires you to trust a bunch of other entities: the source of the code, the tools used to download and build, and even the tools used to read the code. You also have to trust the operating system (which is many millions of lines of code), the network, and so on.
Yoiks! What’s a programmer to do?
Normal people tend to break out of this mental spiral, by deciding to trust someone. For instance, most of us trust our operating system and language tools. And our own computer. And our own network (though that’s a closer call). And so on.
But all this “trust” just doesn’t cut it for true Nakamotoans. The whole notion of Bitcoin is to have a “trustless” system. So what can be done?
Alyssa Hertig reports on work by Carl Dong, who is implementing support to enable “reproducible builds” for Bitcoin core code . The basic idea is to document (in executable form) all the dependencies and steps in the build, so you can be assured that what you have is what you think you have. Or at least, to assure that you can build it exactly the same way over and over.
This is clever and useful stuff. It is called configuration management, and it is a standard part of software engineering. Serious software engineering projects have been doing this for decades, especially for security sensitive and mission critical code. So, yes, this is a good idea.
Does this make the build process more “trustless”? No, of course not. We are still “trusting” all kinds of stuff, mostly in ways we don’t know about (and can’t do anything about anyway).
The thing is, the software build depends not only on the software you use directly, but on the whole shebang: the operating system, the network, and, I’m sorry to have to remind you, the hardware in all the computers and networks involved. The configuration management described is a very good thing, but it’s really only the tip of the iceberg of the dependencies.
Configuration management makes the Bitcoin build sort of trustless, but not completely. It’s better but is it good enough? I dunno. Obviously, Dong thinks it is worth the trouble.
But this raises a different question: is there any such thing as “trustless” computing?
Personally, I think the answer is no.
It’s obviously infeasible to even understand the dependencies of any non-trivial computing system. Worse, the entire concept of a “trustless” system is basically about “trusting” logical proofs. E.g., using cryptographic signatures to validate software is actually based on a proof that it is very, very, very unlikely that this is a forgery. If you trust the proof, you trust the signature. But should you trust the proof? That’s hard to know for sure.
A true Nakamotoan believes that a mathematical proof is more trustworthy than any human being (other than yourself). And I hate to be the one who tells you this, but that means you are placing faith in unprovable and unknowable abstractions.
My own view is that this whole deal about “trust” should be taken as a sort of Bayesian problem, in which we have to take estimates of trustworthiness, evaluate evidence, and make decisions about “how much trust is enough”. It is never going to be possible to have 100% trust, and, more important, “trust” is a subjective value in the Bayesian sense.
In this view, technical measures such as Nakamotoan consensus and the configuration management discussed by Hertig are confidence building exercises that push our posterior trust higher.
If my priors are different than yours (either more or less trusting), a given engineering practice will have greater or lesser impact on my posterior than yours.
From this perspective, we can see that much of the talk about “trustless” systems is rather misguided, or at least poorly defined.
“Trust” is a subjective value held by a human, and Nakamotoan “trustless” systems are actually systems designed to have specific kinds of trust (math proofs) and not others (third parties on the network). Claims about “trustless” are arguments that must be taken in the context of your own priors.
In this light, technical innovations have a significant psychological component in them, and that means that they have different value for different people.
I would say that Nakamotoans have extremely high prior distrust of governments and corporations, high prior trust of cryptography, and high prior trust in “markets”, among other things. Nakamotoan cryptocurrencies deploy a suite of technical measures that aim to push these priors to a high posterior “trust” in the overall system, without trusting governments or corporations. (If this paragraph is logically muddled, it’s probably because Nakamotoans use the term “trust” in more than one way.)
Non-Nakamotoans may start with different priors, and so the same technical measures may result is different posterior “trust” in the system. For example, a low prior trust of “markets” may mean that Nakamotoan consensus protocols do not produce high posterior trust in the overall system.
In short, There Aint Any Such Thing As A Trustless System. But…good engineering is always better than poor engineering.
- Alyssa Hertig (2019) ‘Building’ Bitcoin’s Software Just Got a Bit More Trustless. Coindesk, https://www.coindesk.com/building-bitcoins-software-just-got-a-bit-more-trustless
- Ken Thompson, Reflections on trusting trust. Communications of the ACM, 27 (8):761-763, August 1984. https://dl.acm.org/citation.cfm?doid=358198.358210