Author: bitcoindevphilosophy
This chapter dissects the concept of "trustlessness," explains its meaning from a computer science perspective, and clarifies why Bitcoin must be trustless to maintain its intrinsic value. We then discuss what "using Bitcoin in a trustless manner" means, what guarantees a "full node" can and cannot provide. In the final section, we examine the real-world interactions of Bitcoin with real software and users, and the trade-offs that must be made between convenience and trustlessness to achieve meaningful results.
People often say, "Bitcoin is great because it's trustless." But what does "trustless" mean? Pieter Wuille explained this widely used term on the Stack Exchange Q&A forum :
The "trust" in "trustless" is an abstract technical term. When a distributed system can function normally without being associated with any trusted group, we say it is "trustless".
—— Pieter Wuille, Bitcoin Stack Exchange (2016)
In short, this term refers to a property of the Bitcoin protocol: it can function logically without "any trusted entity." This is different from the trust you inevitably place in the software or hardware you run. This latter type of trust will be discussed further in this chapter.
In centralized systems, we rely on the reputation of a central participant to determine whether they will prioritize security, roll back the system state in case of problems, and punish any breaches of trust through the judicial system. These trust requirements are problematic in anonymous decentralized systems—because there is virtually no traceability, it is practically impossible to trust anyone. Satoshi Nakamoto describes this problem in the introduction to the Bitcoin white paper :
Online commerce has become almost entirely reliant on financial institutions as trusted third parties to process electronic payments. While such systems handle most transactions well enough, they have inherent weaknesses due to this trust-based model. First, completely irreversible transactions are impossible, as financial institutions cannot avoid disputes and mediation. Second, intermediary costs increase transaction fees, limit the minimum viable transaction size, and eliminate the possibility of small, casual transactions. The inability to create irreversible payments for irreversible services is an even greater cost. Because of the possibility of reversibility, the need for trust is extended. Merchants must be vigilant with their customers and ask them for information they wouldn't otherwise need to know. A certain percentage of fraud is considered unavoidable. These costs and payment uncertainties can be avoided by individuals using physical currency, but currently there is no mechanism to initiate payments through communication channels without a trusted third party.
— Satoshi Nakamoto, *Bitcoin: A Peer-to-Peer Electronic Payment System* (2008)
It seems that we cannot have a trust-based decentralized system, which is why trustlessness is so important in Bitcoin.
To use Bitcoin in a trustless manner, you must run a fully verified Bitcoin node (i.e., a "full node"). Only then can you verify that Bitcoin blocks (confirmed transaction data) received from others comply with Bitcoin's consensus rules; for example, that the block complies with Bitcoin's currency issuance rules and does not double-spend funds. If you don't run a full node, you are outsourcing the work of verifying Bitcoin blocks to others and trusting them to tell you the truth, which means you are not using Bitcoin in a trustless manner.
David Harding once wrote an article on bitcoin.org explaining how to run a full node—or rather, how to use Bitcoin in a trustless manner—that will definitely help you.
Bitcoin can only become currency if people are willing to use it to exchange for other things of value. This means that it is the people who accept Bitcoin who give it value and determine how Bitcoin should function.
When you accept Bitcoin, you have the power to enforce Bitcoin rules, such as preventing anyone's Bitcoin from being confiscated without their private keys being exposed.
Unfortunately, many users outsource their enforcement power . This weakens Bitcoin's decentralization, allowing a small number of miners, in collusion with a few banks and free services, to change Bitcoin's rules for users who have outsourced their power and do not verify blocks.
Unlike other wallet software, Bitcoin Core software enforces Bitcoin consensus rules —so if miners and banks change the rules for unverified users, those users will be unable to make payments to fully verified Bitcoin Core users (like you).
——David Harding, Full Validation on bitcoin.org (2015)
He said that running a full node can help you verify every aspect of the Bitcoin blockchain without trusting anyone else, so you can be sure that the Bitcoin you receive is genuine. This is great, but there's one important thing a full node can't help you with: it can't prevent double-spending through chain rewriting.
Note that while all processes—including Bitcoin Core—are affected by chain reorganization, the Bitcoin protocol provides a defense mechanism: the more block confirmations your transaction receives, the more secure you are. This is the best known decentralized defense mechanism.
——David Harding, Full Validation on bitcoin.org (2015)
(Translator's note: A "block" is a method for periodically confirming a batch of transactions and synchronizing them across a peer-to-peer network; blocks linked together form a chain; because each block requires proof-of-work (paying an economic cost) to become a valid block on the chain, blocks earlier in the chain are less likely to be reversed, and transactions confirmed by them are more secure. "Blockchain reorganization" refers to a new block attempting to occupy the same position (height) where a block has already been observed to exist. This can be intentional or unintentional, but its possibility cannot be eliminated.)
No matter how advanced your software is, you must always trust that the blocks that have confirmed your transactions will not be overwritten. However, as Harding points out, you can wait for a certain number of confirmations (new blocks following the blocks that confirmed your transactions) until you believe the probability of a blockchain reorganization affecting your transaction is low enough to be acceptable.
The incentive to use Bitcoin in a trustless manner aligns with the system's need for " full node decentralization ." The more people use their own full nodes, the more fully decentralized the full node system becomes, and the stronger Bitcoin's ability to resist malicious protocol changes. However, as explained in the section on full node decentralization, because a conflict inevitably arises between trustlessness and convenience, users often choose services that require trust.
From a systems perspective, Bitcoin's trustlessness is absolutely essential. In 2018, Matt Corallo explained trustlessness at the Baltic Honeybadger conference in Riga. The core point of his presentation was that you cannot build a trustless system on a system that requires trust, but the reverse is possible—for example, you can develop a custodial wallet on a trustless system.
Figure 2. A trustless base layer allows for trade-offs at higher levels.
This security model allows system designers to make trade-offs that are meaningful to them, without having to impose those trade-offs on others.
2.1 Don't trust, verify.
Bitcoin operates on a trustless basis, but you still need to trust the software and hardware you're using to some extent. This is because your software and hardware may not be exactly what's on the packaging. For example:
- The CPU could be maliciously designed, and cryptographic operations that detect your private key could leak it.
- The operating system's random number generator may not be as random as it claims.
- Bitcoin Core may contain a backdoor in its code that could send your private key to malicious actors.
Therefore, in addition to running a full node, you also need to ensure that you are running exactly what you intend to run. Reddit user "brianddk" discussed several trust levels to choose from when verifying the software you're using. In the "Trusting the Developer" section, he discussed " reproducible builds ":
"Reproducible compilation" is a software design methodology that allows many community developers to compile the software independently, ensuring that the final installation files compiled by each developer are identical to those compiled by others. In a highly public and reproducible project (such as
bitcoin), users do not need to completely trust any single developer. Many developers can run the compilation and witness themselves obtaining files identical to those digitally signed by the original compiler.—— brianddk, Bitcoin v22.0 and Guix (2022)
This article defines five levels of trust: trusting the website, trusting the developer, trusting the compiler, trusting the operating system kernel, and trusting the hardware.
To further explore the topic of reproducible compilation, Carl Dong gave a talk on Guix , explaining why trusting the operating system, codebase, and compiler can be problematic, and how to fix these issues using a system called "Guix," which is the system currently used by the Bitcoin Core project.
So, given the fact that our toolchain may contain many trusted binaries that could be maliciously copied, what can we do? We need more than just reproducibility; we need self-reliance. We can't simply download these binaries from servers controlled by other organizations and trust those external servers. We should know how these tools were developed, how we can recompile them, and ideally start with a much smaller set of trusted binaries. We need to minimize the set of trusted binaries as much as possible and devise a simple path to audit the entire process from these toolchains to what we actually use to develop Bitcoin. This will allow us to maximize verification and minimize trust.
—— Carl Dong on Guix, Breaking Bitcoin Conference (2019)
Carl then explained how Guix allows us to trust only a 357-byte binary that is verifiable and completely understandable if you know how to interpret the instructions. This is remarkable: you only need to verify that this 357-byte binary does what it's supposed to do, and then you can use it to compile a complete build system from the source code, ultimately resulting in a Bitcoin Core binary that is exactly the same as anything compiled by others.
Many Bitcoin enthusiasts subscribe to a single tenet that perfectly encapsulates the above:
Don't trust, verify.
— Bitcoiners everywhere
The quote originates from former US President Ronald Reagan's statement, " Trust, but verify, " made in the context of nuclear disarmament. Bitcoiners have adapted this to emphasize the importance of rejecting trust factors and running a full node .
The extent to which a user verifies the software they use and the blockchain data they receive is up to them. And, as with many things in the Bitcoin world, there's a trade-off between convenience and trustlessness. Using a managed wallet is almost always more convenient than running Bitcoin Core on your own hardware. However, as Bitcoin software matures and the user interface improves, it will undoubtedly better serve users who want trustlessness. Furthermore, as users gain more knowledge, they should gradually remove the element of trust.
Some users take a more serious approach (see Chapter 6 of this book for details), verifying the vast majority of the software they run. As a result, they can minimize the trust factor: they only need to trust their own computer hardware and operating system. In doing so, they also help those who don't thoroughly verify their hardware: once they discover a problem, they can speak out publicly. One such example occurred in 2018 when a bug was discovered that allowed miners to repeatedly spend an output of a transaction:
CVE-2018-17144 has been patched in Bitcoin Core versions 0.16.3 and 0.17.0rc4, released on September 18th. The vulnerabilities included a denial-of-service attack interface and a critical inflation vulnerability. Initially, on September 17th, this vulnerability was reported as a denial-of-service attack to several Bitcoin Core developers and projects supporting other cryptocurrencies (including ABC and Unlimited); however, we quickly determined that it was also an inflation vulnerability, with the same root cause and fix.
—— Full disclosure of CVE-2018-17144 (2018)
In this incident, an anonymous user reported the issue, and it turned out to be far more serious than they initially thought. This highlights the fact that those who verify code typically report security vulnerabilities rather than exploit them. This also benefits those who cannot verify everything themselves. However, users should not trust others to protect their security; they should verify things themselves (wherever they are capable and where there is an incident). This is the way to maintain independence as much as possible, and it's what has allowed Bitcoin to thrive. The more eyes are on the software, the less likely malicious code and security vulnerabilities are to get into it.
2.2 Conclusion
The Bitcoin protocol is trustless because users interacting with it do not need to trust any third party. However, in reality, most users cannot verify all the hardware and software that run the Bitcoin protocol. Skilled users can verify the software or hardware, and they can alert other (less technically savvy) users when they find malicious code or vulnerabilities.
Without trustlessness, we lack decentralization, because trust inevitably involves some central authority. You can develop a trust-dependent system on a trustless system, but the reverse is not possible—it's impossible to develop a trustless system on a trust-dependent system.
