Lesson 16

Reflections on "Don't Trust, Verify"

"Now for the evidence," said the King, "and then the sentence."
Read by Guy Swann.

Bitcoin aims to replace, or at least provide an alternative to, conventional currency. Conventional currency is bound to a centralized authority, no matter if we are talking about legal tender like the US dollar or modern monopoly money like Fortnite’s V-Bucks. In both examples, you are bound to trust the central authority to issue, manage and circulate your money. Bitcoin unties this bound, and the main issue Bitcoin solves is the issue of trust.

“The root problem with conventional currency is all the trust that’s required to make it work. […] What is needed is an electronic payment system based on cryptographic proof instead of trust” Satoshi

Bitcoin solves the problem of trust by being completely decentralized, with no central server or trusted parties. Not even trusted third parties, but trusted parties, period. When there is no central authority, there simply is no-one to trust. Complete decentralization is the innovation. It is the root of Bitcoin’s resilience, the reason why it is still alive. Decentralization is also why we have mining, nodes, hardware wallets, and yes, the blockchain. The only thing you have to “trust” is that our understanding of mathematics and physics isn’t totally off and that the majority of miners act honestly (which they are incentivized to do).

While the regular world operates under the assumption of “trust, but verify,” Bitcoin operates under the assumption of “don’t trust, verify.” Satoshi made the importance of removing trust very clear in both the introduction as well as the conclusion of the Bitcoin whitepaper.

“Conclusion: We have proposed a system for electronic transactions without relying on trust.” Satoshi Nakamoto

Note that “without relying on trust” is used in a very specific context here. We are talking about trusted third parties, i.e. other entities which you trust to produce, hold, and process your money. It is assumed, for example, that you can trust your computer.

As Ken Thompson showed in his Turing Award lecture, trust is an extremely tricky thing in the computational world. When running a program, you have to trust all kinds of software (and hardware) which, in theory, could alter the program you are trying to run in a malicious way. As Thompson summarized in his Reflections on Trusting Trust: “The moral is obvious. You can’t trust code that you did not totally create yourself.”

Thompson demonstrated that even if you have access to the source code, your compiler — or any other program-handling program or hardware — could be compromised and detecting this backdoor would be very difficult. Thus, in practice, a truly trustless system does not exist. You would have to create all your software and all your hardware (assemblers, compilers, linkers, etc.) from scratch, without the aid of any external software or software-aided machinery.

“If you wish to make an apple pie from scratch, you must first invent the universe.” Carl Sagan

The Ken Thompson Hack is a particularly ingenious and hard-to-detect backdoor, so let’s take a quick look at a hard-to-detect backdoor which works without modifying any software. Researchers found a way to compromise security-critical hardware by altering the polarity of silicon impurities. Just by changing the physical properties of the stuff that computer chips are made of they were able to compromise a cryptographically secure random number generator. Since this change can’t be seen, the backdoor can’t be detected by optical inspection, which is one of the most important tamper-detection mechanism for chips like these.

Stealthy Dopant-Level Hardware Trojans by Becker, Regazzoni, Paar, Burleson

Sounds scary? Well, even if you would be able to build everything from scratch, you would still have to trust the underlying mathematics. You would have to trust that secp256k1 is an elliptic curve without backdoors. Yes, malicious backdoors can be inserted in the mathematical foundations of cryptographic functions and arguably this has already happened at least once. There are good reasons to be paranoid, and the fact that everything from your hardware, to your software, to the elliptic curves used can have backdoors are some of them.

“Don’t trust. Verify.”

The above examples should illustrate that trustless computing is utopic. Bitcoin is probably the one system which comes closest to this utopia, but still, it is trust-minimized — aiming to remove trust wherever possible. Arguably, the chain-of-trust is neverending, since you will also have to trust that computation requires energy, that P does not equal NP, and that you are actually in base reality and not imprisoned in a simulation by malicious actors.

Developers are working on tools and procedures to minimize any remaining trust even further. For example, Bitcoin developers created Gitian, which is a software distribution method to create deterministic builds. The idea is that if multiple developers are able to reproduce identical binaries, the chance of malicious tampering is reduced. Fancy backdoors aren’t the only attack vector. Simple blackmail or extortion are real threats as well. As in the main protocol, decentralization is used to minimize trust.

Various efforts are being made to improve upon the chicken-and-egg problem of bootstrapping which Ken Thompson’s hack so brilliantly pointed out. One such effort is Guix (pronounced geeks), which uses functionally declared package management leading to bit-for-bit reproducible builds by design. The result is that you don’t have to trust any software-providing servers anymore since you can verify that the served binary was not tampered with by rebuilding it from scratch. Recently, a pull-request was merged to integrate Guix into the Bitcoin build process.

Which came first, the chicken or the egg?

Luckily, Bitcoin doesn’t rely on a single algorithm or piece of hardware. One effect of Bitcoin’s radical decentralization is a distributed security model. Although the backdoors described above are not to be taken lightly, it is unlikely that every software wallet, every hardware wallet, every cryptographic library, every node implementation, and every compiler of every language is compromised. Possible, but highly unlikely.

Note that you can generate a private key without relying on any computational hardware or software. You can flip a coin a couple of times, although depending on your coin and tossing style this source of randomness might not be sufficiently random. There is a reason why storage protocols like Glacier advise to use casino-grade dice as one of two sources of entropy.

Bitcoin forced me to reflect on what trusting nobody actually entails. It raised my awareness of the bootstrapping problem, and the implicit chain-of-trust in developing and running software. It also raised my awareness of the many ways in which software and hardware can be compromised.

Bitcoin taught me not to trust, but to verify.

    Down the Rabbit Hole