Bitzuma

Bitcoin from Scratch: Redundancy

By Rich Apodaca | Updated

Auditing transactions solves the double spending problem, but leads to a potentially devastating side-effect. A single accident or attack on a single auditor can lead to financial collapse. The risk can, however, be reduced through redundancy.

This post is part of the extended series Bitcoin from Scratch.

Redundancy duplicates a system’s critical components or functions for the purpose of increasing reliability. In the context of an auditor-mediated electronic cash system, redundancy means adding a second auditor, and possibly more. The presence of one or more redundant auditors would allow transactions to be processed even if one auditor failed.

Although hundreds or thousands of auditors might collaborate, the simplest system would consist of just two. Ideally, these two auditors would operate as independently as possible. For example, each auditor should be controlled by a different organization, subject to a different legal jurisdiction, and be physically located in a different geopolitical area.

To effectively work together, auditors would need to apply a consistent set of rules. Synchronized ledgers would provide part of the solution. Two auditors can synchronize their respective ledgers by relaying audit requests to each other.

SVG Image
Auditor Redundancy. Victor, an auditor, receives a transaction audit request and processes it as usual (top right). He relays the request to a second auditor, Vanna, who processes it and updates her ledger (bottom right).

Imagine a system of two auditors, Victor and Vanna. Victor accepts an audit request containing a transaction. Detecting no double spending attempt, Victor updates his ledger to reflect the new transaction. He then relays the audit request to Vanna. Detecting no double spending attempt, Vanna updates her ledger. Relaying audit requests to each other allows Vanna and Victor to maintain synchronized ledgers. Both will reach the same decision when presented with the same audit request.

But this system is fragile. At some point, Vanna and Victor will separately receive and relay independent audit requests at almost exactly the same time. This causes the auditors’ respective ledgers to differ in a subtle, but important way. The ledgers list the same transactions, but in different orders.

SVG Image
Out of Order. Simultaneous relay of audit requests cause the auditors’ ledgers to differ in the ordering of transactions.

The order in which each auditor records incoming transactions plays a crucial role in audit decisions. Imagine that Chuck wants to double spend a coin. He begins by creating two sibling transactions that each spend the same output. Chuck then simultaneously submits the first transaction to Vanna and the second to Victor. The auditors process these transactions independently, updating their respective ledgers. Then each auditor relays its respective audit request to the other, again simultaneously.

SVG Image
Splitting a Double Spend. Chuck creates two sibling transactions spending the same coin and sends each one to a different auditor. Victor rejects the request relayed from Vanna as a double spend, and Vanna does the same. From this moment on, Victor will assert that the coin belongs to Alice, but Vanna will assert the owner is Bob.

This is where the problems start. Victor rejects the transaction relayed by Vanna as a double spend of Chuck’s coin. For the same reason, Vanna rejects the transaction Victor relayed. From this moment on, the auditors disagree about the legitimate owner of Chuck’s coin. Victor believes Alice to the new owner, but Vanna believes the new owner to be Bob. Chuck has succeeded in his double spending attempt, despite the best efforts of two auditors working together.

For redundancy to work, auditors must find a way to agree on a single global transaction sequence. But before they can do that, they need a better language for talking about transaction order.