Participating Projects

Bitcoin is designed to facilitate the transfer of value through a communications medium on a peer-to-peer basis with no third parties required to authorize or order transactions. A proof of work consensus mechanism is employed to give users a trust-minimized signal of which transactional branch to follow. The units of currency in the network are designed to be scarce and issued in a decaying manner, ultimately capping supply. Strong property rights are guaranteed through cryptographic public-private keypairs, the knowledge of which enables users to prove ownership of a ledger entry. Pseudonymous addresses constitute identity in the network.

Success would consist of the continued functionality of the Bitcoin system without arbitrary reordering which would impair the network’s settlement guarantees – this requires that honest nodes control 50% of the computational power in perpetuity. Satoshi did not give clear success metrics but noted that “in 20 years there will either be very large transaction volume or no volume.” Which suggests that a lot of transactional volume would be a reasonable proxy for a successful network.

There is no single or official coordinator in bitcoin. The entities which employ the largest number of developers are Blockstream, Chaincode labs, the Digital Currency Initiative, and Square Crypto, although these organizations generally do not demand that their developers advocate for a given political strategy within Bitcoin. Bitcoin development is fragmented and coordination happens through a mailing list, the official bitcoin github, social media settings like twitter and reddit, and a large number of conferences and meetups, in particular the bitdevs meetups. Currently Wladimir van der Laan is the lead maintainer of the Bitcoin Core Github for housekeeping purposes, although he explicitly disavows any power over the direction of protocol development.

Previously, miners were entrusted with signaling authority to ratify various soft forks, giving them effective coordinating ability. However, it is currently unclear whether this coordination method would be adopted for future changes.

Network participants are denoted through a public-private keypair associated with a set of native units of the currency, called unspent transaction outputs (UTXOs). No other network identification is employed. Optionally, some miners self-identify in the Coinbase field of new blocks, although this serves a nonessential discretionary (and spoofable) signaling purpose.

The network’s dry code treats nodes and miners as one and the same. It doesn’t recognize any hierarchy among nodes – the fork choice rule is enforced by the heaviest chain which is a function of total work done.

Roughly speaking, the three demographic groups consist of economic node operators (enterprises, firms, and individuals accounting for significant usage and volume and running their own node software), core developers who write the software, and miners who order transactions and occasionally ratify developer choices. There are further stratifications among the economic nodes and developers.

The most critical group is the highly-engaged core developers who can develop and understand consensus-critical components of the software. In an emergency situation, these individuals will typically coordinate to triage and resolve issues such as bugs. Vulnerabilities will occasionally be withheld (until they can be remediated in future updates to the software), again typically by individuals within this loose organization.

Miners are critical to the network in that it depends on mining to retain liveness. For new blocks to be produced, miners must be active on the network – although this can occur with just a single individual mining on a laptop, as was the case in early 2009. Today, however, Bitcoin is infrastructure depended on by many any hence industrial mining is required; if difficulty dropped back to the Satoshi era, participants would likely not trust the finality guarantees of the network. Mining pools are an important interest group within the mining industry, as they consolidate individual entities which mine. Mining pools can to some degree act on behalf of miners, but miners have the choice to leave pools if they misbehave.

Today, there are a number of exchanges, custodians, and other financial intermediaries which facilitate the trading, custody, and financialization of Bitcoin. While they are not individually critical to the continued function of the network, they allow it to be traded in a liquid manner as a meaningful global asset.

Among miners – convergence to a single canonical history; liveness (as in, the production of new blocks at predictable intervals), and honest behavior – inducing miners to avoid double spends. Additionally, the presence of fees is an inducement to miners to include transactions in blocks, and to prioritize appropriately. Node operators are not incentivized.

There is a subsidy to miners which decays every four years, and users have the option of appending fees to their transactions as a secondary incentive.

Developers have reputational exposure as their commit histories are known through software like github. Miners are pseudonymous and so do not have reputational risks to consider. They have skin in the game through medium/long term acquisition of domain-specific hardware which cannot be externally repurposed, namely ASICs. If they misbehave and crash the value of the protocol, their ASICs will depreciate. Full nodes that third parties rely on have an incentive to behave well for reputational reasons.

Bitcoin is the most liquid cryptocurrency so exiting a position can be done without too much market impact. Developers have historically lost status as they have become disenchanted with Bitcoin and left it for other projects. For a full node which is offline, when it comes back online, it can cheaply verify the history of what happened while it was away without trusting a third party because it can verify that miners were indeed producing blocks of the required difficulty.

The incentive scheme for miners works well; exceptions are empty blocks, block stuffing attacks by miners (whereby miners could drive up fees by stuffing their blocks and recouping the cost), and selfish mining (although this hasn’t been much witnessed in Bitcoin). Generally, exceptions occur because miners are making a political point, to their own detriment. No significant revisions to the incentive scheme are planned.

No.

Bitcoin functions on a patronage model. While some core developers receive subsidies from businesses which benefit from the existence of Bitcoin (Blockstream, Square Crypto, Xapo), others are unaffiliated and contribute to the project out of altruism or for the sheer interest and intellectual challenge.

The social contract and constitutional principles laid out by Satoshi, paired with the credibility accumulated over time as these principles proved practical and realistic in their implementation. Today, the elite cadre of developers interprets Satoshi’s vision under modern day constraints and maintains the protocol while retaining consistency with the original objectives. Current developers have some degree of interpretive power, within limits. Major constraints to their authority are the potential for a user rebellion (the UASF of 2017 was user-driven, against the wish of many Core Developers) and miner dissent, as exhibited from 2016-17 when miners were reluctant to ratify proposed the proposed SegWit upgrade to the software.

Another source of legitimacy is the relatively stable nature of the blockchain itself, which has experienced very little downtime since inception, and where upgrades typically occur through soft forks (non-coercively allowing users to opt in to new configurations). As the blockchain has matured, its own persistence gives the stewards of the system more credibility.

High profile and well-networked developers who can lay out a coherent vision for a new proposal. There is no explicit process here, so understanding the nuances behind getting support for a proposal is a key requirement. This can also serve as an exclusionary system design, as an understanding of the politics of the proposal process are essentially a requirement.

Generally speaking, the core developer community does. These are often negotiated with miners and economic nodes (as was the case with the 2x fork and the NYA compromise) but ultimately developers will make a scientific decision as to the validity of a proposal.

Node operators (by accepting an update into their code), and at times, miners.

The judicial group is economic node operators. They can threaten to run a dangerous or hostile implementation which would partition the network, as was the case with the User Activated Soft Fork. This has only happened once though so should be considered infrequent. However in this case it was sufficient to induce the miners to upgrade to SegWit which they had been reluctant to do. In this case they overrode the wishes of both miners and core developers. They node operators can be understood to be the ultimate interest group within bitcoin. However this is a power which is rarely called upon.

The checks and balances consist of the distribution of power between economic nodes (exchanges, API services, wallet providers, custodians), core developers, and miners. Each group has influence and neither has unilateral influence over the direction of the project. Thus power is nicely poised between the three groups.

Through a combination of public discussion and negotiation among key stakeholder groups, and at last resort through a hostile blockchain fork, as happened with Bitcoin Cash. This latter dispute was “resolved” by splitting Bitcoin into two and letting the market price each token respectively. There is no explicit framework for resolving conflicts. Sometimes codified arbitration mechanisms are employed, as with the miner signaling for the SegWit upgrade in 2017, but the very selection of that mechanism is a political choice in of itself (and is unlikely to be redeployed for future soft forks). Public discussion happens at conferences, in the mainstream and industry press, in person, in closed-door meetings (like the infamous New York Agreement brokered by industry powerhouses like Digital Currency Group), on the mailing list, reddit, and twitter.

In the past, miner signaling has been employed to ensure nodes would upgrade to new software versions synchronously; this ended up being used as a de facto signaling mechanism even though this was not the original intention of the mechanism. Also, by choosing to run different node software (BIP148 nodes for instance was the node type run by supporters of the User Activated Soft Fork, in an attempt to convince miners to upgrade), users and service providers could signal their intent to support a given proposal. However there is an acknowledgment that this signaling method is not “sybil-resistant”, in that it can be gamed by an adversary, so it is of limited use.

Bitcoin has no explicit constitution, simply the white paper (which is more of a brochure for the code), the 0.1 release of the code which contained some implied constitutional features, and the aggregate writings of Satoshi on the mailing list and BitcoinTalk forums. As such nothing can be considered to be truly essential or unchangeable, but in practice certain features of the system are commonly considered to be Bitcoin’s essence – in particular the 21 million cap on the number of units, the supply schedule, and the public-key approach to identities.

Virtually any system feature can be changed by a hard fork, although in practice the community and developers are generally opposed to hard forks and they are difficult to coordinate in any non-emergency situation.

The standard process is a soft fork, whereby node operators have the option but not the obligation to transition their software to a new more permissive ruleset. The last major change, the SegWit implementation in August 2017, was carried out via soft fork. Generally, the core developers have committed to implementing changes through soft forks.

Changes which are considered routine are changes like transaction standardness – which sort of transactions get relayed – updates to the Bitcoin Core software itself (non-consensus changes), and which opcodes are used (opcodes are defined functions in the Bitcoin Script programming language). All of these features can be altered on a routine and non-controversial basis.

The implementation of drastic changes in Consensus critical software, such that alterations risk introducing a particition to the network if not done correctly, are generally considered extraordinary. In this respect, SegWit was understood as a rather drastic change, and as such occurred through a heavily-debated Soft Fork. SegWit changed the block size, fee structure, and tweaked the standard block contents, altering the economics and data throughput of the blockchain. You could say that changes to the block size are therefore extraordinary (although they were routine in prior years, because the block size was not a contentious issue).

Other features, like adding native privacy to transactions through a scheme like Confidential Transactions, would likely require extraordinary measures, because it would be controversial, and it would likely require a hard fork. Lastly, hard forks have been used in emergency settings to fix bugs (like the overflow bug in 2013).

The core rules of Bitcoin are hotly debated but it is generally understood that the supply features (the schedule and the cap) are essential to the protocol. There is little else which is essential to the protocol aside from perhaps features like transactions representing chains of signatures. Most other features have changed or evolved over time.

Generally speaking, change has gone from easy and unilateral (in the early days Satoshi made changes without notifying members of the community) to progressively more difficult and multilateral. Today significant updates to the software have not taken place for two years. The last major change happened in August 2017, and a touted change in November 2017 (doubling the block size) was rejected. Moving from hard forks (there were some in the earliest days) to soft forks as the default change method made change more difficult (since soft forks are more complex). The community has begun to shy away from miner-signaling as well, thus introducing uncertainty into the process, again making change more difficult. Any new proposal would require overwhelming buy-in from virtually all major stakeholders for it to pass today.

Governance in bitcoin is emergent, so it’s more a function of what methods are used in practice to govern the network. The model has been largely static over the years.