master-thesis.tex

\documentclass[12pt,a4paper]{article}

\usepackage[utf8]{inputenc}
\usepackage[english]{babel}
\usepackage{abstract}
\usepackage[nottoc]{tocbibind}
\usepackage[acronym,toc]{glossaries}
\usepackage{setspace}
\usepackage{graphicx}
\usepackage{url}
\usepackage{csquotes}
\usepackage{float}

\renewcommand{\abstractname}{}
\renewcommand{\absnamepos}{empty}

\setcounter{secnumdepth}{3}
\setcounter{tocdepth}{3}

\makeglossaries

\newglossaryentry{node}
{
name=node,
description={A node is a participant in a blockchain network, relaying messages such as transactions and blocks in a peer-to-peer fashion.}
}

\newglossaryentry{transaction}
{
name=transaction,
description={A transaction in the context of a blockchain network is a transfer of value from one account to another account in the consensus state. It can optionally include data and manipulate data stored in the consensus state. It is always applied atomically as part of a state transition.}
}

\newglossaryentry{block}
{
name=block,
description={A block represents a bundle of transactions which represent a non-conflicting valid state transaction for the current consensus state on a blockchain network. It is secured with a hash that contains a certain number of zero bits at the beginning in order to make it difficult to find a valid solution.}
}

\newglossaryentry{reward}
{
name=block reward,
description={The block reward is an economic incentive given to the generator of a valid block in exchange for the hashrate he invested to discover a block with the necessary amount of zero bits at the beginning of the validation hash.}
}

\newglossaryentry{double}
{
name=double spend,
description={A double spend is the action of spending the same funds on a blockchain network more than once. Fundamentally, this is the problem that consensus algorithms try to solve by deciding between conflicting transactions. A successful double spend allows a malicious actor to trick a recipient of a transaction into delivering value for funds that will later become void}
}

\newglossaryentry{blockchain}
{
name=blockchain network,
description={A blockchain network is a peer-to-peer network where the participants run a consensus algorithm with a number of consensus rules in order to find agreement on the state of the data in the system.}
}

\newglossaryentry{consensus}
{
name=consensus state,
description={The consensus state of a blockchain network describes the part of the state which all participants have agreed on in their common blockchain history and which is therefore shared amongst all participants on the network.}
}

\newglossaryentry{miner}
{
name=miner,
description={A miner is a block generator in a proof-of-work blockchain network. A miner will execute a hash algorithm repeatedly to find a valid solution for the block header puzzle, thus the comparison to "mining".}
}

\newglossaryentry{validator}
{
name=validator,
description={A validator is a block generator in a proof-of-stake blockchain network. A validator will stake some of his funds and in return has a proportional probability to be selected to generate the next block for the blockchain network.}
}

\newglossaryentry{pool}
{
name=mining pool,
description={When mining alone, miners are subject to significant variance between block discoveries. Pooling hashrate allows them to diminish variance and receive income at more predictable intervals. Some protocols were specifically designed to make communal mining possible with auditable reward distributions.}
}

\newglossaryentry{hashrate}
{
name=hashrate,
description={The hashrate is the amount of hashing operations a miner can execute on a blockchain network in one second. The higher the hashrate, the higher the chance for the miner to discover a valid hash for the next block generation, thus increasing the chance of gaining the block reward.}
}

\newglossaryentry{effect}
{
name=network effect,
description={The network effect explains the phenomenon of a network exponentially gaining in usefulness with a linearly growing number of participants.}
}

\newacronym{pow}{PoW}{proof-of-work}
\newacronym{pos}{PoS}{proof-of-stake}
\newacronym{dag}{DAG}{directed acyclical graph}
\newacronym{fud}{FUD}{fear, doubt and uncertainty}
\newacronym{p2p}{P2P}{peer-to-peer}

\begin{document}

\thispagestyle{empty}

\begin{center}
  {\huge Risk Management for\\Blockchain Networks}\\
  \vspace{1cm}
  {\large Max Wolter\\0060218257\\max@alvalor.org}\\
  \vspace{1cm}
  {\Large June 2018}\\
  \vspace{2cm}
  \includegraphics[scale=0.25]{logo_uni.jpg}\\
  \vspace{1.5cm}
  {\Large University of Luxembourg\\
  Faculty of Science, Technology and Communication}\\
  \vspace{1cm}
  {\large This thesis is presented for the degree of\\
  \textit{Master of Information Systems Security Management}}\\
  \vspace{1cm}
  {\large Academic Year: 2017 - 2018\\Supervisor: Dr Nicolas Mayer}\\
\end{center}

\newpage

\vspace{4cm}

\section*{Abstract}

\begin{abstract}
  This paper explores the feasability of a modern risk management approach in the context of blockchain consensus networks. A framework is created on the basis of a theoretical, technical and social analysis of vulnerabilities on \glspl{blockchain}. The result is then applied to a real-world blockchain project with a method similar to popular risk management approaches.
\end{abstract}

\newpage

\section*{Declaration of honesty}

I hereby declare that, except where specic reference is made to the work of others, the contents of this thesis are original and have not been submitted in whole or in part for consideration for any other degree or qualication in this or any other university. This thesis is the result of my own work and includes nothing which is the outcome of work done in collaboration, except where specically indicated in the text.\\
\vspace{4cm}
\begin{displayquote}
  \textit{Max Wolter}
\end{displayquote}

\newpage

\onehalfspacing
\tableofcontents
\singlespacing
\newpage

\section{Introduction}

The concept of a \gls{blockchain} was introduced in the form of Bitcoin in 2008 by an anonymous author under the name of Satoshi Nakamoto \cite{bitcoin}. Since then, the potential of the underlying blockchain technology to serve as a trustless mechanism to find consensus on the state of an underlying system has spread to many applications beyond the maintenance of a ledger of account balances.\\

The main value proposition of a \gls{blockchain} is its ability to ensure the security of the \gls{consensus} in a verifiable and transparent manner. While the software \& business ecosystem developed around a blockchain project are susceptible to the same information security risks as typical software and business projects, the core platform has its own unique security properties.\\

This paper explores the applicability of a traditional information security risk management approach to the context of \glspl{blockchain}. It makes an attempt to integrate the current research litterature in the blockchain space with the more mature sphere of information security risk management.\\

In a first step, we explore current academic literature to establish a framework which applies the principles of modern risk management methodologies to the context of \glspl{blockchain}. We define the scope and conditions under which we examine the topic and use them as a basis to evaluate a number of relevant vulnerabilities and risks.\\

As the second step, a small case study applies the framework to a real-world \gls{blockchain}. We use the established risks to identify vulnerabilities and exploits for the project, assess the related probability \& impact and finally recommend a number of measures to improve the security of the \gls{blockchain} underlying the \gls{consensus}.\\

\section{Framework}

\subsection{Asset Identification}

When identifying risks, the usual approach dictates that we identify assets which are vulnerable and use them as a basis for the analysis \cite{iso}. For a \gls{blockchain}, this proposition is a difficult one; the network is composed of thousands of nodes which communicate in a peer-to-peer fashion. While each node can be compromised in its own right, there is no single tangible asset or actor that impacts the security of the \gls{consensus} as a whole. The same can be said for the periphery, consisting of infrastructure, tools and solutions built around the \gls{blockchain}.\\

Our approach posits that we can define the abstract concept of the \gls{consensus} itself as the asset which needs to be protected. In that context, we can focus on vulnerabilities that are unique to \glspl{blockchain}. We can then establish our own security criteria which should be fulfilled in order for the \gls{consensus} to be considered secure. At the end, can evaluate the potential risks to the \gls{consensus} in terms of impact on these criteria.\\

There are various algorithms used to achieved consensus in \glspl{blockchain}. Where the type of consensus algorithm is relevant, we will focus on the two most common algorithms: \acrfull{pow} and \acrfull{pos}. Other models, such as the \acrfull{dag} approach or derivatives of the \acrshort{pos} approach, have not been explored in sufficient depth in scientific literature to provide a meaningful analysis.\\

\subsection{Security Criteria}

As alluded to earlier, the usual security criteria of confidentiality, integrity and availability are not a good fit for the abstract concept of the \gls{consensus} in a \gls{blockchain}. We can, however, establish our own security criteria which make sense in the context of \glspl{blockchain}. The foundation for these criteria should be found in the basic process of consensus finding and on the security guarantees that a \gls{blockchain} tries to provide.\\

Fundamentally, a \gls{blockchain} are provides and open, (mostly) transparent \& global platform for potentially malicious participants to find consensus on the state of the system in a trustless manner. It does so by employing cryptography to prove events that happened in the past and economic incentives to cause events to happen in the future \cite{crypto}. This implies a number of properties which have to be conserved in order to provide the desired environment.\\

First, we need to conserve the integrity of the cryptography which protects the events in the past. Once the participants have agreed on a the history of the \gls{consensus}, it needs to be reliable. One important security criterion for a \gls{blockchain} is therefore the \textbf{immutability} of its \gls{consensus}.\\

Second, we need to make sure that all participants of the \gls{blockchain} can access the \gls{consensus} in the designed way. This implies being able to read the latest valid \gls{consensus} and being able to write to the \gls{consensus} according to the consensus rules. We call this criterion the \textbf{accessibility} of the \gls{consensus}.\\

Last but not least, we need to conserve the balance between the cryptography and the economics of the platform in order to conserve a viable theoretical model. Disrupting the economic equilibrium of a \gls{blockchain} will undermine its incentive structure and make the security guarantees weaker. We call this aspect the \textbf{stability} of the \gls{consensus}.\\

\subsection{Vulnerability Categories}

\Glspl{blockchain} can have flaws inherent in the theoretical models of the \gls{consensus}. In this respect, possible exploits which rely on work in the field of mathematics, more specifically game theory, and information science, in particular in regards to distributed systems, can be explored. This category of risks is confined to the internal model of the \gls{consensus}, so these intrinsic aspects will be defined as \textbf{theoretical} vulnerabilities.\\

It is also possible to exploit technical means outside of the immediate model to disrupt the \gls{consensus}. One prime target could be \acrfull{p2p} topology underlying the \gls{blockchain}, where disrupting the characteristics of the network can undermine assumptions of the overlayed theoretical model. We will describe these external aspects as \textbf{technical} vulnerabilities.\\

Last but not least, a \gls{blockchain} is run by software which encodes the consensus rules, and this software is written by humans working for projects governed by humans. This means that the direction of a blockchain project, including the evolution of the consensus rules and algorithm, is subject to the weaknesses of human psychology and online communities. We call these aspects the \textbf{social} vulnerabilities.\\

\subsection{Risk Analysis}

Our method for analysing risks is based on a systemic definition of the information security risk management domain \cite{domain}. This nomencloture defines a risk as an event, occurring with a certain probability, leading to a certain impact on the security criteria of our asset. An event, in turn, is a threat agent using an attack method to exploit a vulnerability.\\

In this paper, we propose to extend the framework slightly to make a clear distinction between the attack method and the attacks themselves. Indeed, one attack method applied to one vulnerability can open the door to the execution of a variety of attacks in the context of blockchain. In general, this means that most mitigations address the vulnerability directly, rather than handling each attack on its own.\\

We establish the following modified definition as the basis for our risk analysis: a risk is the event with certain probability of a threat agent using an attack method to exploit a vulnerability of the \gls{blockchain} in order to execute an attack, impacting the immutability, accessibility or stability of the \gls{consensus}.\\

In general, attacks require either access to block generators, or they can be executed by an outside party; however, the threat agent is not identified as part of our analysis. Identification of the threat agent adds little value to risk management in the context of \glspl{blockchain}, which attempt to provide global security properties, and is thus beyond the scope of this paper.\\

\subsection{Mitigation Controls}

The collapse of one security criterion often opens up the door for a number of attacks, regardless of the attack method used to exploit the vulnerability. This means that the mere exploit of a vulnerability already undermines the security of the \gls{blockchain}. At the point where a \gls{blockchain}'s security is unreliable, it is broken even if no attack is executed against any victim. Often, the level of impact is relevant in this consideration.\\

For instance, a narrow impact on immutability of specific \glspl{transaction} in the \gls{consensus} allows the execution of \gls{double} attacks against one victim, but doesn't affect the rest of the \gls{blockchain}. In contrast, a wide impact on immutability allows the reversal of any \gls{transaction} and thus makes the \gls{blockchain} unusable due to unacceptable risks.\\

Similarly, a narrow impact on accessibility can simply mean that one network participant can not execute any \glspl{transaction} or has a wrong local view of the \gls{consensus}. However, if the accessibility to the \gls{blockchain} is globally disrupted, network participants can no longer rely on the \gls{consensus} and the \gls{blockchain} in no longer useful.\\

It can therefore be said that the mere exploitation of a vulnerability can already lead to the collapse of the security criteria of the \gls{consensus}, thus making the \gls{blockchain} useless for its intended purposes. This means that we can have controls on all levels: vulnerability, attack method or the attack itself.\\

\section{Theoretical Vulnerabilities}

\subsection{Hashrate Distribution}

The security of \acrshort{pow} blockchains relies on the the miners, which compete in a lottery to generate the next block in order to obtain the related \gls{reward}. Through this design, all miners are incentivized to work on the latest valid version of the blockchain history, as they would otherwise run a higher risk of not obtaining said \gls{reward}.\\

However, this also creates a fundamental vulnerability of the \gls{blockchain}, as already noted in section 11 of the original Bitcoin white paper \cite{bitcoin}. With a sufficiently high \gls{hashrate}, an attacker can overwhelm the consensus forming of the rest of the \gls{blockchain} and disable the security guarantees of the \gls{consensus} either temporarily or permanently.\\

There are a number of possible mitigations for a hashrate exploit. On the social layer, participants on the network can run algorithms which \textit{automatically balance} their \gls{hashrate} between \glspl{pool}, which can eliminate the risk of any pool operator acquiring a majority hashpower. Unfortunately, this solution is hard to monitor.\\

An alternative solution would deploy a \textit{two-phase \acrshort{pow}} model \cite{twophase}. It would require a second sophisticated cryptographic layer using Markov chains to be built between \glspl{pool}, but would at least be provably diminish the impact of a majority \gls{hashrate} exploit.\\

A much simpler and more complete solution is to simply wait for a certain \textit{number of confirmations}. Indeed, the deeper in the history a \gls{transaction} is found, the harder it is to overwhelm the previously accomplished \acrshort{pow} even with a majority \gls{hashrate} \cite{double}. Unless an attacker permanently has a majorty hashrate, this strategy will always work at some point in time.\\

Finally, a more fundamental change to the \gls{consensus} could make it harder to reverse already written blockchain history. Instead of enforcing the consensus rule of always following the longest chain of valid blocks, \glspl{transaction} could be bound to a history of the blockchain and the \textit{\gls{transaction} weight}, using different algorithms, could be a deciding factor between conflicting histories \cite{weight}.\\

\subsubsection{Majority Hashrate}

The most fundamental breach of security for a \acrshort{pow} \gls{blockchain} is when one participant manages to acquire a majority of the \gls{hashrate} on the network. It allows him to overpower the combined \gls{hashrate} of all other participants and thus gives him the power to define the history of the \gls{consensus} on his own.\\

\textit{Certain double spend}. With the absolute majority of the \gls{hashrate}, an attacker can always overpower the competing \gls{hashrate}. This allows him to reverse his own \gls{transaction} and replace it with another \gls{transaction} spending the same funds on another version of the history with absolute certainty. It impacts the immutability of the \gls{consensus}.\\

\textit{History reversal}. Every time a competing participant generates a block, the attacker can generate an alternative version of the history. Due to his overwhelming \gls{hashrate}, he will overcome and override the competing history. This allows him to both monopolize block generation and rewards on the \gls{blockchain}. It impacts the immutability and the stability of the \gls{consensus}.\\

In order to mitigate history reversals, \textit{checkpoints} can be introduced at certain depths of the blockchain history. They can be broadcasted through the \acrshort{p2p} network or exchanged through a trusted out-of-band system.\\

\textit{Transaction censorship}. Due to his ability to reverse blocks at will, the attacker can decide to censor certain \glspl{transaction} by not including them in his blocks and reversing any block that contains them. This impacts the accessibility of the \gls{consensus}.\\

Targeted censorship can be avoided on blockchains that offer \textit{anonymous transactions}. Due to the fact that nobody knows who is transacting, it's not possible to target any specific victims and only random or complete censorship  of transactions is possible.\\

\subsubsection{Minority Hashrate}

Due to the nature of the \acrshort{pow} algorithm, which is a memoryless process, there is also significant time variance during block generation. This means that a number of attacks remain possible with a non-majority share of the \gls{hashrate} on the network, allowing a malicious minority miner to exploit the vulnerability with a non-zero probability of success.\\

\textit{Probabilistic double spend}. With a minority \gls{hashrate}, an attacker still has a probability at generating one or several block at any point in time. This allows him to attempt generating a sufficient amount of blocks in time to reverse his own unconfirmed or even confirmed \gls{transaction} at a non-zero probability. It impacts the immutability of the \gls{consensus}.\\

\textit{Transaction throttling}. Being able to generate a portion of the blocks for the blockchain history, an attacker with a relevant amount of \gls{hashrate} can slow down the confirmation of \glspl{transaction} he wants excluded from the \gls{consensus}; he even has a chance to reverse confirmation with a non-zero probability. It impacts the accessibility of the \gls{consensus}.\\

\subsection{Block Propagation}

Every miner participating in a \gls{pow} consensus finding algorithm relies on the propagation of valid blocks through the network in order to generate a state transition for the latest valid \gls{consensus}. The theoretical model assumes that all miners will freely share newly found blocks in order to obtain their \glspl{reward}.\\

However, the option to withhold a discovered block and thus hide it from the network is a theoretical possibility. Depending on the intentions of an attacker, this opens up a vulnerability on the \gls{consensus}. An attacker can withhold a block to gain profit in some other way, while still conserving a significant probability of obtaining the \gls{reward}.\\

One mitigation of the vulnerability itself is to make sure blocks not on the recent history are somehow punished. One implementation suggests suggests that blocks need to be received within a maximum acceptable time interval \cite{zeroblock}. Another similar one relies on publishing time rather than generation time for blocks \cite{perish}.\\

\subsubsection{Finney Attack}

The Finney attack is a more sophisticated version of a \gls{double} that does not rely on having a significant amount of \gls{hashrate} on the network \cite{survey}. Instead, the miner waits to generate a block during an arbitrary interval and only starts the attack subsequently. Once the block is found, it's withheld from the network and thus hidden. It includes a \gls{transaction} that sends certain funds from the attacker to the victim.\\

The attacker now propagates a conflicting \gls{transaction} that sends the funds to the victim as part of the \gls{transaction}. As soon as the desired exchange has occurred in both directions, the attacker propagates his hidden block and reclaims the funds. It should be noted that the attacker risks another block being found before the attack was executed, thus risking to lose the \gls{reward}.\\

\textit{Unconfirmed double spend}. As the block with the \gls{transaction} is already mined, the attacker can execute a \gls{double} on an unconfirmed \gls{transaction} instantly. However, the attacker risks losing the \gls{reward} if another network participant generates another valid block during the execution of the attack. It impacts the immutability of the \gls{consensus}.\\

A previously unmentioned method to counter double spends in the case of the unconfirmed kind, which is the easiest to execute, is to \textit{monitor the memory pool} of nodes on the network, either by placing observers or by relaying conflicting transactions.\\

\subsubsection{Block Discarding}

When a miner finds a block, he can simply discard it \cite{less}. A lot of \glspl{pool} reward \glspl{miner} who contribute their work to the \gls{pool} in proportion to the work completed. In order to get rewards, \glspl{miner} submit proofs for completed work to the \gls{pool}. These so-called shares are significantly more frequent than finding a valid \gls{block}, which makes the incured loss negligible.\\

\textit{Unfair economic loss.} A malicious participant of the \gls{pool} can submit his shares and receive most of his \gls{reward}. When he finds a valid \gls{block} he discards it instead of submitting it to the \gls{pool}. This will cause a significant loss to the pool operator, who will award the same rewards but see lower returns. It impacts the stability of the \gls{consensus}.\\

Some pool operators mitigate the risk by using a reward structure that attributes extra \textit{rewards for blocks}, thus making the loss non-negligible for the malicious miner, while at the same time making it less costly for the \gls{pool} operator, as he will pay out less rewards overall.\\

\subsubsection{Selfish Mining}

The most sophisticated block withholding attack is the selfish mining strategy \cite{selfish}. A malicious miner who finds a block can withhold it from the network in order to gain a headstart for next block. Once the network finds a block, he can still release his block to contend for the block reward. However, he will significantly increase his own likelihood of finding the next valid block.\\

\textit{Unfair economic gain}. An attacking miner can increase his profitability over other participants on the network by optimizing his mining strategy according to the selfish mining principle \cite{optimal}. He will thus gain an unfair economic advantage that was not accounted for in the original model. It impacts the stability of the \gls{consensus}.\\

The authors of the original paper suggest accepting the new optimal mining strategy as the default for the network. In order to reduce the advantage for well-connected miners, they suggest propagating all competing block histories and \textit{randomizing the choice} of parent. This would create a level playing field once more.\\

\subsection{Cheap Validation}

In the context of a proof-of-stake consensus algorithm, \glspl{validator} invest a negligible amount of resources into the generation of new \glspl{block}. As the generation is extremely cheap, any \gls{validator} can generate \glspl{block} for many different versions of the block history. At the same time, \glspl{validator} can generate a long blockchain history in a short amount of time.\\

\subsubsection{Nothing-At-Stake}

The nothing-at-stake problem describes the fact that a \gls{validator} can generate \glspl{block} for many different blockchain histories without being punished for it. There is nothing at stake for him to lose, so there is no incentive to resolve conflicts between different versions of the blockchain history.\\

\textit{Follow multiple histories}. The fact that a \gls{validator} will only receive a \gls{reward} for the generated \glspl{block} if they were generated on the blockchain history accepted by all network participants gives economic him incentive to generate blocks for all versions of the blockchain history. The strategy is superior as it guarantees the \glspl{reward}, but it stops conflict resolution. It impacts the stability of the \gls{consensus}.\\

In order to counter the incentive of generating \glspl{block} for all available blockchain histories, we need to introduce a way to punish \glspl{validator} for generating blocks on multiple blockchain histories. Some \acrshort{pos} \glspl{blockchain} do this by \textit{blacklisting \glspl{validator}} working on more than one blockchain history, depriving them of \glspl{reward} \cite{secure}.\\

Another possible solution is the introduction of so-called \textit{slashing conditions} \cite{casper}. They define consensus rules under which validators will lose part of the funds they deposited in order to become \glspl{validator}. This inflicts economic loss on misbehaving \glspl{validator} which is more significant than the potential gain by following multiple blockchain histories.\\

\subsubsection{Long-Range Attack}

As costs for generating \glspl{block} in a \acrshort{pos} algorithm are negligible, any \gls{validator} can generate as many as he wants. This allows the recreation of part or all of the blockchain history. A malicious group of \glspl{validator} can thus take over the \gls{blockchain}, starting at any point of the blockchain history where they collectively held a sufficient amount of the staked tokens.\\

The exploit can be considered similar in effect to the majority hashrate attack for \acrshort{pow} \glspl{blockchain}. However, in the \acrshort{pow} context, the attacker still needs to invest the time to overcome the invested \gls{hashrate} of the previous blockchain history. In the case of \acrshort{pos}, this is not the case, as block generation is cheap and the history can be recreated quickly. This makes the impact even more severe.\\

Finally, the exploit can be strengthened by combining it with the so-called stake-bleeding attack \cite{bleeding}, where a \gls{validator} will not generate \glspl{block} on the attacked blockchain history, thus slowing down its growth at the price of losing part of the staked funds. However, if his competing history prevails, the loss of funds will be reversed.\\

\textit{Attacks}. The possible attacks are similar to the majority hashrate exploit: certain double spending, history reversal and transaction censorship. However, the history reversal is significantly more severe than for \acrshort{pow} \glspl{blockchain}. It impacts the same security criteria, respectively.\\

One solution to limit the impact of a long-range attack is the introduction of a \textit{moving checkpoint}, which is a limit on the number of blocks that can be rewritten. This creates an upper bound on how far into the past history can be rewritten and introduces the concept of finality, which means that a block can never be changed after a certain point in time and can thus be considered final.\\

However, this approach does not address the need for new or reconnecting nodes to synchronize with the network over a long blockchain history. This leaves this relevant subset of nodes vulnerable. It can be addressed by introducing an \textit{out-of-band history verification} of the blockchain, such as pulling checkpoints from a distributed network of trusted nodes.\\

Finally, \textit{key-evolving cryptography} can be used to make sure that each private key can only be used to sign once, thus making it impossible to acquire past keys from validators to increase the share of validation power. Such approaches are still experimental and in the early stages of research.\\

\section{Technical Vulnerabilities}

\subsection{Network Topology}

\Glspl{blockchain} generally rely on rudimentary \acrshort{p2p} gossip protocols to propagate messages, such as \glspl{block} and \glspl{transaction}, to all of the network participants. This network topology can be exploited to isolate certain nodes on the network and control the flow of messages between nodes. This allows can allow an attacker to manipulate the view of the \gls{consensus} for targeted nodes.\\

A popular approach for big service providers and \glspl{miner} in a \gls{blockchain} is to disable incoming connections and \textit{establish connections to trusted \glspl{node}}. While this effectively solves the issue, it does not scale to all network participants, as it would not allow new participants to join the network anymore.\\

A more sophisticated countermeasure involven a number of advanced algorithms when deciding which connections to allow, effectively \textit{randomizing the connections} we establish and maintain. This can be done by implementing random address selection, random address expiry, skewing preference to older known addresses, banning suspect messages and other tweaks. In combination, they eliminate the risk of a \gls{node} having all its connections monopolized by a single adversary, thus countering the attack.\\

\subsubsection{Eclipse Attack}

During an eclipse attack, the attacker monopolizes all the connections of the targeted network participant, effectively controlling the messages which are relayed to the \gls{node} \cite{eclipse}. This allows the attacker to present an inaccurate picture of the \gls{consensus} to the victim, or to delay reception of updates to the \gls{consensus}.\\

\textit{Block race engineering}. Having control over the victim allows the attacker to delay messages on newly found \glspl{block} on the \gls{blockchain}. By targeting multiple \glspl{miner}, the attacker can withhold their blocks until several are found, which then compete for the block reward. It impacts the stability of the \gls{consensus}.\\

\textit{Miner removal}. The attacker could also use the exploit to effectively remove the victim's \gls{hashrate} from the \gls{blockchain}. This would make it easier to execute other attacks based on hashrate distribution. It impacts the stability of the \gls{consensus}.\\

\textit{Confirmed double spend}. The attacker can eclipse a victim for a \gls{double}, as well as some \glspl{miner}. He can then have his transaction mined by the eclipsed miners, forward the block to the merchant and execute the double spend. Subsequently, he will stop withholding the real block history of the \gls{blockchain}, which contains another transaction to overwrite the previous one. It impacts the immutability of the \gls{consensus}.\\

\subsubsection{Balance Attack}

The balance attack doesn't involve isolating a node or a group of nodes from the main network; rather, it attempts to become the only relay for messages between different partitions of the \gls{blockchain} by placing the attacker's nodes at important edges of the network graph \cite{balance}. This requires in-depth knowledge about the \gls{hashrate} distribution and the communication topology of the underlying peer-to-peer network.\\

Rather than manipulating the view of the victims, the attacker can then play different network partitions against each other by deciding which progression of the blockhcain history to propagate and which one to delay or censor. While more difficult to exploit, it is also more difficult to detect and counter.\\

\textit{Attacks}. The possible attacks mirror the ones for the eclipse attack. We can instigate block races, remove \glspl{miner} from the effective \gls{hashrate} of the \gls{blockchain} and execute \glspl{double}.\\

In addition to previous mitigation strategies, we can use the fact that a balance attack requires advanced knowledge and monitoring of the network topology. We can therefore use traditional IT security controls to make it harder to execute BGP hijacking or DNS poisoning. Additionally, we can \textit{encrypt communication} on the network.\\

\section{Social Vulnerabilities}

\subsection{Node Owners}

Blockchain technology is a complex topic and many average users do not have the background to fully understand the technical aspects of \glspl{blockchain} they use. As \glspl{blockchain} rely on the \gls{effect} to increase their usefulness, lowering participation in them has a significant impact. This can be done by discouraging potential network participants in a number of ways.\\

\subsubsection{Content Insertion}

Many \glspl{blockchain} allow \glspl{node} to include arbitrary data into \glspl{transaction}. A malicious actor can thus insert data of any form into the \gls{consensus}, which would exist in immutable form for the lifetime of the \gls{blockchain}. Depending on the data inserted, this can be abused in a number of ways.\\

\textit{Illegal content insertion}. Illegal content can be inserted into the \gls{consensus} of \glspl{blockchain}. As has been demonstrated, this is not merely a theoretical possibility, but has been exploited in real \glspl{blockchain} before \cite{content}. It is a point of contention whether this can have legal implications for the participants of the network. However, it can at least be an effective tool to drive \acrfull{fud} in a community. It impacts the accessibility of the \gls{consensus}.\\

\textit{Data growth acceleration}. By including significant amounts of data into the blockchain, the \gls{consensus} can grow significantly and can expand to a size where some network participants decide it's too expensive to store it. Resource limitations would thus put a barrier around access to the \gls{blockchain}, reducing the number of participants. It impacts the accessibility of the \gls{consensus}.\\

In general, there is only one way to deal with undesired content insertion on \gls{blockchain}: not storing the content in question. This can be put into practice by implementing the possibility of \textit{pruning blockchain data}, as already described in section 7 of the Bitcoin white paper \cite{bitcoin}. They can then choose to discard certain content after validation of the related \glspl{transaction} and \glspl{block} has been completed.\\

An alternative approach is the implementation of a \textit{light synchronization protocol} for the network \cite{light}. It can take advantage of the properties of merkle trees in order to selectively validate blockchain data that the participant is interested in, without storing the full \gls{consensus} locally.\\

\subsection{Project Organization}

\Glspl{blockchain} are based on consensus rules enforced in a trustless manner between network participants. However, these consensus rules still need to be encoded in the software running the nodes of the network. If you manage to disrupt the organization of the project, you can change its direction and affect the usefulness of the \gls{blockchain}.\\

\subsubsection{Governance Structure}

Each blockchain project has a governance structure. In many cases, they are run in a mostly democratic way. This makes blockchain projects susceptible to be manipulated in the same way as modern elections in politics in order to affect certain changes \cite{fakenews}.\\

\textit{Change consensus rules}. The community around a project is crucial for the exchange of ideas and the discussion of the roadmap. This makes \glspl{blockchain} arguable more susceptible to the manipulation of public opinion than any other project. The past has shown that even consensus rule changes are not impossible \cite{forks}. It impacts the stability of the \gls{consensus}.\\

\textit{Block project progress}. By adopting changes which many community members disagree with, a conflict which drives many network participants away con be created at the heart of a blockchain project. This has happened previously in Bitcoin and has basically split the project in two \cite{cash}. It impacts the accessibility of the \gls{consensus}.\\

One initial defense against unexpected consensus rule changes and blocked progress is the clear \textit{definition of the values} behind a blockchain project. This philosophy can serve as a guide for future decisions and can be the basis for the project roadmap.\\

A second important step is to create a \textit{transparent project governance}, which serves as a way to achieve accountability by allowing all community members to audit the decisions and the related processes.\\

Finally, mechanisms to implement some sort of \textit{voting on the blockchain} to gauge the opinion of community stakeholders is a valuable tool to avoid making decisions which will upset or aleniate a significant portion of the network participants.\\

\subsubsection{Community Influence}

Most blockchain projects are governed in a supposedly democratic way. This means that the community around a project is crucial for the exchange of ideas and the discussion of the roadmap. This makes \glspl{blockchain} arguable more susceptible to the manipulation of public opinion than any other project.\\

\textit{Personality cult}. According to authority principle of persuasion defined by Dr. Robert Cialdini, people attribute higher value to the opinion of experts \cite{influence}. The principle of liking states that people prefer to follow those they like. Combining them, we could create leader personas shaping community opinion in a way favourable to the attacker. No criterion is directly impacted.\\

\textit{Social media manipulation}. Two other principles exposed by Cialdini are those of commitment and social proof. Censorship and astroturfing can be used to create a wrong impression of the public opinion \cite{astroturf}. This can lead to pressure by the public to implement certain changes in the project. No criterion is directly impacted.\\

There is a lot of ongoing research into social media manipulation techniques using botnets \cite{botnet}. Additionally, human beings are bad at being objective about the degree they are influenced \cite{echo}. As techniques become increasingly popular, techniques that use simple \textit{scoring and thresholds} for punishment become less and less efficient \cite{countering}.\\

On the other hand, it seems possible that some old techniques were good at identifying groups of users acting in synchronized manner \cite{copycatch}. Combined with a newer approach evaluating the \textit{authenticity of messages} on social media \cite{authenticity}, we believe a platform assisting network participants in forming an informed opinion could be built.\\

\subsection{Out-Of-Band Incentives}

Consensus is achieved on \glspl{blockchain} through the use of economic incentives. If a malicious actor tries to act against the consensus rules, he will usually incur a more or less severe economic punishment. However, the fact that such a loss can be countered by out-of-band payments makes the system vulnerable. As long as the counter-incentives are sufficient, the economic incentives of the system can be circumvented.\\

\textit{Attacks}. In general, any form of acquiring extra hashrate allows an easier execution of attacks related to \gls{hashrate}: double spends, history reversal and transaction censorship. However, they also directly impact the stability of the \gls{consensus}, even when not achieving sufficient \gls{hashrate} accumulation to execute an attack.\\

One of the only suggested solutions for out-of-band incentives is currently to \textit{counter-bribe} the miners in order to keep them away from the original briber and potentially get them back to mining normally \cite{ethcc}. This works because miners have incentive to preserve their block in the history in order to not lose their \gls{reward}.\\

Another suggested solution is to change to another \acrshort{pow} algorithm. This would allow the choice of an algorithm that is difficult to verify in smart contracts, making bribery more difficult. It would also punish miners for being bribed. This would however not be viable long term.\\

\subsubsection{Hashrate Renting}

The simplest form of acquiring extra mining power is through direct payments in return for acquiring a certain \gls{hashrate} \cite{bribery}. This can be done by using a cloud hashing provider, where you can rent \gls{hashrate} as a service. Trust issues with this setup can be overcome by introducing a negative fee \gls{pool}, where the operator overpays the miners to get them to join, so he gets to directly control the \gls{hashrate}.\\

\subsubsection{Contractual Bribery}

A more advanced form of bribing miners can be executed by contractual agreement that is enforced on the blockchain. A simple version would simply create the desired forks with included bribery \glspl{transaction}; miners seeking profit would then mine this fork as it will make the competing history dominant, allowing them to receive the bribes contained in the \glspl{transaction}.\\

A more advanced version uses one \gls{blockchain} with a smart contract to reward miners for solutions, while another \gls{blockchain} is the one the attack is run against \cite{puzzles}. This will over-incentivize the creation of solutions that favour the attacker's intent, thus disrupting the economic equilibrium of the network and the underlying security guarantees.\\

Next to guaranteeing the attacker to outpace the public blockchain history with his private blockchain history if all miners behave rationally, this constellation can be profitable in an of itself, as it allows the attacker to outpace all other miners on the network, even with less than majority \gls{hashrate}, thus allowing him to censor competing blocks and receive all of the rewards.\\

\section{Case Study}

\subsection{Context Definition}

The risks for \glspl{blockchain} and their \gls{consensus} security have been established through research in the previous section. A summary of the identified risks is available in Appendix A for easy reference. The controls related to the mitigation of various vulnerabilities, attack methods and attacks is available as a list for each vulnerability in Appendix B.\\

The created references will now be applied to a real blockchain project to get practical risk management results. During our analysis, the simple method of equating risk score to probability times impact will be used. We will use the scoring as specified below.\\

\begin{figure}[H]
\begin{center}
\begin{tabular}{| l | l |}
  \hline
  \multicolumn{2}{| c |}{\textbf{Probability}}\\
  \hline
  5 & Always\\
  \hline
  4 & Likely\\
  \hline
  3 & Possible\\
  \hline
  2 & Unlikely\\
  \hline
  1 & Never\\
  \hline
\end{tabular}
\qquad
\begin{tabular}{| l | l |}
  \hline
  \multicolumn{2}{| c |}{\textbf{Impact}}\\
  \hline
  5 & Critical\\
  \hline
  4 & Significant\\
  \hline
  3 & Moderate\\
  \hline
  2 & Marginal\\
  \hline
  1 & Negligible\\
  \hline
\end{tabular}
\end{center}
\end{figure}

The risk management will be done for a real \gls{blockchain}, Alvalor, which is currently under active development. Little public information is available, but the author is familiar with the technical design. This will allow the results of this paper to be put into practice and have a real use beyond the academic value.\\

Alvalor is a minimalist \gls{blockchain} based on a simple \acrlong{pow} mechanism. For our purposes, the \glspl{transaction} can be considered as simple, conveying no additional data other than the transfer details, thus rendering them fixed in size. Once the project launches, the \gls{hashrate} of the \gls{blockchain} should be comparatively low.\\

On the foundational layer, which is the only one relevant for our analysis, it can thus be compared to a multitude of other small blockhain projects and a lot of considerations should be applicable to a decent range of \glspl{blockchain}. The recommendations at the end of the section could therefore be translated and applied widely.\\

\subsection{Risk Analysis}

\subsubsection{Identification}

In its current design, Alvalor uses a simple \acrshort{pow} consensus algorithm, which means that all risks from A.1.1 and A.1.2 are applicable, while risks of section A.1.3 are not.\\

The network topology is based on a simple gossip protocol in a \acrlong{p2p} network and is therefore subject to all of the risks listed under A.2.\\

No content insertion is possible, so section A.3.1 can be discarded. Section A.3.2 and A.3.3 merit consideration in our case.\\

This leaves us with the following list of exploits to consider:
\begin{enumerate}
  \item Majority \& minority hashrate
  \item Finney attack, block discarding \& selfish mining
  \item Eclipse \& balance attack
  \item Governance hijacking \& community manipulation
  \item Hashrate renting \& contractual bribery
\end{enumerate}

\subsubsection{Assessment}

Rather than assessing the impact of each attack, we will assess the possible impact of each exploit that enables attacks. This is more meaningful in the context of blockchain as the mere possibility of a risk materializing already impacts the security guarantees of the \gls{blockchain}.\\

\begin{figure}[H]
\begin{center}
\begin{tabular}{| l | l |}
  \hline
  \multicolumn{2}{| c |}{\textbf{Majority hashrate}}\\
  \hline
  Probability & 2\\
  \hline
  Impact & 5\\
  \hline
  \underline{Total} & 10\\
  \hline
\end{tabular}
\qquad
\begin{tabular}{| l | l |}
  \hline
  \multicolumn{2}{| c |}{\textbf{Minority hashrate}}\\
  \hline
  Probability & 3\\
  \hline
  Impact & 3\\
  \hline
  \underline{Total} & 9\\
  \hline
\end{tabular}
\end{center}
\end{figure}

\begin{figure}[H]
\begin{center}
\begin{tabular}{| l | l |}
  \hline
  \multicolumn{2}{| c |}{\textbf{Finney attack}}\\
  \hline
  Probability & 4\\
  \hline
  Impact & 2\\
  \hline
  \underline{Total} & 8\\
  \hline
\end{tabular}
\qquad
\begin{tabular}{| l | l |}
  \hline
  \multicolumn{2}{| c |}{\textbf{Block discarding}}\\
  \hline
  Probability & 2\\
  \hline
  Impact & 1\\
  \hline
  \underline{Total} & 2\\
  \hline
\end{tabular}
\end{center}
\end{figure}

\begin{figure}[H]
\begin{center}
\begin{tabular}{| l | l |}
  \hline
  \multicolumn{2}{| c |}{\textbf{Selfish mining}}\\
  \hline
  Probability & 3\\
  \hline
  Impact & 3\\
  \hline
  \underline{Total} & 9\\
  \hline
\end{tabular}
\qquad
\begin{tabular}{| l | l |}
  \hline
  \multicolumn{2}{| c |}{\textbf{Eclipse attack}}\\
  \hline
  Probability & 2\\
  \hline
  Impact & 2\\
  \hline
  \underline{Total} & 4\\
  \hline
\end{tabular}
\end{center}
\end{figure}

\begin{figure}[H]
\begin{center}
\begin{tabular}{| l | l |}
  \hline
  \multicolumn{2}{| c |}{\textbf{Balance attack}}\\
  \hline
  Probability & 1\\
  \hline
  Impact & 3\\
  \hline
  \underline{Total} & 3\\
  \hline
\end{tabular}
\qquad
\begin{tabular}{| l | l |}
  \hline
  \multicolumn{2}{| c |}{\textbf{Governance hijacking}}\\
  \hline
  Probability & 3\\
  \hline
  Impact & 3\\
  \hline
  \underline{Total} & 9\\
  \hline
\end{tabular}
\end{center}
\end{figure}

\begin{figure}[H]
\begin{center}
\begin{tabular}{| l | l |}
  \hline
  \multicolumn{2}{| c |}{\textbf{Community manipulation}}\\
  \hline
  Probability & 2\\
  \hline
  Impact & 4\\
  \hline
  \underline{Total} & 8\\
  \hline
\end{tabular}
\qquad
\begin{tabular}{| l | l |}
  \hline
  \multicolumn{2}{| c |}{\textbf{Hashrate renting}}\\
  \hline
  Probability & 3\\
  \hline
  Impact & 2\\
  \hline
  \underline{Total} & 6\\
  \hline
\end{tabular}
\end{center}
\end{figure}

\begin{figure}[H]
\begin{center}
\begin{tabular}{| l | l |}
  \hline
  \multicolumn{2}{| c |}{\textbf{Contractual bribery}}\\
  \hline
  Probability & 2\\
  \hline
  Impact & 3\\
  \hline
  \underline{Total} & 6\\
  \hline
\end{tabular}
\end{center}
\end{figure}

\subsubsection{Triage}

In our risk treatment, we want to focus on high and medium exploits for mitigation, while choosing risk acceptance for the risks at the low end of the scale. We will use the following categorization for the exploits.

\begin{itemize}
  \item Low: 1-4
  \item Medium: 5-7
  \item High: 8+
\end{itemize}

The following high risk exploits should be addressed with controls: majority hashrate, minority hashrate, selfish mining, governance hijacking, finney attack and community manipulation.\\

The following medium risk exploits should be address with controls: hashrate renting and contractual bribery.\\

The following low risk exploits will be accepted: eclipse, balance attack and block discarding.\\

\subsection{Security Conclusions}

\subsubsection{Observations}

Our first observation is that the fundamental stability of the proof-of-work consensus algorithm is one of the main concerns in the light of more recent discoveries in terms of vulnerabilities of the theoretical model.\\

The second observation is that social vulnerabilities, which are not part of most blockchain's security considerations, rank on the same level as these fundamental issues.\\

The third observation is that out-of-band incentives are a non-negligible risk to the stability of blockchain security guarantees and should be a part of the threat model surrounding \glspl{blockchain}.\\

\subsubsection{Recommendations}

In order to mitigate vulnerabilities around hashrate distribution and block propagation, we recommend the implementation of the following controls: B1.3 Confirmation wait period, B.1.5 Memory pool monitoring, B.1.7 Blockchain checkpoints and B.2.3 Extended block relaying.\\

While not directly mitigating all risks, it puts the power into the hand of the network participants, which will be able to design the best strategies for their use case while making the necessary tradeoffs for their situation. A good default implementation of such strategies should be provided.\\

In order to mitigate vulnerabilities around the project organization, we recommend the implementation of the following controls: B.6.1 Definition of values, B.6.2 Transparent governance and B.6.3 Onchain voting.\\

While novel approaches such as the evaluation of authenticity of social media messages seem promising, more work in the area is needed before an implementation is possible without spending tremendous resources. Using a human-centered approach seems like the most pragmatic way at this point in time.\\

We do not recommend currently recommend the implementation of any controls regarding the out-of-bound incentive vulnerabilities. However, we strongly recommend defining them as a relevant concern in the threat model of the project.\\

Indeed, none of the current approaches seems to be satisfactory for the time being and additional work in the area is required. However, the progress should be continuously monitored and it is recommend to keep an eye on the surfacing of such practices in the wild.\\

\section{Conclusion}

This paper took a look at risk management for \glspl{blockchain} from the perspective of protecting the security of the \gls{consensus} and thus ensuring the security guarantees that make \glspl{blockchain} uniquely useful in the modern information technology world.\\

One interesting observation was that the author found vaste amounts of research literature on the theoretical soundness of the security model, a growing body of academic literature on the technical aspects of the \acrshort{p2p} network, but almost no consideration for the social aspects of blockchain security.\\

Indeed, no blockchain project has considered attacks on the consensus model through out-of-band incentives as part of their threat model. Nor has any community made an effort to create a platform for the exchange of ideas that is resistent censorship and manipulation.\\

In conclusion, it can be said that, as \glspl{blockchain} will grow in significance and the advantages to be gained from exploiting them will increase, significant challenges remain on the horizon and will have to be tackled in order to guarantee the continued usefulness of this disruptive new technology.\\

\newpage
\begin{thebibliography}{9}

\bibitem{iso}
International Standards Organization,
"Information technology -- Security techniques -- Code of practice for information security controls",
ISO/IEC 27002,
June 2005.

\bibitem{influence}
Robert B. Cialdini,
"The 6 Principles of Persuasion",
\textit{Influence: The Psychology of Persuasion},
HarperBusiness, 2006.

\bibitem{bitcoin}
Satoshi Nakamoto,
"Bitcoin: A Peer-to-Peer Electronic Cash System",
\url{https://bitcoin.org/bitcoin.pdf},
October 2008.

\bibitem{threat}
Carlos Laorden, Borja Sanz, Gonzalo Alvarez and Pablo García Bringas,
"A Threat Model Approach to Threats and Vulnerabilities in On-line Social Networks",
\url{http://paginaspersonales.deusto.es/claorden/publications/2010/sanz_RECSI10_A%20Threat%20Model%20Approach%20to%20Attacks%20and%20Countermeasures%20in%20OSN.pdf},
January 2010.

\bibitem{domain}
Éric Dubois, Patrick Heymans, Nicolas Mayer and Raimundas Matulevičius,
"A Systematic Approach to Define the Domain of Information System Security Risk Management",
\url{https://pdfs.semanticscholar.org/ddb5/ff3f13160733b1ec11b34683e0264a09067e.pdf},
May 2010.

\bibitem{astroturf}
Jacob Ratkiewicz, Michael D. Conover, Mark Meiss, Bruno Gonçalves, Alessandro Flammini and Filippo Menczer,
"Detecting and Tracking Political Abuse in Social Media",
\url{https://www.aaai.org/ocs/index.php/ICWSM/ICWSM11/paper/download/2850/3274},
July 2011.

\bibitem{polarization}
Michael D. Conover, Jacob Ratkiewicz, Matthew Francisco, Bruno Goncalves, Filippo Menczer and Alessandro Flammini,
"Political Polarization on Twitter",
\url{https://www.aaai.org/ocs/index.php/ICWSM/ICWSM11/paper/viewFile/2847/3275},
July 2011.

\bibitem{weight}
Gavin Andresen,
"Neutralizing a 51\% attack",
\url{http://gavintech.blogspot.com/2012/05/neutralizing-51-attack.html},
May 2012.

\bibitem{double}
Meni Rosenfeld,
"Analysis of hashrate-based double-spending",
\url{https://arxiv.org/pdf/1402.2009.pdf},
December 2012.

\bibitem{copycatch}
Alex Beutel, Wanhong Xu, Venkatesan Guruswami, Christopher Palow and Christos Faloutsos,
"CopyCatch: Stopping Group Attacks by Spotting Lockstep Behavior in Social Networks",
\url{http://alexbeutel.com/papers/www2013_copycatch.pdf},
May 2013.

\bibitem{selfish}
Ittay Eyal and Gün Sirer,
"Majority is not Enough: Bitcoin Mining is Vulnerable",
\url{https://www.cs.cornell.edu/~ie53/publications/btcProcFC.pdf},
November 2013.

\bibitem{less}
Lear Bahack,
"Theoretical Bitcoin Attacks with less than Half of the Computational Power",
\url{http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.473.2485&rep=rep1&type=pdf},
December 2013.

\bibitem{light}
Vitalik Buterin,
"Light client protocol",
\url{https://github.com/ethereum/wiki/wiki/Light-client-protocol},
July 2014.

\bibitem{twophase}
Martijn Bastiaan,
"Preventing the 51\%-Attack: a Stochastic Analysis of Two Phase Proof of Work in Bitcoin",
\url{http://referaat.cs.utwente.nl/conference/22/paper/7473/preventingthe-51-attack%20-a-stochastic-analysis-of-two-phase-proof-of-work-in-bitcoin.pdf},
January 2015.

\bibitem{optimal}
Ayelet Saphirshtein, Yonatan Sompolinsky and Aviv Zohar,
"Optimal Selfish Mining Strategies in Bitcoin",
\url{https://fc16.ifca.ai/preproceedings/30_Sapirshtein.pdf},
July 2015.

\bibitem{eclipse}
Ethan Heilman, Alison Kendler, Aviv Zohar and Sharon Golberg,
"Eclipse Attacks on Bitcoin’s Peer-to-Peer Network",
\url{https://eprint.iacr.org/2015/263.pdf},
August 2015.

\bibitem{forks}
Mike Hearn,
"On consensus and forks",
\url{https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7},
August 2015.

\bibitem{bribery}
Joseph Bonneau,
"Why Buy When You Can Rent? Bribery Attacks on Bitcoin-Style Consensus",
\url{https://www.springer.com/cda/content/document/cda_downloaddocument/9783662533567-c2.pdf?SGWID=0-0-45-1587311-p180215767},
February 2016.

\bibitem{puzzles}
Jason Teutsch, Sanjay Jain and Prateek Saxena,
"When cryptocurrencies mine their own business",
\url{https://people.cs.uchicago.edu/~teutsch/papers/repurposing_miners.pdf},
February 2016.

\bibitem{botnet}
Norah Abokhodair, Daisy Yoo and David W. McDonald,
"Dissecting a Social Botnet: Growth, Content and Influence in Twitter",
\url{http://www.pensivepuffin.com/dwmcphd/papers/Abokhodair.SocialBotnet.CSCW2015.pdf},
April 2016.

\bibitem{zeroblock}
Siamak Solat and Maria Potop-Butucaru,
"ZeroBlock: Timestamp-Free Prevention of Block-Withholding Attack in Bitcoin",
\url{https://arxiv.org/pdf/1605.02435.pdf},
May 2016.

\bibitem{counter}
Jinxue Zhang, Rui Zhang, Yanchao Zhang and Guanhua Yan,
"The Rise of Social Botnets: Attacks and Countermeasures",
\url{https://arxiv.org/pdf/1603.02714.pdf},
March 2016.

\bibitem{attacks}
George Bissias, Brian Levine, A. Pinar Ozisik and Gavin Andresen,
"An Analysis of Attacks on Blockchain Consensus",
\url{https://arxiv.org/pdf/1610.07985.pdf},
October 2016.

\bibitem{balance}
Christopher Natoli and Vincent Gramoli,
"The Balance Attack Against Proof-Of-Work Blockchains: The R3 Testbed as an Example",
\url{https://arxiv.org/pdf/1612.09426.pdf},
December 2016.

\bibitem{fakenews}
Hunt Allcott and Matthew Gentzkow,
"Social Media and Fake News in the 2016 Election",
\url{https://web.stanford.edu/~gentzkow/research/fakenews.pdf},
January 2017.

\bibitem{perish}
Reu Zhang and Bart Preneel,
"Publish or Perish: A Backward-Compatible Defense against Selfish Mining in Bitcoin",
\url{https://www.esat.kuleuven.be/cosic/publications/article-2746.pdf},
April 2017.

\bibitem{crypto}
Vitalik Buterin,
"Introduction to Cryptoeconomics",
\url{https://vitalik.ca/files/intro_cryptoeconomics.pdf},
April 2017.

\bibitem{survey}
Mauro Conti, Sandeep Kumar E, Chhagan Lal and Sushmita Ruj,
"A Survey on Security and Privacy Issues of Bitcoin",
\url{https://arxiv.org/pdf/1706.00916.pdf},
June 2017.

\bibitem{authenticity}
Aviad Elyashar, Jorge Bendahan and Rami Puzis,
"Has the Online Discussion Been Manipulated? Quantifying Online Discussion Authenticity within Online Social Media",
\url{https://arxiv.org/pdf/1708.02763.pdf},
August 2017.

\bibitem{secure}
Wenting Li, Sébastien Andreina, Jens-Matthias Bohli and Ghassan Karame,
"Securing Proof-of-Stake Blockchain Protocols",
\url{https://pdfs.semanticscholar.org/ebfb/57843cdf23ce6fe7007c0f1ea233eca4b71e.pdf},
September 2017.

\bibitem{casper}
Vitalik Buterin and Virgil Griffith,
"Casper the Friendly Finality Gadget",
\url{https://arxiv.org/pdf/1710.09437.pdf},
October 2017.

\bibitem{ethcc}
Patrick McCorry, Alexander Hicks and Sarah Meiklejohn,
"Smart Contracts for Bribing Miners",
\url{http://homepages.cs.ncl.ac.uk/patrick.mccorry/minerbribery.pdf},
January 2018.

\bibitem{content}
Roman Matzutt, Jens Hiller, Martin Henze, Jan Henrik Ziegeldorf, Dirk Müllmann, Oliver Hohlfeld and Klaus Wehrle,
"A Quantitative Analysis of the Impact of Arbitrary Blockchain Content on Bitcoin",
\url{https://fc18.ifca.ai/preproceedings/6.pdf},
March 2018.

\bibitem{bleeding}
Peter Gaži, Aggelos Kiayias and Alexander Russell,
"Stake-Bleeding Attacks on Proof-of-Stake Blockchains",
\url{https://eprint.iacr.org/2018/248.pdf},
March 2018.

\bibitem{echo}
Nabeel Gillani, Ann Yuan, Martin Saveski, Soroush Vosoughi and Deb Roy,
"Me, My Echo Chamber, and I: Introspection on Social Media Polarization",
\url{https://arxiv.org/pdf/1803.01731.pdf},
April 2018.

\bibitem{cash}
Alyssa Hertig,
"Bitcoin Cash Fork Leaves Users Behind, But Does It Matter?",
\url{https://www.coindesk.com/bitcoin-cash-fork-leaves-users-behind-matter/},
May 2018.

\end{thebibliography}

\newpage
\printglossary[type=\acronymtype]
\printglossary

\newpage
\appendix

\section{Risks}

\begin{tabular}{| l | l | l |}
  \hline

  \multicolumn{3}{| l |}{\textbf{A.1 Theoretical Risks}}\\
  \hline

  \multicolumn{3}{| l |}{\underline{\smash{A.1.1 Hashrate Distribution}}}\\
  \hline
    Majority hashrate & \textit{Certain double spend} & Immutability\\
  \hline
    Majority hashrate & \textit{History reversal} & Immutability, stability\\
  \hline
    Majority hashrate & \textit{Transaction censorship} & Accessibility\\
  \hline
    Minority hashrate & \textit{Probabilistic double spend} & Immutability\\
  \hline
    Minority hashrate & \textit{Transaction throttling} & Accessibility\\
  \hline

  \multicolumn{3}{| l |}{\underline{\smash{A.1.2 Block Propagation}}}\\
  \hline
    Finney attack & \textit{Unconfirmed double spend} & Immutability\\
  \hline
    Block discarding & \textit{Unfair economic loss} & Stability\\
  \hline
    Selfish mining & \textit{Unfair economic gain} & Stability\\
  \hline

  \multicolumn{3}{| l |}{\underline{\smash{A.1.3 Cheap Validation}}}\\
  \hline
    Nothing-at-stake & \textit{Follow multiple histories} & Stability\\
  \hline
    Long-range attack & \textit{Certain double spend} & Immutability\\
  \hline
    Long-range attack & \textit{History reversal} & Immutability, stability\\
  \hline
    Long-range attack & \textit{Transaction censorship} & Accessibility\\
  \hline

  \multicolumn{3}{| l |}{\textbf{A.2 Technical Risks}}\\
  \hline

  \multicolumn{3}{| l |}{\underline{\smash{A.2.1 Network Topology}}}\\
  \hline
    Eclipse attack & \textit{Block race engineering} & Stability\\
  \hline
    Eclipse attack & \textit{Miner removal} & Stability\\
  \hline
    Eclipse attack & \textit{Confirmed double spend} & Immutability\\
  \hline
    Balance attack & \textit{Block race engineering} & Stability\\
  \hline
    Balance attack & \textit{Miner removal} & Stability\\
  \hline
    Balance attack & \textit{Confirmed double spend} & Immutability\\
  \hline

  \multicolumn{3}{| l |}{\textbf{A.3 Social Risks}}\\
  \hline

  \multicolumn{3}{| l |}{\underline{\smash{A.3.1 Node Owners}}}\\
  \hline
    Content insertion & \textit{Illegal content insertion} & Accessibility\\
  \hline
    Content insertion & \textit{Data growth acceleration} & Accessibility\\
  \hline

  \multicolumn{3}{| l |}{\underline{\smash{A.3.2 Project Organization}}}\\
  \hline
     Governance hijacking & \textit{Change consensus rules} & Stability\\
  \hline
     Governance hijacking & \textit{Block project progress} & Accessibility\\
  \hline
     Community manipulation & \textit{Personality cult} & --\\
  \hline
     Community manipulation & \textit{Social media manipulation} & --\\
  \hline

  \multicolumn{3}{| l |}{\underline{\smash{A.3.3 Out-Of-Band Incentives}}}\\
  \hline
    Hashrate renting & \textit{--} & Stability\\
  \hline
    Contractual Bribery & \textit{--} & Stability\\
  \hline

\end{tabular}

\newpage
\section{Controls}

\begin{tabular}{| l |}
  \hline

  \textbf{B.1 Hashrate Distribution}\\
  \hline
  \textit{B.1.1 Automatic hashrate balancing}\\
  \hline
  \textit{B.1.2 Two-phase proof-of-work}\\
  \hline
  \textit{B.1.3 Confirmation wait period}\\
  \hline
  \textit{B.1.4 History transaction weighting}\\
  \hline
  \textit{B.1.5 Memory pool monitoring}\\
  \hline
  \textit{B.1.6 Anonymous transactions}\\
  \hline
  \textit{B.1.7 Blockchain checkpoints}\\
  \hline

  \textbf{B.2 Block Propagation}\\
  \hline
  \textit{B.2.1 Unpublished block punishment}\\
  \hline
  \textit{B.2.2 Pool block rewards}\\
  \hline
  \textit{B.2.3 Extended block relaying}\\
  \hline
  \textit{B.2.4 Mining parent randomization}\\
  \hline

  \textbf{B.3 Cheap validation}\\
  \hline
  \textit{B.3.1 Validator blacklist}\\
  \hline
  \textit{B.3.2 Slashing conditions}\\
  \hline
  \textit{B.3.3 Moving checkpoints}\\
  \hline
  \textit{B.3.4 Out-of-band verification}\\
  \hline
  \textit{B.3.5 Key-evolving signatures}\\
  \hline

  \textbf{B.4 Network Topology}\\
  \hline
  \textit{B.4.1 Trusted connections}\\
  \hline
  \textit{B.4.2 Randomized connections}\\
  \hline
  \textit{B.4.3 Encrypted communication}\\
  \hline

  \textbf{B.5 Node Owners}\\
  \hline
  \textit{B.5.1 Blockchain pruning}\\
  \hline
  \textit{B.5.2 Light synchronization}\\
  \hline

  \textbf{B.6 Project Organization}\\
  \hline
  \textit{B.6.1 Definition of values}\\
  \hline
  \textit{B.6.2 Transparent governance}\\
  \hline
  \textit{B.6.3 Onchain voting}\\
  \hline
  \textit{B.6.4 Behaviour scoring}\\
  \hline
  \textit{B.6.5 Authenticity evaluation}\\
  \hline

  \textbf{B.7 Out-Of-Band Incentives}\\
  \hline
  \textit{B.7.1 Counter-bribery}\\
  \hline
  \textit{B.7.2 Proof-of-work change}\\
  \hline

\end{tabular}

\end{document}