So far we have argued that free open source software is the right medium for digital infrastructure, because its processes discourage spurious, ceremonial, expensive, and monotechnic developments. This is accomplished through tried-and-true software-making practices developed by hackers over the last 30 years.
In this section, we will discuss how Satoshi Nakamoto innovated on top of existing open allocation governance processes in order to make them robust enough to govern a currency system.
The fundamental challenge of any social system is that people are inclined to break the rules when it’s profitable and expedient. Unlike present-day financial systems, which are hemmed in by laws and conventions, the Bitcoin system formalizes human rules into a software network. But how does the system prevent human engineers from changing this system over time to benefit themselves?
Nakamoto’s solution to this question can be broken down into three parts:
These solutions are nice in theory, but it’s important to remember that Nakamoto sought to enforce these rules upon human participants by using a software system. Prior to the release of Bitcoin, doing so would have run up against two specific unsolved engineering challenges:
To answer these questions, we need to explore how humans and machines in a network reach agreement on common rules and history. This section will focus on how human beings organize within the system into three distinct roles; the next section will focus on the use of a network of machines to enforce the rules and behavior of the participants.
A financial system with the aforementioned attributes is not a new concept. Ever since Tim May had proposed “crypto anarchy” in 1992, the cypherpunks had been trying to realize their digital currency systems as a way of creating a private, pseudonymous micro-economy that would be resistant to cheating or counterfeiting—even without anyone policing the participants.
Bitcoin was not the first attempt at digital money. Indeed, the idea was pioneered by David Chaum in 1983. In Chaum’s model, a central server prevented double-spending, but this was problematic:
“The requirement for a central server became the Achilles’ heel of digital cash. While it is possible to distribute this single point of failure by replacing the central server’s signature with a threshold signature of several signers, it is important for auditability that the signers be distinct 10 and identifiable. This still leaves the system vulnerable to failure, since each signer can fail, or be made to fail, one by one.”
Digicash was another example of a currency that failed due to regulatory requirements placed on its central authority; it was clear that the necessity to police the owners of the system significantly undermined the efficiencies gained by the digitization of a currency system.
Cypherpunk Wei Dei was directly influenced by crypto-anarchy when he came up with his decentralized “B-money” proposal in 1998. “I am fascinated by Tim May's cryptoanarchy,” he writes in the introduction to his essay:
“Unlike the communities traditionally associated with the word ‘anarchy,’ in a crypto-anarchy the government is not temporarily destroyed but permanently forbidden and permanently unnecessary. It's a community where the threat of violence is impotent because violence is impossible, and violence is impossible because its participants cannot be linked to their true names or physical locations.”
Dai’s concept was based on recent developments in computer science which suggested that such a system might be feasible.
As of the early 2000s, recent innovations had made Wei Dai’s B-money concept possible. Scott Stornetta and Stuart Haber had proposed something called “linked timestamping” in 1990 to build a trusted chain of digital signatures which could be used to notarize and timestamp a document, preventing retroactive tampering. In 1997, Adam Back invented Hashcash, a denial of service protection for P2P networks, which would make it expensive and difficult for participants to collude to alter past transactions.
Still, participants might collude to break the rules in other ways, such as to counterfeit coins. Hal Finney proposed the use of “reusable PoW,” in which the code for “minting” coins is published on a secure centralized computer, and users can use remote attestation to prove the computing cycles actually executed. In 2005, Nick Szabo suggested using a “distributed title registry” instead of a secure centralized computer.
In early 2009, Satoshi Nakamoto released the first implementation of a peer-to-peer electronic cash system, wherein the central server’s signature of authority was replaced by a decentralized “Proof-of-Work” system. Nakamoto wrote after launch that “Bitcoin is an implementation of Wei Dai's b-money proposal on Cypherpunks in 1998, and Nick Szabo's Bitgold proposal.”
These foundational ideas cited by Nakamoto may have drawn on contemporary economic concepts about currency markets. In a lecture delivered at the Gold and Monetary Conference, in New Orleans in 1977, economist Friedrich Hayek said:
“The monopoly of government of issuing money has not only deprived us of good money but has also deprived us of the only process by which we can find out what would be good money. We do not even quite know what exact qualities we want, because in the two thousand years in which we have used coins and other money, we have never been allowed to experiment with it, we have never been given a chance to find out what the best kind of money would be.”
This comment from 1984 is also widely attributed to Hayek:
“I don’t believe we shall ever have a good money again before we take the thing out of the hands of government. We can’t take it violently out of the hands of government, all we can do is by some sly roundabout way introduce something that they can’t stop.”
Well-written tutorials about “how Bitcoin works” are plentiful. Instead of reproducing those explanations, the following paragraphs explain only what is required to understand the design rationale of the system, as a way of elucidating its purpose. Specifically, we will explore the incentive system, which keeps Bitcoin’s contributors working together in lieu of any formal association.
Central to the Bitcoin system is the concept of “mining,” which will be explained in greater depth in the next section. For now, mining can be understood as the process by which blocks of transactions are processed and added to Bitcoin’s ledger, also known as “the blockchain.” “Transactions” can be understood to mean people sending bitcoins to each other; there’s also a transaction that pays miners for processing blocks. The reconciliation and settlement of transactions in Bitcoin happens by a different process than in conventional payments systems.
Many users only experience Bitcoin transactions through a lightweight “wallet” application on a mobile phone. Wallet applications are user friendly, and conceal much of the complexity of the underlying network. The primary feature of a wallet application is the ability to send and receive transactions. Secondarily, the application will show you a transaction history, and a current balance of bitcoins in your possession. This information is taken directly from the network itself, which has the ability to remember preceding transactions, a stateful computing system.
Bitcoin is not exactly stateful the way your smartphone or computer is. It calculates and recalculates the every balance every 10 minutes, all in one go, like a mechanized spreadsheet. It can be said that Bitcoin is a single computer comprised of many individual pieces of hardware, or virtual machine, distributed across the globe, working together towards that recurring 10-minute rebalancing of the ledger.
These machines can be sure they are connecting to the same network because they are using a network protocol, or a set of machine instructions built into the Bitcoin software. It is often said that Bitcoin is “not connected to the World Wide Web,” because it does not communicate using the HTTP protocol like Web browsers do.
While it’s true that Bitcoin is not a “Web application” like Facebook or Twitter, it does use the same underlying Internet infrastructure as the Web. The “Internet protocol suite” emerged as a DARPA-funded project at Stanford University between 1973 and 1974. It was made a military standard by the US Department of Defense in 1982, and corporations like AT&T and IBM began using it in 1984.
Figure 5: The layers of the Internet protocol suite. (Credit: Wikimedia)
In the application layer, third-party processes can create user data and send this data to other applications, which live on the same or different hosts. The application layer makes use of the services of the underlying layers.
Within this application layer exists not just the World Wide Web, but also the SMTP email protocol, FTP for file transfer, SSH for secure direct connections to other machines, and various others—including Bitcoin and other cryptocurrency networks. We’ve said that free software like Bitcoin can be copied and re-deployed by anyone, so how can disparate versions not interfere?
In practice, they do, to some extent. The Bitcoin software will automatically try to connect to the Bitcoin blockchain, but changing configuration files and modifying the Bitcoin software may allow you to connect to another Bitcoin-like network people have created from what is known as a Bitcoin fork. Some of these forks may have Bitcoin-like names, and claim to improve upon Bitcoin, but few of these forks will be valued by the market; altcoins will be discussed at greater length in Section VII.
Figure 6. Where Bitcoin sits in the Internet Protocol suite.
With a traditional debit or credit card, any financial activity you conduct over the Internet is recorded within your “account,” stored on the card issuer’s central computer or cloud. There are no accounts in Bitcoin. Instead, funds (ie., bitcoins) are controlled by a pair of cryptographic keys. Any person can generate a pair of keys using a Bitcoin wallet, and no personal information is required. Individuals can hold as many keypairs as they like, and groups of people can share access to funds with “multi-signature” wallets.
As we will see, wallet-users are just one group of stakeholders in the Bitcoin network. Software for technical users also exists in several forms; it can be downloaded directly from the Bitcoin code repository, from your Terminal (in macOS or Linux).
Users who run and store the full transaction history of the network on their computer will see it occupy about 200GB. Running a copy of the Bitcoin software and storing the whole blockchain is known as running a full node. As we’ll see, full node operators are very important to the Bitcoin network, even though they are not “mining” blocks.
Once the Bitcoin software is installed on your Internet-connected phone or computer, you can send and receive Bitcoin transactions to anyone else in the world, for any arbitrary quantity. Sending Bitcoins incurs a small fee, which is paid to miners.
Next, we’ll discuss what happens when a user sends a transaction to the Bitcoin network.
Sending transactions on the Bitcoin network modifies the state of the ledger, the blockchain. In order to hold Bitcoin and make transactions, the user must first generate a pair of cryptographic keys, also known as a keypair. Keys are used to digitally sign data without encrypting it.
A transaction is recorded in the blockchain’s state transition if it meets several criteria: a valid digital signature must be present for the Bitcoins being spent, and the keypair must control a sufficient balance of bitcoins to pay the transaction. Below the full anatomy of a Bitcoin transaction:
Figure 7. Anatomy of a Bitcoin transaction. The transaction ID appears in yellow. Metadata appears in the blue bracket. Transaction inputs, in orange, are already owned by the account sending the transaction, and are used to fund it. The outputs, in green, are the outputs: Bitcoins being transferred to another account. If the available outputs exceed the desired transaction amount, then “change” is returned to the sender in the form of unspent outputs. These unspent transaction outputs are also called “UTXOs.” (Credit: Venzen at Mail.bihthai.net)
General ledgers have been in use in accounting for 1,000 years, and many good primers exist on double-entry accounting and ledger-balancing. Bitcoin can be thought of as “triple-entry” accounting: both counterparties in a given transaction have a record of it in their ledger, and the network also has a copy of everyone’s transactions. This comprehensive history of every Bitcoin transaction ever is stored redundantly on every single full node. This is the 200GB of data you download when you store the blockchain.
Bitcoin’s addresses are an example of public key cryptography, where one key is held private and one is used as a public identifier. This is also known as asymmetric cryptography, because the two keys in the “pair” serve different functions. In Bitcoin, keypairs are derived using the ECDSA algorithm.
Figure 8: Visual representation of a user Alice signing a message and giving it to Bob, who can verify its sender
using Alice’s public key, which she has provided earlier. Many PGP users attach their public key to all email
correspondence, or list it on their personal homepage.
The use of public key cryptography is one of the relatively recent military innovations that make Bitcoin possible; it was developed secretly in 1970 by British intelligence, before being re-invented publicly in 1976.
In Bitcoin, these digital signatures identify digitally-signed transaction data as coming from the expected public key. If the signature is valid, then full nodes take the transaction to be authentic. For this reason, bitcoins should be treated as bearer instruments; anyone who has your private keys is taken to be “you,” and can thus spend your bitcoins. Private keys should be carefully guarded.
The Bitcoin network requires every transaction to be signed by the sender’s private key: this is how the network knows the transaction is real, and should be included in a block. Most users will store their private key in a special software application called a “cryptocurrency wallet.” This wallet ideally allows users to safely access their private key, in order to send and receive transactions through the Bitcoin network. Without a wallet application, one must send and receive transactions in the command-line Bitcoin software, which is inconvenient for non-technical users.
When a wallet application (or full node) submits a transaction to the network, it is picked up by nearby full nodes running the Bitcoin software, and propagated to the rest of the nodes on the network. Each full node validates the digital signature itself before passing the transaction on to other nodes.
Because transactions are processed redundantly on all nodes, each individual node is in a good position to identify fake transactions, and will not propagate them. Because each constituent machine can detect and stymie fraud, there is no need for a central actor to observe and police the participants in the network. Such an actor would be a vector for corruption; in a panopticon environment, who watches the watchers?
Thus it follows that Bitcoin transactions have the following desirable qualities:
Bitcoin’s “minimal trust” is especially visible in its automated monetary policy: the number of bitcoins ever to be produced by the system is fixed and emitted at regular intervals. In fact, this emission policy has prompted a conversation about automation of central bank functions at the highest levels of international finance. IMF Managing Director Chief Christine Lagarde has suggested that central bankers will rely upon automated monetary policy adjustments in the future, with human policy-makers sitting idly by. Nakamoto wrote that this was the only way to restrain medancious or incompetent market participants from convincing the bank to print money:
“The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve.”
Nakamoto’s system automates the central banker, and abstracts the duties the overall maintainers of the systems. If those maintainers someday decide that more bitcoins must be created, they must change the software running on a vast plurality of machines which operate on the Bitcoin network, which are owned by many different people, dispersed globally. A difficult political proposition, if only because bitcoins are divisible to eight decimal places.
In the last section, we encountered “open allocation” governance, wherein a loose group of volunteers collaborates on a project without any official leadership or formal association. We saw how it was used effectively to build “free” and open source software programs which, in the most critical cases, proved to be superior products to the ones made by commercial software companies.
So far, our presentation of open allocation governance and hacker culture has presented as an Edenic ideal where everyone works on what they like, without the hassle of a boss. Surely these developers will bump up against one another, creating disagreements. Surely there is accountability. How does a “leaderless” group actually resolve conflict?
The truth is that open allocation projects do require management, but it’s far less visible, and it happens behind the scenes, through a fairly diffuse and cooperative effort. The goal of this form of group management is to make the project a fun and interesting environment that developers want to return to.
First, it’s important to note that not all conflict is bad—some is generative, and results in better code. Sometimes many epic email threads must be exchanged before parties come into alignment.
But in order to distinguish undesirable conflict from spirited brainstorming, we must first define “success” in an open allocation project context. Mere technical success—building a thing which achieves adoption—is certainly important at the outset of a project. But within a short time, the needs of users will evolve, as will the programmer’s understanding of the user and their goals. An inability to refactor or improve code over time will mean degraded performance and dissatisfaction, and the user base will eventually leave. Continuous maintenance and reassessment are the only way for initial success to continue into growth. Therefore, a regular and robust group of developers needs to be available and committed to the project, even if the founding members of the project leave.
The indicators for long-term and meaningful success can be evaluated in a single trait:
Operational health. The operational health of an open allocation project can be said to be the ease with which it integrates new code contributions or new developers. Good operational health is considered a sign of project survivability. Survivability can be defined as the project’s ability to exist and be maintained independent of outside sponsorship or any individual contributor.
Groups working open allocation may vary in the ways they plan work and resolve conflict. Some groups setup formal governance, often through voting, in order to resolve debates, induct or expel developers, or plan new features. Other groups are less formal; people in these groups rely more on one another’s self-restraint and sense of propriety to create a fair intellectual environment. Still, a few nasty or mischievous contributors can ruin a project.
In some projects, a benevolent dictator or “BD” emerges who has the authority to make important decisions about the software or the group. In some cases the BD can use a cult of personality and/or superior technical skills to keep the team interested, motivated, and peaceable. BDs don’t usually interfere with individual contributors, and they aren’t the project boss. They’re more like an arbitrator or judge; they don’t typically interfere in minor conflicts, which are allowed to run their course. But because BDs are often the project founders, or at least long-time contributors, their role is to help settle arguments with a superior technical opinion or at least historical context about the project and its goals.
It is not necessary for the BD to have the strongest engineering skills of the group; instead, it’s more critical that the BD have design sense, which will allow them to recognize contributions which show a high level of reasoning and skill in the contributor. In many cases, settling an argument is a matter of determining which party has the strongest understanding of the problem being solved, and the most sound approach to solving it. BDs are especially useful when a project is fairly young and still finding its long-term direction.
Mature projects tend to rely less on BDs. Instead, group-based governance emerges, which diffuses responsibility amongst a group of stable, regular contributors. Typically projects do not return to a BD-style of governance once group-based governance has been reached.
Most of the time, an open allocation group without a BD will work by consensus, whereby an issue is discussed until everyone willingly reaches an agreement that all parties are willing to accept. Once no dissent remains, the topic of discussion becomes how to best implement the agreed-upon solution.
This form of governance is lightweight, blending the actual technical discussion itself with the decision-making process. Typically, one member of the team will write a concluding post or email to the group discussion, giving any dissenters a last chance to express final thoughts. Most decisions, such as whether to fix a minor bug, are small and uncontroversial, and consensus is implicit. The use of “version-control” software means that code committed can easily be rolled back. This gives social consensus a fairly relaxed and low-stakes feel. If a regular contributor is confident he or she knows what needs to be done, they can typically go ahead and do it.
Sometimes, however, consensus is not easily reached, and a vote is required. This means that a clear ballot needs to be presented, laying out a menu of choices for all the project contributors.
Like in the consensus process, the discussion of the ballot options is often enmeshed with the technical discussion. So-called honest brokers emerge who occasionally post summary updates for the contributors who are following the discussion from a distance.
The brokers are sometimes participants in the debate—they need not be above the issue—so long as they are accurately representing the views of each constituent group. If they are, then they can muster the credibility to call a vote. Typically those who already have “commit access,” meaning those people who have been given permission to write (or “commit”) code to the project repository are empowered to vote.
By the time a vote is called, there will be little debate about the legitimacy of the options on the ballot, however, obstructionists may try to filibuster. These people are politely tolerated if concern seems sincere, but difficult people are typically asked to leave the project. Allowing or banning contributors is also a matter of voting, however this vote is typically conducted privately amongst existing contributors, rather than on a general project mailing list. There are many voting systems, but they are mostly outside the scope of this essay.
A defining feature of free, open source software is its permissive licensing. Anyone is allowed to copy the codebase and take it in a new direction. This is a critical enabler of open allocation, volunteer-based governance. It means a contributor can spend time and energy on a shared codebase, knowing that if the group priorities diverge from his or her own, they can fork the code and continue in their preferred direction.
In practice, forking has high costs for complex codebases. Few developers are well-rounded enough (or have enough free time) to address and fix every nature of bug and feature that a project might contain.
Forkability puts limits on the powers of Benevolent Dictators. Should they take the project in a direction that most contributors disagree with, it would be trivial for the majority to copy the codebase and continue on without the BD at all. This creates a strong motivation for the BD to adhere with the consensus of the group and “lead from behind.”
A useful guide to open allocation governance in a real, successful project can be found in the Stanford Business School case study entitled “Mozilla: Scaling Through a Community of Volunteers.” (One of the authors of the study, Professor Robert Sutton, is a regular critic of the abuses of hierarchical management, not only for its deleterious effects on workers, but also for its effects on managers themselves.)
According to Sutton and his co-authors, about 1,000 volunteers contributed code to Mozilla outside of a salaried job. Another 20,000 contributed to bug-reporting, a key facet of quality control. Work was contributed on a part-time basis, whenever volunteers found time; only 250 contributors were full time employees of Mozilla. The case study describes how this “chaordic system” works:
“Company management had little leverage over volunteers—they could not be fired, and their efforts could be redirected only if the volunteers wanted to do something different. The overall effort had to have some elements of organization—the basic design direction needed to be established, new modules needed to be consistent with the overall product vision, and decisions had to be made about which code to include in each new release. While community input might be helpful, at the end of the day specific decisions needed to be made. An open source environment could not succeed if it led to anarchy. [Chairman of the Mozilla Foundation John Lily] referred to the environment as a “chaordic system,” combining aspects of both chaos and order. He reflected on issues of leadership, and scaling, in an organization like Mozilla: ‘I think ‘leading a movement’ is a bit of an oxymoron. I think you try to move a movement. You try to get it going in a direction, and you try to make sure it doesn’t go too far off track.’”
In many ways, the Bitcoin project is similar to forerunners like Mozilla. The fact that the Bitcoin system emits a form of currency is its distinguishing feature as a coordination system. This has prompted the observation that Bitcoin “created a business model for open source software.” This analogy is useful in a broad sense, but the devil is in the details.
Financing—which in most technology startups would pay salaries—is not needed in a system where people want to work for free. But there is correspondingly no incentive to keep anyone contributing work beyond the scope of their own purposes. Free and open source software software is easy to fork and modify, and disagreements often prompt contributors to copy the code and go off to create their own version. Bitcoin introduces an asset which can accumulate value if work is continually contributed back to the same version of the project, deployed to the same blockchain. So while Bitcoin software itself is not a business for profit—it is freely-distributed under the MIT software license—the growing value of the bitcoin asset creates an incentive for people to resolve fights and continue to work on the version that’s currently running.
This is what is meant by a so-called business model: holding or mining the asset gives technologists an incentive to contribute continual work (and computing power) to the network, increasing its utility and value, and in return the network receives “free labor.” As Bitcoin-based financial services grow into feature parity with modern banks, and use of the coin expands, its value is perceived to be greater.
Other real-time gross settlement systems, such as the FedWire system operated by the Federal Reserve, transacting in Federal Reserve Notes, can be used as a basis for comparison (in terms of overhead costs, security, and flexibility) to the Bitcoin system, which uses bitcoins as the store of value, unit of account, and medium of exchange. Without the prospect of the improvement of the protocol, as compared to banking equivalents, there is little prospect of increasing the price of Bitcoin; in turn, a stagnant price reduces financial incentive for selfish individuals to keep contributing code and advancing the system.
However, the system must also protect against bad actors, who might try to sabotage the code or carry the project off the rails for some selfish end. Next, we will discuss the challenges with keeping a peer-to-peer network together, and how Bitcoin’s design creates solutions for both.
We have described how open allocation software development works in detail, but we have not yet delved into the roles in the Bitcoin network. Here we describe how technologists join the network.
There are three groups of technical stakeholders, each with different skill sets and different incentives.
The primary role of mining is to ensure that all participants have a consistent view of the Bitcoin ledger. Because there is no central database, the log of all transactions rely on the computational power miners contribute to the network to be immutable and secure.
Miners operate special computer hardware devoted to a cryptocurrency network, and in turn receive a “reward” in the form of bitcoins. This is how Bitcoin and similar networks emit currency. The process of mining is explained in detail in the following pages, but it suffices to say that the activities of miners require IT skills including system administration and a strong understanding of networking. A background in electrical engineering is helpful if operating a large-scale mine, where the power infrastructure may be sophisticated.
Operating this computer hardware incurs an expense, first in the form of the hardware, and then in the form of electricity consumed by the hardware. Thus, miners must be confident that their cryptocurrency rewards will be valuable in the future before they will be willing to risk the capital to mine them. This confidence is typically rooted in the abilities and ideas of the core developers who build the software protocols the miners will follow. As time goes on however, the miners recoup their expenses and make a profit, and may lose interest in a given network.
Developers join cryptocurrency projects looking for personal satisfaction and skill development in a self-directed setting. If they’ve bought the coin, the developer may also be profit motivated, seeking to contribute development to make the value of the coin increase. Many developers simply want to contribute to an interesting, useful, and important project alongside great collaborators. In order to occupy this role, technologists need strong core programming skills. A college CS background helpful, but plenty of cryptocurrency project contributors are self-taught hackers.
In any case, core developers incur very few monetary costs. Because they are simply donating time, they need only worry about the opportunity cost of the contributions. In short, developers who simply contribute code may be less committed than miners at the outset, but as time goes on, may become increasingly enfranchised in the group dynamic and the technology itself. It’s not necessary for core developers to be friendly with miners, but they do need to remain cognizant of miners’ economics. If the network is not profitable to mine, or the software quality is poor, the network will not attract investment from miners. Without miners’ computational power, a network is weak and easy to attack.
Running a “full node” means keeping a full copy of the blockchain locally on a computer, and running an instance of the Bitcoin daemon. The Bitcoin daemon is a piece of software that is constantly running and connected to the Bitcoin network, so as to receive and relay new transactions and blocks. It’s possible to use the daemon without downloading the whole chain.
For the full node operator, running the daemon and storing the chain, the benefit of dedicating hard drive space to the Bitcoin blockchain is “minimally trusted” transactions; that is, he or she can send and receive Bitcoin without needing to trust anyone else’s copy of the ledger, which might be contain errors or purposeful falsifications.
This might not seem practically for non-technical users, but in actuality, the Bitcoin software does the work of rejecting incorrect data. Technical users or developers building Bitcoin-related services can inspect or alter their own copy of the Bitcoin blockchain or software locally to understand how it works.
Other stakeholders benefit from the presence of full nodes in four ways. Full nodes:
Worth mentioning are also two primary groups of second-degree stakeholders:
We have examined the way in which the Bitcoin network creates an incentive system on top of free and open source software projects, for the makers of derivative works to contribute back to the original. How do these disparate actors bring their computers together to create a working peer to peer network? Now that we’ve discussed how human software developers come to consensus about the “rules” in peer to peer systems, we will explore how machines converge on a single “true” record of the transaction ledger, despite no “master copy” existing.