For all its apparent complexity, the Bitcoin Network solves just one problem: double spending. In a nutshell, this problem arises when the same electronic coin is respent. This problem and its solution are described in the first chapter of my book Owning Bitcoin and in the article How Bitcoin Works.

Alternatives

Here, I’ll briefly present Bitcoin’s solution to double spending security together with two others that have emerged since Bitcoin’s introduction. Collectively, these solutions are:

1. Proof-of-Work (PoW, used by Bitcoin, Bitcoin Cash, and Litecoin);
2. Proof-of-Stake (PoS, used by Cardano, Stellar, and eventually Ethereum);
3. Ripple Consensus Process (RCP, used by Ripple).

Why study these solutions if your main interest lies with Bitcoin?

There are three answers. First, doing so affords greater insight into how and why Bitcoin works. Second, it’s not inconceivable that Bitcoin may move toward adopting a variation of something other than proof-of-work some day. Third, if you’re interested in evaluating alternatives to Bitcoin, one of the most important questions you’ll need to answer is how the system prevents double spending.

The Mint

As the Bitcoin white paper points out, double spending can be trivially solved by establishing a Mint. Think of the Mint as a piece of software running on a computer that follows a published protocol. All transactions must be submitted to the Mint. The Mint appends each valid transaction it receives to a log. This update typically occurs as a batch of transactions called a “block.” When the Mint receives a new transaction, the log is consulted to make sure the same coin isn’t being spent again.

But a Mint suffers from two problems: (1) it creates a central point of failure; and (2) users must trust the Mint to process all transactions without bias.

Follow the Leader

The solutions to double spending I’ll describe here attempt to solve the Mint’s problems through redundancy. In a nutshell, the Mint is replaced by a network of independent auditors. Each auditor receives the network’s transactions and so is qualified to detect double spending attempts.

But redundancy comes with a price: the network of auditors must agree among themselves about the order in which transactions appear in their respective logs. This is an aspect of a longstanding computer science problem known as Byzantine fault tolerance.

Fortunately, the problem can be boiled down to one simple goal: randomly choose a single auditor who will update the log and therefore decide on the order of transactions. I’ll call this auditor the Leader.

Proof-of-Work

In proof-of-work, the Leader is chosen through a cryptographic lottery. The first auditor to generate a block whose hash value falls below a target threshold wins. Hashing requires consumption of energy (“work”), giving the protocol its name. The probability of winning equals the auditor’s fractional hash rate relative to the rest of the network. The winner announces the winning block to the other auditors, who validate it and then move on to the next round.

In the event of a tie (two winning blocks are received at the same time), a receiving auditor declares the block that was seen first as the winner. The outcome of the next round then decides the winner. In particular, the block chosen by the winning auditor as the side to build on becomes the winner from the last round. In the event of another tie, the process continues until one chain or the other pulls ahead in terms of cumulative proof-of-work. In practice, ties are usually resolved within one block.

Auditors consume resources (equipment and energy) as a condition for joining the lottery. These costs must be repaid for the system to remain economically viable. In Bitcoin, Bitcoin Cash, and Litecoin, this compensation takes the form of a subsidy (new money creation) and transaction fees. As a result, double-spending security depends on the net revenue to auditors never falling below zero. This economic requirement dominates how a system using proof-of-work operates.

Proof-of-Stake

A random lottery is also used to select the Leader in proof-of-stake. The key difference is that the chance of winning is proportional to the relative wealth of an auditor compared to the others. An auditor proves ownership of funds by signing a message with the key(s) controlling them, and adding this signature to all log updates. A weighted random selection process then chooses the Leader for each round.

Both proof-of-stake and proof-of-work require auditors to post collateral to participate. The main difference is the form this collateral takes. In proof-of-work, collateral consists of hardware and energy consumed on an ongoing basis. Proof-of-stake, in contrast, requires collateral in the form of value held on the network.

Early forms of proof-of-stake were vulnerable to the “nothing at stake” attack. To simplify, a Leader can announce with impunity two sibling blocks claiming the same parent. Proof-of-work punishes this behavior by requiring an auditor to split hash power between branches, thus reducing the chance of winning on any of them. Naive forms of proof-of-stake allow a Leader to produce multiple sibling blocks without penalty, thereby degrading double spend security.

This attack can be mitigated due to the fact that auditors identify themselves by signing all changes made to the log. An auditor that attempts to announce two or more versions of the update can therefore be identified. Other auditors can publish a proof to this effect, and subsequently destroy the auditor’s deposit.

A second problem unique to proof-of-stake is the long range attack. Here, an auditor obtains keys that previously held funds for the purpose of rewriting the log. Because these keys control no money at the time they’re bought, they are worthless to a owner who decides not to stake. However, in the hands of an attacker obtaining them, they can be used to create an alternative log of sufficient length to become dominant.

The practical difficulty of addressing both attacks explains the shortage of systems using secure proof-of-stake. One of the most important efforts along these lines is Ethereum’s Casper update, which was recently launched on a testnet. Another system to watch is Ouroboros, which is under development by the Cardano team.

Although proof-of-stake requires auditors to post collateral, it is not consumed in the same way as proof-of-work. For example, mining equipment depreciates as network difficulty increases. Likewise, electricity is irreversibly consumed during mining. In contrast, collateral is returned intact to honest proof-of-stake auditors.

This key economic difference suggests that proof-of-stake systems may offer comparable security as proof-of-work systems at less overall cost. In other words, auditors should require less compensation in terms of block rewards (money creation) and fees. Proof of such claims requires the long-term deployment of a secure proof-of-stake system.

Ripple Consensus Process

Both proof-of-stake and proof-of-work require some degree of trust in auditors as a collective unit. In proof-of-work, users trust that the majority of hash power is controlled by honest auditors. In proof-of-stake, users trust that the majority of staked funds belong to honest auditors.

The Ripple Consensus Process (RCP) takes this idea as the starting point for a fundamentally different approach in which auditors are explicitly trusted. Although many auditors may be available on the network, a user only trusts some of them while completely ignoring the rest.

In proof-of-work and proof-of-stake, auditors post collateral. The cost of doing so requires compensation that must be paid by the network. In RCP, auditors are explicitly trusted, eliminating the need for them to post collateral while at the same time eliminating the need for compensation.

As a result, RCP auditors lack most of the motivation to become Leader seen in proof-of-work and proof-of-stake systems. With no payout for Leaders, a very different selection protocol becomes possible.

RCP Leader selection begins by each auditor proposing to its trusted peers an update consisting of a set of transactions to be written into the log. After receiving all proposals, an auditor decides which one to use for the next round. Priority is given to those proposals which have supermajority support. In other words, an auditor changes its choice based on whichever proposal gains the most support. This process continues through multiple rounds until a clear supermajority emerges. The threshold for this supermajority is adjustable, but the default used on the Ripple network is 80%.

This process has been called “avalanche” because of the way a single proposal rapidly becomes the preferred choice. The use of avalanche consensus, coupled with the fact that auditors only need to listen to a handful of trusted peers offers the potential for very fast transaction finalization. On the Ripple Network, for example, a transaction can be finalized within five seconds.

Notice that in contrast to proof-of-work and proof-of-stake, RCP offers no mechanism for initial distribution through Leader selection. This leaves only one option: the network creator receives all value at the inception of the network. This value is then distributed to users through a manual process.

Nor does RCP offer a mechanism to distribute transaction fees to auditors. Instead, the Ripple Network simply destroys value used for transaction fees. This results in the inevitable destruction of money during the normal course network operation.

Conclusions

It should be clear that each solution to double spending imposes important economic, security, and political tradeoffs. It seems unlikely that any one of them will serve all of the world’s requirements for digital asset security. Nor does it seem likely that the three systems described here will remain the only solutions to double spending.