Bitcoin's Diversity of Use-Cases and Security Models

28 Feb 2017

A few months ago I ran a hacker residency program with Chaincode Labs 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 ¹. 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.

Scaling Bitcoin Roundup

14 Oct 2016

With Scaling Bitcoin over, and lots of interest in the conference, I figured I should post a summary of my views of how the conference went.

While this year’s Scaling had a similar focus to the previous two, it seemed to have a different target audience. Instead of being focused making short- and medium-term scaling proposals accessible to a general audience for analysis, this this year’s submissions and attendees seemed much more interested in sharing their work with the Bitcoin protocol development community and academics. This made for an incredibly exciting series of talks, with many new technologies to scale Bitcoin presented and discussed, as well as leading to a few misconceptions about the focus of those communities.

Though our CfP mentioned a few topics outside of scalability, the majority of both our submissions and presentations were primarily focused on it, with a number of talks having a refreshing focus on the tradeoffs and limitations (especially effects on fungibility) of various scalability solutions. Of the works presented, I wanted to call people’s attention to a few of them to highlight the expanse of scaling solutions available to us in the (increasingly) near-term future, as well as to encourage the broader community to look closer at some technologies which might be important in discussing Bitcoin’s path forward.

The TumbleBit submission was a particularly cool application of existing crypto primitives to create a novel scaling solution. The authors have managed to design a Chaumian-Ecash-like system, backed by Bitcoin, with hub-and-spoke payment channel-like scalability features, without almost any of the fungibility and privacy drawbacks inherent in such designs. (Note that their paper and the code they have released focuses primarily on the first-step mixing version, which requires more on-chain transactions per payment.) Thanks to works like this, I continue to be excited by the increasingly large range of second layer and exponential scaling solutions available, and am hoping they can find someone to help them implement the rest.

Greg Sanders’ submission on SegWit takeaways and lessons learned provided useful considerations for those working on future protocol upgrades. Though the real effort was put in on Monday and Tuesday as one of the two remaining changes required for 0.13.1 was merged and the non-wallet parts of the other were heavily reviewed and finalized, the development challenges involved in implementing changes to Bitcoin is critical for us all to be aware of as we move forward.

The much longer-term continued research in reconsidering how we order transactions to form a “blockchain” is also exciting. The presentations on both braiding and combining PBFT-based signing with proof-of-work without negatively effecting Bitcoin’s security will hopefully allow Bitcoin to support massively more on-chain transactions in the future.

In spite of the impressive number and types of scaling solutions presented, some attendees felt there was an important topic left out - namely hard fork design and rollout mechanics. Given the lack of thorough analysis of the topic and the seemingly constant discussion of it, it seems appropriate that it would be discussed at Scaling Bitcoin. This year, however, we received no submissions related to hard fork mechanics. Still, there were a number of private discussions around the issues involved, including several new hard fork rollout proposals. Hopefully this type of discussion can move more into the public eye as the protocol development community continues to explore the issues and design proposals, and as SegWit development nears completion.

Ultimately I found the conference to be an exciting venue for new proposals and look forward to the next one. Still, it seems likely we will continue to encourage a broader range of submissions, possibly with multiple tracks in future conferences.