The Bitcoin Backbone Protocol: Analysis and Applications

Bitcoin, introduced in [59], is a decentralized payment system that is based on maintaining a public transaction ledger in a distributed manner. The ledger is maintained by anonymous participants (parties, “players”) called miners, executing a protocol that maintains and extends a distributed data structure called the blockchain. The protocol requires from miners to solve a “proof of work” (PoW, aka “cryptographic puzzle”—see, e.g., [5, 31, 48, 70]), which essentially amounts to brute-forcing a hash inequality based on SHA-256, in order to generate new blocks for the blockchain. The blocks that comprise the blockchain contain sets of transactions that are generated at will by owners of bitcoins, who issue transactions that credit any entity of their choice who accepts payments in bitcoin. Payers broadcast transactions and miners include the transactions they receive into the blocks they generate. Miners are rewarded for maintaining the blockchain by receiving bitcoins; it is in this manner bitcoins are created and distributed among the miners who are the first recipients of newly minted bitcoins.

An important concern in Bitcoin (or any e-payment system for that matter) is the prevention of double-spending attacks. Specifically, in the context of Bitcoin, a double-spending attack can occur when the attacker initially credits an account, receives service or goods by the account holder, but then manages to reorganize the transaction ledger so that the transaction that credits the account holder is reverted. In this way, the attacker keeps her bitcoin while receiving services and thus she is able to spend it again somewhere else.

Nakamoto [59] provides an initial set of arguments of why the Bitcoin system will prevent double-spending attacks. Specifically, he argues that if a payee waits for the transaction that gives her credit to be succeeded in the blockchain by a number of k blocks, then the probability that an attacker can build an alternative blockchain that “reorganizes” the public blockchain (which contains the credit transaction) drops exponentially with k. Nakamoto argues this by modeling the attacker and the set of honest players as two competing actors performing a random walk moving toward a single direction with probabilistic steps. He demonstrates that the k blocks the payee waits are enough to ensure a negligible (in k) probability of the attacker catching up with the honest players.

Nevertheless, the above analysis can be easily seen to be oversimplified: for example, it does not account for the fact that in Bitcoin’s decentralized setting the attacker may attempt to introduce disagreement between the honest miners, thus splitting their hashing power on different PoW instances. Nakamoto himself appeared to recognize the relevance of agreement in the context of Bitcoin, arguing in a forum post [60] that actually “Bitcoin’s basic concept” of building and exchanging a blockchain is capable of solving Byzantine agreement (BA) [57, 68] in the presence of an actively malicious adversary.¹ However, a thorough analysis establishing the exact security properties of the Bitcoin system has yet to appear.

Our results. In this article, we present the first formal treatment of Bitcoin’s core protocol. In more detail, we extract, formally describe, and analyze this protocol, which we call the Bitcoin backbone, as we describe it in a way that is versatile and extensible and can be used to solve other problems, in addition to maintaining a public transaction ledger. The Bitcoin backbone protocol is executed by players (the miners) that build a blockchain following the Bitcoin source code [61], allowing them to maintain a blockchain in a distributed fashion. The protocol is parameterized by three external functions \(V(\cdot), I(\cdot), R(\cdot)\) which we call the content validation predicate, the input contribution function, and the chain reading function, respectively. At a high level, \(V(\cdot)\) determines the proper structure of the information that is stored into the blockchain, \(I(\cdot)\) specifies how the contents of the blocks are formed by the players, and \(R(\cdot)\) determines how a blockchain is supposed to be interpreted in the context of the application. Note that the structure, contents, and interpretation of the blockchain are not important for the description of the backbone protocol and are left to be specified by the three external functions above, which are application-specific (we provide examples of these functions in Section 5).

Analysis of the Bitcoin backbone protocol. We analyze the protocol in a static setting when the participants operate in a synchronous communication network (more details below and in Section 2; see also Section 7 for an extension of the analysis to a model with bounded delays [30, 66]) in the presence of an adversary that controls a subset of the players. We assume that the protocol is executed by a fixed number of players denoted by n; note, however, that this number is not known to the protocol participants. The players themselves cannot authenticate each other and therefore there is no way to know the source of a message; we capture this by allowing the adversary to “spoof” the source address of any message that is delivered. We assume that messages are eventually delivered and all parties in the network are able to synchronize in the course of a “round.” The notion of round is not important for the description of the backbone protocol (which can also be executed in a loose and asynchronous fashion in the same way that Bitcoin works), however, it is important in terms of Bitcoin’s inherent computational assumption regarding the players’ ability to produce PoWs.

Specifically, we assume that in a single round, all parties involved are allowed the same number of queries to a cryptographic hash function, as well as to communicate with the other participants. The hash function is modeled as a random oracle [10]. For simplicity we assume a “flat model,” where all parties have the same quota of hashing queries per round, say q; the non-flat model where parties have differing hashing power capabilities can be easily captured by clustering the flat-model parties into larger virtual entities that are comprised by more than one flat-model player. In fact “mining pools” in Bitcoin can be thought of such aggregations of flat-model players. The adversary itself represents such pool as it controls \(t\lt n\) players; for this reason, the adversary’s quota per round is \(t\cdot q\) hashing queries. Note that in this setting, \(t\lt n/2\) directly corresponds to the adversary controlling strictly less than half of the system’s total “hashing power” that all players collectively harness, thus, we will use terms such as “honest majority” and “ \((1/2)\) -bounded adversary” interchangeably.

In our analysis of the Bitcoin backbone protocol, we formalize and prove three fundamental properties it possesses. The properties are quantified by the parameter f that represents the probability of a successful PoW calculation by an honest party during a round of protocol execution.

While the above security properties may seem rather abstract since they refer to properties of the data structure that is maintained distributedly by the parties, we demonstrate that they are in fact quite powerful and show that the Bitcoin backbone protocol armed with the above properties can be used as a basis for solving other problems, including the problem of distributively maintaining a “robust” public transaction ledger. In Figure 1, we show how the two properties relate to the properties of the applications that are explained below.

BA for \((1/3)\) -bounded adversaries. As a first application, we show how a randomized BA protocol can be built on top of the Bitcoin backbone protocol in a reasonably direct fashion. We instantiate the \(V(\cdot), I(\cdot), R(\cdot)\) functions so that parties form blockchains and act according to the following rules: each party i attempts to insert its own input \(v_i \in \lbrace 0,1\rbrace\) into the blockchain; a blockchain is valid only if blocks contain elements in \(\lbrace 0,1\rbrace\) ; the protocol terminates at a predetermined number of rounds where, with high probability, the blockchain has reached a sufficient length due to chain growth. Each honest party reads its local blockchain and prunes k elements from its end, returning the majority bit appearing in the resulting blockchain’s prefix. We show how the common prefix property and the chain quality property of the backbone protocol ensure Agreement and Validity (BA’s basic properties; see Section 2) with high probability, thus turning the Bitcoin backbone protocol into a probabilistic BA protocol.

Observe that for the above protocol to work, the chain quality property should ensure that a majority of blocks in the blockchain originate from the honest players (otherwise validity is lost). Our chain quality property enables this with overwhelming probability assuming the adversarial power is suitably bounded below \(1/3\) . This approach is different from Nakamoto’s proposal [60] for BA, which, as we also show, only guarantees Validity with overwhelming probability if the adversary has a negligible amount of hashing power. On the positive side, we stress that Nakamoto’s protocol fails gracefully when the adversarial power is larger and even close to \(50\%\) as Validity can be shown with constant probability (but not overwhelming, as one would wish from a randomized BA protocol).

Public transaction ledgers and BA for honest majority. Next, we focus on how a “robust public transaction ledger” can be built on top of the Bitcoin backbone. We instantiate the \(V(\cdot), I(\cdot), R(\cdot)\) functions so that parties form blockchains and act according to the following rules: each party (which in this context is called a “miner”) receives a set S of transactions on its input tape and attempts to insert those in its blockchain, omitting any transactions in S that are already included in it. (A Bitcoin transaction is, for example, a statement of the type “account A credits account B a z number of bitcoins,” which is signed using the secret key that corresponds to account A’s Bitcoin address; each account has a unique Bitcoin address.) Reading a blockchain, on the other hand, amounts to returning the total sequence of transactions that is contained in the blockchain of the miner (and note that miners may disagree about the chain they report).

We show how the common prefix property and the chain quality property ensure two properties needed by the ledger, which we call Persistence and Liveness, assuming an honest majority and arbitrary adversarial behavior. Persistence³ states that once a transaction goes more than k blocks “deep” into the blockchain of one honest player, then it will be included in every honest player’s blockchain with overwhelming probability, and it will be assigned a permanent position in the ledger. On the other hand, Liveness says that all transactions originating from honest account holders will eventually end up at a depth more than k blocks in an honest player’s blockchain, and hence the adversary cannot perform a selective denial of service attack against honest account holders. For both properties to hold we require an honest majority (i.e., that the adversary’s hashing power is strictly less than \(50\%\) ) assuming high network synchronicity (i.e., the duration of a round in terms of the number of computational steps the parties take towards finding a PoW is close to 0). If this is violated, persistence requires stricter bounds on adversarial hashing power in order to be preserved following the bounds of the common prefix property.

The problem of constructing robust transaction ledgers is related to the classical state machine replication (SMR) problem [71] (see Remark 12 for further discussion). In the context of Bitcoin, our analysis implies that the Bitcoin backbone provides an operational transaction ledger under the assumptions: (i) the adversary controls less than half of the total hashing power, and (ii) the network synchronizes much faster relative to the PoW solution rate, (iii) digital signatures cannot be forged. On the other hand, when the network desynchronizes our results cannot support that the ledger is maintained by assuming an honest majority. This negative result is consistent with the experimental analysis provided by Decker and Wattenhoffer [25], who predicted a drop below \(50\%\) in the required adversarial bound for any setting when information propagation is problematic. Our result also provides some justification for the “slow” rate of 10-minute increments used in Bitcoin block generation. Specifically, information propagation in the Bitcoin network is on the order of a few seconds so the ratio (essentially f) of this time window over the average 10-minute period is reasonably close to zero and thus transaction persistence can be shown for roughly an honest majority. On the other hand, cryptocurrencies including Litecoin, Primecoin and others, reacting to the demand to offer faster transaction processing, opted for a faster response rate (some as small as 1 minute), which results in more precarious situations, for example, \(f\gt 0.1\) , which is far from being sufficiently close to 0 and thus cannot support our analysis that a common prefix would be guaranteed by merely assuming an honest majority.

We finally note that the persistence and liveness properties we put forth and prove should not be interpreted as proofs that all Bitcoin’s objectives are met or that they embody all the properties that Bitcoin was intended to offer. For example, they do not guarantee that miners are properly incentivized to carry out the backbone protocol, and they can only offer guarantees in a setting of an honest majority amongst a fixed number of players as opposed to a setting where there is an ever changing population of parties acting rationally; see related work below as well as Section 8 for further discussion.

Next, we present a BA protocol assuming an honest majority, by suitably exploiting the properties of the robust transaction ledger above. The protocol substitutes Bitcoin’s transactions with a type of transactions that are themselves based on PoWs and carry the parties’ inputs. Hence this protocol uses PoWs in two distinct ways: for the maintenance of the ledger and for recording the users’ inputs in the ledger. We show that the ledger’s persistence implies agreement, and that liveness implies validity, because assuming the ledger is maintained for long enough, a majority of transactions originating from the honest parties will be included (despite the fact that honest parties may control a minority of blocks in the blockchain) and as a result applying the majority function on the submitted inputs will recover the honest parties’ input, if they all start with the same bit value. The protocol requires special care in the way it employs PoWs since the adversary should be incapable of “shifting” work between the two PoW tasks that it faces in each round. To solve this problem, we introduce a special strategy for PoW-based protocol composition which we call “2-for-1 PoWs.”

The Bitcoin backbone in the bounded-delay model. We sketch how to extend our analysis for the synchronous model to a bounded-delay model, where, in a nutshell, instead of messages sent in a round being guaranteed to arrive by the end of the round, there is an upper bound of \(\Delta\) rounds for each message delivery event that is unknown to the honest parties (cf. [30, 66]). This analysis is presented in Section 7. It shows that the protocol is secure provided the difficulty level is in a favorable relation with respect to \(\Delta\) . Treating \(\Delta\) as a separate parameter bounding the message passing delay enables to express the honest majority assumption also as a function of \(\Delta\) showing how approaching the \(1/2\) bound hinges on \(\Delta\) being sufficiently small.

Related work. Realizing a digital currency with a centralized entity but while achieving a degree of privacy was proposed early on by Chaum in [21]. A number of other works improved various aspects of this concept, however the approach remained centralized. Nakamoto [59] proposed the first decentralized currency system based on PoWs while relaxing the anonymity property of the payment system to mere pseudonymity. This work was followed by a multitude of other related proposals including Litecoin,⁴ Ethereum,⁵ to mention a few. Our analysis of the Bitcoin backbone covers many of these systems as well, as they are based on the same protocol with only parameter adjustments.

It is interesting to juxtapose our positive results to the results of Eyal and Sirer [32], who introduce an attack strategy called “selfish mining” that shows how the number of blocks contributed to the blockchain by an adversary can exceed the percentage of the hashing power the adversary possesses. Their results are consistent with and complementary to ours. The crux of the issue is (in our terminology) in terms of the chain quality property, as its formulation is quite permissive: in particular we show that if the adversary controls a suitably bounded amount of hashing power, then it is also suitably bounded in terms of the number of blocks it has managed to insert in the blockchain that honest players maintain. Specifically, recall that we prove that the adversary may control at most a \(\frac{t}{n-t}\) percentage of the blocks in the chain (a bound we prove it is tight). For instance, if the adversary has less than \(1/3\) of the hashing power, then it will provably control less than \(50\%\) of the blocks in the honest players’ blockchain. It follows that this does not guarantee that the rate of a party’s hashing power translates to an equal rate of rewards (recall that in Bitcoin the rewards are linearly proportional to the number of blocks that a party contributes in the chain). We define as ideal chain quality the property that for any coalition of parties (following any mining strategy) the percentage of blocks in the blockchain is exactly proportional to their collective hashing power, that is, \(\frac{t}{n}\) . The chain quality property that we prove is not ideal and the results of [32] show that in fact there is a strategy that magnifies the percentage of blocks that a malicious coalition contributes to the blockchain. Still, their selfish mining strategy in our model does worse than our bound. Closing this gap, we show a simple mining strategy that matches our upper bound and hence our chain quality result is tight⁶ assuming the number of honest parties is large.

BA aka “consensus” [57, 68] considers a set of n parties connected by reliable and authenticated pair-wise communication links and with possible conflicting initial inputs that wish to agree on a common output in the presence of the disruptive (even malicious) behavior of some of them. The problem has received a considerable amount of attention under various models. In this article, we are interested in randomized solutions to the problem (e.g., [11, 14, 33, 35, 49, 69])⁷ as in the particular setting we are in (where running time should be sublinear in the number of parties), deterministic BA algorithms are not possible. In more detail, we consider BA in the anonymous synchronous setting, that is, when processors do not have identifiers and cannot correlate messages to their sources, even across rounds, and, further, there is no trusted setup nor a limit to the number of messages delivered per round. Okun, motivated by earlier work [15], considered a slightly weaker model called “anonymous model without port awareness,” which matches the above except for imposing a limit on the number of messages per round and proved the aforementioned impossibility result, namely that deterministic algorithms are impossible for even a single failure [63, 64]. In addition, Okun showed that probabilistic BA is feasible in his setting by suitably adapting Ben-Or’s protocol [11] for the standard, non-anonymous setting (cf. [64]);⁸ the protocol, however, takes exponentially many rounds. It turns out that by additionally assuming that the parties are “port-aware” (i.e., they can correlate messages to sources across rounds), deterministic protocols are possible and some more efficient solutions were proposed [65].

The anonymous synchronous setting for BA without limits on messages per round and hence prone to Sybil attacks [28], was considered by Aspnes et al. [3] who pointed to the potential usefulness of proofs of work (e.g., [5, 31, 48, 70]) as an identity assignment tool, in such a way that the number of identities assigned to the honest and adversarial parties can be made proportional to their aggregate computational power, respectively. For example, by assuming that the adversary’s computational power is less than \(50\%\) , one of the algorithms in [3] results in a number of adversarial identities less than half of the total identities obtained. By running this procedure in a pre-processing stage, it is then suggested that a standard authenticated BA protocol could be run. Such protocols, however, would require the establishment of a consistent PKI (as well as of digital signatures), details of which are not laid out in [3].

In contrast, and as mentioned above, building on our analysis of the Bitcoin backbone protocol, we propose two BA protocols solely based on PoWs that operate in \(O(k)\) rounds with error probability \(e^{-{\mathrm{\Omega }}(k)}\) . The protocols solve BA with overwhelming probability under the assumption that the adversary controls less than \(1/3\) and \(1/2\) of the computational power, respectively. Note that our BA protocols do not require the assignment of identities to parties; furthermore, they require no cryptographic assumption other than the RO model.

The connection between Bitcoin and probabilistic BA was also considered by Miller and LaViola in [58] where they take a different approach compared to ours, by not formalizing how Bitcoin works, but rather only focusing on Nakamoto’s suggestion for BA [60] as a standalone protocol. As we observe here, and also recognized in [58], Nakamoto’s protocol does not quite solve BA since it does not satisfy validity with overwhelming probability. The exact repercussions of this fact are left open in [58], while with our analysis, we provide explicit answers regarding the transaction ledger’s actual properties and the level of security that the Bitcoin backbone realization can offer.

Finally, related to the anonymous setting, the feasibility of secure computation without authenticated links was considered by Barak et al. in [9] in a more extreme model where all messages sent by the parties are controlled by the adversary and can be tampered with and modified (i.e., not only source addresses can be “spoofed,” but also messages’ contents can be altered and messages may not be delivered). It is shown in [9] that it is possible to limit the adversary so that all it can do is to partition the network into disjoint sets, where in each set the computation is secure, and also independent of the computation in the other sets. Evidently, in such system, one cannot hope to build a global ledger.

We refer to [39] for a systematic overview of the consensus problem in the context of blockchain protocols.

Summary of differences with [40]. The most important difference in the current version of the article compared to the original one [40] is the complete rewrite of all our proofs, which now follow a much more streamlined and easier presentation. In particular, this version incorporates the concept of a typical execution that we have in fact introduced in [41] (analysis of the backbone protocol with chains of variable difficulty) and which greatly simplifies our probabilistic analysis, concentrating it on a single theorem (specifically, Theorem 4.5, showing that most executions are typical).

The present version also includes the explicit treatment of security against adaptive adversaries, showing how to reduce the analysis to the case of static adversaries (Section 4.4). We also present an analysis sketch of the Bitcoin backbone protocol in the bounded-delay model against static adversaries, where an (unknown) upper bound is imposed on message delivery (cf. Section 7). This model was considered by Pass et al. [66] and was tackled with a different proof technique; nevertheless, here, we show how our analysis can also extend to the bounded-delay setting and our proof strategy using typical executions can provide a simple security proof. This suggests that the notion of typical executions of [41] and the associated analysis approach are useful tools with the potential of wider applicability in the analysis of blockchain protocols.

In the current version, we refer to the length of the hash function output \(\kappa\) as the (sole) security parameter, and refer to \(\lambda\) —typically the number of consecutive rounds for which a statement would hold—as the tail-bounds parameter. This way, making \(\lambda\) polylogarithmic in the security parameter (e.g., \(\Omega (\log ^2(\kappa))\) ) allows us to clearly express how blockchain properties and applications (e.g., consensus) are satisfied except with negligible probability after that many rounds. Finally, we note that the model in this version makes explicit an upper bound on the number of computation and verification queries to the hash function/random oracle functionality for both honest parties and the adversary.

Organization of the article. The rest of the article is organized as follows. In Section 2, we present our model within which we formally express the Bitcoin backbone protocol and prove its basic properties. The backbone protocol builds “blockchains” based on a cryptographic hash function; we introduce notation for this data structure as well as the backbone protocol itself in Section 3, followed by its analysis in Section 4. Sections 5 and 6 are dedicated to the applications built on top of the backbone protocol—(simple) BA protocols and a robust transaction ledger, respectively. Specifically, Section 5 covers Nakamoto’s suggestion for BA as well as our solution for \(1/3\) adversarial power, while in Section 6, we present our treatment of a robust public ledger (Section 6.1) formalizing the properties of Persistence and Liveness and how they apply to Bitcoin (Section 6.2). We also include in this section (Section 6.3) our BA protocol for \(1/2\) adversarial power. The extension of our analysis to the bounded-delay model is presented in Section 7, while some directions for future research are offered in Section 8.

In this section, we define our notion of protocol execution and provide a definition of BA in our model. We will describe and analyze our protocols in a multiparty setting that employs elements from previous formulations of secure multiparty computation (MPC) (specifically, Canetti’s formulation of “real world” execution as in [17] and [18, 19, 20]). We adopt the notation and definitions of [20],⁹ while we also employ ideas regarding the formulation of synchronous, proceeding in rounds, secure MPC from [50].

Programs involved in a protocol execution. The execution of a protocol \(\Pi\) is driven by an “environment” program \(\mathcal {Z}\) that may spawn multiple instances running the protocol \(\Pi\) . The programs in question can be thought of as “interactive Turing machines” (ITM) that have communication, input and output tapes. An instance of an ITM running a certain program will be referred to as an ITM instance or ITI. The spawning of new ITI’s by an existing ITI as well as the interaction between them is at the discretion of a control program which is also an ITM and is denoted by C. The pair \((\mathcal {Z}, C)\) is called a system of ITMs [18]. As in this latter article, we will be restricting our exposition to “locally polynomial-bounded” systems of ITM’s which ensures a polynomial-time execution overall [18, Proposition 3]. Moreover, we will be using a more stringent control program C that will be forcing the environment to perform a “round-robin” participant execution sequence for a fixed set of parties.

Specifically, the execution driven by \(\mathcal {Z}\) is defined with respect to a protocol \(\Pi\) , an adversary \(\mathcal {A}\) (also an ITM) and a set of parties \(P_1,\ldots ,P_n\) ; these are hardcoded in the control program C. The protocol \({\mathrm{\Pi }}\) is defined in a “hybrid” setting and has access to two “ideal functionalities,” which are two other ITM’s to be defined below, called the random oracle and the diffusion channel. They are used as subroutines by the programs involved in the execution (the ITI’s of \(\Pi\) and \(\mathcal {A}\) ) and they are accessible by all parties once they are spawned.

Initially, the environment \(\mathcal {Z}\) is restricted by C to spawn the adversary \(\mathcal {A}\) . Each time the adversary is activated, it may send one or more messages of the form \(({\sf Corrupt}, P_i)\) to C. The control program C will register party \(P_i\) as corrupted, only provided that the environment has previously given an input of the form \(({\sf Corrupt}, P_i)\) to \(\mathcal {A}\) and that the number of corrupted parties is less or equal t, a bound that is also hardcoded in C. The first ITI party to be spawned running protocol \(\Pi\) is restricted by C to be party \(P_1\) . After a party \(P_i\) is activated, the environment is restricted to activate party \(P_{i+1}\) , except when \(P_n\) is activated in which case the next ITI to be activated is always the adversary \(\mathcal {A}\) . Note that when a corrupted party \(P_i\) is activated the adversary \(\mathcal {A}\) is activated instead.

Communication and “hashing power.”. We describe next the two functionalities that are accessible to the parties. These functionalities will reflect the parties’ ability (i) to communicate with each other and (ii) to calculate values of a hash function \(H(\cdot):\lbrace 0,1\rbrace ^*\rightarrow \lbrace 0,1\rbrace ^\kappa\) concurrently. We note that they share a state and thus they can be viewed as a single functionality, nevertheless it is convenient to describe them as separate entities.

We note that by adopting the resource-bounded computation modeling of systems of ITM’s by [20] we obviate the need of imposing a strict upper bound on the number of messages that may be transmitted by the adversary in each activation. In our setting, honest parties, at the discretion of the environment, are given sufficient time to process all messages delivered via the diffuse functionality including all messages that are injected by the adversary. This is also facilitated by the fact that the q bound that is imposed on queries to \(H(\cdot)\) is not imposed for hash verification (with foresight, the q-bound will be only imposed for hash computations during the PoW stage of the protocol).

Note that the above formulation also reflects the fact that the communication graph is not fully connected and messages are delivered through “diffusion”, a communication means that reflects Bitcoin’s peer-to-peer structure. As evidenced by the above, our adversarial model in the network is “adaptive,” meaning that the adversary is allowed to take control of parties on the fly, and “rushing,” meaning that in any given round the adversary gets to see all honest players’ messages before deciding his strategy, and, furthermore, there is no definite source information that can be guaranteed for each delivered message. Note that the adversary cannot change the contents of the messages sent by honest parties nor prevent them from being delivered as restricted by the diffuse functionality. Effectively, this parallels communication over TCP/IP in the Internet where messages between parties are delivered reliably, but nevertheless malicious parties may “spoof” the source of a message they transmit and make it appear as originating from an arbitrary party (including another honest party) in the view of the receiver. Note that the adversary is permitted to abuse the diffusion mechanism and attempt to confuse honest parties by sending and delivering inconsistent messages to them (thus diffuse does not constitute a reliable broadcast).¹¹

The parties’ inputs are provided by the environment \(\mathcal {Z}\) which also receives the parties’ outputs. Parties that receive no input from the environment remain inactive, in the sense that they will not act when their turn comes in each round. The environment activates parties in each round by writing to their input tape. Note that C forces the environment to give all parties an activation in round-robin fashion. In our exposition, we will denote by Input the input tape of each party.

The q-bounded synchronous setting. Based on the above, we will use the notation { view \(^{P,t,n}_{{\mathrm{\Pi }}, \mathcal {A},\mathcal {Z}}(z)\rbrace _{z\in \lbrace 0,1\rbrace ^*}\) to denote the random variable ensemble describing the view of party P after the completion of an execution with environment \(\mathcal {Z}\) , running protocol \({\mathrm{\Pi }}\) , and adversary \(\mathcal {A}\) , on auxiliary input \(z\in \lbrace 0,1\rbrace ^*\) . The view contains all messages sent to and received from the two functionalities the party P has access to, as well as the environment.

In our exposition, we are concerned with a “stand-alone” execution of \({\mathrm{\Pi }}\) and thus we will consider z to be fixed to \(1^\kappa\) for \(\kappa \in \mathbb {N}\) . For this reason, we will simply refer to the ensemble by view \(^{P,t,n}_{{\mathrm{\Pi }},\mathcal {A},\mathcal {Z}}\) . If n parties \(P_1,\ldots , P_n\) execute \({\mathrm{\Pi }}\) , the concatenation of the view of all parties 〈view \(^{P_i,t,n}_{{\mathrm{\Pi }}, \mathcal {A},\mathcal {Z}} \rangle _{i=1,\ldots ,n}\) is denoted by view \(^{t,n}_{{\mathrm{\Pi }}, \mathcal {A},\mathcal {Z}}\) (the views of corrupted parties, by convention, are empty). With foresight, we note that, in contrast to the standard setting where parties are aware of the number of parties executing the protocol, we are interested in protocols \({\mathrm{\Pi }}\) that do not make explicit use of the number of parties n or their identities. Further, note that because of the unauthenticated nature of the communication model the parties may never be certain about the number of participants in a protocol execution. Nonetheless note that the number of parties is fixed during the course of the protocol execution, as this is hardcoded in the control program C.

The parties’ limited ability to produce PoWs is reflected in the limit imposed to all parties in their access of the function \(H(\cdot)\) . Parties are allowed to perform a number of queries q per round. We remark that this is a “flat-model” interpretation of the parties’ computation power, where all parties are assumed equal. In the real world, different honest parties may have different “hashing power;” nevertheless, our flat-model does not sacrifice generality since one can imagine that real honest parties are simply clusters of some arbitrary number of honest flat-model parties. The adversary \(\mathcal {A}\) is allowed to perform \(t^{\prime }\cdot q\) queries per round, where \(t^{\prime }\le t\) is the number of corrupted parties. The environment \(\mathcal {Z}\) , on the other hand, is not permitted any queries to \(H(\cdot)\) . The rationale for this is that we would like to bound the “CPU power” [59] of the adversary to be proportional to the number of parties it controls while making it infeasible for them to be aided by external sources or by transferring the hashing power potentially invested in concurrent or previous protocol executions. This underscores the fact that our analysis is in the standalone setting, where a single protocol instance is executed in isolation.

We will refer to all the above restrictions on the environment, the parties and the adversary as the q-bounded synchronous setting.

Properties of protocols. In our theorems, we will be concerned with properties of protocols \(\Pi\) in the q-bounded synchronous setting. Such properties will be defined as predicates over the random variable view \(^{t,n}_{{\mathrm{\Pi }}, \mathcal {A},\mathcal {Z}}\) by quantifying over all possible adversaries \(\mathcal {A}\) and environments \(\mathcal {Z}\) that are polynomially bounded. Note that all our protocols will only satisfy properties with a small probability of error in \(\kappa\) as well as in potentially other parameters. The probability space is determined by the random choices of the random oracle functionality as well as the private coins of all ITI’s.

Note that we will only consider properties that are polynomial-time computable predicates.

BA. As a simple illustration of the formulation above we define the properties of a BA protocol.

We note that in our protocols, the participants are capable of detecting agreement and furthermore they can also detect whether other parties detect agreement, thus termination can be easily achieved by all honest parties. In the traditional cryptographic setting with no trusted setup, it is known that the problem does not have a solution if \(t \ge \frac{n}{3}\) [16]. Interestingly, one of our PoW-based BA protocols works for \(t \lt \frac{n}{2}\) (in the Random Oracle model), assuming only a simultaneous start without a PKI, the same bound that is achievable when a PKI is available.

The formulation of Validity above is intended to capture security/correctness against adaptive adversaries. The notion (specifically, the requirement that the output value be one of the honest parties’ inputs) has also been called “Strong Validity” [62], but the distinction is only important in the case of non-binary inputs. In either case, it is known that in the synchronous cryptographic setting with trusted setup the problem has a solution if and only if \(n \gt |V| t\) , where V is the input/decision domain [35]. Our PoW-based protocol also achieves this bound.

We start by introducing blockchain notation. Let \(G(\cdot),H(\cdot)\) be cryptographic hash functions with output in \(\lbrace 0,1\rbrace ^\kappa\) . A block is any triple of the form \(B=\langle s, x, ctr\rangle\) where \(s\in \lbrace 0,1\rbrace ^\kappa , x \in \lbrace 0,1\rbrace ^*, ctr\in \mathbb {N}\) are such that satisfy predicate \(\mathsf {validblock}^T_q(B)\) defined as follows:

The parameter \(T\in \mathbb {N}\) is also called the block’s difficulty level. The parameter \(q \in \mathbb {N}\) is a bound that in the Bitcoin implementation determines the size of the register ctr; in our treatment, we allow this to be arbitrary, and use it to denote the maximum allowed number of hash queries in a round. We do this for convenience and our analysis applies in a straightforward manner to the case that ctr is restricted to the range \(0 \le ctr \lt 2^{32}\) and q is independent of ctr.

A blockchain, or simply a chain is a sequence of blocks and their hash values in the form of pairs \((B,s)\) . The rightmost block and its hash value is the head of the chain, denoted \(\mathrm{head}(\mathcal {C})\) . Note that the empty string \(\varepsilon\) is also a chain; by convention we set \(\mathrm{head}(\varepsilon) = \varepsilon\) . A chain \(\mathcal {C}\) with \(\mathrm{head}(\mathcal {C}) = (\langle s^{\prime },x^{\prime },ctr^{\prime }\rangle , s)\) can be extended to a longer chain by appending a valid block \(B = \langle s, x, ctr \rangle\) and its hash value \(H(ctr, G(s,x))\) . In case \(\mathcal {C}=\varepsilon\) , by convention, any valid block of the form \(B=\langle s,x,ctr\rangle\) may extend it. Note that in this case s can be an arbitrary string¹² and we may refer to B as the “genesis” block. In either case, we have an extended chain \(\mathcal {C}_\mathsf {new} = \mathcal {C}{\color {black} || (B,s_\mathsf {new})}\) that satisfies \(\mathrm{head}(\mathcal {C}_\mathsf {new}) = (B,s_\mathsf {new})\) . Note that, for brevity, we may simply write B instead of \((B,s_\mathsf {new})\) .

The length of a chain \(\mathop {\rm len}(\mathcal {C})\) is its number of blocks. Given a chain \(\mathcal {C}\) that has length \(\mathop {\rm len}(\mathcal {C})=n\gt 0\) we can define a vector \(\mathbf {x}_\mathcal {C}= \langle x_1,\ldots , x_n\rangle\) that contains all the x-values that are stored in the chain such that \(x_i\) is the value of the ith block.

Consider a chain \(\mathcal {C}\) of length m and any nonnegative integer k. We denote by \(\mathcal {C}^{\lceil k}\) the chain resulting from the “pruning” the k rightmost blocks. Note that for \(k\ge \mathop {\rm len}(\mathcal {C})\) , \(\mathcal {C}^{\lceil k}=\varepsilon\) . If \(\mathcal {C}_1\) is a prefix of \(\mathcal {C}_2\) we write \(\mathcal {C}_1 \preceq \mathcal {C}_2\) .

We note that Bitcoin uses chains of variable difficulty, that is, the value T may change across different blocks within the same chain according to some rule that is determined by the x values stored in the chain.¹³ This is done to account for the fact that the number of parties (and hence the total hashing power of the system) is variable from round to round (as opposed to the unknown but fixed number of parties n we assume). See Section 8 for further discussion. We are now ready to describe the protocol.

In this section, we perform the analysis of the protocol presented in the previous section. We will first consider the case of static adversaries; then, in Section 4.4, we will show how an adaptive adversary reduces to a static one.

We now turn to applications of the Bitcoin backbone protocol, showing how it can be used as a basis to solve other problems. We start in this section by analyzing Nakamoto’s suggestion for solving BA, observing that it falls short of satisfying Definition 2.2; we then present our simple instantiation which solves BA. This protocol, however, only tolerates an adversarial hashing power less than \(1/3\) , which takes us to the next section, where we present Bitcoin’s essential task, namely, distributively maintaining a public transaction ledger, as well as a more elaborate BA protocol tolerating an adversarial power strictly less than \(1/2\) . For simplicity, the algorithms are specified for the case of binary inputs, but the analysis applies to the case of inputs coming from an arbitrary set V, \(|V|\gt 2\) . An overview of our applications and the way their properties depend on those of the backbone protocol was already presented in Figure 1.

We now come to the application which the Bitcoin backbone was designed to solve: maintaining a public transaction ledger. We first formally introduce this object—a “book” where transactions are recorded—and its properties, and then we show how it can be used to implement the Bitcoin ledger and BA in the honest majority setting by properly instantiating the notion of a transaction.

In this section, we show how we can extend our analysis to the bounded delay model with static adversaries. The bounded delay model is identical to the model of Section 2 with the following modifications: (1) the parameter q is fixed to be 1, (2) the diffuse functionality allows for \(\Delta\) -delays, that is, when it inspects the contents of all Receive strings, it will necessarily include messages if they are \(\Delta\) rounds old. Note that \(\Delta\) is a parameter of the execution that is unknown to the honest protocol participants (in contrast to q). Observe that now rounds are just units of time rather than message passing rounds where all messages are supposed to be delivered to honest parties from the previous round.

We now describe how to extend our analysis in the bounded delay setting. The most crucial observation is in the notion of uniquely successful round: specifically, while in the synchronous setting we were counting uniquely successful rounds, now we need to count \(\Delta\) -isolated uniquely successful rounds, where isolated means that there is a window of \(\Delta\) rounds before and after where no other successful round took place for the honest parties. (This notion is analogous to the definition of convergence opportunity in [66].) In the rest of this section, we first present formally the parts of the analysis that differ significantly and then discuss informally how the rest of the analysis can be adjusted so that analogous statements can be obtained.

In more details, we can replace the \(Y_i\) random variable by a random variable \(Y^{\prime }_i\) defined as follows. It takes values in \(\lbrace 0,1\rbrace\) and \(Y^{\prime }_i=1\) if and only if round i was uniquely successful (i.e., \(Y_i=1\) ) and \(X_j=0\) for each \(j\ne i\) such that \(|j-i|\lt \Delta\) . When \(Y^{\prime }_i=1\) , we call i a \(\Delta\) -isolated uniquely successful round (we may drop \(\Delta\) if it is clear from the context). We haveTo verify this inequality observe that the bound \(\mathbb {E}[Y_i]\ge f(1-f)\) in (2) still holds (with \(q=1\) in the definition of f) and that the event that anyone of the \(2\Delta -2\) surrounding rounds is unsuccessful is independent of the other rounds and equal to \((1-f)\) .

We remark that the definition of isolated successful round is adopted with the goal that the (easy but crucial) observation of Lemma 4.1 still holds. This is the main difference with the q-bounded model; in what follows we will argue that the same lemmas and theorems still hold, with small modifications of proofs and parameters.

To obtain a Chain Growth Lemma, cf. Lemma 4.2, although we could use the isolated uniquely successful rounds, it is more natural and gives slightly better results if we use a new Boolean variable \(X^{\prime }_i\) . For a round i, we define \(X^{\prime }_i=1\) , if \(X_i=1\) and \(X_j=0\) for each j such that \(i-\Delta \lt j\lt i\) . When \(X^{\prime }_i=1\) , we call i an isolated successful round. We have

The honest majority assumption (the part relating \(\epsilon ,f\) , and \(\delta\) ) needs to be strengthened to accommodate the decreased values of \(\mathbb {E}[Y^{\prime }_i]\) and \(\mathbb {E}[X^{\prime }_i]\) . In particular, in the inequality \(3\epsilon +3f\lt \delta\) , instead of f, the product \(\Delta f\) should appear (with an appropriate constant). This is because, in view of the expectations calculated above, we now deal with \((1-f)^\Delta \ge 1-\Delta f\) instead of \((1-f)\) .

We now discuss Chain Growth, Common Prefix, and Chain Quality.

Chain Growth. Note that Lemma 4.8 holds as is, since its proof relies only on the bounds for \(X(S)\) and \(Z(S)\) . Combining with the Chain Growth Lemma (Lemma 7.1) for this model, we obtain that the Chain Growth Property holds with parameter \(\tau =(1-\epsilon)f(1-f)^{\Delta -1}\) .

Common Prefix. To prove a Common Prefix Lemma we may follow the proof of the corresponding Lemma 4.9. The difference is that with respect to the honest parties we need to consider the set of rounds \(S=\lbrace i:r^*+\Delta \lt i\lt r-\Delta -1\rbrace\) . As already mentioned, the definition of a \(\Delta\) -isolated uniquely successful round is such that, if we substitute such rounds for uniquely successful, Lemma 4.1 holds in the bounded-delay model. Thus, we can pair each \(\Delta\) -isolated uniquely successful round in S with an adversarial block computed in \(S^{\prime }\) . To finish the proof we need to argue thatand that the additional rounds in \(S^{\prime }\) are not enough to compensate the adversary’s inferior computational power. Note that an increased lower bound for k will be required in the statement of the lemma, to absorb the decreased growth rate. This bound will be needed to obtain an analogous statement to that of Lemma 4.8. Then, the Common Prefix property for a typical execution can follow with exactly the same proof as that of Theorem 4.10.

Chain Quality. The Chain Quality property will require an increased lower bound for \(\ell\) , to account for the decreased growth rate. The proof of Theorem 4.11 should be adjusted so that it refers to isolated successful rounds instead of the (simply) successful ones. This in turn asks for the consideration of \(S^{\prime }=\lbrace r:r_1\le r\lt r_2-\Delta \rbrace\) instead of S. As in common prefix, the intuition here is that the few added rounds the adversary has in his disposal are not enough to compensate for his inferior computational power.

In this article, we presented a formal treatment of the Bitcoin backbone, the protocol used at the core of Bitcoin’s transaction ledger. We identified and proved basic properties of the backbone protocol — “common prefix,” “chain quality,” “chain growth” — and showed how they can be used as foundations for designing BA and robust public transaction ledger protocols. Our results show that a (near) honest majority among the (equally equipped) participants suffices, assuming the network synchronizes much faster than the PoW rate (i.e., f is relatively small using our notation), the proper inputs (e.g., transactions) are available to the honest majority,³¹ while the bound on the adversary for honest parties to reach agreement degenerates as f gets larger.

While these are encouraging results, we have demonstrated deviations that are of concern for the proper operation of Bitcoin. Importantly, we show that as the network ceases to synchronize fast enough compared to the PoW rate (i.e., the worst-case time that takes honest players to “hear” each other becomes substantial compared to the time it takes to solve a PoW), the honest majority property ceases to hold and the bound offered by our analysis that is required to obtain a robust transaction ledger approaches 0 as f approaches 1. Note that the effects of bad synchronization is in the maintenance of the Common Prefix property, which is the critical property for showing agreement. A tight characterization of this behavior was provided in follow-up work, [26, 45].

A second important concern is regarding the chain quality property, where our results show that if an adversary controls a hashing power ratio corresponding to some value \(t/n\) then the ratio of the blocks it can contribute to the blockchain is bounded but can be strictly bigger than \(t/n\) , approaching \(t / (n-t)\) in the worst case.

The above caveats in the two basic properties of the backbone protocol have repercussions on the Persistence and Liveness properties of the Bitcoin ledger. Firstly, they illustrate that fast information propagation amongst honest players (in relation to PoW) is essential for transaction persistence. Secondly, they show that transaction liveness becomes more fragile as the relative adversarial power \(t/(n-t)\) , gets close to 1. Note that we achieve Liveness for any relative power less than 1 but we do not assume any upper bound on the number of transactions that may be inserted in a block;³² it is obvious that the fewer blocks the honest miners get into the blockchain the harder may be for a transaction to get through. Furthermore, the fact that chain quality demonstrably fails to preserve a linear correspondence between a party’s hashing power and the ratio of its contributions to the ledger point to the fact that Bitcoin’s rewarding mechanism is not incentive compatible (cf. [32]). In fact we show that the relative hashing power \(\frac{t}{n-t}\) is the essential upper bound on chain quality for the Bitcoin backbone —a result we show also to be tight in our rushing adversary model. In this way, our results flesh out the incentive compatibility problems of the Bitcoin backbone, but, on a more positive note, they also point to the fact that an honest hashing-power majority is sufficient to maintain the public ledger (under favorable network conditions), and hence suggest that the Bitcoin protocol can work as long as the majority of the miners want it to work (without taking into account the rationality of their decision—see below for follow-up work in this direction).

The above observations apply to the setting where the number of participants is fixed. In the dynamic setting (where the number of parties running the protocol may change from round to round), given the flat model that we consider, the difficulty of the blockchain, determined by the target T, may be calibrated according to the number of players n that are active in the system. If T is set by an omniscient trusted party then the analysis carries in a straightforward way but otherwise, if T is somehow calculated by the parties themselves, the adversary can try to exploit its calculation. Note that in this case the \(\mathsf {maxvalid}\) function would need to take the difficulty’s variability into account and thus choose the “most difficult” chain (as opposed to the longest). Comparing chains based on difficulty is simply done by computing the length of a chain by counting blocks proportionally to how difficult they are (for example, a block whose difficulty is two times larger than a given difficulty value would contribute twice as much in “length”). The analysis of the Bitcoin backbone protocol with chains of variable of difficulty is the subject of our follow-up work [41].

Our security analysis is property-based, and holds for stand-alone executions. A follow-up work, which offers a simulation-based, composable treatment of the Bitcoin backbone protocol was presented by Badertscher et al. in [7]. Further, we mentioned above incentive compatibility and majority of miners wanting the protocol to work. Some follow-up work has focused on the security analysis of the Bitcoin backbone protocol in a rational setting as opposed to our cryptographically standard honest/malicious setting. In particular, in [6] Badertscher et al. formally show that assuming a natural class of incentives for the miners’ behavior—that is, rewarding them for adding blocks to the blockchain but having them pay for mining—one can reserve the honest-majority assumption as a fallback: in the setting where the utility of the miners aligns with the rational modeling they provide, the Bitcoin backbone protocol will work as expected.

Other interesting open questions include the substitution of the random oracle assumption with a suitable computational assumption, as well as the development of backbone modifications that improve its characteristics in terms of common prefix and chain quality; see [43, 44] for some work in this direction. In terms of the ledger application, transaction processing times (i.e., reducing the wait time parameter u in the Liveness property) is also an interesting question with implications to practice (since real-world payment systems benefit greatly from fast transaction confirmation and verification—see, for example, [23] for scalability issues and suggestions). In all these cases, our work offers a formal foundation that allows analyzing the security properties of “tweaks” on the backbone protocol (such as the randomization rule of [32] or the “GHOST” rule in [72] used in Ethereum³³) towards meeting the above goals.

We remark that follow-up work has examined additional backbone protocol properties, protocols and model extensions. For instance, we have already mentioned the chain growth property, introduced in [51] which enables one to abstract the blockchain feature of being able to grow unhindered by the adversary. While this is a quite simple property to prove for the Bitcoin backbone, it becomes more subtle in alternative blockchain protocols such as those using the GHOST rule [72]; see [52] for an analysis of such protocols. In [66], Pass et al. put forth a property called self-consistency, which refers to the inability of the adversary to make honest parties disagree with themselves as the protocol advances. Chain growth and self-consistency are useful if one wants to do a black-box reduction of Persistence and Liveness of the ledger to the underlying properties of the blockchain, an approach also fulfilled in the current version of this article, where the common prefix property in Section 3.2 captures self-consistency and chain growth is explicitly treated. Further, [66] also studied the robustness of transaction ledger in the bounded delay model, where messages may not be delivered at the end of a round, but there is still a certain bound within which all messages are eventually delivered, see [30]. We show how the analysis for the synchronous model extends to that setting, cf. Section 7.

Another set of interesting directions includes the development of other applications that may be built on top of the Bitcoin backbone protocol. A notable example is secure MPC [46, 73] with properties such as fairness and guaranteed output delivery (current works in this direction, for example, [2, 12, 13, 54, 55, 56] assume an idealized version of the Bitcoin system).

Further contrast between the solvability of “classical” BA and PoW-based BA in terms of setup assumptions has been established in works such as [1, 42], where it is shown how the latter can be achieved “from scratch”—that is, with no trusted setup, as opposed to the classical setting, where a PKI is required. We refer to [37] for a more detailed treatment of this subject.

The core protocol construct for BA introduced in Section 6.3 (namely composing two PoW sub-protocols, one maintaining a blockchain and the other creating PoWs to enter inputs in the blockchain that are provably in proportion to the honest parties’ computational power) has found further applications in designing blockchain protocols. Specifically, in [67] it was shown that it can be used to achieve a type of fairness in terms of rewards while in [8] it was shown that it can be used to increase transaction throughput. In [53] and later in [36] a “proof-of-stake” equivalent concept was developed that was shown it can be used to achieve similar objectives.

The authors are grateful to Giorgos Panagiotakos, Sergio Rajsbaum, Apostolos Tzinas, Hong-Sheng Zhou and Dionysis Zindros for helpful comments and discussions.

We will require the following inequalities.

We provide here the form of the Chernoff bound we use in the proofs.

In Section 7 we need more general concentration bounds. We provide here the relevant definition and bounds. (See [29, Corollary 5.2])