Add trustlessness post

diff --git a/_posts/2017-02-28-bitcoin-trustlessness.md b/_posts/2017-02-28-bitcoin-trustlessness.md
new file mode 100644 (file)
index 0000000..68f9e1d
--- /dev/null
+++ b/_posts/2017-02-28-bitcoin-trustlessness.md
@@ -0,0 +1,38 @@
+---
+layout: post
+title: Bitcoin's Diversity of Use-Cases and Security Models
+---
+
+A few months ago I ran a [hacker residency program with Chaincode Labs]({% post_url 2016-08-08-chaincode%}) where we taught about Bitcoin philosophy, security, implementation, and technology. This is the first in a series of posts in which I'm going to write up some of what we discussed, hopefully making Bitcoin protocol development more accessible and helping frame discussions around proposed changes to the system.
+
+Before I can begin talking about Bitcoin's security model or protocol development generally, we have to agree on one thing: what IS Bitcoin? Or, at least, what are the key features of Bitcoin that we must protect as we endeavour to change the system?
+
+Of course Bitcoin is many different things depending on whom you ask, but to understand what is critical to its operation, we need to understand why people use Bitcoin. Ultimately, the properties which must be maintained are those which users of Bitcoin care about, not some arbitrary design decisions which its creator picked out of a hat.
+
+Of Bitcoin's many properties, trustlessness, or the ability to use Bitcoin without trusting anything but the open-source software you run, is, by far, king. More specifically, interest in Bitcoin appears to almost exclusively derive from a desire to avoid needing to trust some third party or combination of third parties. This should hardly be news to anyone, but an understanding of exactly why this trustlessness is so important (and what forms it takes) is critical to building and upgrading Bitcoin technology.
+
+The debates over Bitcoin's future which have occurred over the past year or two have repeatedly been described as a choice between two extremes - Bitcoin is either a trustless payment system or a trustless digital gold. While this is far from an accurate characterization, it does provide a useful basis for understanding the primary Bitcoin use-cases - most can be categorized into one of these two broad categories. Further, the trust models of these two categories differ greatly, and it often seems that those arguing for one group of use-cases in favor of another are more often arguing in favor of one trust model over another.
+
+The digital gold uses of Bitcoin are enabled largely through users fully validating the entire chain history, trusting only the open source software they run themselves to enforce the 21 million Bitcoin limit and the validation of transfers. While there is arguably some trust in miners required to ensure the entirety of the blockchain isn't reorganized, the financial incentives baked into the system provide clear costs to such actions. Of course to ensure you aren't trusting miners and pools to secure their operations perfectly, such users have to wait for a large number of "confirmations" (eg waiting a week or two, a timeframe on which humans can respond to issues; still, after all, it's a long-term investment, right? What's an extra week to buy in?).
+
+Whether you want a digital gold because you don't trust your national bank's ability to protect your currency from inflating uncontrollably (or want to hedge against such a scenario) or you want to hedge against global financial contraction (and don't want to manage the storage of physical gold), or you just want a secure medium-term settlement layer for large value transfers, avoiding trust in *anyone* is critical, and full validation with large work requirements can enable that.
+
+Conversely, Bitcoin use-cases which fall more into the "payment system" category, today, almost always require a slightly reduced trust model to be practical, though to varying degrees. Clearly a payment system which requires a week or more for payment to clear would not be able to compete with much faster alternatives. Thus, Bitcoin users rely on 6 (or less!) confirmations to secure their payment, potentially opening themselves up to any number of transient attacks [^1]. Still, these use-cases end up being possible only because users can avoid some element of third-party trust by using Bitcoin, even if it requires some trust in miners.
+
+If you want a system which provides uncensorable payments through privacy enhancements which protect users from asset seizure by governments and freezing by private institutions, you're using Bitcoin because you don't want to have to trust a third party. If you want an asset storage or transfer system with strong programmability and cryptographic ownership features not found elsewhere in most of the financial world, Bitcoin (or other cryptocurrencies) is likely your only option to avoid single points of failure from centralized third-party trust. Even if you only want a cheap international transfer system and don't directly care about trustlessness yourself, you ultimately are choosing Bitcoin because you want the benefits associated with transacting without a single, centralized counterparty, and the costs (or censorship) associated with a lack of competition between such counterparties.
+
+Clearly trustlessness and the ability to operate without counterparty risk is critical to Bitcoin's functionality, but individual users (and use-cases) are willing to tolerate varying levels of such trust, and are willing to trust only in different parties. When considering changes to Bitcoin, it is critical that we, the community of Bitcoin users, consider the effects of such changes carefully. We must consider not only our own ability to use Bitcoin, but consider how proposed changes might require others to trust third-parties more than they currently do.
+
+Take, for example, Proof of Stake systems. While often compared to Bitcoin, such systems have never overcome the bootstrapping problem - new users (or users who have been offline for an extended period of time, often on the order of a week or month) are not able to find the current network consensus without trusting some third-party for a current checkpoint. While this works perfectly fine for some use-cases of Bitcoin, users who wish to store away Bitcoin and come back to spend them six months later would now have the same security as a multi-signed centralized blockchain!
+
+All that said, trust should not be discouraged where it is not otherwise harmful. Many investors who care strongly about Bitcoin's scarcity properties are happy to trust centralized third-parties in the form of Bitcoin exchanges and "Bitcoin banks". Many Bitcoin users who want fast payments for medium- to small-value transactions are happy to trust miners, in sufficient measure. Such trust relationships, as long as users aren't forced into them (either by explicit requirement or sufficiently strong financial incentive), can provide significantly better user experience through faster, cheaper, and more user-friendly transactions.
+
+Users willing to trust miners with only one or three confirmations are likely also willing to trust the lightning network and similar systems which require that a user be able to reliably get a transaction confirmed within a day or three. Users who trust the current crop of Bitcoin businesses, or at least one or two of them, might be interested in the functionality or low fees of a federated sidechain. Users looking for features like real-name recipients may even hold some money in a centralized Bitcoin bank. By building on top of, but not directly on, the Bitcoin blockchain, all of these systems can provide significant usability improvements for their users. This without introducing more required trust than necessary, at least as long as their backstop, the Bitcoin blockchain, remains truly trustless.
+
+Sadly, the best designs we have for trustless Bitcoin and Bitcoin-like systems all fail to scale to even moderate transaction volumes. Further, in order to ensure that properties which users care about remain in place without requiring users trust others to enforce them (eg trusting miners or developers to keep the 21 million Bitcoin limit), Bitcoin must only change by consensus of its ever-growing userbase. This results in changes to the Bitcoin protocol getting bogged down in politics and social debate, hampering the agility of the system.
+
+Putting all of this together we see a picture of where Bitcoin must evolve if it wants to retain its trustless properties while providing a usable system for its many, vastly divergent, use-cases. Users who do not need or want a fully trustless Bitcoin (eg because they want a payment system that doesn't require weeks to confirm payments) can and should use the most optimal system which fits into their trust model - whether it be the lightning network, a federated sidechain, a merged-mined sidechain, TumbleBit, or even a trusted "Bitcoin bank". Users which do not even want to trust miners should be free to do so, placing their transactions on the blockchain and waiting weeks to ensure even future hashpower attacks will not reverse them (and paying fees to ensure sufficient hashpower provides security for their transactions).
+
+In order to enable users to continue to transact and trust in Bitcoin as they always have, the community of Bitcoin users must continue to enforce that changes happen only through consensus among the ever-broadening group. Conversely, in order to keep Bitcoin from stagnating unnecessarily, its community must be willing to form consensus around and make changes which help the system they wish to use without hurting others and make common-sense changes, whatever form they might take. Critically, this means that all changes which do not harm the utility of Bitcoin for any of its many use-cases, while helping others, should be made, wherever possible. I am always impressed with the social resilience of the Bitcoin community, and continue to be optimistic that it will come together with a unified vision to continue to move the Bitcoin protocol forward.
+
+[^1] See, for example, the Border Gateway Protocol (BGP) attacks against cryptocurrency pools in the past, allowing attackers to temporarily gain control of the vast majority of hashpower. Similar attacks could be envisioned against hosting providers (something which the cryptocurrency space has seen repeatedly).