Ledgers

Let’s start our exploration of money with a really simple case: Alice is paying $2 to Bob. Presumably the payment is in exchange for some goods or service, but we’re only concerned here with the payment. They can use paper currency, the familiar pieces of paper printed in green and black ink by the U.S. government. For example, Alice can hand two one-dollar bills to Bob. Let’s say she starts with $6 and Bob starts with $5. Then she takes $2 to give to Bob, reducing her total to $4. After Bob adds the $2 to his pile, Alice has $4 and Bob has $7.

There are many circumstances where paper currency is inconvenient. When a large amount of money is involved, no one wants to be handling large stacks of bills. Similarly, if Alice and Bob are far away from each other, handing over pieces of paper is physically impossible.

Instead of handling pieces of paper, we can accomplish the same effect through various kinds of recordkeeping. For example, Alice and Bob can write entries in a shared book. A book that’s used in this way is typically called a ledger. Figure 25.1 shows the same starting state as the one we described previously, but now Alice’s and Bob’s money piles are recorded in a ledger.

Figure 25.2 shows the same final state that we described previously, but using an updated ledger instead of handing over dollar bills.

Notice that these ledger entries are themselves the payments—not just the record of payments that took place in some other way. Once we see that the payment can just be an updated record instead of handing over pieces of paper, it’s easier to see how payments can happen even if Alice and Bob are far apart.

It might seem a little weird to think about using a ledger this way to replace cash payments. But a similar kind of recordkeeping happens if Alice and Bob hold accounts at the same bank, and they perform transfers between their accounts. Instead of writing in the shared book, they instead trust the shared bank to keep accurate records of their holdings. Of course, a modern bank doesn’t use a ledger book to keep those accounts; instead, it stores and handles the necessary data using computers.

For most people in economically developed countries, there’s nothing new or surprising in what we’ve described so far. There are also many variations and elaborations possible with different parties in the middle. There may be more than one bank involved, and there are specialized interbank payment systems with well-known brands like Visa or MasterCard, as well as various more obscure payment entities like check clearinghouses.

However, it sometimes surprises people that this kind of recordkeeping represents the majority of money. There are two main ways that people use money: to store something valuable for possible future use, or to pay someone in exchange for goods or services. When experts look at the money that is “at rest” and being used primarily as stored value, most of it turns out to be in bank accounts and investment accounts of various kinds. Likewise, when experts look at money that is “in motion” and being used for payments, most of it is actually in transaction records: checks, electronic payments, charge cards, credit cards, debit cards, and the like. So in any realistic assessment, modern money is just bookkeeping.

As we think about computer systems and money, we may find ourselves considering philosophical questions like “What is digital money?” or “How does money function in the network age?” To answer, it’s helpful to keep in mind that in some important ways money is already digital. Even before we start to consider Bitcoin or another exotic-seeming new system, we can see that in the modern world most money exists only in the form of computerized records.

Special Roles vs. Ordinary Participants

We can analyze the bank-transfer approach in a little more detail. We’ve seen that there is a special role: the bookkeeper (probably a bank) keeps the accounts of how much money each person has. The bookkeeper role may involve more than one person or organization, but for simplicity we’ll talk about it as a single party.

There is also a second special role: the guarantor (probably the U.S. Federal Reserve) underpins the value of the currency in use. Again, the guarantor role may involve more than one person or organization, but for simplicity we’ll also talk about it as a single party.

Apart from these two special trusted parties, there are the ordinary parties who transfer money among themselves. For want of a better term, we’ll call them participants. The essence of Bitcoin is building a system that allows the participants to transfer money without having any special trusted parties.

To see what’s required to eliminate the special parties, let’s first consider each of them in turn.

Bookkeeper

The bookkeeper tracks the changes made by each participant. All participants must trust the bookkeeper. In addition, the bookkeeper must always be available to record whatever changes a participant wants to make. What happens if the bookkeeper disappears or doesn’t function? In that situation, the participants don’t know what their balances are. Participants have to make do with their last best guess of their holdings. If they want to do something with that money—buy, sell, transfer—they have to find a way to do it without the bookkeeper. In the worst case, all the money may be gone—there may be no way to prove one’s ownership of the money without the bookkeeper.

In practice, banks in most developed countries have deposit insurance to protect against this worst-case scenario of losing your money—at least up to a certain amount of money per account holder. But even if we believe we are protected against the total loss of our money, we may nevertheless be uncomfortable with what this worst case shows. There is a hazard that comes with trusting the bookkeeper: the system fails catastrophically if the bookkeeper is actually faulty or malicious. There is a potential for a bookkeeper’s poor behavior to impair your ability to use your money.

Guarantor

Now let’s turn to the other special party, the guarantor. Whereas the bookkeeper tracks balances in dollar terms, the guarantor controls what a dollar means. We previously asked what happens to participants if the bookkeeper fails; now let’s ask, what happens if the guarantor fails?

Sometimes such a failure occurs because the guaranteeing government ceases to exist, such as happened to South Vietnam in 1975 at the end of the war between North Vietnam and South Vietnam. At other times, the guaranteeing government is still sovereign, but has spectacularly mismanaged the currency. The most striking example of such mismanagement is when a currency has severe inflation. Inflation is the rate at which money is losing its value—or, equivalently, the rate at which prices are increasing.

Although there is disagreement among economists about the “right” level of inflation, all parties agree that high inflation is bad. A number of countries have experienced hyperinflation, with a recent example being Zimbabwe. Its annual inflation rate increased from an uncomfortable 7 percent in 1980 to the last official rate of more than 231 million percent in 2008, which in turn prompted the printing of 100-trillion-dollar banknotes (yes, each individual banknote was worth 100 trillion Zimbabwe dollars!). Eventually the Zimbabwean currency was abandoned and foreign currencies used instead.

Although few people anticipate a situation in which the U.S. Federal Reserve acts as poorly as the Zimbabwe government did, there are people who are skeptical of the Federal Reserve’s competence and good intentions. The potential for poor performance by the guarantor is a little like the potential for misbehavior by the bookkeeper—unlikely, but with severe consequences if it does occur.

Bitcoin

The Bitcoin system supports payments among distributed participants without any special roles. There is no need for a bookkeeper to maintain a ledger. Instead, the participants collectively implement a shared distributed ledger. There is likewise no need for a guarantor to regulate the issuance of currency; instead, the participants collectively implement a unit of value called a bitcoin.

(Notice that the usual custom is to use the capitalized term “Bitcoin” to refer to the system architecture, as in “With Bitcoin, there’s no central bank.” Meanwhile, lower-case “bitcoin” refers to the unit of value, as in “Joe just paid me 1.2 bitcoins.”)

Bitcoin goes beyond removing the two special trusted roles. There really aren’t any trusted entities in Bitcoin; in particular, the participants don’t trust each other. In fact, Bitcoin is designed to continue functioning as a reliable trustworthy ledger even when the community of participants includes some members who are trying to cheat or otherwise undermine the system.

Does that mean that Bitcoin is unstoppable and indestructible? No: Bitcoin won’t work reliably if everyone in the community is attacking it, or even if a majority of the community is trying to subvert it. But the system will give correct results even when some of the participants are not behaving correctly—indeed, even if they are actively undermining the system’s operation. Our previous look at fault-tolerance and software failures exposed us to some similar concerns (chapter 17), but the mechanisms in Bitcoin will prove to be quite different from what we’ve seen before.

Bitcoin provides both a distributed shared ledger and a unit of value. In principle, these two constructs are completely unrelated:

•  A bank could maintain an ordinary ledger that is denominated in bitcoins. The use of bitcoins doesn’t require a distributed ledger.

•  A group of participants could implement a distributed ledger in which the entries track balances and transfers of dollars. The use of a distributed ledger doesn’t require the entries to be denominated in bitcoins.

In practice, the distributed ledger and the unit of value have an intertwined implementation, as we’ll see in the next chapter. In our explanation, we’ll first consider how to get the distributed ledger to work for a community, without worrying about bitcoins as a unit of value.

Distributed Ledger

A distributed ledger has to work despite failure or misbehavior by some parts of the system. As with any other fault-tolerant system (chapter 16), we know that depending on a single copy of data means that we can’t tolerate a loss or failure of that copy. So instead we have to think in terms of multiple copies that somehow cooperate.

We’ll work our way to the Bitcoin solution by considering some simpler ways to build a distributed ledger. One initial possibility is that each participant simply keeps a separate copy of the ledger. If we pursue this approach, we also need some mechanism so that all the participants always see the same changes—we don’t want to be in a situation where two participants have different ideas about how much money some particular participant has.

It’s helpful to return to using the language of “attackers” and “defenders.” The correctly functioning participants in the Bitcoin community are defenders, while those that are malfunctioning or actively subverting the system are attackers. The defenders want to achieve these properties:

•  Every defender has an identical view of every item in the ledger. We call this the agreed sequence.

•  The agreed sequence is stable and only changes at one end (we’ll refer to the end that changes as the tail). Like other logs (chapter 16) it can grow as more entries are added, but old entries are permanent and unaffected by these additions.

•  The group of participants can grow or shrink over time; a particular participant can choose whether and when to join or leave. (In a later section, we’ll consider the motivations of participants for joining or leaving the group.)

•  The group achieves some kind of shared consensus about state changes: in particular, the defenders have to agree on the same result in spite of the attackers actively working against a successful resolution.

Each participant trusts or distrusts other participants equally; unfortunately, the participants are not clearly labeled as “attacker” or “defender.”

We have seen this kind of problem before: it’s basically Byzantine agreement (agreement with a Byzantine failure model). As we mentioned in chapter 17, Byzantine agreement allows a group of participants to reach a common agreement as long as a substantial majority (typically 2/3 or 3/5) of the participants are behaving correctly. So one high-level way of understanding Bitcoin is that it’s a shared, extensible recordkeeping system in which each update is shared with other participants via a kind of Byzantine agreement. (A computer scientist might quibble about this characterization. In a careful comparison, true Byzantine agreement requires a greater fraction of “good” players but also gives a more reliable shared answer. Bitcoin is somewhat looser, supplying a weaker notion of the agreed sequence while allowing a larger fraction of attackers before failing. However, these distinctions aren’t especially important for our purposes.) The next chapter looks in somewhat more detail at how to actually build such a system.