# An Empirical Study on Governance in Bitcoin’s Consensus Evolution

Jakob Svennevik Notland  The Norwegian University of Science and
TechnologyTrondheimNorway<EMAIL_ADDRESS>,  Mariusz Nowostawski  The
Norwegian University of Science and TechnologyGjøvikNorway
<EMAIL_ADDRESS>and  Jingyue Li  The Norwegian University of
Science and TechnologyTrondheimNorway<EMAIL_ADDRESS>
(2018)

###### Abstract.

Blockchain systems run consensus rules as code to agree on the state of the
distributed ledger and secure the network. Changing these rules can be risky
and challenging. In addition, it can often be controversial and take much
effort to make all the necessary participants agree to adopt a change.
Arguably, Bitcoin has seen centralisation tendencies in pools and in
development. However, how these tendencies influence blockchain governance has
received minimal community and academic attention. Our study analyses the
governmental structures in a blockchain by looking into the history of
Bitcoin. We investigate the process of changing consensus rules through a
grounded theory analysis comprising quantitative and qualitative data from 34
consensus forks in Bitcoin and Bitcoin Cash. The results reveal the
decentralised behaviour in Bitcoin and blockchain. Our results are in contrast
to related work, emphasising centralisation among miners and developers.
Furthermore, our results show how the consensus-driven deployment techniques
and governance of consensus rules are intertwined.

datasets, neural networks, gaze detection, text tagging

††copyright: acmcopyright††journalyear: 2018††doi:
XXXXXXX.XXXXXXX††conference: Make sure to enter the correct conference title
from your rights confirmation emai; June 03–05, 2018; Woodstock, NY††price:
15.00††isbn: 978-1-4503-XXXX-X/18/06††ccs: Computer systems organization
Embedded systems††ccs: Computer systems organization Redundancy††ccs: Computer
systems organization Robotics

##  1\. Introduction

Consensus rule changes in public permissionless blockchains such as Bitcoin
are challenging (Andresen, 2014; Bitcoin.org, 2015; Core, 2018a), and the most
trivial change could cause suspended services (Harper, 2021), lost mining
revenue (Bitcoin.org, 2015) and theft (macbook air, 2013; Kiffer et al.,
2017). However, the hardest part about these changes is usually not to
implement them correctly but rather to reach a consensus on adopting them
(Wirdum, 2020, 2017). The Bitcoin Core (BTC) repository maintainers and mining
pools have been pointed out as centralising factors in Bitcoin. Because only a
small group of highly skilled developers can change the rules of the system
(De Filippi and Loveluck, 2016; Parkin, 2019). Furthermore, pool
centralisation can be a worry regarding majority attacks (Beikverdi and Song,
2015a; Romiti et al., 2019). We analyse qualitative data from developer
communication channels and quantitative data from the Bitcoin ledger using
Strauss’ Grounded Theory (GT) (Corbin and Strauss, 2014) approach to
understand how Bitcoin manages governance through community coordination and
infrastructure mechanisms. Our analysis encompasses 34 consensus forks in
Bitcoin and Bitcoin Cash (BCH) from the launch in 2009 until 2022. We mainly
collect samples from developer channels, e.g., emails, forums and internet
relay chat (IRC).

The findings show how miners, full nodes, end-users, and developers influence
consensus change differently. Despite developer and pool centralisation, the
power of the economic majority, miners, and full nodes perform as
decentralising factors in the governance process. Consensus forks can be
deployed differently depending on their compatibility with current consensus
rules (e.g., reduction fork, expansion fork and bilateral fork (Zamyatin et
al., 2018)), and the chosen deployment strategy (e.g., miner-activation, user-
activation, and emergency-activation). The combination of fork types and
deployment strategies form deployment techniques, where the chosen technique
resembles a tradeoff between consistency and functionality (Notland et al.,
2022). We have identified how the deployment techniques rely on consensus to
enhance decentralisation and how they intertwine with the governance
processes. For instance, the blockchain can be a tool to coordinate and time
the activation of a fork. Our study focuses on obtaining new knowledge and
insights into the governance of consensus rules in blockchain in general based
on experience from Bitcoin and Bitcoin forks.

The remaining parts of this paper are structured as follows: Section 2
introduces the background on blockchain consensus and its evolution. Section 3
describes the research design and implementation. Section 4 presents the
results, describing governance processes in Bitcoin. Section 5 discusses the
results before the conclusion in Section 6. In the end, we suggest future work
in Section 7.

##  2\. Background

The process for Bitcoin Improvement Proposals (BIPs) as seen in Figure 1
(Core, 2021a) has been adopted from Python Enhancement Proposals (PEPs)
(Python-dev, 2000), that again was based on Request for Comments (RFC)
(Encyclopedia, 2022). In the early days of the Internet protocols, governance
relied on ”rough consensus and running code” to settle disputes (Russell,
2006). On the other hand, Bitcoin is an immutable and consistent distributed
ledger moving away from rough to uniform consensus to secure its integrity and
value. Even if a small group of maintainers decide to adopt consensus changes
on a repository level, they will need support from the community to deploy the
changes to the network. Technically, the power to change consensus rules lies
in the hand of miners and nodes that run the code, and the system’s success
relies on network-wide consensus and adoption.

Figure 1. BIP-0002: BIP process, revised (Core, 2021a)

[The process of creating and evaluating Bitcoin Improvement Proposals.]The
process of a BIP starts with a draft and must gain community support before an
eventual implementation can be activated.

###  2.1. The Bitcoin consensus protocol

Bitcoin is ”a peer-to-peer electronic cash system” (Nakamoto, 2008) consisting
of a chain of blocks containing transaction history, as illustrated by Figure
2. Any new block must abide by the consensus rules to be regarded as valid by
the nodes in the network. Miners attempt different values for the nonce
variable in a brute-force manner to produce an SHA-256 hash based on the
entire block. The miners find a valid nonce for the block header when the
resulting hash meets the required target difficulty. The difficulty indicates
that the resulting hash must have a certain number of leading zeros. This
mechanism is known as Proof-of-Work (PoW), first proposed to prevent email
spam (Dwork and Naor, 1993) and later applied for cryptocurrencies (Jakobsson
and Juels, 1999). In the case of Bitcoin, PoW prevents Sybil attacks (Douceur,
2002) and provides an immutability feature. The strength of these principles
is preserved by the difficulty adjustment algorithm (Nakamoto, 2008), ensuring
that the network will produce blocks with an average rate of around ten
minutes. Miners must comply with further consensus rules. Generally, blocks
and transactions must be in a valid format. Miners are incentivised to follow
these rules by collecting fees and the block reward generated in a special
coinbase transaction with no inputs from previous transactions.

Block collisions occur when two new valid blocks are produced at the same
height at approximately the same time. These two blocks can contain different
or even conflicting transactions. Collisions are resolved by the longest
(valid) chain rule as specified in Nakamoto’s whitepaper: ”The majority
decision is represented by the longest chain, which has the greatest proof-of-
work effort invested in it” (Nakamoto, 2008). The notion of a valid chain is
important because validness is subjective from the implementation’s point of
view. This rule specifies that the currently accepted chain has the most
dedicated work in terms of hash power. Therefore, any collision should quickly
resolve during regular operation as soon as another block is appended on top
of one of the colliding blocks, making it the longest chain. This behaviour
implies that blocks have a slight chance of being orphaned (discarded), along
with the corresponding transactions as illustrated in Figure 3. To prevent
financial loss from orphaned blocks, the rule of thumb is to wait until the
block containing the relevant transaction has at least six blocks built on top
of it, i.e., six confirmations (Rosenfeld, 2014). Collisions in blockchain can
happen naturally, by an attack (Sayeed and Marco-Gisbert, 2019), or by
inconsistent consensus validation (Bitcoin.org, 2015).

Figure 2. Bitcoin blocks in a blockchain showing the content of the header and
the body.

[Figure 2 fully described in the text.]

Figure 3. Choosing the longest chain in the event of a collision.

[Figure 3 fully described in the text.]

###  2.2. Bitcoin consensus evolution

An inherent ideology within Bitcoin and especially BTC (in comparison to BCH)
indicates what kind of changes are viable or controversial. The quote in
listing LABEL:longestChain from the creator(s) can be seen as a cornerstone of
this ideology.

⬇

"The nature of Bitcoin is such that once version 0.1 was released, the core
design was set in stone for the rest of its lifetime."

Listing 1: Satoshi 2010-06-17 Forum, ID: 195

The statement from Nakamoto explains that the system itself, as well as the
original specification (Nakamoto, 2008) defines Bitcoin’s fundamental
behaviour. Moreover, it highlights the importance of non-disruptive changes
within this system, no matter how insignificant they may seem. Additionally,
any change in behaviour that alters consensus rules in Bitcoin should
preferably allow backward compatibility such that legacy nodes can accept any
new behaviour from the basis of the original specification, keeping the
network consistent. Our work distinguishes between Bitcoin in general, BTC and
BCH, which have different approaches to consensus changes in the blockchain.

In some cases, backwards-incompatible changes are needed if the implementation
does not work as intended. Such a change could be required to prevent exploits
or allow for the adaption and survival of the system. The Bitcoin community is
sceptical of consensus changes and making them a habit because bugged or ill-
intended code may be deployed and disrupt the integrity and stability of the
entire system.

The BTC community has a conservative approach to this policy, making it rare
that BTC implements backwards-incompatible changes, resulting in most changes
being deployed as backwards-compatible soft forks (Narayanan et al., 2016).
When referring to rules, rule changes, changes or forks in this paper, then we
are referring to changes in the consensus rules of a blockchain. A blockchain
node may validate a subset of those rules, while full nodes validate based on
all the rules. Any block or transaction violating those rules will be rejected
by these validators. As opposed to using popular terms such as soft fork and
hard fork to describe different kinds of changes, we use the notion of
reduction, expansion, and bilateral forks (Zamyatin et al., 2018).

  * •

A reduction fork reduces the set of valid actions in a blockchain, and legacy
implementations will accept all actions under the new validity set.

  * •

An expansion fork expands the set of valid actions in a blockchain, and the
new implementation will accept all actions in the legacy validity set and
more.

  * •

A bilateral fork creates a conflicting validity set where all previously valid
actions are invalid according to the fork, and the fork is entirely invalid
according to the legacy rules.

To avoid confusion in the terminology, we will refer to conflicting blocks as
chain splits. Chain splits can be temporary; a few (less than six) blocks will
be orphaned, persistent; six or more blocks are orphaned, or permanent; both
chains are expanded independently for all foreseeable future. An accidental
chain split caused by inconsistent validation among the nodes will be referred
to as a consensus failure. The longest chain rule is the most fundamental
factor in deciding whether a rule change is successfully adopted in Bitcoin.
The longest chain rule implies that the majority of miners can apply a
network-wide backwards-compatible rule change in terms of hash power. Relying
on the majority is the most popular technique to deploy changes in the
conservative BTC implementations.

In Bitcoin, one may rely on the majority (>50%) of block-producing nodes (n)
to perform a backwards-compatible consensus change. The reason for this to
work is because the Nakamoto consensus model has a Byzantine Fault Tolerance
(BFT) (Lamport et al., 1982) threshold of 50% (f). Other consensus models
might have different fault tolerance, such as 33% or 20% (Knudsen et al.,
2021). We will use the term super-majority (SM) to generalize the minimal
threshold requirement for different deployment techniques and to describe the
required threshold where faulty nodes are equal to or less than the tolerated
threshold. A super-majority of abiding nodes (h) is denoted as h>(n-f).

Consensus changes in BTC’s history have mainly been deployed with techniques
such as IsSuperMajority (ISM) (Todd, 2014), and in later deployments, the more
mature miner-activated soft fork (MASF) (Wuille et al., 2015). Other well-
known techniques are the user-activated soft fork (UASF) (Fry, 2017) or BCH’s
preferred user-activated hard fork (UAHF) (Bitcoincash.org, 2017). The user-
activated forks value new functionality over consistency in the network.
Hence, they carry a considerably higher risk of persistent or permanent chain
splits.

To better understand the dynamics of consensus rules changes, we refer to soft
forks as reduction forks, and hard forks as expansion or bilateral forks
(Zamyatin et al., 2018). The fork type depends on the compatibility between
the old and the new versions. The fork types can be combined with three
deployment strategies, user-activation, miner-activation and emergency-
activation, to form nine deployment techniques (Notland et al., 2022):

  1. (1)

Miner-activated reduction fork (MARF)

  2. (2)

Miner-activated expansion fork (MAEF)

  3. (3)

Miner-activated bilateral fork (MABF)

  4. (4)

User-activated reduction fork (UARF)

  5. (5)

User-activated expansion fork (UAEF)

  6. (6)

User-activated bilateral fork (UABF)

  7. (7)

Emergency-activated reduction fork (EARF)

  8. (8)

Emergency-activated expansion fork (EAEF)

  9. (9)

Emergency-activated bilateral fork (EABF)

A miner-activated strategy relies on coordination to be deployed, user-
activated strategies prioritize change over consistency and are activated
regardless of network adoption, and a crisis defines the immediate trigger for
emergency-activated changes.

##  3\. Research design

###  3.1. Research motivation

Concerns have been raised regarding Bitcoin centralisation in development
(Parkin, 2019; De Filippi and Loveluck, 2016) and mining (Romiti et al., 2019;
Beikverdi and Song, 2015a). We assume these tendencies have a low impact on
the governance of consensus rules in Bitcoin and blockchains. We have this
assumption because the consensus mechanisms restrict blockchain governance and
deployment capabilities (Notland et al., 2022). We formulate the research
question: How have the different deployment techniques and features been used
as governmental instruments when making consensus changes in blockchain?

Related work on Bitcoin governance mainly divides between ”governance of the
infrastructure” and ”governance by the infrastructure” (Parkin, 2019; De
Filippi and Loveluck, 2016). Our research is motivated to understand how these
two perspectives interact and whether the infrastructure’s decentralised
consensus mechanisms tame the centralised process of governing the
infrastructure. Other related work shows that mining operations are becoming
more centralised through pools and that it can be a problem in terms of
majority attacks (Romiti et al., 2019; Beikverdi and Song, 2015a). We
hypothesise that despite the pools’ ability to disrupt the blockchain short-
term, they cannot govern the system and force consensus changes without
support from their miners, full nodes, and end-users. In contrast to
describing how blockchains are designed to decentralise a currency’s power
structures, we are motivated to perform an empirical investigation on how a
blockchain manages decentralised governance.

###  3.2. Research method

In this article, we investigate the governance of consensus rules in
blockchain and the relationship between the governance of the infrastructure
and the governance by infrastructure. The analysis and background partially
overlap with our previous work, where we investigate deployment techniques for
consensus rules (Notland et al., 2022).

The sheer amount of available samples on the world-wide-web would allow for
quantitative and qualitative analysis. It became apparent that a qualitative
and inductive approach needs to be at the method’s core to reach the goal of
an insightful and holistic view of consensus changes in blockchains. To answer
the research question, we performed Strauss’ GT analysis (Corbin and Strauss,
2014) of Bitcoin’s consensus forks. The GT approach is an iterative and
recursive approach where the researchers must jump back and forth until they
achieve theoretical saturation. That is when new samples stop contributing to
the theories under development. In addition to the qualitative analysis, we
performed a statistical analysis of Bitcoin blocks (e.g., the arbitrary
coinbase messages and version numbers) to further understand how the
blockchain acts as an instrument in the governance process.

The observations done throughout the study are covert (Oates, 2006), where a
researcher can get the most authentic experience of how the actors conduct a
process. Although covert observations can be ethically questionable, it is
crucial to consider that the public archives of Bitcoin were created for this
purpose and to provide transparency and accountability in the project. With
this in mind, the actors should expect their actions to be considered in
research. The actors are represented by their chosen alias without further
effort to reveal the person behind or make connections between different
aliases.

###  3.3. Research implementation

We outline the implementation of the research method conducted for this study
in an abstract graph in Figure 4. The oval shapes indicate processes, the
lines show the process flow, the rectangular shapes indicate data objects, and
the cylinders indicate archives. Different colours highlight whether the
processes and corresponding objects are related to data sampling or GT
analysis. The process steps are further described in the subsequent sections.

In summary, the process started with a purposeful sampling (Oates, 2006) of
data, specifically from BTC’s development channels. Relevant samples were
discovered in these archives by filtering and purposefully selecting (cherry-
picking) samples with high relevance to consensus rule changes. The selected
samples are efficiently sorted through the use of flexible coding (Deterding
and Waters, 2021). Further, snowball sampling and triangulation (Corbin and
Strauss, 2014) avoided limitations from the selected samples by discovering
additional samples.

Figure 4. Method process model (detailed) (Notland et al., 2022).

[Figure 4 fully described in the text.]

####  3.3.1. Purposeful sampling

The initial step in collecting data related to the consensus changes and
governance in Bitcoin was to identify the consensus changing events in
Bitcoin. A summary of all the consensus change implementations in BTC’s
history is listed in the Bitcoin Wiki (Wiki, 2022) and in Table 1. Further
inspection reveals an overview of the main events and information such as the
time, block height, version number, and deployment techniques. Development
channels were identified as the most fruitful sources, and their data was
extracted to initiate the filtering process. However, the sample boundary was
fluid, so samples from other domains were considered whenever they appeared.
These could be domains such as other Bitcoin channels, announcements, news
articles, magazines, videos, or other blockchains. The additional sources
strengthened the theories and the initial assumptions rather than expanding
them, showing the relevance of the development channels initially selected by
purposeful sampling.

Table 1. Overview of consensus changes in Bitcoin Core and applied search strings. Version | Consensus change | Maintenance type | Search strings
---|---|---|---
BTC 0.1.6 | Time based locking nLockTime | Corrective | nLockTime
BTC 0.3.5 | CVE-2010-5137 & CVE-2010-5141 | Corrective | CVE-2010-5137, CVE-2010-5141, 0.3.5
BTC 0.3.6 | Disable/enable opcodes | Adaptive & preventive | OP_CHECKSIG, OP_NOP, 0.3.6
BTC 0.3.7 | Separate scriptSig & scriptPubKey | Corrective | scriptSig, scriptPubKey, 0.3.7
BTC 0.3.10 | Output-value-overflow CVE-2010-5139 | Corrective | overflow bug, 184, CVE-2010-5139, 0.3.10, 74638, 74 638
BTC 0.3.12 | 20 000-signature operation limit & 1MB blocksize | Corrective | MAX_BLOCK_SIZE, 79400, 79 400,
|  |  | MAX_BLOCK_SIGOPS, 0.3.12
BTC 0.6.0 | BIP30: Duplicate transactions CVE-2012-1909 | Corrective | bip30, bip 30, duplicate transactions
BTC 0.6.0 | BIP16: Pay-to-script-hash | Perfective | bip12, bip 12, bip16, bip 16, bip17, bip 17, bip18, bip 18,
|  |  | OP_EVAL, P2SH, pay-to-script-hash, 0.6, 0.6.0
BTC 0.7.0 | BIP34: Include block height in coinbase | Corrective | bip34, bip 34, 0.7, 0.7.0, 227835, 227 835
BTC 0.8.0 | BIP50: Migrate from Berkeley DB to LevelDB | Corrective & perfective | bip50, bip 50, leveldb, berkeley db, 225430, 225 430,
|  |  | max 4 500, reduce blocksize, lock limit, 0.8
BTC 0.8.1 | BIP50: Database lock limit & Max TxID limit | Corrective | -——-
BTC 0.8.1 | BIP50: Relax database lock limit & max TxID limit | Corrective | -——-
BTC 0.9.2 | BIP42: 21 million supply | Preventive | bip42, bip 42, 21 million, 21 000 000, 0.9.0,
|  |  | 13,440,000, 13440000, 13 440 000
BTC 0.10.0 | BIP66: Strict DER signature | Corrective | bip66, bip 66, strict der signatures, 0.10.0, 0.9.5
BTC 0.11.0 | BIP65: Check lock time verify | Perfective | bip65, bip 65, check lock-time verify, CLTV,
|  |  | CHECKLOCKTIMEVERIFY, 0.10.4, 0.11.2
BTC 0.12.1 | BIP68, BIP112, BIP113: Check sequence verify | Perfective | bip68, bip 68, bip112, bip 112, bip113, bip 113,
|  |  | Check sequence verify, Relative lock-time,
|  |  | CHECKSEQUENCEVERIFY, CSV, 0.11.3, 0.12.1
BTC 0.13.1 | BIP141, BIP143, BIP147: Segregated Witness | Perfective, corrective, | bip141, bip 141, bip143, bip 143, bip147, bip 147,
|  | adaptive & preventive | segwit, 0.13, bip91, bip 91, bip148, bip 148,
|  |  | segregated witness, 481824, 481 824
BTC 0.14.0 | CVE-2018-17144 | Perfective | -
BTC 0.16.3 | Fix CVE-2018-17144 | Preventive | -
BTC 0.21.1 | BIP341, BIP342, BIP343: Taproot | Perfective & adaptive | -

The channels that were selected as initial data were the Bitcoin improvement
proposals (Core, 2021a), the bitcoin-dev emails (Foundation, 2022a), the
Development & Technical Discussion topic in the Bitcoin forum (Forum, 2021),
the code repository (pull requests (Core, 2021c) and issues (Core, 2021b)),
and IRC channels (#bitcoin-dev and #bitcoin-core-dev (wiki, 2020)). The total
sample count is 1700, as depicted in Figure 5. One sample corresponds to one
thread (email, forum and Github), one proposal (BIP) or one day of IRC
messages. The sum of samples across the events is larger than the sum across
sources because some samples are related to multiple events.

Figure 5. Sample distribution among different sources and events.

[Figure 5 fully described in the text.]

####  3.3.2. Data collection

After acquiring an overview of consensus change events and corresponding BIP
specifications, we applied filtering to the initial data. The first source of
data considered was the email list. With a relatively compact overview of all
the threads, it was viable to traverse through the titles to find relevant
samples. After email samples were collected, the next step was the forum.
However, the forum source proved large and challenging to sort through.
Therefore the search was conducted in two stages: First, all the threads
leading up to and surrounding the dates of each consensus incident were
checked for relevance, referred to as cherry-picking samples. Second, we
filtered the forum with the help of a search tool targeting the Bitcoin forum
(Ninjastic, 2021). The filtering was commenced using the search strings shown
in Table 1. This filtering approach was also applied to the Github search. We
found the relevant BIPs as they correlate to consensus changes and deployment
techniques.

When considering the IRC channels, the initial plan was to focus on the
meetings conducted in Bitcoin’s history and limit the number of samples
collected in the initial phase. However, after getting familiar with Bitcoin
meetings of the past, it became clear that there were only a few meetings
(four in total) before the developers decided on weekly meetings in fall 2015.
Therefore a search was conducted by applying a few search strings that could
indicate conversations about the issues of consensus changes that have taken
place. These strings were ”fork”, ”chain split”, ”stuck” and ”reorg”. The
files were traversed together with the use of grep (Foundation, 2020), showing
each related sentence. The whole log from each sample was collected whenever
indicating some value or relevance. Considering the size of the resulting data
set of IRC samples, they indicate that the search strings were accurate and
broad enough to catch relevant samples. The logs around important dates were
cherry-picked and inspected, even if they included the search strings or not.
Finding relevant samples became simpler from the fall of 2015 as the weekly
meetings could be collected. A challenge with the IRC logs has been that the
logs are somewhat dispersed between different archives (Erisian, 2021a, b;
BuildingBitcoin, 2019; Erisian, 2018). Together with the inherent
inconsistencies (Ellenbogen, 2016) within the archives, it became clear that
all the different archives had to be considered when searching.

The qualitative sources, especially the BIP documentations (Core, 2021a),
reveal how the blockchain is actively used in governance. Concrete data from
the version header and the coinbase message field show traces of on-chain
signals to support different consensus forks. We install the BTC full node
implementation (Core, 2022) to retrieve the blocks and use Matplotlib
(development team, 2022) to make a graphical representation of signals related
to consensus forks in BTC as presented in Section 4.3: Figure 11 and Figure 11
and Appendix A: Figure 14 and Figure 15. The graphs provide insight into how
the blockchain is used in BTC and BCH governance and how it changes over time.
Our script traverses the BTC blockchain from the genesis block until block
737000 to include all consensus forks to date. We implement a constant rolling
window of 1000 blocks to calculate the percentage of signalling miners. This
size is accurate enough for graphical representation, although the actual
rolling window size used for deployments ranges from 336 to 2016.
Additionally, we plot known activation timings of different consensus changes
in BTC and BCH, regardless of whether they rely on signalling.

##### Open coding

It became apparent that the GT approaches do not describe how to utilise
modern data analysis tools most effectively when analysing a large number of
samples. To cope with this, we refer to flexible coding from Deterding and
Waters (Deterding and Waters, 2021), which explains ways that large sets of
data can be collected and coded using qualitative data analysis software
(QDAS) such as Atlas.ti (Atlas.ti, 2022), NVIVO (NVIVO, 2022) or MaxQDA
(MAXQDA, 2022). We applied the indexing approach as a specific form of open
coding designed to provide an overview of the initial data and effectively
define and evaluate codes and categories. In practice, the data was initially
indexed on a sample basis to highlight the essence of each sample. We
constantly evaluated the indexing as new codes and categories emerged. Memos
were created to understand the correlation between codes, categories, and
events. One specific code was used to highlight notable quotes that had a
considerable impact on the results (Deterding and Waters, 2021). This code
always overlaps with other codes and is labelled ”aha” to signal the aha
experience these quotes represent. Quotes labelled with this code were
consistently revisited and were candidates to support the results.

##### Axial coding

The axial coding phase was conducted by revising, combining, and splitting
codes and categories. Some of them were combined with decreasing levels of
granularity when the low-level details became unhelpful in addressing the
research question and increasing theoretical saturation. On the other hand,
some codes were split to increase granularity and enhance insights. This stage
also developed patterns and relations within the codes and categories as
formerly described and depicted in Figure 7.

##### Selective coding

At this stage, the analysis revealed the main category of governance.
Therefore, selective coding would focus on saturating this category and the
opportunities for quantitative analysis from blockchain traces of governance
processes. We further elaborated on Bitcoin and other blockchains such as BCH
to reflect on the governance structures and their relation to the deployment
techniques.

##### Constant comparison and theoretical saturation

The codes, categories and emerging theories were constantly compared by
controlling whether they made sense regarding the research question and the
objective domain. Samples that no longer gave more insights were stored in a
group labelled ”not interesting” to ensure that the most relevant and
interesting logs were saturated first. It was assumed that the samples
collected in the initial search could lead to an adequate theory in this
paper. However, there was always a possibility that the current data set was
too narrow. Therefore the techniques of snowballing (Penrod et al., 2003) and
data triangulation (Corbin and Strauss, 2014) were systematically applied.

The data saturation process led to additional findings not identified in the
initial data collection phase. The findings could, for instance, be missing
links from one of the resources used in the data collection, or it could be an
article from the Bitcoin Project’s website (Bitcoin.org, 2022), a blog post,
or a video. These new samples were systematically collected by applying the
snowballing technique. Then they were also included in the data set if they
were relevant to the research question, which gave a significant amount of
additional samples from resources other than the initially collected ones.

Data triangulation was applied between the different resources to see the same
phenomena from different perspectives. It was possible to figure out that when
something important happened in one place, there would probably be more to
read about from other samples. This gave a rich data set with multiple
perspectives and helped when, for instance, the IRC chat had inconsistencies
on the 2015 event (version 0.10.0) where 2015-07-03, 2015-07-04, and
2015-07-05 are missing. Many other samples revealed how this specific
consensus failure was caused by custom and lazy validation, as well as spy-
mining (Research, 2017).

##  4\. Results

The codes, constant comparison and theoretical saturation based on the codes
reveal the system, roles, and processes to develop in a symbiosis of chaos
tamed by the underlying blockchain infrastructure. Initially, it can be
challenging to identify the causalities within the decentralized environment.
However, as the analysis commences with codes giving meaning to the data, data
triangulation shows the relationships within. Eventually, this forms a chain
of events, as seen in the timeline of Figure 7, showing how the processes of
governance, evolution, and maintenance have been refined through trial and
error.

The timeline summarizes 34 consensus-changing events, including 24 changes in
BTC and 10 changes in BCH (represented by Bitcoin Cash Node (BCHN)) marked as
grey boxes. The dates are based on either the flag day/block for the
activation, the date the changes activated based on signal thresholds, or when
these versions were released. The red boxes indicate some issues where the
deployment was performed by emergency, caused a chain split, or other issues
(Notland et al., 2022). All the events in the timeline represent instances of
governing Bitcoin, either by deploying planned changes or by handling
emergencies in the blockchain.

The codes and categories discovered and applied through GT are introduced in
Figure 7. The codes within the categories of issues, development, and human
error have been stripped to enhance readability and focus on the codes
relevant for the research question of this study. The figure indicates the
process of defining, implementing, and deploying consensus rules. In Bitcoin’s
case, these changes are usually motivated by some issues which prevent the
implementation from providing the full service envisaged in Nakamoto’s white
paper or code. The discovery of an issue leads to development before moving on
to deployment. On the outskirts of the process lays the possible influence of
human error and social/political (governance). Human errors may disturb either
development or deployment, where mistakes and errors typically occur during
development and violations occur in deployment. The social/political influence
is only applied to deployment because Bitcoin also must abide by the rules of
open source software (Nyman and Lindman, 2013), which is that anyone can fork
the code at any time. In other words, the network can bypass the developers’
influence and control over a single repository.

Figure 6. Timeline of consensus changes in BTC and BCH (Notland et al., 2022).

[Figure 7 fully described in the text.]

Figure 7. Codes and categories

[Figure 7 fully described in the text.]

###  4.1. Initialising the governance process

The analysis codes related to the social/political category (figure 7) show
how the governance process relies on the controversy of a change. A change
with low controversy requires low effort in terms of deployment.
Centralisation tendencies in development and mining operations can streamline
the deployment of non-controversial changes. The changes that can be deployed
most quickly are those related to fixing an immediate issue in the blockchain.
In that case, the developers are in a hurry to implement a solution while
miners and pool operators eagerly install it, and the change may apply
quickly. The fix of CVE-2018-17144 is the latest example of developers and
pools streamlining deployment (applied in BTC 0.16.3 and BCHN 0.18.2), where
the Slush pool collaborated with developers to deploy the upgrade before it
was publicly released (Core, 2018b).

However, for planned changes, the deployment must happen publicly and with
enough time to review the proposal and implementation. Back-room-like
agreements between pools and developers will cause havoc in a decentralised
blockchain. The closest example of such behaviour has been seen in the Hong
Kong Roundtable Consensus (Roundtable, 2016), and New York Agreement (Group,
2017), where prominent mining actors and central developers agreed to pursue a
2MB expansion fork on top of SegWit. The proposal was named Segwit2x, and the
proponents held around 80% of the network’s hashing power. However, the
proposal did not gain enough traction in the community and ended up being
cancelled (Belshe, 2017).

Whether a change is a reduction, an expanding, or a bilateral fork is vital
because reduction forks can be deployed with only a supermajority of miner
support. In contrast, expanding and bilateral forks require 100% support from
miners to prevent a chain split. Therefore expanding and bilateral forks rely
more on support from end-users to adopt the new chain, maintain its value, and
pay fees. If a large portion of miners (e.g., 80%) causes a chain split to
deploy a change with low adoption from end-users (e.g., 20%), then the new
chain could lose its value, and miners will be incentivised to jump back to
the legacy chain. In this way, the miners depend on user adoption to
financially support the system, as much as users depend on miners for the
system’s security. With a reduction fork, the case is different because a
supermajority (i.e., 51%) of miners can deploy a change without causing a
persistent split. The rest of the network will have few choices except to
accept such a change.

Moreover, if opposing miners and users wish to prevent or revert a reduction
fork, they would have to gain control of the majority of hashing power or
force a chain split by deploying a new fork. Therefore, if the Segwit2x
proposal was a reduction fork, they could force the rest of the network to
abide by their consensus change. However, as it was an expanding fork, they
would rather detach from the legacy network.

Controversial changes can be tedious to deploy, regardless of the fork type.
Controversial proposals often lead the community to split in two and create a
series of opposing posts and comments expressing FUD (fear, uncertainty, and
death) or shill to express all the advantages and fortune that can be made by
deploying the change. In these cases, the developers of a change must
carefully use the deployment techniques for a change, optimally leading to
deployment without a chain split or no deployment at all. Miners choose
whether they want to support the change or not. That decision heavily relies
on seeing the direct benefit of that change and whether the users are willing
to adopt and pay for the system’s services after the change.

###  4.2. Roles in governance

The nodes running in a blockchain network are complex and connected in an m-n
fashion in the peer-to-peer network. The Wenn diagram in Figure 8 illustrates
the complexity of the four roles an actor can take in a blockchain network.
The four main roles are: 1) The developer has access to all the components in
the diagram but does not necessarily run them. 2) End-users can be satisfied
by running any wallet service. 3) Miners run mining operations. 4) Full nodes
must hold all blockchain data from the genesis block and run the latest
consensus rules. As the figure shows, a single node can represent one or many
of these roles at the same time. Figure 9 illustrates how the actors are
connected in the Bitcoin network.

Figure 8. Blockchain node Wenn diagram.

[Figure 8 fully described in the text.]

Figure 9. Decentralised blockchain network topology.

[Figure 8 fully described in the text.]

In the end, miners decide the future of a blockchain, whether nodes will
evolve in harmony or split into different blockchains. At the same time, the
full nodes hold the consensus rules and will judge which chain their connected
users will follow in case of a split. One can argue that the development of
some repositories, such as Bitcoin Core is centralised (Parkin, 2019; De
Filippi and Loveluck, 2016). However, the maintainers can only make changes to
that specific implementation of the consensus rules. They cannot force anyone
to use them.

On the other hand, miners include transactions and produce blocks. Without
miners, the blockchain will stop extending. The miners can deploy a reduction
fork without causing a chain split by having super-majority adoption, or 100%
in the cases of expanding and bilateral forks. There will always be an
economic incentive to avoid chain splits because the network will be perceived
as more reliable if it stays consistent.

###  4.3. Bitcoin governance overview

The graphs of Figure 11 and Figure 11 illustrate the evolutionary decisions
made in BTC’s history up to the latest changes deployed in 2022. The y-axes
represent the percentage of signalling blocks based on the latest 1000 blocks,
and the x-axes show the time. Solid lines show the signals retrieved from
coinbase messages or the version bit field from blocks. The lines are dotted
after activation to show that they no longer make a difference. The dashed
lines at the top of Figure 11 show the timing of successful deployments where
those signals reached the required threshold of miner-activated strategies or
were triggered by user-activation or emergency-activation. All the plots are
retrieved from the BTC blockchain, while the graphs are separate to enhance
readability. The graphs in Figure 11 and Figure 11 only include the deployment
processes and events discussed in Section 4.4.

Figure 10. The graph shows key deployments in BTC including signals used with
MARF deployments and flag days/blocks.

[Figure 11 fully described in the text.]

Figure 11. The graph shows failed attempts to deploy increased blocksize with
signals used with the MAEF deployments.

[Figure 11 fully described in the text.]

More detailed graphs are included in Appendix A. Figure 14 shows all the
signals related to activated changes in BTC, including known activation
timings in BTC. Figure 15 shows all the BTC signals related to failed attempts
of deploying increased block size combined with BCH flag day timings. The BCH
chain is yet to utilize signals as part of the deployment process since the
chain split. Instead, miners often signal which node implementation they
support (e.g., BCHN) (Unlimited, 2022). Some rule changes are not included in
the graphs because it is impossible to state the exact activation time. This
is because these deployments did not have an exact timing based on a signal,
flag day/block height or chain split. Those are BTC 0.3.5, BTC 0.3.6, BTC
0.3.7, BTC 0.9.2, BTC 0.14.0 (CVE-2018-17144), BTC 0.16.3. and BCHN 0.18.2.
Most of these changes were deployed through emergency-activation.

###  4.4. Key Bitcoin governance events

Some key governance examples appear as numbered in Figure 11.  1) In the early
stages of Bitcoin, from late 2011 and early 2012, there were three conflicting
proposals for pay-to-script-hash (P2SH) (BIP12, BIP16, and BIP17). All the
proposals were attempted using a simple MARF deployment technique for the
first time, and influential Bitcoin developers stood behind each proposal. The
MARF technique is simple because the activation threshold was evaluated
manually, and the timing was moved manually. In contrast to the later
techniques, which implement a rolling window to automatically activate based
on the threshold (Notland et al., 2022).

The BIP12 proposal was at first discarded when a bug allowing unlimited
recursion was discovered in the code. Afterwards, two conflicting proposals
were created; BIP16 and BIP17. The conflicting proposals made the situation
even more contentious. The operator (Tycho) of Bitcoin’s biggest mining pool
(Deepbit) at that time represented roughly 1/3 of the hash power and the
reluctant voice of opinion by being unwilling to support the enforcement
before it gained more traction and technical guarantees, as seen in listing
LABEL:tycho. In the end, with more improvements, miner support, and influence
from most of the Bitcoin Core maintainers, the miners decided to enforce BIP16
as the desired solution. The contention of deploying this feature and the
manual change of the timing caused a delay in the deployment process, which
led some nodes to enforce and judge the rules too early and reject valid
blocks.

⬇

I would like to add something about one of the reasons why I don’t want to be
the FIRST to adopt P2SH: I don’t like doing beta tests in a production
environment. In last 2 days I already got 3 messages from Gavin about new bugs
found in his implementation: one "minor bug" and one "major bug" ("one
critical line was dropped in a merge and missed in my testing"). Also some
coins were possibly destroyed in the process because a bug caused block fees
to be lost.

Listing 2: Tycho 2012-01-25 Forum, ID: 61125

The consensus mechanisms of the blockchain restricted the decisions on the
implementation and deployment of P2SH. The political view was that the change
should be compatible with old nodes and deployed in the network collectively
to avoid a chain split. The rule changes were implemented as a ”hackish”
solution to achieve compatibility, making it a reduction fork. Further, the
deployment relied on majority adoption to ensure that the network would
enforce the new rules collectively. The arbitrary coinbase message in blocks
was used as a governmental instrument to measure and reach the adoption
threshold before activation.

2) The signal for BIP16 stayed active for a few years after the activation of
pay-to-script-hash. The signal does not matter as it simply stayed active
because it was not removed from the code before 2015 (Luke-jr, 2015). After
activation, the blue line signalling BIP16 shows traces of miners turning off
the flag manually as it goes down before going up again with major releases of
Bitcoin Core, which by default included the signal in the coinbase message. In
later versions (from and including BTC 0.12.1  (3)), the activation signals
were configured to cease as soon as they have served their purpose, seen as an
immediate drop in support after activation.

4) The Bitcoin network experienced an accidental chain split caused by a non-
deterministic expansion fork in BTC 0.8.0 (Andresen, 2014). One could say that
the full nodes and miners were split in two, judging and enforced by different
constitutions. The end-users and miners would follow the chain judged as valid
by the full nodes they were running or connected to. As shown in listing
LABEL:rollbackIRC, developers (Luke-Jr, sipa, jgarzik, and gavinandresen) and
pool operators (Eleuthria and doublec) coordinated a rollback of Bitcoin to
let the nodes reorganise to the legacy chain. This emergency response shows a
case where the centralisation tendencies in the developer team and pools
streamlined the governance process.

⬇

<Luke-Jr> gavinandresen: sipa: jgarzik: can we get a consensus on
recommendation for miners to downgrade? (...)

<Eleuthria> I can single handedly put 0.7 back to the majority hash power

<Eleuthria> I just need confirmation that thats what should be done (...)

<sipa> Eleuthria: imho, that is was you should do, but we should have
consensus first (...)

<jgarzik> sipa, Eleuthria: ACK on preferring 0.7 chain, for the moment (...)

<gavinandresen> Eleuthria: if you can cleanly get us back on the 0.7 chain,
ACK from here, too (...)

<Eleuthria> alright (...)

<doublec> ok, rolling back to 0.7.2

Listing 3: Developers: Luke-Jr, sipa, jgarzik, and gavinandresen. Pool
operators: Eleuthria and doublec 2013-03-12 IRC: #bitcoin-dev

BTC’s consensus mechanisms and technical landscape steered the community
toward a rollback to the legacy, flawed implementation. Since BTC 0.8.0 was a
(non-deterministic) expansion fork, the network would require all miners to
upgrade and discard the legacy chain. On the other hand, only a majority had
to mine on the legacy chain to discard the new chain. Additionally, many end-
users still relied on legacy implementations, such as Mt.Gox, the largest
exchange at the time. If the community choose to proceed with 0.8.0, it would
be a long-lasting inconsistency with service outages. Only the emergency-
activated reduction fork (EARF) could quickly gather the community on one
chain. The later patch (0.8.1) was created as an uncontroversial change to fix
the bug permanently and deployed through user-activation since resolving the
bug was more important than keeping the network consistent with unpatched
nodes at that point. The patch gave node operators reasonable time to upgrade
through a flag day.

5) The deployment of BIP66 implemented in BTC 0.10.0 demonstrates full nodes
passing judgement on misbehaving miners. The incident occurred during the
activation in July 2015 without notable traces in the graph itself. Regarding
governance, roughly 50% of miners were not performing full node validation
according to new rules, enforced old rules and produced short-chain splits.
Thus, competing for the longest chain. The full nodes noticed this and
rejected those blocks, and the full node validated chain prevailed in the end.
The quote in listing LABEL:SPVMining emphasises the risk of mining without
validation.

⬇

Note that the roughly 50% of the network that was SPV mining had explicitly
indicated that they would enforce the BIP66 rules. By not doing so, several
large miners have lost over $50,000 dollars worth of mining income so far.

Listing 4: Bitcoin.org (Bitcoin.org, 2015)

6) The most contentious consensus rule change of Bitcoin and any blockchain so
far is the deployment of SegWit in August 2017. In the beginning, the pink
line shows the struggle to reach the required 95% threshold. This struggle is
often referred to as an attempt to veto the deployment of SegWit. Many SegWit
proponents were determined to force through the upgrade with a user-activated
reduction fork (UARF) and set a flag day to exclude non-signalling nodes on
2017-08-01. They gained support from the SegWit2x community, who intended to
enforce SegWit signalling triggered by a 80% threshold. The SegWit2x community
also intended to increase the blocksize of Bitcoin later, albeit not
successful. The SegWit2x community used BIP91 to reduce the evaluation window
and reached its threshold at 2017-07-20. The original 95% threshold was
reached on 2017-08-08, and the planned miner-activated reduction fork (MARF)
deployment technique then activated SegWit after a grace time of 2016 blocks
on 2017-08-24.

The point of highlighting the deployment process of SegWit is to show how
external (SegWit2x/BIP91) and anonymous (BIP148) developers enabled miners to
enforce the upgrade using a reduced threshold, flag day activation, and
exclusion against the advice of developers behind the original proposal
(BIP141, BIP143 and BIP147). As the quotes in listings LABEL:sipaUASF and
LABEL:maxwellUASF emphasise, the miners went through with UARF (noted as UASF
or BIP148 in listings LABEL:sipaUASF and LABEL:maxwellUASF) even though it was
discouraged by developers from the centralised core team and increased the
risk of a chain split.

⬇

I believe there is widespread support for SegWit, and I sure as hell hope it
activates at some point in time. Unsure if you’re aware, but I’m the primary
author of the SegWit proposal and patches. However, I don’t think there is a
rush, and BIP148 seems an unnecessarily risky way to bring that about.

Listing 5: Sipa 2017-05-17 Github: Pull 10417

⬇

I do not support the BIP148 UASF for some of the same reasons that I do
support segwit: Bitcoin is valuable in part because it has high security and
stability, segwit was carefully designed to support and amplify that
engineering integrity that people can count on now and into the future.

Listing 6: Gregory Maxwell 2017-04-05 Email: #bitcoin-dev

The UARF deployment technique was used as a governmental instrument to
persuade the sceptics to adopt SegWit. The UARF worked such that patched nodes
would discard blocks that were not signalling support for SegWit. Therefore
the proponents demonstrated the willingness to bet on Bitcoin’s economic
future to ensure SegWit adoption with two possible outcomes. First, a majority
of nodes discard non-signalling nodes, and the non-signalling nodes will be
denied block rewards. Second, A minority of nodes discard non-signalling
blocks, making a chain split, causing the legacy network to lose a significant
portion of its users and miners, leading to network disruption and economic
instability. The more users and miners enforce signalling, the more it impacts
non-signalling miners.

The second graph in Figure 11 shows several failed attempts to activate
increased blocksize with miner-activated expansion forks (MAEFs) in Bitcoin
between 2015 and 2018.  7) The signal with the highest support was BIP100
which reached support higher than 60%. However, the activation threshold of
75% was never reached. This expansion fork would have split the chain in two
if it were to happen with less than 100%, and end-users and miners would
follow one of them depending on which constitution they like, decided by the
full nodes they chose to run or connect to. It is also worth noting that these
proposals were backed by at least one highly influential developer, the
successor of Satoshi Nakamoto: Gavin Andresen. However, his influence was
insufficient to convince a significant majority to adopt larger blocks.
Listing LABEL:ballsyAndresen indicates lead maintainer Andresen’s failed
assumption of having actual decision-making power as a benevolent dictator.

⬇

That may be what has to happen with the blocksize, frankly. I may just have to
throw my weight around and say: This is the way its gonna be and if you don’t
like it, go find another project.

Listing 7: Gavin Andresen 2015-04-18 (Andresen, 2015)

BCH was deployed as an alternative to BTC’s SegWit user-activated reduction
fork in August 2017. The deployment was commenced using a user-activated
bilateral fork technique (UABF). The deployment classifies as user-activated
because it did not rely on coordination between nodes to reach a certain
threshold of support before activation. Additionally, the fork would activate
using a flag day regardless of network adoption, thus prioritizing the
features of BCH before the consistency of the network. BCH’s increase in block
size is an expansion fork by itself. If BCH was deployed as a plain expansion
fork, it would still accept SegWit blocks. Additional changes were needed
since the fork was likely to be deployed by a minority. Therefore BCH’s
deployment implementation required the first block in BCH to be larger than
1MB, causing a conflict between the legacy and the new chain. This conflict
makes BCH a bilateral fork rather than an expansion fork to ensure a chain
split at the activation time. The deployment of BCH demonstrates another
connection between the governance of the infrastructure and governance by the
infrastructure.

After the deployment of BCH, the remaining planned upgrades in BCH have all
been deployed using user-activated strategies. BCH is being operated with
several node implementations (Bitcoin.com, 2022), and Bitcoin Cash Node (BCHN)
is one of them. Thus, a successful and consistent deployment relies on the
developers that maintain those implementations to agree on the path forward
and the miners to adopt the changes harmoniously. There are two events where
BCH has experienced disruptions causing permanent chain splits. One was in the
event of splitting off Bitcoin SV (November 2018), and the other one was
splitting off Bitcoin ABC (November 2020). These events give further evidence
that user-activated strategies value new functionality over the consistency of
the network and the blockchain.

###  4.5. Roles and power distribution

As explained in the sections, the consolidation of results of the social and
political aspects of the governance reveals the process and balance of power
deciding the evolutionary path for a decentralised distributed ledger as
illustrated in Figure 12. The figure shows that the system’s constitution is
the consensus rules or the implementation. Developers act as a council and can
propose changes, which will be enforced in practice if the miners choose to do
so. Full nodes are the only actors who fully validate the blockchain according
to the consensus rules and the complete history of the ledger. Hence, full
nodes act as judges in the blockchain.

The end-users can choose whatever blockchain they like depending on their
preferred consensus rules. In practice, they do that either by running a full
node powered wallet or, more commonly, a simple payment verification (SPV)
wallet connected to full nodes running a specific implementation of Bitcoin.
Miners enforce the consensus rules by including transactions in blocks and
broadcasting them on the network. If a miner violates the rules of the end-
user’s full nodes, their blocks and transactions will not be accepted.

Anyone can participate in any or all of the roles if they like. If the
constitution is unsatisfactory, anyone may fork off and change it. However,
any blockchain holds its value in participation and adoption, and all the
actors will generally benefit from collaborating. Whether a rule change is
worth deploying is a tradeoff between the impact of the new functionality and
the impact on the network’s consistency. The miners also benefit from choosing
the path supported by the community and the economic majority, which is viable
for the system’s stability and long-term efficacy.

Figure 12. Blockchain governance; roles and power distribution.

[Figure 12 fully described in the text.]

The deployment techniques and observations from Bitcoin’s history demonstrate
Bitcoin’s flat and decentralized power structure among miners in a blockchain.
As pointed out in Figure 12 anyone can be a developer and write whatever code
they want, but it is up to the miners to adopt consensus changes. Bitcoin is
not an oligarchy nor a democracy; it is a consensus driven by miners and the
longest valid chain rule. The aspect of validity is subjective, and it is up
to every individual which constitution they want to follow. However,
consistency is essential, and a cryptocurrency’s value relies on usage and
adoption. Moreover, the security in PoW blockchains relies on the total hash
power and its distribution in the network.

##  5\. Discussion

###  5.1. Comparison with related work

Andresen and Bogusz address Bitcoin governance; ”how and when code development
practices combine into a pattern of self-organizing.” (Andersen and Bogusz,
2017). The paper demonstrates how and when different forks occur, being both
consensus forks and forks in community groups. In contrast, this paper solely
focuses on consensus changes and shows the power structures in their
governance and their relation to different deployment techniques.

Parkin (Parkin, 2019) and Filippi et al. (De Filippi and Loveluck, 2016) focus
on governance in Bitcoin, specifically on the inherent power structures.
Bitcoin is described as a technocratic system that relies on the knowledge of
exceptionally skilled developers, which is agreeable on a repository level.
Their results isolate governance conducted by the infrastructure and by the
architects of the infrastructure, which our analysis deems to be highly
intertwined. The main reason is that the fork type decides whether a super-
majority of at least 51% can deploy a change without a chain split, which is
eligible for reduction forks. The expanding and bilateral fork types will give
the proponents the options to deploy with 100% support of miners to avoid a
chain split. Alternatively, one must consider whether it is economically
reasonable to deploy with a chain split given the disruption it creates and
whether a certain portion of end-users will use the new chain. Moreover, if
the consensus change is prioritized over the community and economic effects,
it can be deployed regardless of network support by user-activated strategies.

We further argue that developers’ centralisation in deciding which changes can
be included in a repository is insignificant because they cannot force anyone
to adopt their proposed changes. In contrast, they might be allowed to hold
the wheel if their contributions are appreciated. This view was also supported
by both papers and highlighted by Parkin et al:

> ”Put simply, because Bitcoin is an open network, anyone can create their own
> clients to interact with it as long as they follow the rules of other nodes.
> If clients join the network with new rules then they will be dislocated from
> those following the old ones. This allows different groups of programmers to
> compete for ’the same’ protocol: a multitude of senates.” (Parkin, 2019)

Our work expands upon that: We show Bitcoin’s history with traces of proposals
and ideas from acknowledged developers branching from Bitcoin Core’s
repository being bypassed or restricted by the end-users and miners when
attempting to deploy P2SH or increase the block size. In addition to external
and anonymous developers influencing the government to accelerate SegWit
adoption.

Kroll, et al. (Kroll et al., 2013) Argue that Bitcoin needs governance more
than the participants might be willing to admit and that tendencies of
governance structures are evolving, primarily as a collaboration between pool
operators and developers. They are supported by the example from the 2013
rollback (Andresen, 2014) where developers and pool operators, worked together
to make an exception from the longest chain rule. Although centralisation
tendencies in pools and developers may streamline deployment of an upgrade,
they do not consider their limitations in governance. Because miners can
change between pools whenever they disagree on which direction to steer
Bitcoin.

The papers (Beikverdi and Song, 2015b; Romiti et al., 2019) consider pool
centralisation, and underline the risk of majority attack and block
withholding attack by colluding pools. However, we argue that these attacks do
not necessarily give pools with majority control to perform persistent
consensus changes. Pools could collude to deploy a change in the consensus
rules of Bitcoin with the risk of becoming unpopular and abandoned by the
miners. The decision power lying with the individual miners suggests that
unapproved changes can easily be reverted by disconnecting from those pools,
meaning that there is a high-risk, low-reward scenario for pools trying to
affect consensus without support from the rest of the network.

Other blockchains show tendencies of self-regulation and governance. MakerDAO
(MakerDAO, 2022) implements an emergency shutdown, which can be initiated by
asset holders. A redeployment may require human intervention and a vote among
the token holders. Similarly, Dash (Core, 2021d) implements a mechanism for
network-wide rollback initiated by the developers. These mechanisms can be
compared to the Ethereum DAO hack (Kiffer et al., 2017) where an emergency was
resolved through a voting period followed by a rollback. These scenarios are
similar to the spontaneous reorganisations performed due to the faulty
implementation in BTC $<$ 0.3.10 and the deployment of the incompatible BTC
0.8.0.

The main similarities between blockchain evolution and open software evolution
can be seen in the decision-making on a code repository level (Guzzi et al.,
2013; Sharma et al., 2021). In a blockchain, anyone can propose changes,
depending on whether the repository’s maintainers want to include that change.
However, the decision is not only based on the maintainers’ preference but
also on the opinion of the larger community; end-users, miners and possibly
developers of other implementations of the same protocol. Even when a change
is included in a code repository, it does not mean it will be adopted in the
network. This is where blockchain deviates from other open source software as
the governance process initiates the path towards deployment.

###  5.2. Implications

Former academic work has focused on the centralised management of code and
miners in Bitcoin without considering the implications this has on governance
and consensus rule changes. This paper shows that the strength of developers’
influence mainly lies in confidence in the proposals they make. Pool operators
can help coordinate to resolve a consensus failure. However, any ill-intended
consensus change has many restrictions. It will only be effective as a
reduction fork and might lose traction unless accepted by miners and end-users
in the long run. This paper can reassure blockchain practitioners and those
worried about centralised governance of consensus rules. Further, the results
show how decisions on former consensus changes have been made.

An article characterising deployment techniques for consensus rule changes
(Notland et al., 2022) demonstrated that the selected deployment strategy
relies on the tradeoff between adopting a new feature and keeping the network
consistent. By combining this with the knowledge of power structures in
Blockchain, we propose a framework for choosing the most suitable deployment
technique and the suggested governance strategy, shown in Figure 13.
Governmental structures are evolving in Bitcoin (Kroll et al., 2013) and pool
operators, developers, and miners are in a position to coordinate, especially
in the case of an emergency-activated fork. The conservative approach is to
roll back to a previous version or otherwise perform a reduction fork by
emergency-activation. The rollback or reduction fork is the most seamless
approach since the end-users and miners will prefer a solution that most
quickly gathers nodes to run compatible consensus rules. In contrast, even a
coordinated emergency-activated expansion or bilateral fork could lead to a
long period of inconsistencies in the transaction ledger (Notland et al.,
2022). Further, planned changes rely more on the whole network to coordinate
and will do so depending on the fork type and the importance of the change
compared to the importance of adoption.

Figure 13. Choosing a deployment technique.

[Figure 13 fully described in the text.]

Our research investigates governance in the decentralised blockchain based on
Bitcoin and Bitcoin forks. Bitcoin is a one-of-a-kind system and the longest-
living blockchain project. Our results can be generalised to other
decentralised software systems. However, the results apply more confidently to
systems with a similar network structure and consensus model. As they mature,
other decentralised systems such as the Lightning Network (Lightning, 2022),
Polkadot (Foundation, 2022b), and Cosmos (Tendermint, 2022) could be
comparable.

###  5.3. From benevolent dictator to decentralized governance

Bitcoin was established as a system that operates without any trusted
authority (Nakamoto, 2008). However, Satoshi did not mention how to govern the
maintenance and evolution of Bitcoin. The exceptions are the longest chain
rule and that version 0.1 set the core design in stone for the rest of its
lifetime. Ironically, Satoshi more or less acted as the trusted authority or
”benevolent dictator” in Bitcoin before his absence. During that time he
patched consensus related code six times (0.1.6, 0.3.5, 0.3.6, 0.3.7, 0.3.10,
and 0.3.12), mainly through immediate emergency-activation or user-activation
by block height timing. Satoshi also created an emergency alert system to
notify nodes of urgent issues. Satoshi can be seen as the trusted authority of
Bitcoin because the community probably would have accepted any sane code
change, in contrast to the current mature and more sceptical community.

However, Satoshi declared his absence after staying with Bitcoin for less than
two years. There are many speculations about why Satoshi left the project at
that given time. Our analysis indicates that he planned to step down sooner or
later when his presence was no longer needed to maintain the project. Satoshi
did not add any new utility to Bitcoin after release, and the patches made
before his absence was enough for Bitcoin to function as envisaged and prevent
severe issues from disrupting the adoption of Bitcoin. Additionally, the
community had grown with end-users, miners and developers to prosper further
adoption.

The latest consensus change by Satoshi indicates why it was time to step down
as a benevolent dictator. That was in version 0.3.12, where the block size
limit was enforced at 1MB. The change was created without traces of
discussion. People started questioning the change within a month of its
release before becoming the most controversial topic in Bitcoin. The block
size debate could have looked different if there had been consensus on the
initial value and whether to change it later. Further upgrades are no longer
accepted so naively by miners since miners are actively participating in the
BIP process and the different deployment techniques.

###  5.4. Threats to validity

We emphasise the repeatability and verification of our research by thoroughly
describing developing theories based on the available data. The data used in
this study is public and accessible through the archives and references
presented in this paper. The samples (Notland, 2022) used for the analysis as
exported from Atlas.ti is also provided. Furthermore, the paper shows nuanced
and accurate results derived from data triangulation and snowballing to
demonstrate the results’ source and extensively connect both qualitative and
quantitative data from the analysis to the concepts derived.

The sheer amount of data and the limited number of researchers dedicated to
this project may raise questions about missing data or analysis. To address
this, the three authors thoroughly evaluated the results through regular
cross-author discussions. The recursive process in grounded theory has caused
us to look closely at BCH even though all the initial data was gathered from
BTC. BCH is interesting because the community has a different culture
regarding consensus changes than BTC, where functionality might trump
consistency.

##  6\. Conclusion

In Bitcoin, miners organise in pools, and developers organise around
repositories. These are pragmatic structures to coordinate the development and
deployment of changes and allow for swift response in an emergency. In
contrast to concerns about centralised tendencies in pools and repositories,
the consensus in Bitcoin falls back on the individual miners and the economic
influence of users. Pools that act against the system’s interest can only
cause short-term harm and could quickly be abandoned by miners. Repository
maintainers are in a position to propose changes but rely on consensus in the
community. This paper provides empirical evidence that the decentralised
consensus mechanisms in blockchain restrict the centralisation tendencies
observed for developers and pools. The power to make permanent changes in
consensus rules lies with the miners, constructing the longest chain,
restricted by the different deployment techniques and dependence on end-user
adoption.

##  7\. Future work

This paper indicates that pool and developer centralisation are insignificant
regarding the governance of a blockchain. Instead, analysing hash power
distribution among individual miners could be more interesting. A better
understanding of hash power distribution can reveal how many mining actors
that would need to collude to have longitudinal influence over a blockchain in
terms of majority attacks and reduction forks. Other factors such as
juristical or geographical distribution of hash power could, for instance,
demonstrate how much influence governments and regulators could have in the
long term.

It would also be interesting to see the frequency of miners changing between
pools and whether that is related to pools’ stance regarding consensus
governance. That can reveal to what extent miners are exercising their
governmental influence. Furthermore, the centralisation of economic funds
among users can be a factor in centralised influence over the system. If only
a few actors are responsible for a large portion of the transactions and
network fees, these will have considerable influence on a blockchain. Further
work can provide novel contributions by finding factors that measure
governance centralisation in a blockchain.

###### Acknowledgements.

This work is jointly supported by the National Key Research and Development
Program of China (No.2019YFE0105500) and the Research Council of Norway
(No.309494).

## References

  * (1)
  * Andersen and Bogusz (2017) Jonas Valbjørn Andersen and Claire Ingram Bogusz. 2017.  Patterns of Self-Organising in the Bitcoin Online Community: Code Forking as Organising in Digital Infrastructure.. In _ICIS_. AIS, Seoul, South Korea, 20 pages.  https://pure.itu.dk/portal//files/83566552/ICIS_revision_2017.pdf
  * Andresen (2014) Gavin Andresen. 2014\.  _March 2013 Chain Fork Post-Mortem_.  Bitcoin Core.  Retrieved February 9, 2022 from https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
  * Andresen (2015) Gavin Andresen. 2015\.  _CoinScrum: QA with Gavin Andresen and Mike Hearn_.  CoinScrum.  Retrieved June 8, 2022 from https://www.youtube.com/watch?v=RIafZXRDH7w&t=1672s
  * Atlas.ti (2022) Atlas.ti. 2022.  _All-in-one Research Software_.  ATLAS.ti Scientific Software Development GmbH.  Retrieved June 7, 2022 from https://atlasti.com/
  * Beikverdi and Song (2015a) Alireza Beikverdi and JooSeok Song. 2015a.  Trend of centralization in Bitcoin’s distributed network. In _2015 IEEE/ACIS 16th international conference on software engineering, artificial intelligence, networking and parallel/distributed computing (SNPD)_. IEEE, 1–6.
  * Beikverdi and Song (2015b) Alireza Beikverdi and JooSeok Song. 2015b.  Trend of centralization in Bitcoin’s distributed network. In _2015 IEEE/ACIS 16th International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing (SNPD)_. IEEE, Takamatsu, Japan, 377–383.  https://doi.org/10.1109/SNPD.2015.7176229
  * Belshe (2017) Mike Belshe. 2017\.  _Segwit2x Final Steps_.  Retrieved September 1, 2022 from https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html
  * Bitcoincash.org (2017) Bitcoincash.org. 2017\.  _Mandatory activation of segwit deployment_.  Bitcoincash.org.  Retrieved June 7, 2022 from https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/uahf-technical-spec.md
  * Bitcoin.com (2022) Bitcoin.com. 2022\.  _Full nodes_.  Bitcoin.com.  Retrieved June 8, 2022 from https://www.bitcoin.com/full-nodes/
  * Bitcoin.org (2015) Bitcoin.org. 2015\.  _Some Miners Generating Invalid Blocks_.  Bitcoin.org.  Retrieved June 7, 2022 from https://bitcoin.org/en/alert/2015-07-04-spv-mining
  * Bitcoin.org (2022) Bitcoin.org. 2022\.  _Bitcoin is an innovative payment network and a new kind of money._ Bitcoin.org.  Retrieved June 7, 2022 from https://bitcoin.org/
  * BuildingBitcoin (2019) BuildingBitcoin. 2019\.  _bitcoin-dev_.  buildingbitcoin.  Retrieved November 3, 2021 from https://buildingbitcoin.org/bitcoin-dev/
  * Corbin and Strauss (2014) Juliet Corbin and Anselm Strauss. 2014.  _Basics of qualitative research: Techniques and procedures for developing grounded theory_.  Sage publications, London, England, UK.
  * Core (2018a) Bitcoin Core. 2018a.  _CVE-2018-17144 Full Disclosure_.  Bitcoin Core.  Retrieved June 7, 2022 from https://bitcoincore.org/en/2018/09/20/notice/
  * Core (2018b) Bitcoin Core. 2018b.  _CVE-2018-17144 Full Disclosure_.  Retrieved September 1, 2022 from https://bitcoincore.org/en/2018/09/20/notice/
  * Core (2021a) Bitcoin Core. 2021a.  _Bitcoin Core integration/staging tree_.  Bitcoin Core.  Retrieved February 19, 2021 from https://github.com/bitcoin/bips
  * Core (2021b) Bitcoin Core. 2021b.  _Issues_.  Bitcoin Core.  Retrieved November 3, 2021 from https://github.com/bitcoin/bitcoin/issues
  * Core (2021c) Bitcoin Core. 2021c.  _Pull requests_.  Bitcoin Core.  Retrieved February 2, 2021 from https://github.com/bitcoin/bitcoin/pulls
  * Core (2022) Bitcoin Core. 2022\.  _Download Bitcoin Core_.  Retrieved September 9, 2022 from https://bitcoin.org/en/download
  * Core (2021d) Dash Core. 2021d.  _sporks_.  Dash Core.  Retrieved April 21, 2022 from https://docs.dash.org/en/stable/introduction/features.html#sporks
  * De Filippi and Loveluck (2016) Primavera De Filippi and Benjamin Loveluck. 2016.  The invisible politics of bitcoin: governance crisis of a decentralized infrastructure.  _Internet Policy Review_ 5, 4 (2016), 32 pages.  https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2852691
  * Deterding and Waters (2021) Nicole M Deterding and Mary C Waters. 2021.  Flexible coding of in-depth interviews: A twenty-first-century approach.  _Sociological methods & research_ 50, 2 (2021), 708–739.
  * development team (2022) The Matplotlib development team. 2022\.  _Matplotlib: Visualization with Python_.  Retrieved September 9, 2022 from https://matplotlib.org/
  * Douceur (2002) John R. Douceur. 2002\.  The Sybil Attack. In _Peer-to-Peer Systems_ , Peter Druschel, Frans Kaashoek, and Antony Rowstron (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 251–260.
  * Dwork and Naor (1993) Cynthia Dwork and Moni Naor. 1993.  Pricing via Processing or Combatting Junk Mail. In _Advances in Cryptology — CRYPTO’ 92_ , Ernest F. Brickell (Ed.). Springer Berlin Heidelberg, Berlin, Heidelberg, 139–147.
  * Ellenbogen (2016) Paul Ellenbogen. 2016\.  _Bitcoin’s history deserves to be better preserved_.  Princeton University.  Retrieved June 8, 2022 from https://freedom-to-tinker.com/2016/09/15/bitcoins-history-deserves-to-be-better-preserved/
  * Encyclopedia (2022) Network Encyclopedia. 2022\.  _Request for Comments (RFC)_.  Retrieved July 15, 2022 from https://networkencyclopedia.com/request-for-comments-rfc/
  * Erisian (2018) Erisian. 2018.  _bitcoin-dev_.  Erisian Consulting.  Retrieved November 3, 2021 from http://azure.erisian.com.au/~aj/tmp/irc/
  * Erisian (2021a) Erisian. 2021a.  _bitcoin-core-dev_.  Erisian Consulting.  Retrieved November 3, 2021 from https://www.erisian.com.au/bitcoin-core-dev/
  * Erisian (2021b) Erisian. 2021b.  _bitcoin-dev_.  Erisian Consulting.  Retrieved November 3, 2021 from https://www.erisian.com.au/bitcoin-dev/
  * Forum (2021) Simple Machines Forum. 2021\.  _Bitcoin Forum_.  Simple Machines Forum.  Retrieved February 2, 2021 from https://bitcointalk.org/
  * Foundation (2022a) Linux Foundation. 2022a.  _Bitcoin-dev email list_.  Linux Foundation.  Retrieved June 7, 2022 from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
  * Foundation (2020) The Free Software Foundation. 2020\.  _GNU Grep_.  the Free Software Foundation.  Retrieved June 7, 2022 from https://www.gnu.org/software/grep/
  * Foundation (2022b) © 2022 Web3 Foundation. 2022b.  _The multichain vision for Web3 starts here._ Retrieved October 26, 2022 from https://polkadot.network/
  * Fry (2017) Shaolin Fry. 2017\.  _Mandatory activation of segwit deployment_.  Bitcoin Core.  Retrieved February 9, 2022 from https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
  * Group (2017) Digital Currency Group. 2017\.  _Bitcoin Scaling Agreement at Consensus 2017_.  Retrieved September 1, 2022 from https://dcgco.medium.com/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77
  * Guzzi et al. (2013) Anja Guzzi, Alberto Bacchelli, Michele Lanza, Martin Pinzger, and Arie Van Deursen. 2013\.  Communication in open source software development mailing lists. In _2013 10th Working Conference on Mining Software Repositories (MSR)_. IEEE, San Francisco, CA, USA, 277–286.
  * Harper (2021) Colin Harper. 2021\.  _Open Ethereum Clients Encounter ‘Consensus Error’ After Berlin Hard Fork; Coinbase Pauses ETH Withdrawals_.  CoinDesk.  Retrieved June 7, 2022 from https://www.coindesk.com/tech/2021/04/15/open-ethereum-clients-encounter-consensus-error-after-berlin-hard-fork-coinbase-pauses-eth-withdrawals/
  * Jakobsson and Juels (1999) Markus Jakobsson and Ari Juels. 1999.  _Proofs of Work and Bread Pudding Protocols(Extended Abstract)_.  Springer US, Boston, MA, 258–272.  https://doi.org/10.1007/978-0-387-35568-9_18
  * Kiffer et al. (2017) Lucianna Kiffer, Dave Levin, and Alan Mislove. 2017\.  Stick a fork in it: analysing the Ethereum network partition. In _Proceedings of the 16th ACM Workshop on Hot Topics in Networks_. ACM, New York, NY, USA, 94–100.  https://doi.org/10.1145/3152434.3152449
  * Knudsen et al. (2021) Henrik Knudsen, Jakob Svennevik Notland, Peter Halland Haro, Truls Bakkejord Raeder, and Jingyue Li. 2021.  _Consensus in Blockchain Systems with Low Network Throughput: A Systematic Mapping Study_.  Association for Computing Machinery, New York, NY, USA, 15–23.  https://doi.org/10.1145/3475992.3475995
  * Kroll et al. (2013) Joshua A Kroll, Ian C Davey, and Edward W Felten. 2013\.  The economics of Bitcoin mining, or Bitcoin in the presence of adversaries. In _Proceedings of WEIS_. Washington, DC, ISE, 37th and O Streets, Rafik B. Hariri Building, Washington, DC 20057, United States, 21 pages.  http://www.infosecon.net/workshop/downloads/2013/pdf/The_Economics_of_Bitcoin_Mining,_or_Bitcoin_in_the_Presence_of_Adversaries.pdf
  * Lamport et al. (1982) Leslie Lamport, Robert Shostak, and Marshall Pease. 1982\.  The Byzantine Generals Problem.  _ACM Trans. Program. Lang. Syst._ 4, 3 (jul 1982), 382–401.  https://doi.org/10.1145/357172.357176
  * Lightning (2022) Lightning. 2022\.  _Lightning Network_.  Retrieved October 26, 2022 from https://lightning.network/
  * Luke-jr (2015) Luke-jr. 2015.  _Remove P2SH coinbase flag, no longer interesting_.  Bitcoin Core.  Retrieved April 21, 2022 from https://github.com/bitcoin/bitcoin/pull/6203
  * macbook air (2013) macbook air. 2013\.  _A successful DOUBLE SPEND US$10000 against OKPAY this morning._ Simple Machines Forum.  Retrieved June 7, 2022 from https://bitcointalk.org/index.php?topic=152348.msg1616747#msg1616747
  * MakerDAO (2022) MakerDAO. 2022.  _Emergency Shutdown_.  MakerDAO.  Retrieved October 25, 2022 from https://makerdao.world/en/learn/governance/emergency-shutdown/
  * MAXQDA (2022) MAXQDA. 2022.  _Organize. Code. analyse. Present._ VERBI GmbH.  Retrieved June 7, 2022 from https://www.maxqda.com/
  * Nakamoto (2008) Satoshi Nakamoto. 2008\.  _Bitcoin: A peer-to-peer electronic cash system_.  Bitcoin.org.  Retrieved June 25, 2021 from https://bitcoin.org/bitcoin.pdf
  * Narayanan et al. (2016) Arvind Narayanan, Joseph Bonneau, Edward Felten, Andrew Miller, and Steven Goldfeder. 2016.  _Bitcoin and cryptocurrency technologies: a comprehensive introduction_.  Princeton University Press, Princeton, New Jersey, USA.
  * Ninjastic (2021) Ninjastic. 2021\.  _Ninjastic.space_.  Ninjastic.space.  Retrieved November 3, 2021 from https://ninjastic.space
  * Notland (2022) Jakob Svennevik Notland. 2022\.  _Exported samples_.  Norwegian University of Technology and Science.  Retrieved June 3, 2022 from https://folk.ntnu.no/jakobsn/Runtime%20Evolution%20of%20Bitcoin’s%20Consensus%20Rules/exported%20samples.zip
  * Notland et al. (2022) Jakob Svennevik Notland, Mariusz Nowostawski, and Jingyue Li. 2022\.  Runtime Evolution of Bitcoin’s Consensus Rules.  (7 2022).  https://doi.org/10.36227/techrxiv.20310105.v1
  * NVIVO (2022) NVIVO. 2022.  _Qualitative Data analysis Software_.  QSR International.  Retrieved June 7, 2022 from https://www.qsrinternational.com/nvivo-qualitative-data-analysis-software/home
  * Nyman and Lindman (2013) Linus Nyman and Juho Lindman. 2013.  Code forking, governance, and sustainability in open source software.  _Technology Innovation Management Review_ 3, 1 (2013), 12 pages.
  * Oates (2006) Briony J Oates. 2006\.  Researching Information Systems and Computing.
  * Parkin (2019) Jack Parkin. 2019\.  The senatorial governance of Bitcoin: making (de) centralized money.  _Economy and society_ 48, 4 (2019), 463–487.
  * Penrod et al. (2003) Janice Penrod, Deborah Bray Preston, Richard E Cain, and Michael T Starks. 2003.  A discussion of chain referral as a method of sampling hard-to-reach populations.  _Journal of Transcultural nursing_ 14, 2 (2003), 100–107.
  * Python-dev (2000) Python-dev. 2000\.  _PEP 0 – Index of Python Enhancement Proposals (PEPs)_.  Python.org.  Retrieved November 3, 2021 from https://www.python.org/dev/peps/
  * Research (2017) BitMex Research. 2017\.  _Empty Block Data by Mining Pool_.  BitMex.  Retrieved March 29, 2022 from https://blog.bitmex.com/empty-block-data-by-mining-pool/
  * Romiti et al. (2019) Matteo Romiti, Aljosha Judmayer, Alexei Zamyatin, and Bernhard Haslhofer. 2019.  A deep dive into bitcoin mining pools: An empirical analysis of mining shares.  _arXiv preprint arXiv:1905.05999_ abs/1905.05999 (2019), 19 pages.  https://doi.org/10.48550/arXiv.1905.05999 arXiv:arXiv:1905.05999
  * Rosenfeld (2014) Meni Rosenfeld. 2014\.  analysis of hashrate-based double spending.  _arXiv preprint arXiv:1402.2009_ abs/1402.2009 (2014), 13 pages.  https://doi.org/10.48550/arXiv.1402.2009 arXiv:arXiv:1402.2009
  * Roundtable (2016) Bitcoin Roundtable. 2016\.  _Bitcoin Roundtable Consensus_.  Retrieved September 1, 2022 from https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff
  * Russell (2006) Andrew L Russell. 2006\.  ’Rough consensus and running code’and the Internet-OSI standards war.  _IEEE Annals of the History of Computing_ 28, 3 (2006), 48–61.
  * Sayeed and Marco-Gisbert (2019) Sarwar Sayeed and Hector Marco-Gisbert. 2019.  Assessing blockchain consensus and security mechanisms against the 51% attack.  _Applied Sciences_ 9, 9 (2019), 1788.
  * Sharma et al. (2021) Pankajeshwara Nand Sharma, Bastin Tony Roy Savarimuthu, and Nigel Stanger. 2021.  Extracting Rationale for Open Source Software Development Decisions—A Study of Python Email Archives. In _2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE)_. IEEE, Madrid, ES, 1008–1019.
  * Tendermint (2022) © 2022 Tendermint. 2022\.  _Building the most powerful tools for distributed networks._ Retrieved October 26, 2022 from https://tendermint.com/
  * Todd (2014) Peter Todd. 2014\.  _OP_CHECKLOCKTIMEVERIFY_.  Bitcoin Core.  Retrieved February 2, 2022 from https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
  * Unlimited (2022) Bitcoin Unlimited. 2022\.  _BitcoinCashNodes_.  Retrieved July 18, 2022 from https://cashnodes.io/
  * wiki (2020) Bitcoin wiki. 2020\.  _IRC channels_.  Bitcoin Core.  Retrieved March 26, 2021 from https://en.bitcoin.it/IRC_channels
  * Wiki (2022) Bitcoin Wiki. 2022\.  _Consensus versions_.  Bitcoin Wiki.  Retrieved June 7, 2022 from https://en.bitcoin.it/wiki/Consensus_versions
  * Wirdum (2017) Aaron Van Wirdum. 2017\.  _The Long Road To SegWit: How Bitcoin’s Biggest Protocol Upgrade Became Reality_.  Bitcoin Magazine.  Retrieved June 7, 2022 from https://bitcoinmagazine.com/technical/the-long-road-to-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality
  * Wirdum (2020) Aaron Van Wirdum. 2020\.  _The Battle For P2SH: The Untold Story Of The First Bitcoin War_.  Bitcoin Magazine.  Retrieved June 7, 2022 from https://bitcoinmagazine.com/technical/the-battle-for-p2sh-the-untold-story-of-the-first-bitcoin-war
  * Wuille et al. (2015) Pieter Wuille, Peter Todd, Greg Maxwell, and Rusty Russel. 2015\.  _Version bits with timeout and delay_.  Bitcoin Core.  Retrieved February 9, 2022 from https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
  * Zamyatin et al. (2018) Alexei Zamyatin, Nicholas Stifter, Aljosha Judmayer, Philipp Schindler, Edgar Weippl, and William J Knottenbelt. 2018.  A wild velvet fork appears! inclusive blockchain protocol changes in practice. In _International Conference on Financial Cryptography and Data Security_. Springer, Berlin, Heidelberg, 31–42.

##  Appendix A Demployment signals and activation timings

Figure 14. Evolution of BTC including signals and flag days/blocks

[Figure 14 fully described in the text.]

Figure 15. Evolution of BCH including failed signaling attempts to increase
block size and flag days/blocks

[Figure 15 fully described in the text.]