Author: BuleMatt
Source: https://bluematt.bitcoin.ninja/2017/02/28/bitcoin-trustlessness/
The original article was published in February 2017.
A few months ago, I partnered with Chaincode Labs on a hack-in-residence program where we taught the philosophy, security, implementation, and technology of Bitcoin. I'm going to write about some of the topics we discussed there, and this will be the first in a series. I hope it will make the development of the Bitcoin protocol more transparent and help foster discussion about proposed changes to the system.
Before we can begin a general discussion about Bitcoin's security models and protocol development, we need to agree on one thing: What is Bitcoin? Or, at the very least, what are the key characteristics of Bitcoin that we must protect as we strive to change this system?
Of course, different people may give many different answers, but in order to understand what is most crucial to its operation, we need to understand why people use Bitcoin. Ultimately, the attributes that must be retained are those that Bitcoin users care about, not design choices made on a whim by its creators.
Of Bitcoin's many features, trustlessness—the ability to use Bitcoin without trusting anything but the open-source software you run—is (by far) the most prominent. More specifically, interest in Bitcoin seems to stem entirely from the desire to avoid trusting third parties or combinations of third parties. This should be little news to most, but understanding why trustlessness is so important (and in what forms) is crucial for developing and upgrading Bitcoin technology.
The debates of the past year or two have repeatedly framed Bitcoin's future as a choice between two extremes—either becoming a trustless payment system or a trustless form of digital gold. While neither is an accurate description, it offers a useful framework for understanding Bitcoin's primary use cases—the vast majority of which fall into one of these two categories. However, these two overlapping trust models are quite different; and it seems that those who claim one type of use case is superior to the other are often those who advocate for one trust model over the other.
Bitcoin's use as digital gold is largely achieved through users fully verifying the complete blockchain history and enforcing the 21 million BTC supply limit and transaction rules solely by trusting the open-source code they use. While it's debatable whether some trust in miners is still necessary to ensure the blockchain won't be restructured, the system's economic incentives make such actions clearly costly. Of course, to ensure operational security without relying entirely on miners, you need to wait for numerous "block confirmations" (e.g., a week to two weeks, a timescale for people to react to such issues; but regardless, it's a long-term investment, right? Buying a week earlier or later wouldn't make much difference, would it?).
Whether you're looking to hedge against hyperinflation because you distrust your country's central bank, or because you want to hedge against a global financial crisis (but don't want to manage physical gold storage), or simply want a settlement layer that can handle large-value transfers with appropriate latency, avoiding trust in anyone is crucial. This is where the demand for digital gold comes in, and full verification of (blocks) with high proof-of-work requirements can achieve this trustlessness.
Conversely, currently, almost all of Bitcoin's applications that fall under the category of "payment systems" rely on a slightly weakened trust model to gain practicality, albeit to varying degrees. Clearly, a payment system that takes a week or even longer to settle cannot compete with other systems that are much faster. Therefore, Bitcoin users rely on 6 (or even fewer!) block confirmations to protect their payments, potentially leaving them vulnerable to brief attacks.<sup> 1 </sup> However, these applications ultimately become possible only because users can avoid some trust in third parties when using Bitcoin, although some trust in miners is still required.
If you want a system that provides censorship-resistant payments through privacy-enhancing measures, protecting users from government asset seizures and private freezes, then you use Bitcoin because you don't want to have to trust a third party. If you want an asset storage and transfer system with robust programmability and cryptographic ownership features not found in most parts of the financial world, Bitcoin (and other cryptocurrencies) may be your only option to avoid single points of failure from a trusted central third party. Even if you just want a cheap international transfer system and don't care so much about trustlessness, the ultimate reason you choose Bitcoin is that you're not transacting with a centralized counterparty, which offers advantages without incurring additional costs (or censorship) due to a lack of competition among these counterparties.
Clearly, trustlessness and operation without counterparty risk are crucial to Bitcoin's functionality; it's just that individual users (and specific use cases) are willing to tolerate varying degrees of trust and prefer to trust only different stakeholders. When considering changes to Bitcoin, we (the Bitcoin user community) must carefully consider the consequences of such changes. We must consider not only our ability to use Bitcoin but also whether these proposed changes would require others to trust third parties more than they currently do.
For example, consider a "Proof of Stake" system. While often compared to Bitcoin, such systems have never overcome the startup problem—new users (and those offline for extended periods, typically weeks or months) must trust a third party to provide the latest checkpoints to find the current network consensus. While such systems work for some Bitcoin use cases, users who want to hold onto their Bitcoin for six months before spending it can now achieve the same security on some multi-signature centralized blockchains!
Nevertheless, trust should not be discouraged unless it is harmful. Some investors primarily concerned with Bitcoin's scarcity are happy to trust centralized third parties such as Bitcoin exchanges and "Bitcoin banks." Many Bitcoin users seeking fast, small/medium-sized payments are also, to some extent, happy to trust miners. These trust relationships, provided users are not forced into them (whether by explicit compulsion or sufficiently strong financial incentives), can provide a significantly better user experience through faster, cheaper, and more convenient transactions.
Users willing to trust miners (those requiring only 1 to 3 block confirmations) might also be willing to trust the Lightning Network and similar systems—which require users to reliably obtain block confirmation for a transaction within 1 to 3 days. Users who trust existing Bitcoin businesses (at least one or two) might also be interested in the functionality and low fees of a consortium sidechain. Users wanting features like verified recipients might even deposit Bitcoin in centralized Bitcoin banks. By building on top of the Bitcoin blockchain, rather than implementing it directly on the Bitcoin blockchain, all these systems can provide a significant improvement in usability for their users. This doesn't require more trust beyond what's necessary, at least not as long as their foundation—the Bitcoin blockchain—remains completely trustless.
Frustratingly, even after making optimal choices for trustless Bitcoin and systems like Bitcoin, neither can scale to merely adequate transaction throughput. Furthermore, to ensure that user-sensitive attributes are maintained and that users aren't forced to trust others to enforce these attributes (e.g., trusting miners or developers to maintain the 21 million BTC limit), Bitcoin must only change after consensus is reached among its growing user base. As a result, changes to the Bitcoin protocol become mired in political and social debates, hindering the system's flexibility.
Considering all these factors, we can see the reasons why Bitcoin must evolve—as long as it wants to maintain its trustless nature while providing a usable system for its diverse (and even vastly different) use cases. Users who don't need or want a completely trustless Bitcoin (for example, because they want a system that doesn't take weeks to confirm payments) can and should choose a better system that fits their trust model—whether it's the Lightning Network, consortium sidechains, merge mining sidechains, TumbleBit, or a trusted "Bitcoin bank." Users who don't even want to trust miners should also be free to put their transactions on the blockchain and wait weeks to ensure that any hash power attacks that haven't yet occurred can't reverse them (and pay fees to ensure enough computing power will provide security for their transactions).
For users to continue using and trusting Bitcoin as they have always done, the Bitcoin community must be resolute: proposed changes should only be implemented after consensus is reached within a broader group. Conversely, to prevent Bitcoin from unnecessarily stagnating, the community must be willing to reach consensus and implement changes, as long as these changes help them use the system without harming others, and as long as they are common-sense, regardless of their form. Crucially, this means that any changes that do not harm Bitcoin's utility in any use case and help others should be implemented whenever possible. I have always been amazed by the social resilience of the Bitcoin community, and I remain optimistic that the Bitcoin community will come together around a unified vision and continue to push the Bitcoin protocol forward.
footnote
1. For example, in the past, Border Gateway Protocol (BGP) attacks targeting cryptocurrency mining pools allowed attackers to temporarily control a large portion of the hashing power. Similar attacks can be carried out against hosting service providers (this has happened repeatedly in the cryptocurrency space).
