Bitcoin blockchain dynamics: The selfish-mine strategy in the presence of propagation delay

Abstract

In the context of the ‘selfish-mine’ strategy proposed by Eyal and Sirer, we study the effect of communication delay on the evolution of the Bitcoin blockchain. First, we use a simplified Markov model that tracks the contrasting states of belief about the blockchain of a small pool of dishonest miners and the ‘rest of the community’ to establish that the use of block-hiding strategies, such as selfish-mine, causes the rate of production of orphan blocks to increase. Then we use a spatial Poisson process model to study values of Eyal and Sirer’s parameter $\gamma$, which denotes the proportion of the honest community that mines on a previously-secret block released by the pool in response to the mining of a block by the honest community. Finally, we use discrete-event simulation to study the behaviour of a network of Bitcoin miners, a proportion of which is colluding in using the selfish-mine strategy, under the assumption that there is a delay in the communication of information between miners. The models indicate that both the dishonest and the honest miners were worse off than they would have been if no dishonest mining were present, and that it is possible for the mining community to detect block-hiding behaviour, such as that used in selfish-mine, by monitoring the rate of production of orphan blocks.

Introduction

Bitcoin is a peer to peer electronic payment system in which transactions are performed without the need for a central clearing agency to authorise transactions. Bitcoin users conduct transactions by transmitting electronic messages which identify who is to be debited, who is to be credited, and where the change (if any) is to be deposited.

Bitcoin payments use Public Key Encryption. The payers and payees are identified by the public keys of their Bitcoin wallet identities. Each Bitcoin transaction is encrypted and broadcast over the network. Suppose you receive a transaction from Mary. If you can decrypt Mary’s message using her public key, then you have confirmed that the message was encrypted using Mary’s private key and therefore the message indisputably came from Mary. But how can you verify that Mary has sufficient bitcoins to pay you?

The Bitcoin system solves this problem by verifying transactions in a coded form in a data structure called the blockchain, which is maintained by a community of participants, known as miners.

It can happen that different miners have different versions of the blockchain, something which occurs because of communication delays, see Decker and Wattenhofer  [1]. For Bitcoin to be able to function, it is essential that these inconsistencies are resolved within a short timescale. We are interested in how the inconsistencies arise and how they are resolved (1) when all participants are acting according to the Bitcoin protocol, and (2) when a pool of participants is using the ‘selfish-mine’ strategy proposed by Eyal and Sirer  [2].

At the heart of the Bitcoin system is the computational process called mining, which involves the solution of a computationally-difficult cryptographic problem. Bitcoin miners receive copies of all transactions as they are generated. They examine the blockchain to investigate the history of the bitcoins involved in each transaction. If the proposed transaction has sufficient bitcoin credit, then it is accepted for incorporation into the block that the miner is currently working on.

Each transaction is identified with a double SHA-256 hash. Miners gather transactions together and use their hashes, together with the hash that is at the current head of the blockchain, as inputs to the cryptographic problem. If a miner succeeds in solving the problem, it is said to have mined a block that contains records of all the transactions that were part of the calculation. The miner receives a reward (currently 12.5 bitcoins) for accomplishing this, along with a small transaction fee gathered from each transaction in the block.

The process works as follows. A miner  $M$ computes a double SHA-256 hash  $h$ (the merkle hash) over a unique ordering of the hashes of all the transactions that it is intending to incorporate into its next block $B$. It also takes as input the block solution  $s^{\prime }$ at the head of its current version of the blockchain. Denoting concatenation of strings by the symbol +, the cryptographic problem that $M$ has to solve is: compute a double SHA-256 hash

$$s=SHA256\left(SHA256(n+h+s^{\prime })\right)\text{,}$$

such that  $s$ has at least a specified number  $x$ of leading zeros where $x\sim 64$. The string  $n$ is a random ‘nonce’ value. If  $s$ does not have at least  $x$ leading zeros, then  $n$ is updated and  $s$ is recomputed until a solution is found with the required number of leading zeros.

Once mined, the new block is communicated to the members of the peer network and, subject to the fine detail of the rules that we shall discuss in the next section, the new block is added to the blockchain at each peer. The blockchain thus functions as a public ledger: it records every Bitcoin payment ever made.

The objective of the designers of the Bitcoin protocol was to keep the average rate at which blocks are added to the long-term blockchain at six blocks per hour. To this end, the value of $x$, which reflects the difficulty of the computational problem inherent in (1), is adjusted after the creation of each set of 2016 new blocks. If the previous 2016 blocks were created at an average rate faster than six blocks per hour, then the problem is made more difficult, if they were created at a slower average rate, then it is made less difficult. The effect is that the difficulty varies in response to the total amount of computational power that the community of miners is applying.

The test of whether a particular hash has the required number of leading zeros is a success/failure experiment whose outcome is independent of previous experiments. Therefore, the number of experiments required for the first success is geometrically distributed and, given that the individual success probabilities are very low and the time taken to perform an experiment is correspondingly very small, the time taken to achieve a success is very well-modelled by an exponential random variable. It is thus reasonable to model block creation instants as a Poisson process with a constant rate of six per hour.

The difficulty of a sequence of blocks is a measure of the amount of computing effort that was required to generate the sequence. This can be evaluated in terms of the numbers of leading zeros that were required when the blocks in the sequence were created. When Bitcoin was started, miners used PCs to solve the cryptographic puzzle and earn bitcoins. The difficulty of the puzzle was increased to limit the rate of producing bitcoins. Miners started using the parallel processing capabilities of Graphical Processing Units (GPUs) to solve the cryptographic puzzle. The difficulty of the puzzle was increased again. Miners started using Field Programmable Gate Arrays (FPGAs). The difficulty was increased yet again. Today miners use dedicated hardware built around custom Application Specific Integrated Circuits (ASICs).

Miners communicate by broadcasting newly-discovered blocks via a peer-to-peer network. Each miner maintains its own version of the blockchain based upon the communications that it receives and its own discoveries. The protocol is designed so that blockchains are locally updated in such a way that they are identical at each miner or, if they differ, then the differences will soon be resolved and the blockchains will become identical. The way that this process works is explained in the next subsection.

The material discussed here is obtained from  [3]. The main branch of the blockchain is defined to be the branch with highest total difficulty.

There are three categories of blocks

• Blocks in the main branch: the transactions in these blocks are considered to be tentatively confirmed.

• Blocks in side branches off the main branch: these blocks have tentatively lost the race to be in the main branch.

• Blocks which do not link into the main branch, because of a missing predecessor or $n$th-level predecessor.

Blocks in the first two categories form a tree rooted at the very first block, which is known as the genesis block, linked by the reference to the hash of the predecessor block that each block was built upon. The tree is almost linear with a few short branches off the main branch.

Consider the situation where a node learns of a new block. This block could either be mined locally or have been communicated after being mined at another node. The actions (a complete list of the actions is given in  [3]) that the node takes are to:

• Reject the new block if a duplicate of the block is present in any of the three block categories mentioned above.

• Compute the double SHA-256 hash of the new block according to  (1) and check that the hash has the required number of leading zeros.

• Check the timestamp of the new block.

• Compute and verify the merkle hash of the new block.

• Check if the predecessor block (that is, the block matching the previous hash) is in the main branch or a side branch. If it is in neither then query the peer that sent the new block to ask it to send the predecessor block, and abandon the blockchain update.

• Add the new block to the blockchain if the predecessor block is in the main branch or a side branch. There are three cases.

  • The new block extends the main branch: add the new block to the main branch. If the new block is mined locally, relay the block to the node’s peers.

  • The new block extends a side branch but does not add enough difficulty to cause it to become the new main branch: add the new block to the side branch.

  • The new block extends a side branch which becomes the new main branch: add the new block to the side branch and

    • find the fork block on the main branch from which this side branch forks off,

    • redefine the main branch to extend only to this fork block,

    • add each block on the side branch, from the child of the fork block to the leaf, to the main branch,

    • delete each block in the old main branch, from the child of the fork block to the leaf,

    • relay the new block to the node’s peers.

• Run all these steps (including this one) recursively, for each block for which the new block is its previous block.

Suppose miner  $M_i$ is mining block $B_i$ with hash $h_i$ on its version $C$ of the blockchain which has  $s_i^{\prime }$ as its previous hash, and computes a solution  $s_i$ to the cryptographic puzzle with nonce $n_i$. Miner  $M_i$ will add $B_i$ to $C$ and broadcast $B_i$ to the network.

The header of block $B_i$ contains the nonce  $n_i$ and the merkle hash  $h_i$ as well as the block version, the double SHA-256 hash  $s_i^{\prime }$ of the header of the previous block, the target difficulty, and a timestamp which records when the block was mined.

With reference to Fig. 1, when another miner  $M_j$, who is also working on the blockchain  $C$ which has  $s_j^{\prime }$ as its previous hash, receives the communication, it will compute

$$s_j=SHA256\left(SHA256(n_i+h_i+s_j^{\prime })\right)\text{.}$$

If  $s_j$ is a valid solution according to the rules of Section  1.2.2 then miner $M_j$ will add block $B_i$ to its blockchain  $C$, abandon the block $B_j$ that it is working on and commence trying to add a block to the chain $C{B}_i$. Any transactions in $B_j$ that are not in $B_i$ will be incorporated into this new block. Importantly, miners  $M_i$ and  $M_j$ now have identical versions of the blockchain.

The existence of communication delays can upset the above process, because blocks can be discovered while communication and validation is in process. Decker and Wattenhofer  [1] measured the difference between the time that a node announced the discovery of a new block or a transaction and the time that it was received by other nodes for a period of operation in the actual Bitcoin network. They observed that the median time until a node receives a block was 6.5 s, the mean was 12.6 s and the 95th percentile of the distribution was around 40 s. Moreover, they showed that an exponential distribution provides a reasonable fit to the unconditional communication delay distribution.

Suppose all miners are working on the same version $C$ of the blockchain and miner  $M_i$ mines block $B_i$ at time $t$. It will then add $B_i$ to the blockchain  $C$ and broadcast block $B_i$ to all its peers. Suppose that this communication reaches miner  $M_j$ at time $t+{\delta }_j$ and that  $M_j$ has mined a block $B_j$ at time $t^{\prime }\in [t,t+{\delta }_j)$.

Miner  $M_j$ now knows about two versions $C{B}_i$ and $C{B}_j$ of the blockchain, which are of the same length. From the point of view of Miner  $M_j$, the blockchain has split, and we can think of the node as being in a ‘race’ to see which version of the blockchain survives.

Miner  $M_i$ will build on $C{B}_i$ because this is the version of the blockchain that it knew about first. However, miner $M_j$ knew about $C{B}_j$ first, and will attempt to build on this version of the blockchain. Other miners will work on either $C{B}_i$ or $C{B}_j$ depending on which version they heard about first. The ‘race’ situation is resolved when the next block $B^{\ast }$ is mined, say on $C{B}_i$, and communicated via the peer network. Then $C{B}_i{B}^{\ast }$ will be longer than $C{B}_j$ and all miners will eventually start building on $C{B}_i{B}^{\ast }$. It is then likely that the block $B_j$ will not be part of the longterm blockchain and it will become an orphan block. Any transactions that are in $B_j$, but not in $B_i$ or $B^{\ast }$, will be incorporated into a future block.

The above situation can get more complicated if yet more blocks are mined while communication is taking place, although this would require the conjunction of two or more low-probability events.

A rough calculation based upon the fact that it takes 600 s on average for the community to mine a block shows that we should expect that the probability that a new block is discovered while communication and validation of a block discovery is taking place is of the order of 12.6/600≈1/50, which is small but not negligible. Given that, on average, 144 blocks are mined each day, we should expect this circumstance to occur two to three times each day, which accords with the observed rate of orphan blocks  [4].

In his seminal paper proposing the Bitcoin system  [5], Nakamoto dealt with the issue of transaction integrity. He proposed that a vendor should wait until his/her payment transaction has been included in a block, and then $z$ further blocks have been added to the blockchain, before dispatching the purchased goods. The rule-of-thumb that has been adopted is to take $z=6$, which roughly corresponds to waiting for an hour before dispatching the goods. Assuming that the community can generate blocks at rate ${\lambda }_2$, Nakamoto presented a calculation of the probability $P_A$ that an attacker with enough computing power to generate blocks at rate ${\lambda }_1<{\lambda }_2$ could rewrite the history of the payment transaction by creating an alternate version of the blockchain that is longer than the community’s version. Unfortunately, Nakamoto’s calculation is incorrect, a fact that was observed by Rosenfeld in  [6].

Let the random variable $K$ be the number of blocks created by the attacker in the time that it takes the community to create $z$ blocks. Then, we can get the correct expression for the probability that the attack is successful by noting that $z+K$ is the number of Bernoulli trials required to achieve $z$ successes, with the success probability of an individual trial given by $p\equiv {\lambda }_2/({\lambda }_1+{\lambda }_2)$. It is thus a negative binomial random variable with parameters  $p$ and  $z$.

Now, using Nakamoto’s observation that, conditional on the attacker having created $K$ blocks when the vendor dispatches the goods, the probability of the attacker ever being able to build a blockchain longer than the community blockchain is ${({\lambda }_1/{\lambda }_2)}^{z-K}$ if $K<z$, and one otherwise, we arrive at the expression in equation (1) of  [6],

$$P_A=1-\sum _{k=0}^z\left(\genfrac{}{}{0ex}{}{z+k-1}{z-1}\right)(p^z{(1-p)}^k-p^k{(1-p)}^z)\text{.}$$

It follows from an analysis similar to that in Section  1.4 that, if a group of miners controls more than half of the total computer power, they can collude to rewrite the history of the transactions. There might, however, be ways for a group to gain an advantage even if it does not control a majority of the computational power.

In  [2], Eyal and Sirer proposed a strategy, called ‘selfish-mine’, and claimed that, using this strategy, a pool of colluding ‘dishonest’ miners, with a proportion $\alpha <1/2$ of the total computational power, can earn a proportion greater than $\alpha$ of the mining revenue. In this sense, a pool of miners collaborating in using the selfish-mine strategy can earn more than its fair share of the total revenue.

In brief, selfish-mine works as follows. When a pool miner mines a block, it informs its colluding pool of miners, but not the whole community of miners. Effectively, the mining pool creates a secret extension of its blockchain, which it continues to work on. The honest miners are unaware of the blocks in the secret extension and continue to mine and to publish their mined blocks and solutions according to the standard protocol.

The computational power available to the honest miners is greater than that available to the mining pool. So, with probability one, the public branch will eventually become as long as the pool’s secret extension. However it is possible that the secret extension will remain longer than the public branch in the short term. The mining pool is giving up the almost certain revenue that it would receive if it published its recently-mined block in return for a bet that its secret branch will become long enough for it to take short-term control of the mining process.

Specifically, if the lead happens to become two or more, then the pool can publish a single block every time that the honest community mines a block, and publish two blocks when its lead is eventually reduced to one. In this way the pool works on its version of the blockchain while allowing the honest community to be engaged in a fruitless search for blocks that have no chance of being included in the long-term blockchain.

The risk to the pool is that, if it has established a lead of exactly one by mining a block $B_p$, which it has kept secret, and then it is informed that the community has mined a block $B_h$, the pool may end up not getting credit for the block $B_p$. To minimise this risk, the selfish-mine strategy dictates that the pool should publish the block $B_p$ immediately it hears about $B_h$. The pool continues working on $B_p$ itself, and it hopes that at least some of the honest community will also work on $B_p$, so that the pool will get the credit for $B_p$ if an honest miner manages to extend it.

When Eyal and Sirer  [2] modelled the selfish-mine strategy, they included a parameter  $\gamma$ to denote the proportion of the honest community that work on $B_p$ after it has been published according to the scenario described above. They deduced that the pool can obtain revenue larger than its relative size provided that

$$\frac{1-\gamma }{3-2\gamma }<\alpha <\frac{1}{2}\text{.}$$

Eyal and Sirer’s analysis did not, however, take communication delay into account. Since the honest community has a head start in propagating $B_h$ before the dishonest miners have even heard about it and then there is a further communication delay before $B_p$ reaches other honest miners, our first intuition was that $\gamma$ is likely to be very low in the presence of communication delays.

In a survey of subversive mining strategies  [7], Courtois and Bahack stated (provisionally) that the claims made for efficacy of the selfish-mine strategy  [2], which was one of the block discarding attacks studied in  [8], were exaggerated. However, the conclusions presented in  [7] concerning the selfish-mine attack were not based on experimental or modelling analysis.

The purpose of the rest of this paper is to propose some simple models that explicitly take communication delay into account, which we can use to compare the behaviour of the Bitcoin network when all miners are observing the standard protocol with its behaviour if there is a pool following the selfish-mine strategy.

In the next section, we shall introduce and analyse a simple continuous-time Markov chain model that tracks the contrasting states of belief of a ‘pool’ and the ‘rest of the community’ under the assumption that the pool and the community are physically-separated so that communication between the pool and the community takes longer than communication within the pool and within the community. Effectively, we assume that there is no communication delay within the pool and within the community. We conclude that the rate of production of orphan blocks is likely to be much higher when the pool is keeping its newly-discovered blocks secret.

In the following Section  3, we study the value of Eyal and Sirer’s parameter  $\gamma$ in a model in which pool miners are distributed according to Poisson processes in the plane and the communication delay between two miners is normally distributed with a mean that depends on the distance between them.

Finally, in Section  4, we shall report results from a simulation of a network of 1000 miners, of which a fraction forms a dishonest pool, again with communication delays between all miners that depend on their spatial separation. Some conclusions and further observations are given in Section  5.