Bitcoin as a Transaction Ledger: A Composable Treatment
 33 Citations
 3.7k Downloads
Abstract
Bitcoin is one of the most prominent examples of a distributed cryptographic protocol that is extensively used in reality. Nonetheless, existing security proofs are propertybased, and as such they do not support composition.
In this work we put forth a universally composable treatment of the Bitcoin protocol. We specify the goal that Bitcoin aims to achieve as a ledger functionality in the (G)UC model of Canetti et al. [TCC’07]. Our ledger functionality is weaker than the one recently proposed by Kiayias, Zhou, and Zikas [EUROCRYPT’16], but unlike the latter suggestion, which is arguably not implementable given the Bitcoin assumptions, we prove that the one proposed here is securely UC realized under standard assumptions by an appropriate abstraction of Bitcoin as a UC protocol. We further show how known propertybased approaches can be cast as special instances of our treatment and how their underlying assumptions can be cast in (G)UC without restricting the environment or the adversary.
1 Introduction
Since Nakamoto first proposed Bitcoin as a decentralized cryptocurrency [28], several works have focused on analyzing and/or predicting its behavior under different attack scenarios [4, 14, 15, 18, 30, 33, 34]. However, a core question remained:
What security goal does Bitcoin achieve under what assumptions?
An intuitive answer to this question was already given in Nakamoto’s original white paper [28]: Bitcoin aims to achieve some form of consensus on a set of valid transactions. The core difference of this consensus mechanism with traditional consensus [24, 25, 26, 31] is that it does not rely on having a known (permissioned) set of participants, but everyone can join and leave at any point in time. This is often referred to as the permissionless model. Consensus in this model is achieved by shifting from the traditional assumptions on the fraction of cheating versus honest participants, to assumptions on the collective computing power of the cheating participants compared to the total computing power of the parties that support the consensus mechanism. The core idea is that in order for a party’s action to affect the system’s behavior, it needs to prove that it is investing sufficient computing resources. In Bitcoin, these resources are measured by means of solutions to a presumably computationintensive problem.
Although the above idea is implicit in [28], a formal description of Bitcoin’s goal had not been proposed or known to be achieved (and under what assumptions) until the recent works of Garay et al. [16] and Pass et al. [29]. In a nutshell, these works set forth models of computation and, in these models, an abstraction of Bitcoin as a distributed protocol, and proved that the output of this protocol satisfies certain security properties, for example the common prefix [16] or consistency [29] property. This property confirms—under the assumption that not too much of the total computing power of the system is invested in breaking it—a heuristic argument used by the Bitcoin specification: if some block makes it deep enough into the blockchain of an honest party, then it will eventually make it into the blockchain of every honest party and will never be reversed.^{1} In addition to the common prefix property, other quality properties of the output of the abstracted blockchain protocol were also defined and proved. A more detailed description of the security properties in [16, 29] is included in Sect. 4.4.
Bitcoin as a Service for Cryptographic Protocols. The main use of the Bitcoin protocol is as a decentralized monetary system with a payment mechanism, which is what it was designed for. And although the exact economic forces that guide its sustainability are still being researched, and certain rational models predict it is not a stable solution, it is a fact that Bitcoin has not met any of these pessimistic predictions for several years and it is not clear it ever will do. And even if it does, the research community has produced and is testing several alternative decentralized cryptocurrencies, e.g., [7, 9, 27], that are more functional and/or resilient to theoretic attacks than Bitcoin. Thus, it is reasonable to assume that decentralized cryptocurrencies are here to stay.
This leads to the natural questions of how one can use this new reality to improve the security and/or efficiency of cryptographic protocols? First answers to this question were given in [1, 2, 3, 8, 20, 21, 22, 23] where it was shown how Bitcoin can be used as a punishment mechanism to incentivize honest behavior in higher level cryptographic protocols such as fair lotteries, poker, and general multiparty computation. But in order to formally define and prove the security of the above constructions in a widely accepted cryptographic framework for multiparty protocols, one needs to define what it means for these protocols to be run in a world that gives them access to the Bitcoin network as a resource to improve their security. In other words, the question now becomes:
What functionality can Bitcoin provide to cryptographic protocols?
To address this question, Bentov and Kumaresan [8] introduced a model of computation in which protocols can use a punishment mechanism to incentivize adversaries to adhere to their protocol instructions. As a basis, they use the universal composition framework of Canetti [10], but the proposed modifications do not support composition and it is not clear how standard UC cryptographic protocols can be cast as protocols in that model.
In a different direction, Kiayias et al. [19] connected the above question with the original question of Bitcoin’s security goal. More concretely, they proposed identifying the resource that Bitcoin (or other decentralized cryptocurrencies) offers to cryptographic protocols as its security goal, and expressing it in a standard language compatible with the existing literature on cryptographic multiparty protocols. More specifically, they modeled the ideal guarantees as a transactionledger functionality in the universal composition framework. To be more precise, the ledger of [19] is formally a global setup in the (extended) GUC framework of Canetti et al. [11].
In a nutshell, the ledger proposed by [19] corresponds to a trusted party which keeps a state of blocks of transactions and makes it available, upon request, to any party. Furthermore, it accepts transactions from any party and records them as long as they pass an appropriate validation procedure that depends on the above publicly available state as well as other registered messages. Periodically, this ledger puts the transactions that were recently registered into a block and adds them into the state. As proved in [19], giving multiparty protocols access to such a transactionledger functionality allows for formally capturing, within the composable (G)UC framework, the mechanism of leveraging security loss with coins. The proposed ledger functionality guarantees all properties that one could expect from Bitcoin and encompasses the properties in [16, 29]. Therefore, it is natural to postulate that it is a candidate for defining the security goal of Bitcoin (and potentially other decentralized cryptocurrencies). However, the ledger functionality proposed by [19] was not accompanied by a security proof that any of the known cryptocurrencies implements it.
However, as we show, despite being a step in the right direction, the ledger proposed in [19] cannot be realized under standard assumptions about the Bitcoin network. On the positive side, we specify a new transaction ledger functionality which still guarantees all properties postulated in [16, 29], and prove that a reasonable abstraction of the Bitcoin protocol implements this ledger. In our construction, we describe Bitcoin as a UC protocol which generalizes both protocols proposed in [16, 29]. Along the way we devise a compound way of capturing in UC assumptions like the ones in [16, 29], which enables us to compare the strengths of these models.
Related Literature. The security of Bitcoin as a cryptographic protocol was previously studied by Garay et al. [16] and by Pass et al. [29] who proposed and analyzed an abstraction of the core of the Bitcoin protocol in a propertybased manner. The treatment of [16, 29] does not offer composable security guarantees. More recently, Kiayias et al. [19] proposed capturing the security goal and resource implemented by Bitcoin by means of a shared transactionledger functionality in the universal composition with global setup (GUC) framework of Canetti et al. [11]. However, the proposed ledgerfunctionality is too strong to be implementable by Bitcoin. We refer the interested reader to the full version [6] for the basic elements of these works and a discussion on simulationbased security in general. A formal comparison of our treatment with [16, 29], which indicates how both these protocols and definitions can be captured as special cases of our security definition, is given in Sect. 4.4.
Our Results. We put forth the first universally composable (simulationbased) proof of security of Bitcoin in the (G)UC model of Canetti et al. [11]. We observe that the ledger functionality proposed by Kiayas et al. [19] is too strong to be implemented by the Bitcoin protocol—in fact, by any protocol in the permissionless setting, which uses network assumptions similar to Bitcoin. Intuitively, the reason is that the functionality allows too little interference of the simulator with its state, making it impossible to emulate adversarial attacks that result, e.g., in the adversary inserting only transactions coming from parties it wants or that result in parties holding chains of different length.
Therefore, we propose an alternative ledger functionality \(\mathcal {G}_{\textsc {ledger}}\) which shares certain design properties with the proposal in [19] but which can be provably implemented by the Bitcoin protocol. As in [19], our proposed functionality can be used as a global setup to allow protocols with different sessions to make use of it, thereby enabling the ledger to be cast as shared among any protocol that wants to use it. The ledger is parametrized by a generic transaction validation predicate which enables it to capture decentralized blockchain protocols beyond Bitcoin. Our functionality allows for parties/miners to join and or leave the computation and allows for adaptive corruption.
Having defined our ledger functionality we next prove that for an appropriate validation predicate \(\mathcal {G}_{\textsc {ledger}}\) is implemented by Bitcoin assuming that miners which deviate from the Bitcoin protocol do not control a majority of the total hashing power at any point. To this end, we describe an abstraction of the Bitcoin protocol as a synchronous UC protocol. Our protocol generalizes both [16, 29]—as we argue, the protocols described in these works can be captured as instances of our protocols. The difference between these two instances is the network assumption that is used—more precisely, the assumption about knowledge on the network delay—and the assumption on the number of queries per round. To capture these assumptions in UC, we devise a methodology to formulate functionality wrappers to capture assumptions, and discuss the implications of such a method in preserving universal composability.
Our protocol works over a network of boundeddelay channels, where similar to [29], the miners are not aware of (an upper bound on) the actual delay that the network induces. We argue that such a network is strictly weaker than a network with known bounded delay, which is implicit in the synchrony assumptions of [16] (cf. Remark 1). Notwithstanding, unlike previous works, instead of starting from a complete network that offers multicast, we explain how such a network could be implemented by running the messagediffusion mechanism of the Bitcoin network (which is run over a lower level network of unicast channels). Intuitively, this network is built by every miner, upon joining the system, choosing some existing miners of its choice to use them as relaynodes.
Our security proof proposes a useful modularization of the Bitcoin protocol. Concretely, we first identify the part of the Bitcoin code which intuitively corresponds to the lottery aspect, provide an ideal UC functionality that reflects this lottery aspect, and prove that this part of the Bitcoin code realizes the proposed functionality. We then analyze the remainder of the protocol in the simpler world where the respective code that implements the lottery aspect is replaced by invocations of the corresponding functionality. Using the composition theorem, we can then immediately combine the two parts into a proof of the full protocol.
Similarly to the backbone protocol from [16] our above UC protocol description of Bitcoin relies only on proofs of work and not on digital signatures. As a result, it implements a somewhat weaker ledger, which does not guarantee that transactions submitted by honest parties will eventually make it into the blockchain.^{2} As a last result, we show that (similarly to [16]) by incorporating publickey cryptography, i.e., taking signatures into account in the validation predicate, we can implement a stronger ledger that ensures that transactions issued by honest users—i.e., users who do not sign contradicting transactions and who keep their signing keys for themselves—are guaranteed to be eventually included into the blockchain. The fact that our protocol is described in UC makes this a straightforward, modular construction using the proposed transaction ledger as a hybrid. In particular, we do not need to consider the specifics of the Bitcoin protocol in the proof of this step. This also allows us to identify the maximum (worstcase) delay a user needs to wait before being guaranteed to see its transaction on the blockchain and be assured that it will not be inverted.
2 A Composable Model for Blockchain Protocols in the Permissionless Model
In this section we describe our (G)UCbased model of execution for the Bitcoin protocol. We remark that providing such a formal model of execution forces us to make explicit all the implicit assumptions from previous works. As we lay down the theoretical framework, we will also discuss these assumptions along with their strengths and differences.
Bitcoin miners are represented as players—formally Interactive Turing Machine instances (ITIs)—in a multiparty computation. They interact which each other by exchanging messages over an unauthenticated multicast network with eventual delivery (see below) and might make queries to a common random oracle. We will assume a central adversary \(\mathcal {A}_{}\) who gets to corrupt miners and might use them to attempt to break the protocol’s security. As is common in (G)UC, the resources available to the parties are described as hybrid functionalities. Before we provide the formal specification of such functionalities, we first discuss a delicate issue that relates to the set of parties (ITIs) that might interact with an ideal functionality.

Upon receiving \((\textsc {register}, \textsf {sid})\) from some party \(p _i\) (or from \(\mathcal {A}_{}\) on behalf of a corrupted \(p_i\)), set \(\mathcal {P}= \mathcal {P}\cup \left\{ { p _i }\right\} \). Return \((\textsc {register}, \textsf {sid}, p _i)\) to the caller.

Upon receiving (deregister, \(\textsf {sid} \)) from some party \(p _i \in \mathcal {P}\), set \(\mathcal {P}:=\mathcal {P}\setminus \{p _i\}\). Return (deregister, \(\textsf {sid},p _i\)) to \(p_i\).

Upon receiving (getregistered, \(\textsf {sid} \)) from the adversary \(\mathcal {A}_{}\), the functionality returns (getregistered, \(\textsf {sid},\mathcal {P}\)) to \(\mathcal {A}_{}\).
For simplicity in the description of the functionalities, for a party \(p _i\in \mathcal {P}\) we will use \(p _i\) to refer to this party’s ID.

Upon receiving \((\textsc {register}, \textsf {sid} _C)\) from a functionality \(\mathcal {F}_{\textsc {}} \), set \(F := F \cup \{\mathcal {F}_{\textsc {}} \}\).

Upon receiving (deregister, \(\textsf {sid} _C\)) from a functionality \(\mathcal {F}_{\textsc {}} \), set \(F := F \setminus \{\mathcal {F}_{\textsc {}} \}\).

Upon receiving (getregisteredf, \(\textsf {sid} _C\)) from the adversary \(\mathcal {A}_{}\), the functionality returns (getregisteredf, \(\textsf {sid} _C, F\)) to \(\mathcal {A}_{}\).
The above three (or six in case of global setups) instructions will be part of the code of all ideal functionalities considered in this work. However, to keep the description simpler we will omit these instructions from the formal descriptions. We are now ready to formally describe each of the available functionalities.

They guarantee (reliable) delivery of messages within a delay parameter \(\varDelta \), but are otherwise specified to be of asynchronous nature (see below) and hence no protocol can rely on timings regarding the delivery of messages. The adversary might delay any message sent through such a channel, but at most by \(\varDelta \). In particular, the adversary cannot block messages. However, he can induce an arbitrary order on the messages sent to some party.

The receiver gets no information other than the messages themselves. In particular, a receiver cannot link a message to its sender nor can he observe whether or not two messages were sent from the same sender.

The channel offers no privacy guarantees. The adversary is given read access to all messages sent on the network.
Our formal description of communication with eventual delivery within the UC framework builds on ideas from [5, 13, 17]. In particular, we capture such communication by assuming for each miner \(p _{j} \in \mathcal {P}\) a multiuse unicast channel \(\mathcal {F}_{\textsc {u}\text {}\textsc {ch}}\) with receiver \(p _j\), to which any miner \(p _{i} \in \mathcal {P}\) can connect and input messages to be delivered to \(p _{j} \in \mathcal {P}\). A miner connecting to the unicast channel with receiver \(p _j\) corresponds to the above process of looking up \(p _j\) and making him one of its access points. The unicast channel does not provide any information to its receiver about who else is using it. In particular, messages are buffered but the information of who is the sender is deleted; instead, the channel creates unique independent messageIDs that are used as handles for the messages. Furthermore, the adversary—who is informed about both the content of the messages and about the handles—is allowed to delay messages by any finite amount, and allowed to deliver them in an arbitrary outoforder manner.
To ensure that the adversary cannot arbitrarily delay the delivery of messages submitted by honest parties, we use the following idea: We first turn the UC channelfunctionality to work in a “fetch message” mode, where the channel delivers the message to its intended recipient \(p _{j} \) if and only if \(p _{j} \) asks to receive it by issuing a special “fetch” command. If the adversary wishes to delay the delivery of some message with message ID \(\textsf {mid}\), he needs to submit to the channel functionality an integer value \(T_\textsf {mid} \)—the delay for message with ID \(\textsf {mid}\). This will have the effect that the channel ignores the next \(T_\textsf {mid} \) fetch attempts, and only then allows the receipt of the sender’s message. Importantly, we require that the channel does not accept more than \(\varDelta \) accumulative delay on any message. To allow the adversary freedom in scheduling the delivery of messages, we allow him to input delays more than once, which are added to the current delay amount. If the adversary wants to deliver the message in the next activation, all he needs to do is submit a negative delay. Furthermore, we allow the adversary to schedule more than one messages to be delivered in the same “fetch” command. Finally, to ensure that the adversary is able to reorder such batches of messages arbitrarily, we allow \(\mathcal {A}_{}\) to send special \((\texttt {swap},\textsf {mid},\textsf {mid} ')\) commands that have as an effect to change the order of the corresponding messages. The detailed specification of the described channels, denoted \(\mathcal {F}_{\textsc {u}\text {}\textsc {ch}}\) is provided in the full version [6]. Note that in the descriptions throughout the paper, for a vector \(\vec {M}\) we denote by the symbol  the operation which adds a new element to \({\vec {M}}\).
From Unicast to Multicast. As already mentioned, the Bitcoin protocol uses the above asynchronousandboundeddelay unicast network as a basis to achieve a multicast mechanism. A multicast functionality with bounded delay can be defined similarly to the above unicast channel. The main difference is that once a message is inserted it is recorded once for each possible receiver. The adversary can add delays to any subset of messages, but again for any message the cumulative delay cannot exceed \(\varDelta \). He is further allowed to do partial and inconsistent multicasts, i.e., where different messages are sent to different parties. This is the main difference of such a multicast network from a broadcast network. The detailed specification of the corresponding functionality \(\mathcal {F}_{\textsc {n}\text {}\textsc {mc}}\) is similar to that of \(\mathcal {F}_{\textsc {u}\text {}\textsc {ch}}\) and is provided in the full version [6]. There we also show how the simple roundbased diffusion mechanism can be used to implement a multicast mechanism from unicast channels as long as the corresponding network among honest parties stays strongly connected. (A network graph is strongly connected if there is a directed path between any two nodes in the network, where the unicast channels are seen as the directed edges from sender to receiver.)
The Random Oracle. As usual in cryptographic proofs, the queries to the hash function are modeled by assuming access to a random oracle (functionality) \(\mathcal {F}_{\textsc {ro}} \). This functionality is specified as follows: upon receiving a query \((\textsc {eval}, \textsf {sid}, x)\) from a registered party, if x has not been queried before, a value y is chosen uniformly at random from \(\{0,1\}^\kappa \) (for security parameter \(\kappa \)) and returned to the party (and the mapping (x, y) is internally stored). If x has been queried before, the corresponding y is returned.
Synchrony. Katz et al. [17], proposed a methodology for casting synchronous protocols in UC by assuming they have access to an ideal functionality \(\mathcal {G}_{\textsc {clock}} \), the clock, that allows parties to ensure that they proceed in synchronized rounds. Informally, the idea is that the clock keeps track of a round variable whose value the parties can request by sending it (clockread, \(\textsf {sid} _C\)). This value is updated only once all honest parties sent the clock a (clockupdate, \(\textsf {sid} _C\)) command.
Given such a clock, the authors of [17] describe how synchronous protocols can maintain their necessary round structure in UC: For every round \(\rho \) each party first executes all its round\(\rho \) instructions and then sends the clock a clockupdate command. Subsequently, whenever activated, it sends the clock a clockread command and does not advance to round \(\rho +1\) before it sees the clocks variable being updated. This ensures that no honest party will start round \(\rho +1\) before every honest party has completed round \(\rho \). In [19], this idea was transfered to the (G)UC setting, by assuming that the clock is a global setup. This allows for different protocols to use the same clock and is the model we will also use here. The detailed specification of \(\mathcal {G}_{\textsc {clock}} \) is given in the full version [6].
As argued in [17], in order for an eventualdelivery (aka guaranteed termination) functionality to be UC implementable by a synchronous protocol, it needs to keep track of the number of activations that an honest party gets—so that it knows when to generate output for honest parties. This requires that the protocol itself, when described as a UC interactive Turingmachine instance (ITI), has a predictable behavior when it comes to the pattern of activations that it needs before it sends the clock an update command. We capture this property in a generic manner in Definition 1.
In order to make the definition better accessible, we briefly recall the mechanics of activations in UC. In a UC protocol execution, an honest party (ITI) gets activated either by receiving an input from the environment, or by receiving a message from one of its hybridfunctionalities (or from the adversary). Any activation results in the activated ITI performing some computation on its view of the protocol and its local state and ends with either the party sending a message to some of its hybrid functionalities or sending an output to the environment, or not sending any message. In either of this case, the party loses the activation.^{6}
For any given protocol execution, we define the honestinput sequence \(\vec {\mathcal {I}}_H \) to consist of all inputs that the environment gives to honest parties in the given execution (in the order that they were given) along with the identity of the party who received the input. For an execution in which the environment has given m inputs to the honest parties in total, \(\vec {\mathcal {I}}_H \) is a vector of the form \(((x_1,\texttt {pid} _1),\ldots ,(x_m,\texttt {pid} _m))\), where \(x_i\) is the ith input that was given in this execution, and \(\texttt {pid} _i\) is the corresponding party who received this input. We further define the timed honestinput sequence, denoted as \(\vec {\mathcal {I}}^T_H \), to be the honestinput sequence augmented with the respective clock time when an input was given. If the timed honestinput sequence of an execution is \(\vec {\mathcal {I}}^T_H =((x_1,\texttt {pid} _1,\tau _1),\ldots ,(x_m,\texttt {pid} _m,\tau _m))\), this means that \(((x_1,\texttt {pid} _1),\ldots ,(x_m,\texttt {pid} _m))\) is the honestinput sequence corresponding to this execution, and for each \(i\in [n]\), \(\tau _i\) is the time of the global clock when input \(x_i\) was handed to \(\texttt {pid} _i\).
Definition 1
A \(\mathcal {G}_{\textsc {clock}}\)hybrid protocol \(\varPi \) has a predictable synchronization pattern iff there exist an algorithm \(\texttt {predict}\text {}{} \texttt {time} _\varPi (\cdot )\) such that for any possible execution of \(\varPi \) (i.e., for any adversary and environment, and any choice of random coins) the following holds: If \(\vec {\mathcal {I}}^T_H =((x_1,\texttt {pid} _1,\tau _1),\ldots ,(x_m,\texttt {pid} _m,\tau _m))\) is the corresponding timed honestinput sequence for this execution, then for any \(i\in [m1]: \texttt {predict}\text {}{} \texttt {time} _\varPi ((x_1,\texttt {pid} _1,\tau _1),\ldots ,(x_i,\texttt {pid} _i,\tau _i))=\tau _{i+1}.\)
As we argue, all synchronous protocol described in this work are designed to have a predictable synchronization pattern.
Assumptions as UC Functionality Wrappers. In order to prove statements about cryptographic protocols one often makes assumptions about what the environment can or cannot do. For example, a standard assumption in [16, 29] is that in each round the adversary cannot do more calls to the random oracle than what the honest parties (collectively) can do. This can be captured by assuming a restricted environment and adversary which balances the amount of times that the adversary queries the random oracle. In a propertybased treatment such as [16, 29] this assumptions is typically acceptable.
However, in a simulationbased definition, restricting the class of adversaries and environments in a security statement means that we can no longer generically apply the composition theorem, which dismisses one of the major advantages of using simulationbased security in the first place. Therefore, instead of restricting the class of environments/adversaries, here we take a different approach to capture the fact that the adversary’s access to the RO is restricted with respect to that of honest parties. In particular, we capture this assumption by means of a functionality wrapper that wraps the RO functionality and forces the above restrictions on the adversary, for example by assigning to each corrupted party at most q activations per round for a parameter q. To keep track of rounds the functionality registers with the global clock \(\mathcal {G}_{\textsc {clock}} \). We refer the reader to [6] for a detailed specification of such a wrapped randomoracle functionality \(\mathcal {W}^{q}(\mathcal {F}_{\textsc {ro}})\).
Remark 1
(Functionally Blackbox Use of the Network (Delay)). A key difference between the models in [16, 29] is that in the latter the parties do not know any bound on the delay of the network. In particular, although both models are in the synchronous setting, in [29] a party in the protocol does not know when to expect a message which was sent to it in the previous round. Using terminology from [32], the protocol uses the channel in a functionally blackbox manner. Restricting to such protocols—a restriction which we also adopt in this work—is in fact implying a weaker assumption on the protocol than standard (known) boundeddelay channel. Intuitively the reason is that no such protocol can realize a boundeddelay network with a known upper bound (unless it sacrifices termination) since the protocol cannot decide whether or not the bound has been reached.
3 The TransactionLedger Functionality
In this section we describe our ledger functionality, denoted as \(\mathcal {G}_{\textsc {ledger}} \), which can, for example, be achieved by (a UC version) of the Bitcoin protocol. As in [19], our ledger is parametrized by certain algorithms/predicates that allow us to capture a more general version of a ledger which can be instantiated by various cryptocurrencies. Since our abstraction of the Bitcoin protocol is in the synchronous model of computation (this is consistent with known approaches in the cryptographic literature), our ledger is also designed for this synchronous model. Nonetheless, several of our modeling choices are made with the foresight of removing or limiting the use of the clock and leaving room for less synchrony.
At a high level, our ledger \(\mathcal {G}_{\textsc {ledger}}\) has a similar structure as the ledger proposed in [19]. Concretely, anyone (whether an honest miner or the adversary) might submit a transaction which is validated by means of a predicate \(\textsf {Validate}\), and if it is found valid it is added to a buffer \(\textsf {buffer}\). The adversary \(\mathcal {A}_{}\) is informed that the transaction was received and is given its contents.^{7} Informally, this buffer also contains transactions that, although validated, are not yet deep enough in the blockchain to be considered outofreach for a adversary.^{8} Periodically, \(\mathcal {G}_{\textsc {ledger}}\) fetches some of the transactions in the buffer, and using an algorithm \(\textsf {Blockify}\) creates a block including these transactions and adds this block to its permanent state \(\textsf {state}\), which is a data structure that includes the part of the blockchain the adversary can no longer change. This corresponds to the common prefix in [16, 29]. Any miner or the adversary is allowed to request a read of the contents of the state.
This sketched specification is simple, but in order to have a ledger that can be implemented by existing blockchain protocols, we need to relax this functionality by giving the adversary more power to interfere with it and influence its behavior. Before sketching the necessary relaxations we discuss the need for a new ledger definition and it potential use as a global setup.
Remark 2
(Impossibility to realize the ledger of [19]). The main reasons why the ledger in [19] is not realizable by known protocols under reasonable assumptions are as follows: first, their ledger guarantees that parties always obtain the same common state. Even with strong synchrony assumptions, this is not realizable since an adversary, who just mined a new block, is not forced to inform each party instantaneously (or at all) and thus could, e.g., make parties observe different lengths of the same prefix. Second, the adversarial influence is restricted to permuting the buffer. This is too optimistic, as in reality the adversary can try to mine a new block and possibly exclude certain transactions. Also, this excludes any possibility to quantify quality. Third, letting the update rate be fixed does not adequately reflect the probabilistic nature of blockchain protocols.
Remark 3
(On the sound usage of a ledger as a global setup). As presented in [19], a UC ledger functionality \(\mathcal {G}_{\textsc {ledger}} \) can be cast as a global setup [11] which allows different protocols to share state. This is true for any UC functionality as stated in [11, 12]. Nonetheless, as pointed out in the recent work of Canetti et al. [12], one needs to be extra careful when replacing a global setup by its implementation, e.g., in the case of \(\mathcal {G}_{\textsc {ledger}} \) by the UC Bitcoin protocol of Sect. 4. Indeed, such a replacement does not, in general, preserve a realization proof of some ideal functionality \(\mathcal {F}\) that is conducted in a ledgerhybrid world, because the simulator in that proof might rely on specific capabilities that are not available any more after replacement (as the global setup is also replaced in the ideal world). The authors of [12] provide a sufficient condition for such a replacement to be sound. This condition is generally too strong to be satisfied by any natural ledger implementation, which opens the question of devising relaxed sufficient conditions for sound replacements in an MPC context. As this work focuses on the realization of ledger functionalities per se, we can treat \(\mathcal {G}_{\textsc {ledger}} \) as a standard UC functionality.
In the following, we review the necessary relaxations to obtain a realizable ledger. We conclude this section with the specification of our generic ledger functionality.
StateBuffer Validation. The first relaxation is with respect to the invariant that is enforced by the validation predicate \(\textsf {Validate}\). Concretely, in [19] it is assumed that the validation predicate enforces that the buffer does not include conflicting transactions, i.e., upon receipt of a transaction, \(\textsf {Validate}\) checks that it is not in conflict with the state and the buffer, and if so the transaction is added to the buffer. However, in reality we do not know how to implement such a strong filter, as different miners might be working on different, potentially conflicting sets of transactions. The only time when it becomes clear which of these conflicting transactions will make it into the state is once one of them has been inserted into a block which has made it deep enough into the blockchain (i.e., has become part of \(\textsf {state}\)). Hence, given that the buffer includes all transactions that might end up in the state, it might at some point include both conflicting transactions.
To enable us for a provably implementable ledger, in this work we take a different approach. The validate predicate will be less restrictive as to which transactions make it into the buffer. Concretely, at the very least, \(\textsf {Validate}\) will enforce the invariant that no single transaction in the buffer contradicts the state \(\textsf {state}\), while different transactions in \(\textsf {buffer}\) might contradict each other. Looking ahead, a stronger version that is achievable by employing digital signatures (presented in Sect. 5), could enforce that no submitted transaction contradicts other submitted transactions. As in [19], whenever a new transaction x is submitted to \(\mathcal {G}_{\textsc {ledger}} \), it is passed to \(\textsf {Validate}\) which takes as input a transaction and the current state and decides if x should be added to the buffer. Additionally, as \(\textsf {buffer}\) might include conflicts, whenever a new block is added to the state, the buffer (i.e., every single transaction in \(\textsf {buffer}\)) is revalidated using \(\textsf {Validate}\) and invalid transactions in \(\textsf {buffer}\) are removed. To allow for this revalidation to be generic, transactions that are added to the buffer are accompanied by certain metadata, i.e., the identity of the submitter, a unique transaction ID \(\texttt {txid} \) ^{9}, or the time \(\tau \) when x was received.
State Update Policies and Security Guarantees. The second relaxation is with respect to the rate and the form and/or origin of transactions that make it into a block. Concretely, instead of assuming that the state is extended in fixed time intervals, we allow the adversary to define when this update occurs. This is done by allowing the adversary, at any point, to propose what we refer to as the nextblock candidate \(\texttt {NxtBC} \). This is a data structure containing the contents of the next block that \(\mathcal {A}_{}\) wants to have inserted into the state. Leaving \(\texttt {NxtBC} \) empty can be interpreted as the adversary signaling that it does not want the state to be updated in the current clock tick.
Of course allowing the adversary to always decide what makes it into the state \(\textsf {state}\), or if anything ever does, yields a very weak ledger. Intuitively, this would be a ledger that only guarantees the common prefix property [16] but no liveness or chain quality. Therefore, to enable us to capture also stronger properties of blockchain protocols we parameterize the ledger by an algorithm \(\texttt {ExtendPolicy}\) that, informally, enforces a stateupdate policy restricting the freedom of the adversary to choose the next block and implementing an appropriate complianceenforcing mechanism in case the adversary does not follow the policy. This enforcing mechanism simply returns a default policycomplying block using the current contents of the buffer. We point out that a good simulator for realizing the ledger will avoid triggering this complianceenforcing mechanism, as this could result in an uncontrolled update of the state which would yield a potential distinguishing advantage. In other words, a good simulator, i.e., idealworld adversary, always complies with the policy.
In a nutshell, \(\texttt {ExtendPolicy}\) takes the current contents of the buffer \(\textsf {buffer}\), along with the adversary’s recommendation \(\texttt {NxtBC} \), and the blockinsertion times vector \(\vec {\tau }_\texttt {state} \). The latter is a vector listing the times when each block was inserted into \(\textsf {state}\). The output of \(\texttt {ExtendPolicy}\) is a vector including the blocks to be appended to the state during the next stateextend timeslot (where again, \(\texttt {ExtendPolicy}\) outputting an empty vector is a signal to not extend). To ensure that \(\texttt {ExtendPolicy}\) can also enforce properties that depend on who inserted how many (or which) blocks into the state—e.g. the socalled chain quality property from [16]—we also pass to it the timed honestinput sequence \(\vec {\mathcal {I}}^T_H \) (cf. Sect. 2).

Liveness corresponds to \(\texttt {ExtendPolicy}\) enforcing the following policy: If the state has not been extended for more that a certain number of rounds and the simulator keeps recommending an empty \(\texttt {NxtBC} \), \(\texttt {ExtendPolicy}\) can choose some of the transactions in the buffer (e.g., those that have been in the buffer for a long time) and add them to the next block. Note that a good idealworld adversary will never allow for this automatic update to happen and will make sure that he keeps the state extend rate within the right amount.

Chain quality corresponds to \(\texttt {ExtendPolicy}\) enforcing the following policy: \(\texttt {ExtendPolicy}\) looks into the blocks of \(\textsf {state}\) for a special type of transaction (corresponding to a socalled coinbase transaction) and parses the state (using the sequence of honest inputs \(\vec {\mathcal {I}}^T_H\) and the blockinsertion times vector \(\vec {\tau }_\texttt {state} \)) to see how long ago (in time or blocknumber) the last block that gave a blockmining reward to some honest party was inserted into the state. If this happened “too long” ago (this will be a parameter of this \(\texttt {ExtendPolicy}\)), then \(\texttt {ExtendPolicy}\) forces the coinbase transaction of the next block to have as the miner ID the ID submitted by some honest miner.
In addition to the above standard properties, \(\texttt {ExtendPolicy}\) allows us to also capture additional security properties of various blockchain protocols, e.g., the fact that honest transactions eventually make it into a block and the fact that transactions with higher rewards make it into a block faster than others.
In Sect. 4 where we prove the security of Bitcoin, we will provide the concrete specification of \(\textsf {Validate}\) and \(\texttt {ExtendPolicy}\) for which the Bitcoin protocol realizes our ledger.
Output Slackness and Sliding Window of State Blocks. The common prefix property guarantees that blocks which are sufficiently deep in the blockchain of an honest miner will eventually be included in the blockchain of every honest miner. Stated differently, if an honest miner receives as output from the ledger a state \(\textsf {state}\), every honest miner will eventually receive \(\textsf {state}\) as its output. However, in reality we cannot guarantee that at any given point in time all honest miners see exactly the same blockchain length; this is especially the case when network delays are incorporated into the model, but it is also true in the zerodelay model of [16]. Thus it is unclear how \(\textsf {state}\) can be defined so that at any point all parties have the same view on it.
Therefore, to have a ledger implementable by standard assumptions we make the following relaxation: We interpret \(\textsf {state} \) as the view of the state of the miner with the longest blockchain. And we allow the adversary to define for every honest miner \(p _i\) a subchain \(\textsf {state} _i\) of \(\textsf {state}\) of length \(\textsf {state} _i=\texttt {pt} _i\) that corresponds to what \(p _i\) gets as a response when he reads the state of the ledger (formally, the adversary can fix a pointer \(\texttt {pt} _i\)). For convenience, we denote by \(\textsf {state} _{\texttt {pt} _i}\) the subchain of \(\textsf {state} \) that finishes in the \(\texttt {pt} _i\)th block. Once again, to avoid overrelaxing the functionality to an unuseful setup, our ledger allows the adversary to only move the pointers forward and it forbids the adversary to define pointers for honest miners that are too far apart, i.e., more than \(\texttt {windowSize} \) state blocks. The parameter \(\texttt {windowSize} \in \mathbb {N}\) denotes a core parameter of the ledger. In particular, the parameter \(\texttt {windowSize} \) reflects the similarity of the blockchain to the dynamics of a socalled sliding window, where the window of size \(\texttt {windowSize} \) contains the possible views of honest miners onto \(\textsf {state} \) and where the head of the window advances with the head of the \(\textsf {state} \). In addition, it is convenient to express security properties of concrete blockchain protocols, including the properties discussed above, as assertions that hold within such a sliding window (for any point in time).
Synchrony. In order to keep the ideal execution indistinguishable from the real execution, the adversary should be unable to use the clock for distinguishing. Since in the ideal world when a dummy party receives a clockupdatemessage for \(\mathcal {G}_{\textsc {clock}} \) it will forward it, the ledger needs to be responsible that the clock counter does not advance before all honest parties have received sufficiently many activations. This is achieved by the use of the function \(\texttt {predict}\text {}{} \texttt {time} (\vec {\mathcal {I}}^T_H)\) (see Definition 1), which, as we show, is defined for our ledger protocol. This function allows \(\mathcal {G}_{\textsc {ledger}}\) to predict when the protocol would update the round and ensure that it only allows the clock to advance if and only if the protocol would. Observe that the ledger sees all protocolrelevant inputs/activations to honest parties and can therefore easily keep track of the honest inputs sequence \(\vec {\mathcal {I}}^T_H\).
A final observation is with respect to guarantees that the protocol (and therefore also the ledger) can give to recently registered honest parties. Consider the following scenario: An honest party registers as miner in round r and waits to receive from honest parties the transactions to mine and the current longest blockchain. In Bitcoin, upon joining, the miner sends out a special request—we denote this here as a special newminermessage—and as soon as any party receives it, it responds with the set of transactions and longest blockchain it knows. Due to the network delay, the parties might take up to \(\varDelta \) rounds to receive the newminer notification, and their response might also take up to \(\varDelta \) rounds before it arrives to the new miner. However, because we do not make any assumption on honest parties knowing \(\varDelta \) (see Remark 1) they need to start mining as soon as a message arrives (otherwise they might wait indefinitely). But now the adversary, in the worst case, can make these parties mine on any block he wants and have them accept any valid chain he wants as the current state while they wait for the network’s response: simply delay everything sent to these parties by honest miners by the maximum delay \(\varDelta \), and instead, immediately deliver what you want them to work on. Thus, for the first \(\texttt {Delay} :=2\varDelta \) rounds^{10} (where \(\texttt {Delay} \) is a parameter of our ledger) these parties are practically in the control of the adversary and their computing power is contributed to his. We will call such miners desynchronized and denote the set of such miners by \(\mathcal {P}_{DS}\). The formal specification of our ledger functionality \(\mathcal {G}_{\textsc {ledger}} \) is given in the following. Using standard notation, we write [n] to denote the set \(\{1,\ldots ,n\}\).
4 Bitcoin as a Transaction Ledger Protocol
In this section we prove our main theorem, namely that, under appropriate assumptions, Bitcoin realizes an instantiation of the ledger functionality from the previous section. More concretely, we cast the Bitcoin protocol as a UC protocol, where consistent with the existing methodology we assume that the protocol is synchronous, i.e., parties can keep track of the current round by using an appropriate global clock functionality. We first describe the UC protocol, denoted \(\textsf {Ledger}\text {}\textsf {Protocol}\), in Sect. 4.1 which abstracts the components of Bitcoin that are relevant for the construction of such a ledger—similar to how the backbone protocol [16] captures core Bitcoin properties in their respective model of computation. Later, in Sect. 4.2, we specify the ledger functionality Open image in new window that is implemented by the UC ledger protocol as an instance of our general ledger functionality, i.e., by providing appropriate instantiations of algorithms \(\textsf {Validate}\), \(\textsf {Blockify}\), and \(\texttt {ExtendPolicy}\). In fact, for the sake of generality, we specify generic classes of \(\textsf {Validate} \) and \(\textsf {Blockify} \) and parameterize our \(\textsf {Ledger}\text {}\textsf {Protocol}\) with these classes, so that the security statement still stays generic. We then prove our main theorem (Theorem 1) which can be described informally as follows:
Theorem

In any round of the protocol execution, the collective mining power of the adversary, contributed by corrupted and temporarily desynchronized miners, does not exceed the mining power of honest (and synchronized) parties in that round. The exact relation additionally captures the (negative) impact of network delays on the coordination of mining power of honest parties.

No message can be delayed in the network by more than \(\varDelta =O(1)\) rounds.
4.1 The Bitcoin Ledger as a UC Protocol
In the following we provide the formal description of protocol LedgerProtocol. The protocol assumes as hybrids the multicast network \(\mathcal {F}_{\textsc {n}\text {}\textsc {mc}}\) (recall that we assume that this network does have an upper bound \(\varDelta \) on the delay unknown to the protocol) and a random oracle functionality \(\mathcal {F}_{\textsc {ro}} \). Before providing the detailed specification of our ledger protocol, we establish some useful notation and terminology that we use throughout this section. For compatibility with existing work, wherever it does not overload notation, we use some of the terminology and notation from [16].
Blockchain. A blockchain \(\mathcal {C} = \mathbf {B} _1, \dots , \mathbf {B} _n\) is a (finite) sequence of blocks where each block \(\mathbf {B} _i = \langle \textsf {s} _i,\texttt {st} _i,\textsf {n} _i \rangle \) is a triple consisting of the pointer \(\textsf {s} _i\), the state block \(\texttt {st} _i\), and the nonce \(\textsf {n} _i\). A special block is the genesis block \(\mathbf {G} = \langle \bot ,\texttt {gen},\bot \rangle \) which contains the genesis state \(\texttt {gen} \). The head of chain \(\mathcal {C} \) is the block \(\textsf {head} (\mathcal {C}) := \mathbf {B} _n\) and the length \(\textsf {length} (\mathcal {C})\) of the chain is the number of blocks, i.e., \(\textsf {length} (\mathcal {C})=n\). The chain \(\mathcal {C} ^{\lceil k}\) is the (potentially empty) sequence of the first \(\textsf {length} (\mathcal {C})k\) blocks of \(\mathcal {C} \). The state \(\vec {\texttt {st}}\) corresponding to \(\mathcal {C} \) is defined as a sequence of the corresponding state blocks, i.e., \(\vec {\texttt {st}}:= \texttt {st} _1\dots \texttt {st} _n\). In other words, one should think of the blockchain \(\mathcal {C}\) as an encoding of its underlying state \(\vec {\texttt {st}}\); such an encoding might, e.g., organize \(\mathcal {C}\) is an efficient searchable data structure as is the case in the Bitcoin protocol where a blockchain is a linked list implemented with hashpointers.
In the protocol, the blockchain is the data structure storing a sequence of entries, often referred to as transactions. Furthermore, as in [19], in order to capture blockchains with syntactically different state encoding, we use an algorithm Open image in new window to map a vector of transactions into a state block. Thus, each block \(\texttt {st} \in \vec {\texttt {st}}\) (except the genesis state) of the state encoded in the blockchain has the form \(\texttt {st} = \textsf {Blockify} ({\vec {N}}{)}\) where \({\vec {N}}\) is a vector of transactions.
For a blockchain \(\mathcal {C} \) to be considered a valid blockchain, it needs to satisfy certain conditions. Concretely, the validity of a blockchain \(\mathcal {C} = \mathbf {B} _1, \dots , \mathbf {B} _n\) where \(\mathbf {B} _i = \langle \textsf {s} _i,\texttt {st} _i,\textsf {n} _i \rangle \) depends on two aspects: chainlevel validity, also referred to as syntactic validity, and a statelevel validity also referred to as semantic validity. Syntactic validity is defined with respect to a difficulty parameter \(\textsf {D} \in [\kappa ]\), where \(\kappa \) is the security parameter, and a given hash function \(H(\cdot ):\left\{ { 0,1 }\right\} ^* \rightarrow \left\{ { 0,1 }\right\} ^{\kappa }\); it requires that, for each \(i>1\), the value \(\textsf {s} _i\) contained in \(\mathbf {B} _i\) satisfies \(\textsf {s} _i = H[\mathbf {B} _{i1}]\) and that additionally \(H[\mathbf {B} _i] < \textsf {D} \) holds.
The semantic validity on the other hand is defined on the state \(\vec {\texttt {st}}\) encoded in the blockchain \(\mathcal {C} \) and specifies whether this content is valid (which might depend on a particular application). The validation predicate \(\textsf {Validate} \) defined in the ledger functionality (cf. Sect. 3) plays a similar role. In fact, the semantic validity of the blockchain can be defined using an algorithm that we denote \(\textsf {isvalidstate} \) which is builds upon the \(\textsf {Validate} \) predicate. The idea is that for any choice of \(\textsf {Validate} \), the blockchain protocol using \(\textsf {isvalidstate} \) for semantic validation of the chain implements the ledger parametrized with \(\textsf {Validate}\). More specifically, algorithm \(\textsf {isvalidstate} \) checks that a given blockchain state can be built in an iterative manner, such that each contained transaction is considered valid according to \(\textsf {Validate} \) upon insertion. It further ensures that the state starts with the genesis state and that state blocks contain a special coinbase transaction \(\texttt {x} ^{\textsf {coin}\text {}\textsf {base}}_{\textsf {minerID}}\) which assigns them to a miner. We remark that this only works for predicates \(\textsf {Validate} \) which ignore all information other than the state and transaction that is being validated.^{11} To avoid confusion, throughout this section we use Open image in new window to refer to the validate predicate with the above restriction. The pseudocode of the algorithm \(\textsf {isvalidstate} \) which builds upon Open image in new window is provided in the full version [6]. We succinctly denote by \(\textsf {isvalidchain} _{D}(\mathcal {C})\) the predicate that returns true iff chain \(\mathcal {C} \) satisfies syntactic and semantic validity as defined above.
The Ledger Protocol. We are now ready to formally define our blockchain protocol \(\textsf {Ledger}\text {}\textsf {Protocol}_{q,\textsf {D},T}\) (we usually omit the parameters when clear from the context). The protocol allows an arbitrary number of parties/miners to communicate by means of a multicast network \(\mathcal {F}_{\textsc {n}\text {}\textsc {mc}}\). Note that this means that the adversary can send different messages to different parties. New miners might dynamically joint or leave the protocol by means of the registration/deregistration commands: when they join they register with all associated functionalities and when they leave they deregister.^{12}
Each party maintains a local blockchain which initially consists of the genesis block. The chains of honest parties might differ (but as we will prove, it will have a common prefix which will define the ledger state). New transactions are added in a ‘mining process’. First, a party collects valid transactions (according to Open image in new window ) and creates a new state block \(\texttt {st} \) using Open image in new window . Next, the party attempts to mine a new block which can be validly added to their local blockchain. The mining is done using the \(\textsf {extendchain} _{D}\) algorithm which takes as inputs a chain \(\mathcal {C} \), a state block \(\texttt {st} \), and the number \(q\) of attempts. The core idea of the algorithm is to find a proofofwork which allows to extend \(\mathcal {C} \) by a block which encodes \(\texttt {st} \). The pseudocode of this algorithm is provided in the full version [6]. After each mining attempt parties will multicast their current chain. A party will replace its local chain if it receives a longer chain. When queried to output the state of the ledger, \(\textsf {Ledger}\text {}\textsf {Protocol}\) outputs the state of its longest chain, where it first chopsoff the most recent \(T \) blocks. This behavior will ensure that all honest parties output a consistent ledger state.
As already mentioned, our BitcoinLedger protocol proceeds in rounds which are implemented by using a global synchronization clock \(\mathcal {G}_{\textsc {clock}}\). For formal reasons that have to do with how activations are handled in UC, we have each round correspond to two subrounds (also known as minirounds). To avoid confusion we refer to clock rounds as clockticks. We say that a protocol is in round r if the current time of the clock is \(\tau \in \{2r1, 2r\}\). In fact, having two clockticks per round is the way to ensure in synchronous UC that messages (e.g., a block) sent within a round are delivered at the beginning of the next round. The idea is that each round is divided into two minirounds, where each miniround corresponds to a clock tick, and treat the first miniround as a working miniround where parties might mine new blocks and submit them to the multicast network for delivery, and in the second reading miniround they simply fetch messages from the network to obtain messages sent in the previous round. The pseudocode of this UC blockchain protocol, denoted as LedgerProtocol, is provided in the full version [6], where we also argue that the protocol satisfies Definition 1.
4.2 The Bitcoin Ledger
We next show how to instantiate the ledger functionality from Sect. 3 with appropriate parameters so that it is implemented by protocol LedgerProtocol. To define this Bitcoin ledger Open image in new window , we need to give specific instantiations of the three functions \(\textsf {Validate} \), \(\textsf {Blockify} \), and \(\texttt {ExtendPolicy} \).
 1.
The speed of the ledger is not too fast. This is implemented by defining a bound \(\texttt {minTime} _\mathrm {window} \) on the time (number of rounds) within which no more than \(\texttt {windowSize} \) state blocks can be added.
 2.
The speed of the ledger is not too slow. This is implemented by defining a bound \(\texttt {maxTime} _\mathrm {window} \) within which at least \(\texttt {windowSize} \) state blocks have to be added. This is known as minimal chaingrowth.
 3.
The adversary cannot claim too many block for parties it is corrupting. This is formally enforced by defining an upper bound \(\eta \) on the number of these socalled adversarial blocks within a sequence of state blocks. This is known as chain quality. Formally, this is enforced by requiring that a certain fraction of blocks need to start with a coinbase transaction that is associated with an actual honest and synchronized party.
 4.
Last but not least, \(\texttt {ExtendPolicy} \) guarantees that if a transaction is “old enough”, and still valid with respect to the actual state, then it is included into the state. This is a weak form of guaranteeing that a transaction will make it into the state unless it is in conflict. As we show in Sect. 5, this guarantee can be amplified by using digital signatures.
In order to enforce these policies, \(\texttt {ExtendPolicy} \) first defines an alternative block, which satisfies all of the above criteria in an ideal way, and whenever it catches the adversary in trying to propose blocks that do not obey the policies, it punishes the adversary by proposing its own generated block. The formal description of the extend policy (as pseudocode) for Open image in new window is given in the full version [6].
On the Relation Between Open image in new window and Open image in new window . As already discussed above, \(\texttt {ExtendPolicy} \) guarantees that the adversary cannot block the extension of the state indefinitely, and that occasionally an honest miner will receive the block reward (via the coinbase) transaction. These correspond to the chaingrowth and chainquality properties from [16]. However, our generic \(\texttt {ExtendPolicy} \) makes explicit that a priori, we cannot exclude that the chain always extends with blocks that include a coinbase transaction only, i.e., any submitted transaction is ignored and never inserted into a new blocks. This issue is an orthogonal one to ensuring that honest transactions are not invalidated by adversarial interaction—which, as argued in [16], is achieved by adding digital signatures.
To see where this could be problematic in general, consider a blockify that, at a certain point, creates a block that renders all possible future transactions invalid. Observe that this does not mean that our protocol is insecure and that this is as well possible for the protocols of [16, 29]; indeed our proof shows that the protocol will give exactly the same guarantees as an \(\mathcal {G}_{\textsc {ledger}} \) parametrized with such an algorithm \(\textsf {Blockify}\).
Nonetheless, a look in reality indicates that this situation never occurs with Bitcoin. To capture that this is the case, \(\textsf {Validate}\) and \(\textsf {Blockify}\) need to be in a certain relation with each other. Informally, this relation should ensure that the above sketched situation never occurs. A way to ensure this, which is already implemented by the Bitcoin protocol, is by restricting \(\textsf {Blockify}\) to only make an invertible manipulation of the blocks when they are inserted into the state—e.g., be an encoding function of a code—and define \(\textsf {Validate}\) to depend on the inverse of \(\textsf {Blockify}\). This is captured in the following definition.
Definition 2
We remark that the actual validation of Bitcoin does satisfy the above definition, since a transaction is only rendered invalid with respect to the state if the coins it is trying to spend have already been spent, and this only depends on the transactions in the state and not the metadata added by \(\textsf {Blockify}\). Hence, in the following, we assume that Open image in new window and Open image in new window satisfy the relation in Definition 2.
4.3 Security Analysis
We next turn to the security analysis of our protocol. As already mentioned, we argue security in two step. In a first step, we distill out from the protocol LedgerProtocol a stateextend subprocess, denoted as StateExchangeProtocol, and devise an alternative, modular description of the LedgerProtocol protocol in which every party makes invocations of this subprocess. We denote this modularized protocol by ModularLedgerProtocol. By a gamehopping argument, we prove that the original protocol LedgerProtocol and the modularized protocol ModularLedgerProtocol are in fact functionally equivalent. The advantage of having such a modular description is that we are now able to define an appropriate ideal functionality \(\mathcal {F}_{\textsc {StX}}\) that is realized by StateExchangeProtocol. Using the universal composition theorem we can deduce that LedgerProtocol UC emulates ModularLedgerProtocol where invocations of StateExchangeProtocol are replaced by invocations of \(\mathcal {F}_{\textsc {StX}}\). The second step of the proof consists of proving that, under appropriate assumptions, ModularLedgerProtocol, where invocations of StateExchangeProtocol are replaced by invocations of \(\mathcal {F}_{\textsc {StX}}\), implements the Bitcoin ledger described in Sect. 4.2.
Step 1. The stateexchange functionality \(\mathcal {F}_{\textsc {StX}} \) allows parties to submit ledger states which are accepted with a certain probability. Accepted states are then multicast to all parties. Informally, it can be seen as lottery on which (valid) states are exchanged among the participants. Parties can use \(\mathcal {F}_{\textsc {StX}}\) to multicast a valid state, but instead of accepting any submitted state and sending it to all (registered) parties, \(\mathcal {F}_{\textsc {StX}}\) keeps track of all states that it ever saw, and implements the following mechanism upon submission of a new ledger state \(\vec {\texttt {st}}\) and a state block \(\texttt {st} \) from any party: If \(\vec {\texttt {st}}\) was previously submitted to \(\mathcal {F}_{\textsc {StX}} \) and \(\vec {\texttt {st}} \texttt {st} \) is a valid state, then \(\mathcal {F}_{\textsc {StX}} \) accepts \(\vec {\texttt {st}} \texttt {st} \) with probability \(p_H\) (resp. \(p_A\) for dishonest parties); accepted states are then sent to all registered parties. The formal specification follows:
The ModularLedgerProtocol uses the same hybrids as LedgerProtocol but abstracts the lottery implemented by the mining process by making calls to the above state exchange functionality \(\mathcal {F}_{\textsc {StX}} ^{\varDelta ,p_H,p_A}\). The detailed specification of the ModularLedgerProtocol protocol can be found in the full version [6]. Note that the only remaining parameter of ModularLedgerProtocol is the chopoff parameter \(T \), the rest is part of \(\mathcal {F}_{\textsc {StX}} ^{\varDelta ,p_H,p_A}\). The following Lemma states that our Bitcoin protocol implements the above modular ledger protocol. The proof appears in [6].
Lemma 1
The UC blockchain protocol \(\textsf {Ledger}\text {}\textsf {Protocol}_{q,\textsf {D},T}\) UC emulates the protocol \(\textsf {Modular}\text {}\textsf {Ledger}\text {}\textsf {Protocol}_{T}\) that runs in a hybrid world with access to the functionality \(\mathcal {F}_{\textsc {StX}} ^{\varDelta ,p_H,p_A}\) with \(p_A:= \frac{\textsf {D}}{2^\kappa }\) and \(p_H= 1(1p_A)^q\), and \(\varDelta \) denotes the network delay.
Step 2. We are now ready to complete the proof of our main theorem. Before providing the formal statement it is useful to discuss some of the key properties used in both, the statement and the proof. The security of the Bitcoin protocol depends on various key properties of an execution. This means that its security depends on the number of random oracle queries (or, in the \(\mathcal {F}_{\textsc {StX}} \) hybrid world, the number of submitqueries) by the pool of corrupted miners. Therefore it is important to capture the relevant properties of such a UC execution. In the following we denote by uppercase R the number of rounds of a given protocol execution.
It is convenient to measure the adversary’s contribution to the mining power as the fraction of the overall mining power. In particular, we assume there is a parameter Open image in new window such that in any round r, the relation Open image in new window holds. We then define Open image in new window . Looking ahead, if a model is flat, then the fraction \((1\rho )\) corresponds to the fraction of users that are honest and synchronized.
Remark 4
This view on Bitcoin gives already a glimpse for the relevance of the recalibration subprotocol which is considered as part of future work. Ideally, we would like the variation among the values \(\alpha _r\) and among the values \(\beta _r\) to be small, which needs an additional assumption on the increase of computing power per round. Thanks to the recalibration phase, such a bound can exist at all. If no recalibration phase would happen, any strictly positive gradient of the computing power development would eventually provoke Bitcoin failing, as the value \(\beta \) (as a fraction of the total mining power) could not be reasonably bounded. We are now ready to state the main theorem. The proof of the theorem can be found in the full version [6].
Theorem 1
Remark 5
It is worth noting the implications of Eq. 1. In practice, typically p is small such that \(\alpha \) (and thus \(\gamma \)) can be approximated using Bernoulli’s inequality to be \((1\rho )mp\), where m is the estimated number of hash queries in the Bitcoin network per round. Hence, by canceling out the term mp and letting p be sufficiently small (compared to \(\frac{1}{\varDelta m}\)), Eq. 1 collapses roughly to the condition that \((1\rho )(1\epsilon ) \ge (1+\delta ) \rho \), which basically relates the fractions of adversarial vs. honest mining power. Also, as pointed out by [29], for too large values of p in the order of \(p > \frac{1}{mp}\), Eq. 1 is violated for any constant fraction \(\rho \) of corrupted miners and they present an attack in this case.
Proof
(Overview). To show the theorem we specify a simulator for the ideal world that internally runs the roundbased mining procedure of every honest party. Whenever the real world parties complete a working round, then the simulator has to assemble the views of all honest (and synchronized) miners that it simulates and determine their common prefix of states, i.e., the longest state stored or received by each simulated party when chopping off T blocks. The adversary will then propose a new block candidate, i.e., a list of transactions, to the ledger to announce that the common prefix has increased. To reflect that not all parties have the same view on this common prefix, the simulator can adjust the state pointers accordingly. This simulation is perfect and corresponds to an emulation of realworld processes. What possibly prevents a perfect simulation is the requirement of a consistent prefix and the restrictions imposed by \(\texttt {ExtendPolicy} \). In order to show that these restrictions do not forbid a proper simulation, we have to justify why the choice of the parameters in the theorem statement is acceptable. To this end, we analyze the realworld execution to bound the corresponding bad events that prevent a perfect simulation. This can be done following the detailed analysis provided by Pass et al. [29] which includes the necessary claims for lower and upper on chain growth, chain quality, and prefix consistency. From these claims, it follows that our simulator can simulate the realworld, since the restrictions imposed by the ledger prohibit a prefect simulation only with probability \(R \cdot \textsf {negl} (T)\). This is an upper bound on the distinguishing advantage of the real and ideal world. The detailed proof is found in [6]. \(\square \)
Note that the theorem statement apriori holds for any environment (but simply yields a void statement if the conditions are not met). In order to turn this into a composable statement, we follow the approach proposed in Sect. 2 and model restrictions as wrapper functionalities to ensure the condition of the theorem. We review two particular choices in Sect. 4.4. The general conceptual principle behind this is the following: For the hybrid world, that consists of a network \(\mathcal {F}_{\textsc {n}\text {}\textsc {mc}}\), a clock \(\mathcal {G}_{\textsc {clock}} \) and a random oracle \(\mathcal {F}_{\textsc {ro}} \) with output length \(\kappa \) (or alternatively the stateexchange functionality \(\mathcal {F}_{\textsc {StX}} \) instead of the random oracle), define a wrapper functionality \(\mathcal {W}\) which ensures the condition in Eq. 1 and (possibly) additional conditions on minimal (honest) and maximal (dishonest) mining power. This can be done by enforcing appropriate restrictions along the lines of the basic example in Sect. 2 (e.g., imposing an upper bound on parties, or RO queries per round etc.). We provide the details and the specification of such a general randomoracle wrapper \(\mathcal {W}^{\varDelta , \lambda , \textsf {T} _{mp}}_{\alpha ,\beta , \textsf {D}}(\mathcal {F}_{\textsc {ro}})\) with its parameters^{13} in the full version of this work [6]. For this wrapper we have the following desired corollary to Theorem 1 and Lemma 1. This statement is guaranteed to compose according to the UC composition theorem.
Corollary 1
The UC blockchain protocol \(\textsf {Ledger}\text {}\textsf {Protocol}_{q,\textsf {D},T}\) that is executed in the \((\mathcal {G}_{\textsc {clock}}, \mathcal {F}_{\textsc {n}\text {}\textsc {mc}}^\varDelta , \mathcal {W}^{\varDelta , \lambda , \textsf {T} _{mp}}_{\alpha ,\beta , \textsf {D}}(\mathcal {F}_{\textsc {ro}}))\)hybrid world, UCrealizes functionality Open image in new window (with the respective parameters assured by Theorem 1).
4.4 Comparison with Existing Work
We demonstrate how the protocols, assumptions, and results from the two existing works analyzing security of Bitcoin (in a property based manner) can be cast as special cases of our construction.

Let n denote the number of parties. Each corrupted party gets at most q activations to query the \(\mathcal {F}_{\textsc {StX}} \) per round. Each honest party is activated exactly once per round.

In the model of GKL, we have \(q \ge 1\). Thus, we get \(p_H= 1  (1p)^q\) and \(p_A= p\). We can further conclude that \(\textsf {T} _{mp}^{\mathrm {GKL}}(r) \le p \cdot q \cdot n\).

The adversary gets (at most) q queries per corrupted party with probability Open image in new window and one query per honest but desynchronized party with success probability \(p_H= 1(1p)^q\). If \(t_r\) denotes the number of corrupted or desynchronized parties in round r, we get Open image in new window and thus \(\beta ^{\mathrm {GKL}}_r =p \cdot q \cdot (\rho \cdot n)\), where \(\rho n\) is the (assumed) upper bound on the number of miners contributing to the adversarial mining power (independent of r).

Each honest and synchronized miner gets exactly one activation per round, i.e., \(q_{i,r}:=1\), with \(p_H= 1(1p)^q \in (0,1)\), for some integer \(q>0\). Inserting it into the general equation yields \(\alpha ^{\mathrm {GKL}}_r = 1(1p)^{q(1\rho )\cdot n}\) (independent of r). Note that since n is assumed to be fixed in their model, \(q(1\rho )\cdot n\) is in fact a lower bound on the honest and synchronized hashing power.
We can now easily specify a wrapper \(\mathcal {W}_{\mathrm {GKL}}\) as special case of the above general wrapper. In the hybrid world \((\mathcal {G}_{\textsc {clock}}, \mathcal {W}_{\mathrm {GKL}}(\mathcal {F}_{\textsc {StX}} ^{\varDelta ,p_H, p_A}), \mathcal {F}_{\textsc {n}\text {}\textsc {mc}}^\varDelta )\) this ensures the condition of Theorem 1 and we arrive at the following composable statement:
Corollary 2

For each corrupted (and desynchronized) party, the adversary gets at most one query per round. Each honest miner makes exactly one query per round. This means that \(q^{(r)}_{A} + q^{(r)}_{H} = n_r\).

In the PSs model, \(p_H= p_A= p\) and hence \(\textsf {T} _{mp}^{\mathrm {PSs}}(r) \le p \cdot n_r = p\cdot n\), where n is as above. With these values we get Open image in new window and consequently \(\beta ^{\mathrm {PSs}}_r = p \cdot (\rho \cdot n)\), where \(\rho n\) denotes the upper bound on corrupted parties in any round. Putting things together, we also have \(\alpha ^{\mathrm {PSs}}_r = 1(1p)^{(1\rho )\cdot n}\). Note that since n is assumed to be fixed in their model, \((1\rho )\cdot n\) is in fact a lower bound on the honest and synchronized hashing power.
We can again specify a wrapper functionality \(\mathcal {W}_{\mathrm {PSs}}\) as above (where the restriction is 1 query per corrupted instead of q). We again have that the hybrid world \((\mathcal {G}_{\textsc {clock}}, \mathcal {W}_{\mathrm {PSs}}(\mathcal {F}_{\textsc {StX}} ^{\varDelta , p, p}), \mathcal {F}_{\textsc {n}\text {}\textsc {mc}}^\varDelta )\) will ensure the condition of the theorem and directly yields the following composable statement.
Corollary 3
5 Implementing a Stronger Ledger
As already observed in [16], the Bitcoin protocol makes use of digital signatures to protect transactions which allows it to achieve stronger guarantees. Informally, the stronger guarantee ensures that every transaction submitted by an honest miner will eventually make it into the state. Using our terminology, this means that by employing digital signatures, Bitcoin implements a stronger ledger. In this section we present this stronger ledger and show how such an implementation can be captured as a UC protocol which makes blackbox use of the LedgerProtocol to implement this ledger. The UC composition theorem makes such a proof immediate, as we do not need to think about the specifics of the invoked ledger protocol, and we can instead argue security in a world where this protocol is replaced by Open image in new window .
Protection of Transactions Using Accounts. In Bitcoin, a miner creates an account ID \(\mathsf {AccountID}\) by generating a signature key pair and hashing the public key. Any transaction of this party includes this account ID, i.e., \(\texttt {x} = (\mathsf {AccountID}, \texttt {x} ')\). An important property is that a transaction of a certain account cannot be invalidated by a transaction with a different account ID. Hence, to protect the validity of a transaction, upon submitting \(\texttt {x} \), party \(p _i\) has to sign it, append the signature and verification key to get a transaction \(((\mathsf {AccountID}, \texttt {x} '), vk , \sigma )\). The validation predicate now additionally has to check that the account ID is the hash of the public key and that the signature \(\sigma \) is valid with respect to the verification key \( vk \). Roughly, an adversary can invalidate \(\texttt {x} \), only by either forging a signature relative to \( vk \), or by possessing key pair whose hash of the public key collides with the account ID of the honest party. The details of the protocol and the validate predicate as pseudocode are provided in the full version [6].
Realized Ledger. The realized ledger abstraction, denoted by Open image in new window , is formally specified in [6]. Roughly, it is a ledger functionality as the one from the previous section, but which additionally allows parties to create unique accounts. Upon receiving a transaction from party \(p _i\), Open image in new window only accepts a transaction containing the \(\mathsf {AccountID}\) that was previously associated to \(p _i\) and ensures that parties are restricted to issue transactions using their own accounts.
Amplification of Transaction Liveness. In Bitcoin a given transaction can only be invalidated due to another one with the same account. By definition of the enhanced ledger, this means that no other party can make a transaction of \(p _i\) not enter the state. The liveness guarantee for transactions specified by \(\texttt {ExtendPolicy} \) in the previous chapter implies captures that if a valid transaction is in the buffer for long enough then it eventually enters the state. For Open image in new window , this implies that if \(p _i\) submits a single transaction which is valid according to the current state, then this transaction will eventually be contained in the state. More precisely, we can conclude that this happens within the next \(2\cdot \texttt {windowSize} \) new state blocks in the worst case. Relative to the current view of \(p _i\) this is no more than within the next \(3\cdot \texttt {windowSize} \) blocks as argued in [6].
Footnotes
 1.
In the original Bitcoin heuristic “deep enough” is defined as six blocks, whereas in these works it is defined as linear in an appropriate security parameter.
 2.
We formulate a weakened guarantee, which we then amplify using digital signatures.
 3.
Note that making the set of parties dynamic means that the adversary needs to be informed about which parties are currently in the computation so that he can chose how many (and which) parties to corrupt.
 4.
Although we allow no communication between functionalities, we will allow functionalities to communicate with global setups. (They can use the interface of global setups to additional honest parties, which is anyway open to the environment.)
 5.
In [16] this mechanism is referred to as “broadcast”; here, we use multicast to make explicit the fact that this primitive is different from a standard Byzantineagreementtype broadcast, in that it does not guarantee any consistency for a malicious sender.
 6.
In the latter case the activation goes to the environment by default.
 7.
This is inevitable since we assume nonprivate communication, where the adversary sees any message as soon as it is sent, even if the sender and receiver are honest.
 8.
E.g., in [19] the adversary is allowed to permute the contents of the buffer.
 9.
In Bitcoin, \(\texttt {txid} \) would be the hashpointer corresponding to this transaction. Note that the generic ledger can capture explicit guarantees on the ability or disability to link transactions, as this crucially depends on the concrete choice of an ID mechanism.
 10.
For technical reasons described in Sect. 4.1, \(\varDelta \) rounds in the protocol correspond to \(2\varDelta \) clockticks.
 11.
Recall that in the general ledger description, \(\textsf {Validate} \) might depend on some associated metadata; although this might be useful to capture alternative blockchains, it is not the case for Bitcoin.
 12.
Note that when a party registers to a local functionality such as the network or the random oracle it does not lose its activation token. This is a subtle point to ensure that the real and ideal worlds are insync regarding activations.
 13.
The parameters are the ones introduced in this section: a lower bound on honest mining power (per round) \(\alpha \), an upper bound on adversarial mining power (per round) \(\beta \), the total mining power (per round) \(\textsf {T} _{mp}\), the network delay \(\varDelta \), the difficulty parameter \(\textsf {D} \) (that influences the probability of a successful PoW), and finally a value \(\lambda >1\) describing the required gap between honest and dishonest mining power.
 14.
The flat model means that every party gets the same number of hash queries in every round.
 15.
In a recent paper, the authors of [16] propose an analysis of Bitcoin for a variable number of parties. Capturing the appropriate assumptions for this case, as a wrapper in our composable setting, is part of future work.
References
 1.Andrychowicz, M., Dziembowski, S.: PoWbased distributed cryptography with no trusted setup. In: Gennaro, R., Robshaw, M. (eds.) CRYPTO 2015. LNCS, vol. 9216, pp. 379–399. Springer, Heidelberg (2015). doi: 10.1007/9783662480007_19 CrossRefGoogle Scholar
 2.Andrychowicz, M., Dziembowski, S., Malinowski, D., Mazurek, Ł.: Fair twoparty computations via bitcoin deposits. In: Böhme, R., Brenner, M., Moore, T., Smith, M. (eds.) FC 2014. LNCS, vol. 8438, pp. 105–121. Springer, Heidelberg (2014). doi: 10.1007/9783662447741_8 Google Scholar
 3.Andrychowicz, M., Dziembowski, S., Malinowski, D., Mazurek, L.: Secure multiparty computations on bitcoin. In: 2014 IEEE Symposium on Security and Privacy, pp. 443–458. IEEE Computer Society Press, May 2014Google Scholar
 4.Babaioff, M., Dobzinski, S., Oren, S., Zohar, A.: On bitcoin and red balloons. SIGecom Exch. 10(3), 5–9 (2011)CrossRefGoogle Scholar
 5.Backes, M., Hofheinz, D., MüllerQuade, J., Unruh, D.: On fairness in simulatabilitybased cryptographic systems. In: FMSE 2005 (2005)Google Scholar
 6.Badertscher, C., Maurer, U., Tschudi, D., Zikas, V.: Bitcoin as a transaction ledger: a composable treatment. Cryptology ePrint Archive, Report 2017/149 (2017)Google Scholar
 7.BenSasson, E., Chiesa, A., Garman, C., Green, M., Miers, I., Tromer, E., Virza, M.: Zerocash: decentralized anonymous payments from bitcoin. In: 2014 IEEE Symposium on Security and Privacy, pp. 459–474. IEEE Computer Society Press, May 2014Google Scholar
 8.Bentov, I., Kumaresan, R.: How to use bitcoin to design fair protocols. In: Garay, J.A., Gennaro, R. (eds.) CRYPTO 2014. LNCS, vol. 8617, pp. 421–439. Springer, Heidelberg (2014). doi: 10.1007/9783662443811_24 CrossRefGoogle Scholar
 9.Buterin, V.: A nextgeneration smart contract and decentralized application platform (2013). https://github.com/ethereum/wiki/wiki/WhitePaper
 10.Canetti, R.: Universally composable security: a new paradigm for cryptographic protocols. In: 42nd FOCS, pp. 136–145. IEEE Computer Society Press, October 2001Google Scholar
 11.Canetti, R., Dodis, Y., Pass, R., Walfish, S.: Universally composable security with global setup. In: Vadhan, S.P. (ed.) TCC 2007. LNCS, vol. 4392, pp. 61–85. Springer, Heidelberg (2007). doi: 10.1007/9783540709367_4 CrossRefGoogle Scholar
 12.Canetti, R., Shahaf, D., Vald, M.: Universally composable authentication and keyexchange with global PKI. In: Cheng, C.M., Chung, K.M., Persiano, G., Yang, B.Y. (eds.) PKC 2016. LNCS, vol. 9615, pp. 265–296. Springer, Heidelberg (2016). doi: 10.1007/9783662493878_11 CrossRefGoogle Scholar
 13.Coretti, S., Garay, J., Hirt, M., Zikas, V.: Constantround asynchronous multiparty computation based on oneway functions. In: Cheon, J.H., Takagi, T. (eds.) ASIACRYPT 2016. LNCS, vol. 10032, pp. 998–1021. Springer, Heidelberg (2016). doi: 10.1007/9783662538906_33 CrossRefGoogle Scholar
 14.Eyal, I.: The miner’s dilemma. In: 2015 IEEE Symposium on Security and Privacy, pp. 89–103. IEEE Computer Society Press, May 2015Google Scholar
 15.Eyal, I., Sirer, E.G.: Majority is not enough: bitcoin mining is vulnerable. In: Christin, N., SafaviNaini, R. (eds.) FC 2014. LNCS, vol. 8437, pp. 436–454. Springer, Heidelberg (2014). doi: 10.1007/9783662454725_28 Google Scholar
 16.Garay, J., Kiayias, A., Leonardos, N.: The bitcoin backbone protocol: analysis and applications. In: Oswald, E., Fischlin, M. (eds.) EUROCRYPT 2015. LNCS, vol. 9057, pp. 281–310. Springer, Heidelberg (2015). doi: 10.1007/9783662468036_10 Google Scholar
 17.Katz, J., Maurer, U., Tackmann, B., Zikas, V.: Universally composable synchronous computation. In: Sahai, A. (ed.) TCC 2013. LNCS, vol. 7785, pp. 477–498. Springer, Heidelberg (2013). doi: 10.1007/9783642365942_27 CrossRefGoogle Scholar
 18.Kiayias, A., Koutsoupias, E., Kyropoulou, M., Tselekounis, Y.: Blockchain mining games. In: EC (2016)Google Scholar
 19.Kiayias, A., Zhou, H.S., Zikas, V.: Fair and robust multiparty computation using a global transaction ledger. In: Fischlin, M., Coron, J.S. (eds.) EUROCRYPT 2016. LNCS, vol. 9666, pp. 705–734. Springer, Heidelberg (2016). doi: 10.1007/9783662498965_25 CrossRefGoogle Scholar
 20.Kumaresan, R., Bentov, I.: How to use bitcoin to incentivize correct computations. In: Ahn, G.J., Yung, M., Li, N. (eds.) ACM CCS 2014, pp. 30–41. ACM Press, November 2014Google Scholar
 21.Kumaresan, R., Bentov, I.: Amortizing secure computation with penalties. In: Weippl, E.R., Katzenbeisser, S., Kruegel, C., Myers, A.C., Halevi, S. (eds.) ACM CCS 2016, pp. 418–429. ACM Press, October 2016Google Scholar
 22.Kumaresan, R., Moran, T., Bentov, I.: How to use bitcoin to play decentralized poker. In: Ray, I., Li, N., Kruegel, C. (eds.) ACM CCS 15, pp. 195–206. ACM Press, October 2015Google Scholar
 23.Kumaresan, R., Vaikuntanathan, V., Vasudevan, P.N.: Improvements to secure computation with penalties. In: Weippl, E.R., Katzenbeisser, S., Kruegel, C., Myers, A.C., Halevi, S. (eds.) ACM CCS 2016, pp. 406–417. ACM Press, October 2016Google Scholar
 24.Lamport, L.: The parttime parliament. ACM Trans. Comput. Syst. 16(2), 133–169 (1998)CrossRefGoogle Scholar
 25.Lamport, L.: Paxos made simple, fast, and byzantine. In: OPODIS (2002)Google Scholar
 26.Lamport, L., Shostak, R.E., Pease, M.C.: The byzantine generals problem. ACM Trans. Program. Lang. Syst. 4(3), 382–401 (1982)CrossRefzbMATHGoogle Scholar
 27.Miers, I., Garman, C., Green, M., Rubin, A.D.: Zerocoin: anonymous distributed ecash from bitcoin. In: 2013 IEEE Symposium on Security and Privacy, pp. 397–411. IEEE Computer Society Press, May 2013Google Scholar
 28.Nakamoto, S.: Bitcoin: a peertopeer electronic cash system (2008). http://bitcoin.org/bitcoin.pdf
 29.Pass, R., Seeman, L., Shelat, A.: Analysis of the blockchain protocol in asynchronous networks. In: Coron, J.S., Nielsen, J.B. (eds.) EUROCRYPT 2017. LNCS, vol. 10211, pp. 643–673. Springer, Cham (2017). doi: 10.1007/9783319566146_22 CrossRefGoogle Scholar
 30.Pass, R., Shi, E.: FruitChains: a fair blockchain. Cryptology ePrint Archive, Report 2016/916 (2016)Google Scholar
 31.Rabin, M.O.: Randomized byzantine generals. In: FOCS (1983)Google Scholar
 32.Rosulek, M.: Must you know the code of f to securely compute f? In: SafaviNaini, R., Canetti, R. (eds.) CRYPTO 2012. LNCS, vol. 7417, pp. 87–104. Springer, Heidelberg (2012). doi: 10.1007/9783642320095_7 CrossRefGoogle Scholar
 33.Sompolinsky, Y., Zohar, A.: Secure highrate transaction processing in bitcoin. In: Böhme, R., Okamoto, T. (eds.) FC 2015. LNCS, vol. 8975, pp. 507–527. Springer, Heidelberg (2015). doi: 10.1007/9783662478547_32 CrossRefGoogle Scholar
 34.Zohar, A.: Bitcoin: under the hood. Commun. ACM 58(9), 104–113 (2015)CrossRefGoogle Scholar