Keywords

1 Introduction

Bitcoin introduced by Nakamoto [19] is the first cryptocurrency that allows a ledger to be maintained by the public in a decentralized manner. It has a number of attractive properties including decentralization and pseudonymity. At the core of Bitcoin is a consensus protocol, called the blockchain. The blockchain is a chain-structured ledger maintained by all the participants (or miners), where records (or blocks) can only be added by the miners to the end of the chain.

A key idea of Nakamoto’s blockchain protocol to achieve consensus among distributed miners is the use of proof of work (POW), which requires the miners to solve a “cryptographic puzzle”. Advantages of POW are two folds. First, the “cryptographic puzzle” makes it more difficult for an adversary to modify the block. Second, POW helps distributed miners to synchronize in a permissionless setting. While having low efficiency and high power consumption, the blockchain protocol based on POW is still the most successful one that gains peoples acceptance wildly in practice. The main concern over the blockchain protocol based on POW is security, which has not been proven formally until Garay, Kiayias, and Leonardas [10] provide a rigorous analysis of the blockchain protocol. They model the execution of the blockchain protocol by allowing the adversary to control a concrete percentage of computing power and also to interfere with communication among miners, whereby proving that two basic properties, which are common prefix and chain quality, hold for a blockchain built on POW. Considering the effect of delay, Pass, Seeman and shelat [22] prove the security of the blockchain protocol in an asynchronous network with a-priori bounded delay \(\varDelta \), where the adversary can delay any message with at most \(\varDelta \) rounds. The security analysis in [22] holds for a relatively small delay only. Specifically the delay \(\varDelta \) should be significantly smaller than 1/np, that is \(\varDelta \ll 1/np\), where n and p denote the number of miners and the mining hardness, respectively.

Networks delay is considered to be one of the most important threats to the security of a blockchain. As shown in [6], long delays lead to increased probabilities for forking, which may break the common prefix property. Pass, Seeman and shelat demonstrate a simple attack in a fully asynchronous setting where the adversary is allowed to schedule message delivery with a long delay relative to the mining hardness. What is worse, such attacks could be deployed even when all miners are honest, which means that the adversary does not need any hashing power [10].

In the real world, however, long delays, say \(\varDelta \ge 1/np\), could be caused not only by message propagation over a “bad” asynchronous network but also by malicious attacks. Instead of attempting to corrupt a sizable fraction of miners, it would be much easier for the adversary to disrupt communications among miners. Furthermore, it is also unpractical to require all the miners’ chains to be consistent with the “main chain” due to the long delay.

In practice the adversary cannot delay messages successfully all the time. Consider the eclipse attack [14] that allow an adversary to control 32 IP addresses to monopolize all connections to and from a target bitcoin node with 85% probability. If the attack fails or the adversary loses the ability to intercept messages, blocks will be diffused to other miners at an exponentially fast rate. This naturally brings up a interesting question, that is

Is the blockchain protocol based on POW still secure in a real world asynchronous network, where long delay relative to the mining hardness, say \(\varDelta \ge 1/np\), is allowed?

Our contribution. In this paper, we focus on the effect of long delay, especially \(\varDelta \ge 1/np\), and give results that support a positive answer to the above question. Specifically, we propose a simplified model for the blockchain protocol based on POW, which captures an adversary’s ability to deliver messages maliciously in the real world. We extend the definitions of chain growth and common prefix [10, 11, 22] to allow fractions of miners’ chains to be inconsistent with the main chain. By analyzing the evolution of the main chain in a more subtle way, we prove that the common prefix property and the chain growth property still hold in our model. In addition, to illustrate the threat of long delay attack in our model, we present a concrete attack in which an adversary without any hash power may threaten the common prefix property of a blockchain protocol with certain parameters.

There are a number of subtle differences between our model and previous research in [10, 11, 22]. A detailed discussion follows.

  • Long delay attack: In our model, the upper bound of delay can be large, say \(\varDelta \ge 1/np\), and the adversary can delay a message with probability \(\alpha \in (0,1]\), meaning that the adversary may not always disrupt communications successfully in practice. Previous works consider \(\varDelta \ll 1/np\) or \(\varDelta =1\) and the adversary can always delay any message. Hence, our model is more general in capturing the adversary’s ability to deliver messages maliciously.

  • Common prefix for majority: We relax the requirements of common prefix and chain growth so that certain fractions of miners’ chains are allowed to be inconsistent with the common prefix of the main chain. Previous definitions of common prefix require all the miners’ chains be consistent with the common prefix of the main chain, which is a special case of our definition. We emphasize that such inconsistency tolerance is not only crucial to our proof but also necessary for the blockchain protocol to work in practice.

  • Honest miners: Since we only focus on the effect of delay, we assume all the miners are honest. That is, all the miners follow the protocol honestly and the adversary neither corrupts any miners nor possesses any hash power. Hence, we only need to consider the common prefix property and the chain growth property. Previous works consider adversaries which can collect a fraction of the total hash power by means of corrupting miners and thus analyze chain quality. Additionally we impose restrictions on the miners’ behavior: two consecutive blocks cannot be mined by the same miner. This restriction is reasonable in our honest miner setting, as in practice is unlikely that two consecutive blocks are mined by the same minerFootnote 1, especially when n is large whereas p is small.

In a large-scale blockchain protocol, it is hard for the adversary to collect enough computational power to mount an effective attack, where at least 1/3 computational power of all miners is usually required. Therefore, we ignore the influence of the hash power of an adversary and instead focus on attacks by disrupting communications.

Main techniques. Informally, the common prefix property states that, in addition to the last T blocks, all the miners’ chains should have the same prefix. In order to prove the common prefix property, [22] shows that there are enough “convergence opportunities” for the miners to synchronize the same chain, where the “convergence opportunities” depend on consecutive \(\varDelta \) rounds of “silence”. Here, \(\varDelta \) rounds of “silence” means no honest miners mines a block during these \(\varDelta \) rounds. If \(\varDelta \ll 1/np\), it is likely that no block is mined during \(\varDelta \) rounds. However, the challenge is that, if \(\varDelta \ge 1/np\), at least one block is expected to be mined during those rounds, which will ruin the “convergence opportunities”. So previous proof techniques cannot be applied when \(\varDelta \ge 1/np\). To solve this problem, we introduce an inconsistency tolerance parameter \(\lambda \), which is inspired by the fact that the common prefix property in the real world holds only for the majority miners. Therefore, we redefine the properties of chain growth rate and common prefix using \(\lambda \in (\frac{1}{2},1]\), which captures to what extent the common prefix property holds. Our definitions are more general and allow us to exclude the “bad” miners during \(\varDelta \) rounds of silence. Furthermore, we introduce a powerful tool called \(\textsf {Tree}_{\textsf {MC}}\) to record the state of the main chains. Unlike the \(\mathcal {F}_{tree}\) oracle in [22] which stores all the chains during the execution of the blockchain protocol, our \(\textsf {Tree}_{\textsf {MC}}\) only records the state of the main chain at the current round, which can capture the evolution of main chains in a subtle manner. Then, we show the relation between \(\textsf {Tree}_{\textsf {MC}}\) and the view of the real execution of blockchain protocol. Due to the good properties of \(\textsf {Tree}_{\textsf {MC}}\), we only need to focus on the analysis of \(\textsf {Tree}_{\textsf {MC}}\) instead of the original block chain protocol, which greatly simplified the analysis and security proof.

Related Work. Since the introduction of Bitcoin, a number of cryptocurrency, e.g., Litecoin, Zerocash [2] and Ethereum, have appeared, most of which are based on the idea of Bitcoin. Meanwhile, a series of works [3, 6, 8, 9, 12, 15, 21, 23, 26,27,28,29,30,31] analyze the security of Bitcoin under different attack scenarios and investigate the conditions under which Bitcoin achieves a game-theoretic equilibrium. Eyal and Sirer [8] propose an attack strategy called “selfish mining”, where the adversary only requires about 1/3 of the total mining power. Miller and LaViola [18] show the connection between bitcoin and probabilistic Byzantine agreement protocols. Heilman et al. [14] present eclipse attacks which allow an adversary controlling a sufficient number of IP addresses to “eclipse” a bitcoin node. As mentioned in [14], the attacker can eclipse a fraction of miners and launch N-confirmation double spending attacks without any mining power. In fact, such attacks can be extended to attacks on common prefix. For instance, the attacker can eclipse a fraction of miners in advance and launch the long delay attacks described in Sect. 7. Notice that the target block which the attacker intends to delay may be not mined by the eclipsed miners. In other words, a block can be delayed with some probability, which is the scenario captured by our model. Sompolinsky and Zohar [29] show that the bitcoin protocol with high throughput is more susceptible to double-spend attacks. In order to solve the above problem, [29] presents an algorithm called GHOST, which chooses the main chain by the heaviest subtree instead of the longest branch. Then, Natoli and Gramoli [20] propose the balance attack against POW blockchain systems, where the common prefix property can be broken by disrupting communications between subgroups of similar mining power.

Rigorous cryptographic analysis on blockchain protocol are initiated by Garay, Kiayias and Leonardas [10] and Pass, Seeman and shelat [22]. [10] abstracts the backbone protocol of Bitcoin and proves its security under the proposed model. Furthermore, [22] extends the model to an asynchronous network and shows the security of blockchain protocol with a bounded delay \(\varDelta \ll 1/np\). Kiayias and Panagiotakos [16] investigate the tradeoff between provable security and transaction processing speed. Then, Garay, Kiayias and Leonardas [11] analyze the security of blockchain protocol with variable difficulty. Pass and Shi [24] consider the sleepy model, where players can be either online or offline. Notice that it is difficult for the adversary to control large fractions of the total mining power in practice, and no such attacks has been observed to date. Hence, Badertscher et al. [1] investigates the reason why we can assume the majority of the mining power is honest or why the miners need to follow the protocol honestly. In order to overcome the problems induced by POW, such as large energy demands, another line of research focuses on the blockchain protocol based on proof of stake (POS), where the miner to issue the next block is decided by randomly selecting one of the miners proportionally to their stakes. For instance, Algorand [13], Snow White [4], Ouroboros/Ouroboros Praos [5, 17], and Thunderella [25].

2 Preliminaries

In this section, we recall the blockchain protocol, following the notations of [10, 22].

2.1 Notation

Let B denote a block. A blockchain \(C=\overrightarrow{B}\) consists of a sequence of ordered Bs and the length |C| means the number of blocks in C. Let m denote the message contained in B. \(\overrightarrow{m}\) denotes the messages in \(\overrightarrow{B}\) correspondingly. We denote by \(C_i^{r}\) the chain of miner i at round r. \(C^{\lfloor k}\) denotes the chain C that removes the last k blocks, where k is a nonnegative integer. If \(k\ge |C|\), \(C^{\lfloor k}=\varepsilon \). Let \(C_1 \preceq C_2\) denotes that \(C_1\) is a prefix of \(C_2\). \(\textsf {B}(n,k)\) denotes the binomial distribution with n trials and success probability k. \(H:{\{0,1\}}^*\rightarrow {\{0,1\}}^{\kappa }\) is a cryptographic hash function.

2.2 Blockchain Protocol

A blockchain protocol consists of two algorithms, which are \(\varPi ^V\) and \(\mathcal {C}\). \(\varPi ^V\) is a stateful algorithm, receiving security parameter \(\kappa \) and maintaining a blockchain C. C is a sequence of block B, where \(B=(h_{-1},m,r,h)\). \(h_{-1}\) is a pointer to the previous block. m is the message from the environment. r is a nonce. h is the pointer to the current block such that \(h=H(h_{-1},m,r)\). The cryptographic hash function \(H(\cdot )\) is modeled by a random oracle \(\textsf {H}(\cdot )\), which on inputs x outputs H(x). Let \(\textsf {H.ver}(\cdot ,\cdot )\) be an oracle which takes (xy) as inputs and outputs 1 if \(H(x)=y\) and 0 otherwise. The first block of a chain is called the genesis block \(B_0=(0,\bot ,0,H(0||\bot ||0))\). The algorithm \(\mathcal {C}\) takes C as input and outputs the corresponding sequence of messages \(\overrightarrow{m}\) of C. That is, \(\mathcal {C}(C)=\overrightarrow{m}\). V is an algorithm which checks the validity of \(\overrightarrow{m}\). If \(\overrightarrow{m}\) is valid, \(V(\mathcal {C}(C))\) outputs 1. In the bitcoin protocol, m contains the transaction information and V is used to check the validity of transactions.

A block \(B=(h_{-1},m,r,h)\) is valid with respect to a predecessor block \(B_{-1}=(h'_{-1},m',r',h')\) only if following conditions hold:

  • \(h_{-1}=h'\),

  • \(h=H(h_{-1},m,r)<D_p\), where \(D_p\) is the difficulty parameter.

If all blocks in C are valid and \(V(\mathcal {C}(C))=1\), we say C is valid, where the corresponding validity check algorithm is called “chain-check” algorithm.

Suppose there are n miners, where \(n=n(\kappa )\) is a polynomial function with \(\kappa \). At each round, a miner receives a message m from the environment Z and runs \(\varPi ^V\) to maintain a chain C as follows:

  • If \(V(\mathcal {C}(C)||m)\ne 1\), proceed to the next step. Otherwise, pick \(r\leftarrow {\{0,1\}}^\kappa \) randomly and compute h by querying \(\textsf {H}\) with \((h_{-1},m,r)\), where \(h_{-1}\) is the pointer of the last block of C. If \(h<D_p\), set \(C=CB\), where \(B=(h_{-1},m,r,h)\), and we say the miner succeeds in mining a new block B. The miner can query \(\textsf {H}\) at most q times before he succeeds. Then, broadcast the new chain C. In order to capture the attack that the adversary can disturb the communication among miners, C is considered as being delivered by the adversary.

  • On receiving the chains delivered by the adversary, choose the longest and valid one, say \(C'\), where the validity of blocks is checked by querying \(\textsf {H.ver}\). If \(|C'|>|C|\), replace C by \(C'\). Otherwise, go to the next round.

Note that under the random oracle model \(H(\cdot )\) is modeled by a random oracle \(\textsf {H}(\cdot )\) and a miner is allowed to query \(\textsf {H}\) for at most q times at each round, but can query \(\textsf {H.ver}\) for arbitrary times. p denotes the probability that a miner succeeds in mining a block at a round, where \(p=1-{(1-\frac{D_p}{2^{\kappa }})}^q\approx \frac{qD_p}{2^{\kappa }}\). We use p to describe the difficulty of mining in the following parts.

2.3 \(\mathcal {F}_{tree}\) Model

In this section we recall the simplified blockchain protocol with access to \(\mathcal {F}_{tree}\) oracle introduced by [22]. The \(\mathcal {F}_{tree}\) oracle maintains a tree which contains messages of all valid chains and can answer two kinds of queries, \(\textsf {Tree.extend}\) and \(\textsf {Tree.ver}\). When receiving query \(\textsf {Tree.extend}((B_0,\ldots , B_{l-1}),B)\), it checks whether \((B_0,\ldots , B_{l-1})\) is a path of the tree, where the root of the tree is the genesis block \(B_0\). If so, with probability p it extends this path with B and returns 1; Otherwise, return 0. When receiving \(\textsf {Tree.ver}(B_0,\ldots , B_l)\), it returns 1 if \((B_0,\ldots , B_l)\) is a path of the tree; Otherwise, return 0. Here, a block B only contains message m, i.e., \(B=(m)\). Then the random oracle in blockchain protocol is replaced with \(\mathcal {F}_{tree}\) and the resulting protocol is called \((\varPi _{tree},\mathcal {C}_{tree})\). The main differences between \((\varPi _{tree},\mathcal {C}_{tree})\) and \((\varPi ,\mathcal {C})\) are described as follows.

The protocol \((\varPi _{tree},\mathcal {C}_{tree})\) is also directed by an environment \(Z(1^\kappa )\). The environment activates n miners and sends each miner a message at each round. A miner receives a message m from the environment Z and runs \(\varPi _{tree}\) below:

  • If \(V_{tree}(\mathcal {C}_{tree}(C)||m)\ne 1\), proceed to the next step. Otherwise, query \(\mathcal {F}_{tree}\) with \(\textsf {Tree.extend}(C,m)\). If the oracle answers 1, a new block \(B=(m)\) is mined. Set \(C=CB\) and broadcast C.

  • When receiving the chains delivered by the adversary, choose the longest and valid one, say \(C'\), where the validity of \(C'\) can be checked by querying \(\textsf {Tree.ver}(C')\). If the oracle \(\textsf {Tree.ver}(C')\) returns 1, we say the chain is valid. If \(|C'|>|C|\), set \(C=C'\). Otherwise, go to the next round.

Under the \(\mathcal {F}_{tree}\) model, a miner is allowed to query \(\textsf {Tree.extend}\) only once at each round, but can query \(\textsf {Tree.ver}\) for arbitrary times. Note that the miners described in Sect. 2.3 can query \(\textsf {H}\) at most q times at a round and the probability of successful mining at a round is p. Therefore those queries to \(\textsf {H}\) at a round are considered as one query to \(\textsf {Tree.extend}\).

[22] shows that the security properties in \((\varPi _{tree},\mathcal {C}_{tree})\) still hold in original protocol, while the analysis is much simpler in the \(\mathcal {F}_{tree}\) model. For simplicity, we misuse \((\varPi ,\mathcal {C})\) to denote the basic blockchain protocol in the \(\mathcal {F}_{tree}\) model. Besides, the algorithm \(V_{tree}\) or V depends on the functionality of the concrete protocol. To simplify the description, we consider V which outputs 1 for all inputs. Hence, V is omitted in following parts.

3 Blockchain Model with Long Delays

Nakamoto’s blockchain protocol is proved to be secure [22], where chains broadcasted by miners may suffer at most \(\varDelta \)-bounded delays such that \(\varDelta \ll 1/np\). As discussed in Sect. 1, on one hand, it is much easier for the adversary to disturb the communications rather than collect large computational power. On the other hand, if the adversary fails to delay the target chain, the chain will be diffused to other miners immediately. To capture such scenario, our modifications for the behavior of the adversary are as below:

Execution of adversary at round r :

  • Recieving. On receiving the chains from miners, the adversary chooses which valid chains he wants to delay. But only with probability \(\alpha \) the chosen one can be delayed. Those delayed chains are marked as “delayable”. The other undelayed chains are marked as “undelayable”. Then all the chains the adversary received together with their marks and the round r are saved in a list \(\mathcal {T}\).

  • Distribution. The adversary chooses which chains in \(\mathcal {T}\) to be distributed and these chains will be received by all the miners at the next round. But the following two kinds of chains have to be distributed at the current round.

    • The chains marked as undelayable;

    • The chains having been marked as delayable for \(\varDelta \) rounds.

Note that if the adversary distributes more than one chains at a round, the adversary can adjust the order of these chains. For instance, the adversary can broadcast chains \(C_1\) and \(C_2\) in a way that \((C_1,C_2)\) to miner i but \((C_2,C_1)\) to miner j, where \(|C_1|=|C_2|\). If \(C_1\) and \(C_2\) are longer than i and j’s chains, then i accepts \(C_1\) as his main chain while j accepts \(C_2\). We emphasize that our model is in honest miner setting where the adversary does not corrupt any miners.

Remark. In practice, it is possible that some miners receive a block earlier than others due to the propagation delay in the bitcoin network. As shown in [6], the broadcast of a block follows an exponential behavior. Hence, once a block has been broadcasted to its neighbors, most miners will receive the block immediately and it is difficult for the adversary to delay anymore. It takes about 10 s for a broadcasted block to be known by almost all the miners [6, 22]. In our model, if the adversary broadcasts a block, all the miners will receive it in the next round, where the time span of a round can be 10 s. Such time span is enough for the adversary to influence the miners’ behavior. To capture the possible attacks, e.g., attacks on miner i and j described above, we allow the adversary can adjust the order of these chains, which is equivalent to the case that miner i received \(C_1\) only.

Modification to blockchain protocol. We make additional restrictions on the miners’ behavior in the blockchain protocol. That is, the miner cannot mine in a chain, the last block of which was mined by himself. In other words, the miner who has already mined a block will not execute the mining step of \(\varPi \) until he receives a new chain mined by other miners. The reason why we prevent consecutive blocks mined by the same miner is that such consecutive blocks may cause possible forks even in the honest miner setting. In addition, it is not likely that a miner (not the mining pool) can mine two consecutive blocks in practice due to the large number of miners n and the small difficulty parameter p. Hence, such a restriction is reasonable in our honest miner setting.

We emphasize that our restriction only applies to a single miner which is an independent communication node of the network and has a unit computational power. Hence, such a modification would lead to a slightly decline of the total mining power and we ignore such a mild change in the following proof for simplicity.

In our protocol, we say a miner is “being delayed” if his chain is being delayed by the adversary. Obviously, a miner being delayed will not mine a block until he accepts a new chain mined by others.

4 Properties of Our Blockchain Model

In this section we redefine the chain growth property and the common prefix property in our blockchain model.

4.1 Chain Growth

Previous definition of chain growth [22] considers the minimum increase of the length of all miners’ chains during T rounds. In our model, we consider the length increase of the majority of miners’ chains instead. Informally speaking, if the majority of chains, say, with fraction \(\lambda >\frac{1}{2}\), grows by t blocks during consecutive rounds, we say the blockchain view grows by t blocks during these rounds with majority \(\lambda \). In fact, the definition of chain growth in [22] is a special case of ours when \(\lambda =1\). It is, however, difficult to have \(\lambda =1\) in practice. Hence, our definition is more flexible in capturing the real scenario.

Let \({\texttt {view}}(\varPi , \mathcal {C},A,Z,\kappa )\) and \(|{\texttt {view}}(\varPi ,\mathcal {C},A,Z,\kappa )|\) denote the joint view of all miners and the number of rounds during the execution of \((\varPi ,\mathcal {C})\), respectively.

Definition 1

Given \({\mathtt{view}}(\varPi , \mathcal {C},A,Z,\kappa )\), we say the blockchain grows by at least t blocks with majority \(\lambda \in (\frac{1}{2},1]\) from round \(r_1\) to \(r_2\), if

$$\begin{aligned} \mathop {\text {Pr}}\limits _{i,j}[|C_j^{r_2}|-|C_i^{r_1}| \ge t]\ge \lambda , \end{aligned}$$
(1)

where the probability is taken over all the choice of \(i,j\in [n]\).

Define \({\mathtt{{chain}{} \texttt {-}\mathtt {increase}}}_{A,Z,\kappa }^{(\varPi ,\mathcal {C})}(r_1,r_2,\lambda )\) as the maximum value of t satisfying (1). That is,

$$ {\mathtt{{chain}{} \texttt {-}\mathtt {increase}}}_{A,Z,\kappa }^{(\varPi ,\mathcal {C})}(r_1,r_2,\lambda )=\textsf {max}\{t| \mathop {\text {Pr}}\limits _{i,j}[|C_j^{r_2}|-|C_i^{r_1}| \ge t]\ge \lambda \}. $$

Definition 2

The blockchain protocol \((\varPi ,\mathcal {C})\) has the chain growth rate \({g}\in \mathbb {R}\) with majority \(\lambda \in (\frac{1}{2},1]\), if there exists some constant c and negligible functions \(\epsilon _1,\epsilon _2\) such that for every \(\kappa \in \mathbb {N}, T\ge c\log (\kappa )\) and every \(r\le |{\mathtt{view}}(\varPi ,C,A,Z,\kappa )|-T\), the following holds:

$$\begin{aligned} \Pr [{\mathtt{{chain}{} \texttt {-}\mathtt {increase}}}_{A,Z,\kappa }^{(\varPi ,\mathcal {C})}(r,r+T,\lambda )\ge gT]\ge 1-\epsilon _1(\kappa )-\epsilon _2(T), \end{aligned}$$
(2)

where the probability is taken over the randomness of the protocol.

4.2 Common Prefix

Similarly, we can define common prefix as follows.

Definition 3

\({\mathtt{{common}{} \texttt {-}\mathtt {prefix}}}_{A,Z,\kappa }^{(\varPi ,\mathcal {C})}(r,k,\lambda )=1\) with majority \(\lambda \in (\frac{1}{2},1]\) if the following holds:

$$\begin{aligned} \mathop {\text {Pr}}\limits _{i,j}[{ ({C_i^r}^{\lfloor k} \preceq {C_j^r})\wedge ({C_j^r}^{\lfloor k} \preceq {C_i^r})}]\ge \lambda , \end{aligned}$$
(3)

where the probability is taken over all the choice of \(i,j\in [n]\).

Definition 4

A blockchain protocol \((\varPi ,\mathcal {C})\) satisfies the common prefix property with parameter \(\lambda \in (\frac{1}{2},1]\), if there exists some constant c and negligible function \(\epsilon _1\) and \(\epsilon _2\) such that for every \(\kappa \in \mathbb {N}, T\ge c\log (\kappa )\) and every \(r\le |{\mathtt{view}}(\varPi ,C,A,Z,\kappa )|\), the following holds:

$$\begin{aligned} \Pr [{\mathtt{{common}{} \texttt {-}\mathtt {prefix}}}_{A,Z,\kappa }^{(\varPi ,\mathcal {C})}(r,T,\lambda )=1]\ge 1-\epsilon _1(\kappa )-\epsilon _2(T), \end{aligned}$$
(4)

where the probability is taken over the randomness of the protocol.

5 State of the Main Chain

In this section, we introduce a special tree to capture the evolution of the main chains.

5.1 Record the State of the Main Chain

During the execution of \(\varPi \), miners will “reach agreement” on some chains at each round and those chains are called the main chains. Although the main chains may not be unique at each round, only one of those chains will be the prefix of the main chain after enough rounds. Since the evolution of the main chains is closely related to chain growth and common prefix, we introduce a special tree, denoted by \(\textsf {Tree}_{\textsf {MC}}\), to record the state of the main chains, where a node of the tree is a block of a chain. \(\textsf {Tree}_{\textsf {MC}}\) is initialized to the root \(B_0\). Next, we show how to add and delete blocks at a round in \(\textsf {Tree}_{\textsf {MC}}\).

  • AddBlock: When the adversary broadcasts a chain \(C=(B_0,B_1,\ldots , B_l)\), and there exist a branch (or paths from root to leaves) \(C'\) in \(\textsf {Tree}_{\textsf {MC}}\) such that \(C'=C^{\lfloor k}\) with the smallest k, extend \(C'\) with the last k ordered blocks of C. Note that the adversary is allowed to send more than one chain at a round. That means the same leaf node of \(\textsf {Tree}_{\textsf {MC}}\) may be extended with different branches simultaneously.

  • DeleteBlock: At the end of a round (after the adversary finishes Distribution), suppose \(\textsf {Tree}_{\textsf {MC}}\) has the depth, say d. Delete “useless” blocks or forks so that only the branches Cs satisfying the following conditions remain.

    • \(|C|=d\),

    • For any \(C'\) with depth d, the last block of C was added to \(\textsf {Tree}_{\textsf {MC}}\) no later than the last block of \(C'\).

Once the adversary broadcast the chains, each miner will update his chain with the longer one, and no one will withhold the shorter chains or attempt to extend them. Hence, \(\textsf {Tree}_{\textsf {MC}}\) only records all the main chains of the undelayed miners at current round. But if a miner has a chain longer than the main chain but is delayed by the adversary, this delayed chain is not recorded in \(\textsf {Tree}_{\textsf {MC}}\).

5.2 Properties of \(\textsf {Tree}_{\textsf {MC}}\)

Obviously, all of the branches on \(\textsf {Tree}_{\textsf {MC}}\) at the end of a round are of equal depth and the depth of \(\textsf {Tree}_{\textsf {MC}}\) never decreases. Other interesting properties of \(\textsf {Tree}_{\textsf {MC}}\) are shown below.

Lemma 1

Properties of \(\textsf {Tree}_{\textsf {MC}}\).

  1. 1.

    If new blocks are successfully added to \(\textsf {Tree}_{\textsf {MC}}\) at the end of a round, then the depth of \(\textsf {Tree}_{\textsf {MC}}\) increases.

  2. 2.

    The depth of \(\textsf {Tree}_{\textsf {MC}}\) increases by at most 1 at each round.

  3. 3.

    If only one block is added to \(\textsf {Tree}_{\textsf {MC}}\) at the end of a round, then \(\textsf {Tree}_{\textsf {MC}}\) has only one branch and the depth increases by 1.

Proof

  1. 1.

    Suppose there are new blocks added to the \(\textsf {Tree}_{\textsf {MC}}\) while the depth remains unchanged. So those added blocks are useless and will be deleted at once due to DeleteBlock.

  2. 2.

    Without loss of generality, suppose the depth of \(\textsf {Tree}_{\textsf {MC}}\) at round \(r-1\) and r are d and \(d+2\), respectively. If the \((d+2)\)th block is mined by miner i, then \((d+1)\)th block must be mined by a different miner, say miner j, due to the restriction that the same miner cannot mine two consecutive blocks. Hence, miner i received miner j’s chain of length \(d+1\) from the adversary. That means there exists a round \(r'\) such that \(r'<r\) and the depth of \(\textsf {Tree}_{\textsf {MC}}\) is \(d+1\) at round \(r'\), which contradicts the fact that the depth of \(\textsf {Tree}_{\textsf {MC}}\) is d at round \(r-1\).

  3. 3.

    Suppose the depth of \(\textsf {Tree}_{\textsf {MC}}\) is d at round r and only one block, say B, is successfully added at round \(r+1\). Due to the first property, the depth increases to \(d+1\). And the length of branches without B is still d. After DeleteBlock, the useless blocks of these branches will be deleted from the tree and only the branch with depth \(d+1\) will remain.

5.3 Relation with the View of \((\varPi ,\mathcal {C})\)

\(\textsf {Tree}_{\textsf {MC}}\) records the main chains known by all the miners at current round. But there are some chains at current round which are not recorded in \(\textsf {Tree}_{\textsf {MC}}\) due to the adversarial delay. Hence, the actual view of the main chains of \((\varPi ,\mathcal {C})\) may be different from \(\textsf {Tree}_{\textsf {MC}}\). Fortunately, such difference in terms of chain growth and common prefix is negligible. Therefore, we can prove these properties of \((\varPi ,\mathcal {C})\) by analyzing \(\textsf {Tree}_{\textsf {MC}}\). The relations between \(\textsf {Tree}_{\textsf {MC}}\) and the view of \((\varPi ,\mathcal {C})\) are proven by the following lemmas. (Note that the following lemmas are all discussed after \(\textsf {Tree}_{\textsf {MC}}\) finishes the step of DeleteBlock.)

Lemma 2

Assume \(1/2<\lambda \le 1-8\alpha p\varDelta \). Let \(m^r_{delay}\) be the number of being delayed miners at round r. There exists a polynomial function poly such that

$$\begin{aligned} \Pr [m_{delay}^r>\frac{(1-\lambda )n}{4}]<e^{-poly(\kappa )}. \end{aligned}$$
(5)

Proof

Consider the case that \(r\ge \varDelta \). If a miner i is being delayed at round r, that means i succeeded in mining a delayable block from round \(r-\varDelta +1\) to round r. During these \(\varDelta \) rounds, there are \(n\varDelta \) independent events of mining, each of which is delayable with probability \(\alpha p\). So \(m^r_{delay}\sim \textsf {B}(n\varDelta ,\alpha p)\). According to the Chernoff bound, for any \(\epsilon \ge 1\), we have

$$\begin{aligned} \Pr [m_{delay}^r>(1+\epsilon )\alpha np\varDelta ]<e^{\frac{-{\epsilon } \alpha np\varDelta }{3}}. \end{aligned}$$
(6)

Let \((1+\epsilon )\alpha np\varDelta =\frac{(1-\lambda )n}{4}\) and \(1/2<\lambda \le 1-8\alpha p\varDelta \). We have \(\epsilon =\frac{1-\lambda }{4\alpha p\varDelta }-1\ge 1\). Therefore,

$$\begin{aligned} \Pr [m_{delay}^r>\frac{(1-\lambda )n}{4}]<e^{\frac{-{\epsilon } (1-\lambda )n}{12(1+\epsilon )}}\le e^{\frac{- (1-\lambda )n}{24}}, \end{aligned}$$
(7)

where the last inequality follows from \(\frac{\epsilon }{1+\epsilon }\ge \frac{1}{2}\). Since \(n=n(\kappa )\) is a polynomial function with \(\kappa \), let \(poly(\kappa )=\frac{(1-\lambda )n(\kappa )}{24}\). That completes the proof of Lemma 2.

We denote the event that \(m_{delay}^r>\frac{(1-\lambda )n}{4}\) as Over-delay in the following parts.

Lemma 3

Assume \(1/2<\lambda \le 1-8\alpha p\varDelta \). Let \(d_{tree}^r\) be the depth of \(\textsf {Tree}_{\textsf {MC}}\) at round r. We have

$$\begin{aligned} \Pr [{\mathtt{{chain}{} \texttt {-}\mathtt {increase}}}_{A,Z,\kappa }^{(\varPi ,\mathcal {C})}(r_1,r_2,\lambda )\ge d_{tree}^{r_2}-d_{tree}^{r_1}]\ge 1-2e^{-poly(\kappa )}. \end{aligned}$$
(8)

Proof

If \(|C_i^r|<d_{tree}^r\) which means there exists at least one chain of length \(d_{tree}^r\) distributed by the adversary and known to all the miners, miner i at the end of round r should have updated his state with the chain of length \(d_{tree}^r\). That is, \(|C_i^r|=d_{tree}^r\). So the event that \(|C_i^r|<d_{tree}^r\) cannot happen.

If \(|C_i^r|>d_{tree}^r\), which means \(C_i^r\) is being delayed by the adversary. Assuming that Over-delay doesn’t happen at round \(r_1\) and \(r_2\) (with probability at least \(1-2e^{-poly(\kappa )}\) due to Lemma 2), we have

$$\begin{aligned} \mathop {\text {Pr}}\limits _{i}[|C_i^r|\ne d_{tree}^r]=\frac{m_{delay}^r}{n} \le \frac{1-\lambda }{4}. \end{aligned}$$
(9)

Therefore,

$$\begin{aligned}&\ \mathop {\text {Pr}}\limits _{i,j}[|C_j^{r_2}|-|C_i^{r_1}| \ge d_{tree}^{r_2}-d_{tree}^{r_1}] \\\ge & {} \ \mathop {\text {Pr}}\limits _{i,j}[|C_j^{r_2}|-|C_i^{r_1}| = d_{tree}^{r_2}-d_{tree}^{r_1}] \\\ge & {} \ 1-\mathop {\text {Pr}}\limits _{i}[|C_i^{r_1}| \ne d_{tree}^{r_1}] - \mathop {\text {Pr}}\limits _{j}[|C_j^{r_2}| \ne d_{tree}^{r_2}] \\\ge & {} \ 1-\frac{1-\lambda }{4}-\frac{1-\lambda }{4}>\lambda . \end{aligned}$$

That means \({\texttt {chain-increase}}_{A,Z,\kappa }^{(\varPi ,\mathcal {C})}(r_1,r_2,\lambda )\ge d_{tree}^{r_2}-d_{tree}^{r_1}\), which completes the proof of the Lemma 3.

Lemma 4

Assume \(1/2<\lambda \le 1-8\alpha p\varDelta \). Let d be the depth of \(\textsf {Tree}_{\textsf {MC}}\). If all the branches of \(\textsf {Tree}_{\textsf {MC}}\) at round r have a common prefix with length \(d-T\), we have

$$\begin{aligned} \Pr [{\mathtt{{common}{} \texttt {-}\mathtt {prefix}}}_{A,Z,\kappa }^{(\varPi ,\mathcal {C})}(r,T,\lambda )=1]\ge 1-2e^{-poly(\kappa )}. \end{aligned}$$
(10)

Proof

Suppose all the branches of \(\textsf {Tree}_{\textsf {MC}}\) at round r have a common prefix with length \(d-T\). For any two branches of \(\textsf {Tree}_{\textsf {MC}}\) at round r, say \(C_{tree.1}^r\) and \(C_{tree.2}^r\), we have \(({C_{tree.1}^r}^{\lfloor T} \preceq {C_{tree.2}^r})\wedge ({C_{tree.2}^r}^{\lfloor T} \preceq {C_{tree.1}^r})\). However, not every miner’s view match with \(\textsf {Tree}_{\textsf {MC}}\). Suppose \(C_i^r\) is not a branch of \(\textsf {Tree}_{\textsf {MC}}\) at round r, which is denoted by \(C_i^r\not \subset \textsf {Tree}_{\textsf {MC}}^r\). Consider the following two cases:

  • Case 1: \(C_r^i\) is being delayed by the adversary at round r. Assume that Over-delay doesn’t happen at round r. As is discussed in the proof of Lemma 3, the probability of this case is at most \(\frac{1-\lambda }{4}\).

  • Case 2: \(C_i^r\) is not being delayed by adversary at round r. Then \(|C_i^r|=d_{tree}^r\). Suppose \(C_i^r\not \subset \textsf {Tree}_{\textsf {MC}}^r\). That is, \(C_i^r\) has been distributed by the adversary, which means the last block of \(C_i^r\) was added to \(\textsf {Tree}_{\textsf {MC}}\) due to AddBlock but then deleted due to DeleteBlock at round \(r'\le r\). Since \(d_{tree}^{r'}\ge |C_i^r|\) and \(d_{tree}^{r'}\le d_{tree}^r\) due to Lemma 1, we have \(d_{tree}^{r'}=|C_i^r|=d_{tree}^r\). Hence, there exists another branch \(C^*\) such that \(|C^*_{tree}|=d_{tree}^r\) and \(C^*_{tree}\) is added to \(\textsf {Tree}_{\textsf {MC}}\) earlier than \(C_i^r\). Let \(r^*\) denote the round at which \(C^*_{tree}\) is added. Since \(C^*_{tree}\) is distributed by the adversary at round \(r^*\) but the miner i didn’t update his state with \(C^*_{tree}\), \(C_{i}^{r^*}\) must be no shorter than \(C^*_{tree}\). Therefore, \(|C_{i}^{r^*}|=|C_i^r|=d_{tree}^r\) and \(C_{i}^{r^*}=C_i^r\). We thus conclude that \(C_i^r\) was created no later than \(r^*\) but was distributed at round \(r'>r^*\). That means, miner i was being delayed at round \(r^*\).

    Assuming that Over-delay doesn’t happen at round \(r^*\), the probability that miner i was being delayed at round \(r^*\) is at most \(\frac{1-\lambda }{4}\) due to the proof of Lemma 3. So the probability of \(C_i^r\not \subset \textsf {Tree}_{\textsf {MC}}^r\) in this case is at most \(\frac{1-\lambda }{4}\).

To sum up, on condition that Over-delay doesn’t happen at round \(r^*\) and r (with probability at least \(1-2e^{poly(\kappa )}\)), the probability that \(C_i^r\) is not a branch of \(\textsf {Tree}_{\textsf {MC}}\) at round r is

$$\begin{aligned}&\mathop {\text {Pr}}\limits _i[C_i^r\not \subset \textsf {Tree}_{\textsf {MC}}^r] \\= & {} \ \mathop {\text {Pr}}\limits _i[C_i^r\not \subset \textsf {Tree}_{\textsf {MC}}^r\wedge \text {Case 1}]+\mathop {\text {Pr}}\limits _i[C_i^r\not \subset \textsf {Tree}_{\textsf {MC}}^r\wedge \text {Case 2}] \\\le & {} \ \frac{m_{delay}^r}{n}+\frac{m_{delay}^{r^*}}{n} \\\le & {} \ \frac{1-\lambda }{4}+\frac{1-\lambda }{4}=\frac{1-\lambda }{2} \end{aligned}$$

Therefore,

$$\begin{aligned}&\ \mathop {\text {Pr}}\limits _{i,j}[({C_i^r}^{\lfloor T} \preceq {C_j^r})\wedge ({C_j^r}^{\lfloor T} \preceq {C_i^r})] \\\ge & {} \ \mathop {\text {Pr}}\limits _{i,j}[C_i^r\subset \textsf {Tree}_{\textsf {MC}}^r \wedge C_j^r\subset \textsf {Tree}_{\textsf {MC}}^r] \\\ge & {} \ 1-\mathop {\text {Pr}}\limits _{i}[C_i^r\not \subset \textsf {Tree}_{\textsf {MC}}^r]-\mathop {\text {Pr}}\limits _j[C_j^r\not \subset \textsf {Tree}_{\textsf {MC}}^r] \\\ge & {} \ 1-\frac{1-\lambda }{2}-\frac{1-\lambda }{2}=\lambda , \end{aligned}$$

which completes the proof of Lemma 4.

6 Proofs of Security

In this section we analyze the chain growth property and the common prefix property of \((\varPi ,\mathcal {C})\) using \(\textsf {Tree}_{\textsf {MC}}\).

6.1 Chain Growth

Theorem 1

(Chain growth). Assume \(1/2<\lambda \le 1-8\alpha p\varDelta \). The blockchain protocol \((\varPi ,\mathcal {C})\) has the chain growth rate \( g=\frac{(1-\delta )f}{1+f E[R_{delay}^i]}\) with majority \(\lambda \), where \(f=1-{(1-p)}^n\), \(E[R_{delay}^i]=\frac{\alpha -\alpha \omega ^{\varDelta -1}[\omega +\varDelta (1-\omega ^2)]}{1-\omega }\) and \(\omega =1-(1-\alpha )f\).

Proof

The aim of the adversary is to decrease the chain growth rate by delaying or scheduling the chain delivery. Due to Lemma 3, which shows the relation between the chain growth of \((\varPi , C)\) and that of \(\textsf {Tree}_{\textsf {MC}}\), we only need to focus on the chain growth of \(\textsf {Tree}_{\textsf {MC}}\).

It seems that the adversary can use forks to distract the hashing power of miners in order to slow the chain growth rate. However, the forks does not help in breaking the chain growth property of \(\textsf {Tree}_{\textsf {MC}}\). More precisely, consider the rounds at which two consecutive blocks are added to \(\textsf {Tree}_{\textsf {MC}}\). Once a miner successfully mined a block \(B_1\), which corresponds to chain \(C_1\), the adversary can delay it with probability \(\alpha \) for at most \(\varDelta \) rounds, and waits for the next block \(B_1'\). If \(B_1\) is delayable and the next block \(B_1'\) corresponding to \(C_1'\) is mined within \(\varDelta \) rounds, the adversary can generate a fork by broadcasting both chain \(C_1\) and \(C_1'\) simultaneously. Then \(B_1\) and \(B_1'\) can be added to \(\textsf {Tree}_{\textsf {MC}}\) such that \(B_1\) is the neighbour of \(B_1'\), and depth of \(\textsf {Tree}_{\textsf {MC}}\) grows by 1. Specifically, the adversary can broadcast \(C_1\) to a set of miners, say \(S_1\), and \(C_1'\) to the remaining miners, say \(S_1'\). Then miners in \(S_1\) will accept chain \(C_1\), while miners in \(S_1'\) will accept \(C_1'\). Let \(r_1\) be the round at which \(B_1\) and \(B_1'\) are added to \(\textsf {Tree}_{\textsf {MC}}\) and \(r_2\) be the round at which the next block \(B_2\) is mined. Notice that \(r_2-r_1\) is not influenced by the number of forks which the adversary generated at round \(r_1\), and only the number of the rounds of delays affect the chain growth rate of \(\textsf {Tree}_{\textsf {MC}}\).

Fig. 1.
figure 1

The rounds during which t consecutive blocks are added to \(\textsf {Tree}_{\textsf {MC}}\)

Consider t consecutive blocks in \(\textsf {Tree}_{\textsf {MC}}\) as shown in Fig. 1. Block \(B_0\) is added to the tree at round \(r_0\) and \(B_t\) is added at round \(r_t\). We divide those rounds from \(r_0\) to \(r_t\) into t periods, and each period consists of the rounds during which the depth of \(\textsf {Tree}_{\textsf {MC}}\) increases by 1.

Each period i consists of mining phase and delay phase. For each i, let \(B_i\) be the first block that mined in period i. The round at which block \(B_i\) is mined is the end of mining phase. Let \(R_{mine}^i\) and \(R_{delay}^i\) denotes the number of rounds of mining phase and delay phase of period i, respectively. Let \(R_{mine}=\varSigma _{i=1}^t R_{mine}^i\) and \(R_{delay}=\varSigma _{i=1}^t R_{delay}^i\). So \(R_{mine}+R_{delay}=r_t-r_0\).

Next, we show how to compute \(R_{mine}\) and \(R_{delay}\). Let \(f=1-{(1-p)}^n\) be the probability that some miner succeeds in mining a block in a round. Since \(R_{mine}^i\)s are independent geometrically distributed variables such that \(\Pr [R_{mine}^i=k]=(1-f)^{k-1}f\), the sum \(R_{mine}\) follows a negative binomial distribution \(\textsf {NB}(t,f)\). Due to Lemma 5 in Appendix A, we have

$$\begin{aligned} \Pr [R_{mine}\le \frac{(1+\delta _1)t}{f}]\ge 1-e^{-poly(\delta _1^2t)}, \end{aligned}$$
(11)

where \(0<\delta _1<1/2\).

In delay phase, if \(B_i\) is undelayable, it has to be added to \(\textsf {Tree}_{\textsf {MC}}\) at the current round and \(R_{delay}^i= 0\). Otherwise, the adversary can delay the chain for at most \(\varDelta \) rounds, \(R_{delay}^i\le \varDelta \). It is obvious that \(R_{delay}\le t\varDelta \). To get a lower upper bound, we need to consider the event that a undelayable block is mined during each delay phase. Indeed, if an undelayable block is mined within \(\varDelta \) rounds since the beginning of a delay phase, the adversary has to add such block to \(\textsf {Tree}_{\textsf {MC}}\) and the delay phase is ended. Hence, the probability distribution of \(R_{delay}^i\) is defined as follows:

$$\begin{aligned} \Pr [R_{delay}^i=k]=\left\{ \begin{aligned}&1-\alpha ,&\text { if } k=0,\\&\alpha (1-(1-\alpha )f)^{k-1}(1-\alpha )f,&\text { if } 0<k<\varDelta ,\\&\alpha (1-(1-\alpha )f)^k,&\text { if } k=\varDelta ,\\&0,&\text { otherwise.} \end{aligned} \right. \end{aligned}$$
(12)

So we have

$$\begin{aligned} E[R_{delay}^i]= & {} \alpha (1-(1-\alpha )f)^{\varDelta }\varDelta +\sum _{k=1}^{\varDelta -1}k\alpha (1-(1-\alpha )f)^{k-1}(1-\alpha )f \\= & {} \frac{\alpha -\alpha \omega ^{\varDelta -1}[\omega +\varDelta (1-\omega ^2)]}{1-\omega }, \end{aligned}$$

where \(\omega =1-(1-\alpha )f\).

Since \(R_{delay}^i\)s are independent random variables with the same distribution, the expectation \(E[R_{delay}]=\sum _{i=1}^{t} E[R_{delay}^i]=tE[R_{delay}^i]\). Using the Chernoff bound, we get

$$\begin{aligned} \Pr [R_{delay}<(1+\delta _2)tE[R_{delay}^i]\!]>1- e^{-\frac{\delta _2^2tE[R_{delay}^i]}{3}}, \text { for } 0\le \delta _2\le 1. \end{aligned}$$
(13)

So on the condition that (11) and (13) hold, the chain growth rate of \(\textsf {Tree}_{\textsf {MC}}\) is

$$\begin{aligned} g>\frac{t}{R_{mine}+R_{delay}}=\frac{t}{\frac{(1+\delta _1)t}{f}+(1+\delta _2)t E[R_{delay}^i] }=\frac{(1-\delta )f}{1+f E[R_{delay}^i]}, \end{aligned}$$
(14)

where \(\delta \) is decided by picking sufficiently small \(\delta _1\) and \(\delta _2\).

Due to Lemma 3, the view of \((\varPi ,\mathcal {C})\) has chain growth g with majority \(\lambda \) with probability at least \(1-2e^{-poly(\kappa )}\) conditioned on that (11) and (13) hold. Therefore, given the view of \((\varPi ,\mathcal {C})\), we have

$$\begin{aligned}&\Pr [{\texttt {chain-increase}}_{A,Z,\kappa }^{(\varPi ,\mathcal {C})}(r,r+T,\lambda )\ge gT] \\\ge & {} 1-2e^{-poly(\kappa )}-e^{-poly(\delta _1^2T)}-e^{-\frac{\delta _2^2TE[R_{delay}^i]}{3}}, \end{aligned}$$

which completes the proof of Theorem 1.

Remark. If \(\alpha =1\), then \(E[R_{delay}^i]=\varDelta \) and the chain growth rate is \(\frac{(1-\delta )f}{1+f\varDelta }\), which is the same as that of [22].

6.2 Common Prefix

Theorem 2

(Common prefix). Assume \(0<\alpha <1-np\) and \(1/2<\lambda \le 1-8\alpha p\varDelta \). The blockchain protocol \((\varPi ,\mathcal {C})\) satisfies the common prefix property with parameter \(\lambda \).

Proof

Due to Lemma 4, it remains to prove that \(\textsf {Tree}_{\textsf {MC}}\) have the common prefix property. Suppose the adversary’s goal is to break the common prefix of \(\textsf {Tree}_{\textsf {MC}}\) with depth \(d+T\). That is, the adversary aims to make the length of the common prefix of all branches in \(\textsf {Tree}_{\textsf {MC}}\) at most \(d-1\).

Note that the depth of \(\textsf {Tree}_{\textsf {MC}}\) can increase by 1 at most at each round due to Lemma 1. Therefore, in order to generate a fork in \(\textsf {Tree}_{\textsf {MC}}\), the adversary has to broadcast more than one blocks in a round. If only one block is broadcasted, there will be only one branch in \(\textsf {Tree}_{\textsf {MC}}\) according to Lemma 1 and the adversary fails to generate a fork.

In order to capture the attack for common prefix, we introduce the following game \(\textsf {Experiment}^{\textsf {COMM}}_{A,(\varPi ,\mathcal {C})}\), where the adversary generates a fork and tries to keep the branches of the fork as long as possible.

\(\textsf {Experiment}^{\textsf {COMM}}_{A,(\varPi ,\mathcal {C})}\): Run \((\varPi ,\mathcal {C})\). Suppose that at current round r the depth of \(\textsf {Tree}_{\textsf {MC}}\) is \(d-1\) and there is no blocks being delayed and no forks in \(\textsf {Tree}_{\textsf {MC}}\). Then the adversary A tries to generate a fork and extend the length of forks as follows.

  1. 1.

    Wait for new blocks to be mined. If the new block or blocks are mined at some round \(r'\) such that \(r'>r\).

    • If more than one block are mined in the same round \(r'\), A broadcasts the corresponding chains and goes to step 3. That means a fork is generated and recorded in \(\textsf {Tree}_{\textsf {MC}}\).

    • If only one block, say B, is mined,

      • If B is delayable, A delays the corresponding chain, say \(C_1\), and goes to step 2;

      • Otherwise, go to step 1.

  2. 2.

    A tries to delay \(C_1\) as long as possible. During these rounds of delays, A tries to generate a fork by “collecting” new blocks. If no block have been mined during these rounds, A fails to generate a fork and goes to step 1. Otherwise, go to step 3.

  3. 3.

    A tries to keep the fork of \(\textsf {Tree}_{\textsf {MC}}\) as long as possible. If at least two branches of the fork are extended with T blocks, we say the adversary wins the common prefix game.

Since the adversary can always keep waiting and trying until a fork is created (in step 1 and step 2), the common prefix property is measured by the success probability of A in step 3.

Next, we consider a special event called converge which results in the failure of A. Suppose the depth of \(\textsf {Tree}_{\textsf {MC}}\) increases to l at round r. Let \(B^*\) be the first block mined after round r and let \(r^*\) denote the round at which \(B^*\) is mined. The event converge satisfies the following conditions.

  1. 1.

    Only one miner succeeds in mining at round \(r^*\).

  2. 2.

    The chain \(C^*\) which \(B^*\) lies in is undelayable, or \(C^*\) is delayable while there is no new block mined in following \(\varDelta \) rounds.

Note that if the event converge happens in step 3, then the depth of \(\textsf {Tree}_{\textsf {MC}}\) increases by 1, e.g., from l to \(l+1\).

When the depth of \(\textsf {Tree}_{\textsf {MC}}\) increases to l at round r, the chains of all the miners are of length l. (Notice that the \((l+1)\)th block can be mined only if a chain of length l is distributed). Then, if only one miner succeeds in \(r^*\) and generates an undelayable chain \(C^*\), \(C^*\) will be the unique chain in \(\textsf {Tree}_{\textsf {MC}}\) and A fails to extend the fork. If \(C^*\) is undelayable and there is no new block mined in following \(\varDelta \) rounds, A fails too.

Conditioned on that there exists some miner succeeding at round \(r^*\), the probability of condition 1 is

$$\begin{aligned} \frac{np{(1-p)}^{n-1}}{1-{(1-p)}^n}>\frac{np{(1-p)}^{n-1}}{np}={(1-p)}^{n-1}>1-np \end{aligned}$$
(15)

The probability of condition 2 is

$$\begin{aligned} 1-\alpha +\alpha {(1-p)}^{n\varDelta }>1-\alpha +\alpha (1-np\varDelta )=1-\alpha np\varDelta \end{aligned}$$
(16)

Therefore,

$$\begin{aligned} Pr[\mathbf converge ]>(1-np)(1-\alpha np\varDelta )>1-np(1+\alpha \varDelta ) \end{aligned}$$
(17)

The adversary can keep the fork for consecutive T blocks only if converge does not happen for consecutive T times, the probability of which is at most \((np(1+\alpha \varDelta ))^T\). So the probability that \(\textsf {Tree}_{\textsf {MC}}\) has a common prefix with depth \(d-T\) is at least \(1-(np(1+\alpha \varDelta ))^T\).

If \(\varDelta \le 1/np\), considering the assumption \(\alpha <1-np\), we have

$$\begin{aligned} np(1+\alpha \varDelta )<np(1+\frac{1-np}{np})=1 \end{aligned}$$
(18)

If \(\varDelta >1/np\), the equality (16) can be replaced with \(1-\alpha +\alpha {(1-p)}^{n\varDelta }>1-\alpha \), and the probability that \(\textsf {Tree}_{\textsf {MC}}\) has a common prefix with depth \(d-T\) is at least \(1-{(\alpha +np)}^T\), where \(\alpha +np<1\).

To sum up, the probability that \(\textsf {Tree}_{\textsf {MC}}\) has a common prefix path with depth \(d-T\) is at least \(1-negl(T)\), where negl is a negligible function. Due to Lemma 4, the view of \((\varPi ,\mathcal {C})\) satisfies \({\texttt {common-prefix}}_{A,Z,\kappa }^{(\varPi ,\mathcal {C})}(r,T,\lambda )=1\) with probability at least \(1-2e^{-poly(\kappa )}\). Therefore, given the view of \((\varPi ,\mathcal {C})\), we have

$$\begin{aligned} \Pr [{\texttt {common-prefix}}_{A,Z,\kappa }^{(\varPi ,\mathcal {C})}(r,T,\lambda )=1]\ge 1-2e^{-poly(\kappa )}-negl(T), \end{aligned}$$

which completes the proof of Theorem 2.

7 Long Delay Attack on Common Prefix

7.1 Long Delay Attack

Note that Theorem 2 is an asymptotic result, which means the common prefix property can hold when T is large enough. To illustrate the threat of long delay attack comprehensively, we present a concrete attack on the common prefix of \(\textsf {Tree}_{\textsf {MC}}\) when \(\varDelta \) and \(\alpha \) are “too” large relative to a fixed T.

Fig. 2.
figure 2

For \(\alpha =0.8\) and \(T=6\), the success probability increases as \(\varDelta \) gets larger. In particular, the success probability grows much faster when \(\varDelta >60\) (10 min). When \(\varDelta >120\) (20 min), the success probability can reach about \(1\%\).

Fig. 3.
figure 3

For \(\varDelta =60\) (10 min, the expected time of mining a block) and \(T=6\), the success probability increases as the probability of delay \(\alpha \) get larger. As shown in the figure, the success probability increases much faster when \(\alpha >0.7\).

Fig. 4.
figure 4

For \(\varDelta =60\) (10 min) and \(\alpha =0.8\), the success probability decreases as T gets larger. In particular, when \(T\ge 6\), the success probability becomes extremely small.

Suppose that \(\textsf {Tree}_{\textsf {MC}}\) has a fork with two branchesFootnote 2 of depth 1, which lies in two chains, say chain A and chain B, respectively, and half of the miners accepted chain A and the other half accepted chain B. Then the adversary aims to increase the length of the two branches by T. Note that once the adversary need to broadcast two chains, he distributes in a way that the number of miners which accept one chain equals to that of miners which accepts the other chain. More details of the attack and related analysis are described in Appendix B. The success probability of such attack is

$$\begin{aligned} {(\frac{f}{4}+(\alpha +\frac{f(1-2\alpha )}{4})\frac{f(1-{p_{next}^{\varDelta }})}{2-2p_{next}})}^T \end{aligned}$$
(19)

where \(p_{next}\approx \frac{(2-f(1-\alpha ))(2-f)}{4}\).

For an experimental interpretation of the success probability of the attack, the parameters are set as follows: The time span of a round for full interaction is set to 10s. Since the expected time to mine a block is about 10 min, the probability of all the miners succeeding in mining per round is about \(f=1/60\). Considering \(n=10^5\) miners in the network, we have \(p\approx f/n\approx 1.67\times 10^{-7}\). Let \(\lambda =99.8\%\), which satisfies the assumption \(1/2<\lambda \le 1-8\alpha p \varDelta \) if \(\varDelta <1.5\times 10^3\) (about 4.2 h). In this case, the common prefix of \(\textsf {Tree}_{\textsf {MC}}\) is the same as that of \((\varPi ,\mathcal {C})\) with probability at least \(99.95\%\) due to Lemma 4.

Given the above parameters, Figs. 2, 3 and 4 reflect the success probability of long delay attack when \(\varDelta \), \(\alpha \) and T varies. As shown in those figures, the adversary without any hash power may threaten the common prefix property of blockchain protocol especially when \(\varDelta \) and \(\alpha \) are too large relative to the fixed T.

7.2 Balance Attack

Our attack is reminiscent of the balance attacks introduced by [20], since both attacks can create or maintain forks by splitting honest miners into subgroups of similar mining power. Main differences between the original balance attack in [20] and ours are as follows.

  • The goal of the original balance attack is to make the target branch selected as the main chain, while the goal of ours is to maintain the forks for as long as possible.

  • The attacker in the original balance attack requires a fraction, say 20%, of mining power to launch attack, while our attack as well as N-confirmation double spending attack in [14] does not require any mining power.

  • The original balance attack disrupts the communication between subgroups by delaying messages and those isolated subgroups mine their own blockchains independently. Our attack delays the new block (or blockchain) as soon as it is successfully mined, e.g., the attacker “eclipses” the miner which mines a new block. Then the attacker delivers different blockchains to different subgroups once he obtains enough blockchains.

According to Theorem 5 of [20], we can evaluate the effectiveness of balance attack on bitcoin protocol. Table 1 shows the time of delays (in minutes) required by the original balance attack and ours, where we only consider the ideal case for the attacker of balance attack. More precisely, we assume that all the blocks mined in balance attack can be added to the main chain. For more details of balance attack, we refer to [20].

Table 1. Delays for balance attack and our long delay attack (minutes). \(f=1/60\) and \(T=6\). \(\epsilon \) denotes the success probability of the attack. \(\rho \) denotes the fraction of mining power owned by the adversary in balance attack. \(\alpha \) denotes the probability of delay in our attack. “-” denotes that the corresponding success probability cannot be achieved. For example, the maximum success probability of our attack is about 0.55 when \(\alpha =0.95\) and hence cannot reach 0.9.

Although Table 1 shows that the balance attack requires longer delays than ours, we emphasize that it is not fair to say which attack is better. First, the goals are different. Second, the balance attack only considers the case that the attacker can always delay the message successfully, while our attack considers different probability of delay. Besides, the success probability estimation of balance attack on bitcoin, which is obtained by applying the result on GHOST [20] directly, is not tight and can be further improved.