Publick keys
are shared publicly, like an email address. When sending bitcoin to a counterparty, their public key can be considered the “destination.”
Private keys
are kept secret. Gaining access to the funds held by a public key requires the corresponding private key. Unlike an email password, however, if the private key is lost, access to funds are lost. In Bitcoin, once the private key is generated, it is not stored in any central location by default. Thus, it is up to the user alone to record and retrieve it.
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.
Where transactions are processed
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:
Permissionless and pseudonymous.
Anyone can download the Bitcoin software, create a keypair, and receive Bitcoins. Your public key is your identity in the Bitcoin system.
Minimal trust required.
By running your own full node, you can be sure the transaction history you’re looking at is correct. When operating a full node, it is not necessary to “trust” a wallet application developer’s copy of the blockchain.
Highly available.
The Bitcoin network is always open and has run continuously since launch with 99.99260 percent uptime.
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.
Management within open allocation projects
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.
Operational health and survivability
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.
Forms of governance in open allocation
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.
Emergent consensus-based democracy
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.
Forking the code
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.”
Open allocation governance in practice
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.’”
The Bitcoin “business model” binds hackers together despite conflict
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.
How developers organize in the Bitcoin network
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.
Group A: Miners
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.
Group B: Core Developers
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.
Group C: Full Node Operators
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:
Validate digital signatures on transactions sent to the network. Thus, they are gatekeepers against fake transactions getting into the blockchain.
Validate blocks produced by miners, enforcing rules on miners who (if malicious) may be motivated to collude and change the rules.
Relaying blocks and transactions to other nodes.
Worth mentioning are also two primary groups of second-degree stakeholders:
Third Party Developers:
build a cottage industry around the project, or use it for infrastructure in an application or service (ie., wallet developer, exchange operator, pool operator). These people frequently run full nodes to support services running on thin clients.
Wallet Users:
an end-user who is sending and receiving cryptocurrency transactions. All stakeholders are typically wallet users if they hold the coin. Many wallets are light clients who trust a copy of the ledger stored by the Third Party Developer of the wallet.
Summary
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.