SoK: Unraveling Bitcoin Smart Contracts

Abstract

Albeit the primary usage of Bitcoin is to exchange currency, its blockchain and consensus mechanism can also be exploited to securely execute some forms of smart contracts. These are agreements among mutually distrusting parties, which can be automatically enforced without resorting to a trusted intermediary. Over the last few years a variety of smart contracts for Bitcoin have been proposed, both by the academic community and by that of developers. However, the heterogeneity in their treatment, the informal (often incomplete or imprecise) descriptions, and the use of poorly documented Bitcoin features, pose obstacles to the research. In this paper we present a comprehensive survey of smart contracts on Bitcoin, in a uniform framework. Our treatment is based on a new formal specification language for smart contracts, which also helps us to highlight some subtleties in existing informal descriptions, making a step towards automatic verification. We discuss some obstacles to the diffusion of smart contracts on Bitcoin, and we identify the most promising open research challenges.

1 Introduction

The term “smart contract” was conceived in [43] to describe agreements between two or more parties, that can be automatically enforced without a trusted intermediary. Fallen into oblivion for several years, the idea of smart contract has been resurrected with the recent surge of distributed ledger technologies, led by Ethereum (http://www.ethereum.org/) and Hyperledger (https://www.hyperledger.org/). In such incarnations, smart contracts are rendered as computer programs. Users can request the execution of contracts by sending suitable transactions to the nodes of a peer-to-peer network. These nodes collectively maintain the history of all transactions in a public, append-only data structure, called blockchain. The sequence of transactions on the blockchain determines the state of each contract, and, accordingly, the assets of each user.

A crucial feature of smart contracts is that their correct execution does not rely on a trusted authority: rather, the nodes which process transactions are assumed to be mutually untrusted. Potential conflicts in the execution of contracts are resolved through a consensus protocol, whose nature depends on the specific platform (e.g., it is based on “proof-of-work” in Ethereum). Ideally, contracts execute correctly whenever the adversary does not control the majority of some resource (e.g., computational power for “proof-of-work” consensus).

The absence of a trusted intermediary, combined with the possibility of transferring money given by blockchain-based cryptocurrencies, creates a fertile ground for the development of smart contracts. For instance, a smart contract may promise to pay a reward to anyone who provides some value that satisfies a given public predicate. This generalises cryptographic puzzles, like breaking a cipher, inverting a hash function, etc.

Since smart contracts handle the ownership of valuable assets, attackers may be tempted to exploit vulnerabilities in their implementation to steal or tamper with these assets. Although analysis tools [17, 30, 34] may improve the security of contracts, so far they have not been able to completely prevent attacks. For instance, a series of vulnerabilities in Ethereum contracts [10] have been exploited, causing money losses in the order of hundreds of millions of dollars [3,4,5].

Using domain-specific languages (possibly, not Turing-complete) could help to overcome these security issues, by reducing the distance between contract specification and implementation. For instance, despite the discouraging limitations of its scripting language, Bitcoin has been shown to support a variety of smart contracts. Lotteries [6, 14, 16, 36], gambling games [32], contingent payments [13, 24, 35], and other kinds of fair multi-party computations [8, 31] are some examples of the capabilities of Bitcoin as a smart contracts platform.

Unlike Ethereum, where contracts can be expressed as computer programs with a well-defined semantics, Bitcoin contracts are usually realised as cryptographic protocols, where participants send/receive messages, verify signatures, and put/search transactions on the blockchain. The informal (often incomplete or imprecise) narration of these protocols, together with the use of poorly documented features of Bitcoin (e.g., segregated witnesses, scripts, signature modifiers, temporal constraints), and the overall heterogeneity in their treatment, pose serious obstacles to the research on smart contracts in Bitcoin.

Contributions. This paper is, at the best of our knowledge, the first systematic survey of smart contracts on Bitcoin. In order to obtain a uniform and precise treatment, we exploit a new formal model of contracts. Our model is based on a process calculus with primitives to construct Bitcoin transactions, to put them on the blockchain, and to search the blockchain for transactions matching given patterns. Our calculus allows us to give smart contracts a precise operational semantics, which describes the interactions of the (possibly dishonest) participants involved in the execution of a contract.

We exploit our model to systematically formalise a large portion of the contracts proposed so far both by researchers and Bitcoin developers. In many cases, we find that specifying a contract with the intended security properties is significantly more complex than expected after reading the informal descriptions of the contract. Usually, such informal descriptions focus on the case where all participants are honest, neglecting the cases where one needs to compensate for some unexpected behaviour of the dishonest environment.

Overall, our work aims at building a bridge between research communities: from that of cryptography, where smart contracts have been investigated first, to those of programming languages and formal methods, where smart contracts could be expressed using proper linguistic models, supporting advanced analysis and verification techniques. We outline some promising research perspectives on smart contracts, both in Bitcoin and in other cryptocurrencies, where the synergy between the two communities could have a strong impact in future research.

2 Background on Bitcoin Transactions

In this section we give a minimalistic introduction to Bitcoin [21, 38], focussing on the crucial notion of transaction. To this purpose, we rely on the model of Bitcoin transactions in [11]. Here, instead of repeating the formal machinery of [11], we introduce the needed concepts through a series of examples. We will however follow the same notation of [11], and point to the formal definitions therein, to allow the reader to make precise the intuitions provided in this paper.

Bitcoin is a decentralised infrastructure to securely transfer currency (the bitcoins, ) between users. Transfers of bitcoins are represented as transactions, and the history of all transactions is stored in a public, append-only, distributed data structure called blockchain. Each user can create an arbitrary number of pseudonyms through which sending and receiving bitcoins. The balance of a user is not explicitly stored within the blockchain, but it is determined by the amount of unspent bitcoins directed to the pseudonyms under her control, through one or more transactions. The logic used for linking inputs to outputs is specified by programmable functions, called scripts.

Hereafter we will abstract from a few technical details of Bitcoin, e.g. the fact that transactions are grouped into blocks, and that each transaction must pay a fee to the “miner” who appends it to the blockchain. We refer to [11] for a discussion on the differences between the formal model and the actual Bitcoin.

2.1 Transactions

In their simplest form, Bitcoin transactions allow to transfer bitcoins from one participant to another one. The only exception are the so-called coinbase transactions, which can generate fresh bitcoins. Following [11], we assume that there exists a single coinbase transaction, the first one in the blockchain. We represent this transaction, say , as follows:

The transaction has three fields. The fields and are set to $\bot$, meaning that does not point backwards to any other transaction (since is the first one on the blockchain). The field contains a pair. The first element of the pair, $\lambda x_{}.\, x_{}< 51$, is a script, that given as input a value $x_{}$, checks if $x_{}< 51$ (this is just for didactical purposes: we will introduce more useful scripts in a while). The second element of the pair, , is the amount of currency that can be transferred to other transactions.

Now, assume that participant wants to redeem from , and transfer that amount under her control. To do this, has to append to the blockchain a new transaction, e.g.:

The field points to the transaction in the blockchain. To be able to redeem from there , must provide a witness which makes the script within evaluate to true. In this case the witness is 42, hence the redeem succeeds, and is considered spent. The script within is the most commonly used one in Bitcoin: it verifies the signature $x_{}$ with ’s public key. The message against which the signature is verified is the transaction¹ which attempts to redeem .

Now, to transfer to another participant , can append to the blockchain the following transaction:

where the witness is ’s signature on (but for the field itself).

The ones shown above represent just the simplest cases of transactions. More in general, a Bitcoin transaction can collect bitcoins from many inputs, and split them between one or more outputs; further, it can use more complex scripts, and specify time constraints on when it can be appended to the blockchain.

Following [11], hereafter we represent transactions as tuples of the form , where:

• contains the list of inputs. An input refers to the i-th output of transaction .

• contains the list of witnesses, of the same length as the list of inputs. For each input in the list, the witness at the same index must make the i-th output script of evaluate to true.

• contains the list of outputs. Each index refers to a pair $(\lambda \varvec{z_{}}. e, v_{})$, where the first component is a script, and the second is a currency value.

• and indicate absolute and relative time constraint on when the transaction can be added to the blockchain.

In transaction fields, we represent a list $\ell _1 \cdots \ell _n$ as $1 \mapsto \ell _1, \ldots , n \mapsto \ell _n$, or just as $\ell _1$ when $n=1$. We denote with the canonical transaction, i.e. the transaction with a single output of the form , and with all the other fields empty (denoted with $\bot$).

Example 1

Consider the transactions in Fig. 1. In there are two outputs: the first one transfers to any transaction which provides as witness a signature of with key $k_{}$; the second output can transfer to a transaction whose witness satisfies the script $e_1$. The transaction tries to redeem from the output at index 1 of , by providing the witness $\sigma _1$. Since , then can be appended only after at least $t_{}$ time units have passed since the transaction in (i.e., ) appeared on the blockchain. In , the input 1 refers to the output 2 of , and the input 2 refers to the output 1 of . The witness $\sigma _2$ and $\sigma _2'$ are used to evaluate , replacing the occurrences of $x_{}$ and $x_{}'$ in $e_1$. Similarly, $\sigma _3$ is used to evaluate , replacing the occurrences of $x_{}$ in $e_2$. The transaction can be put on the blockchain only after time $t'_{}$.    $\square$

Fig. 1.

Three Bitcoin transactions.

2.2 Scripts

In Bitcoin, scripts are small programs written in a non-Turing equivalent language. Whoever provides a witness that makes the script evaluate to “true”, can redeem the bitcoins retained in the associated (unspent) output. In the abstract model, scripts are terms of the form $\lambda \varvec{z} . e$, where $\varvec{z}$ is a sequence of variables occurring in $e$, and $e$ is an expression with the following syntax:

Besides variables $x_{}$, constants $k_{}$, and basic arithmetic/logical operators, the other expression are peculiar: $| e |$ denotes the size, in bytes, of the evaluation of $e$; $\mathsf{H}(e)$ evaluates to the hash of $e$; $\mathsf{versig}_{\varvec{k_{}}}({\varvec{e}})$ evaluates to true iff the sequence of signatures $\varvec{e}$ (say, of length m) is verified by using m out of the n keys in $\varvec{k_{}}$. For instance, the script $\lambda x_{}. \mathsf{versig}_{k_{}}({x_{}})$ is satisfied if x is a signature on the redeeming transaction, verified with the key $k_{}$. The expressions and define absolute and relative time constraints: they evaluate as $e$ if the constraints are satisfied, otherwise they evaluate to false.

In Fig. 2 we recap from [11] the semantics of script expressions. The function takes three parameters: is the redeeming transaction, i is the index of the redeeming witness, and $\rho$ is a map from variables to values. We use $\bot$ to represent the “failure” of the evaluation, for a public hash function, and $size ({n})$ for the size (in bytes) of an integer n. The function verifies a sequence of signatures $\varvec{\sigma }$ against a sequence of keys $\varvec{k_{}}$ (see Sect. 2.3) All the semantic operators used in Fig. 2 are strict, i.e. they evaluate to $\bot$ if some of their operands is $\bot$. We use syntactic sugar for expressions, e.g. $false$ denotes $1~\textsf {=}~0$, $true$ denotes $1~\textsf {=}~1$, while $e~\textsf {and}~e'$ denotes $\mathsf {if}~{e}~\mathsf {then}~{e'}~\mathsf {else}~{ false }$.

Fig. 2.

Semantics of script expressions.

Example 2

Recall the transactions in Fig. 1. Let $e_1$ (the script expression within ) be defined as , for $h_{}^{}$ and $t'_{}$ constants such that . Further, let $\sigma _2$ and $\sigma _2'$ (the witnesses within ) be respectively and $s_{}^{}$, where is the signature of (excluding its witnesses) with key $k_{}$, and $s_{}^{}$ is a preimage of $h_{}^{}$, i.e. . Let . To redeem with the witness , the script expression is evaluated as follows:

   $\square$

2.3 Transaction Signatures

The signatures verified with never apply to the whole transaction: the content of field is never signed, while the other fields can be excluded from the signature according to some predefined patterns. To sign parts of a transaction, we first erase the fields which we want to neglect in the signature. Technically, we set these fields to the “null” value $\bot$ using a transaction substitution.

A transaction substitution replaces the content of field with d. If the field is indexed (i.e., all fields but ), we denote with the substitution of the i-th item in field , and with the substitution of all the items of field but the i-th. For instance, to set all the elements of the field of to $\bot$, we write , and to additionally set the second input to $\bot$ we write .

In Bitcoin, there exists a fixed set of transaction substitutions. We represent them as signature modifiers, i.e. transaction substitutions which set to $\bot$ the fields which will not be signed. Signatures never apply to the whole transaction: modifiers always discard the content of the , while they can keep all the inputs or only one, and all the outputs, or only one, or none. Modifiers also take a parameter i, which is instantiated to the index of the witness where the signature will be included. Below we only present two signature modifiers, since the others are not commonly used in Bitcoin smart contracts.

The modifier only sets the first witness to i, and the other witnesses to $\bot$ (so, all inputs and all outputs are signed). This ensures that a signature computed for being included in the witness at index i can not be used in any witness with index $j \ne i$:

The modifier removes the witnesses, and all the inputs but the one at index i (so, a single input and all outputs are signed). Differently from , this modifier discards the index i, so the signature can be included in any witness:

Signatures carry information about which parts of the transaction are signed: formally, they are pairs $\sigma = (w,\mu _{})$, where $\mu$ is the modifier, and w is the signature on the transaction modified with $\mu _{}$. We denote such signature as , where $k_{}$ is a key, and i is the index used by $\mu _{}$, if any. Verification of a signature $\sigma$ for index i is denoted by . Formally:

where and $ver$ are, respectively, the signing function and the verification function of a digital signature scheme.

Multi-signature verification extends verification to the case where $\varvec{\sigma }$ is a sequence of signatures and $\varvec{k_{}}$ is a sequence of keys. Intuitively, if $|\varvec{\sigma }|=m$ and $|\varvec{k_{}}|=n$, it implements a m-of-n multi-signature scheme, evaluating to true if all the m signatures match (some of) the keys in $\varvec{k_{}}$. The actual definition also takes into account the order of signatures, as formalised in Definition 6 of [11].

2.4 Blockchain and Consistency

Abstracting away from the fact that the actual Bitcoin blockchain is formed by blocks of transactions, here we represent a blockchain as a sequence of pairs , where $t_{i}$ is the time when has been appended, and the values $t_{i}$ are increasing. We say that the j-th output of the transaction in the blockchain is spent (or, for brevity, that is spent) if there exists some transaction in the blockchain (with $i' > i$) and some $j'$ such that .

We now describe when a pair can be appended to . Following [11], we say that is a consistent update of at time $t_{}$, in symbols , when the following conditions hold:

• 1. for each input i of , if then:

  • (a) corresponds to one of the transactions in ;

  • (b) is unspent in ;

  • (c) the witness makes the script in evaluate to true;

• 2. the time constraints and in are satisfied at time $t_{}\ge t_{n}$;

• 3. the sum of the amounts of the inputs of is greater or equal² to the sum of the amount of its outputs.

We assume that each transaction in the blockchain is a consistent update of the sequence of past transactions . The consistency of the blockchain is actually ensured by the Bitcoin consensus protocol.

Example 3

Recall the transactions in Fig. 1. Assume a blockchain whose last pair is and $t_{1} \ge t'_{}$, while and are not in .

We verify that is a consistent update of , assuming $t_{2} = t_{1} + t_{}$ and that $\sigma _1$ is the signature of with (the private part of) key $k_{}$. The only input of is . Conditions 1a and 1b are satisfied, since is unspent in . Condition 1c holds because $\mathsf{versig}_{k_{}}({\sigma _1})$ evaluates to true. Condition 2 holds: indeed the relative timelock in is satisfied because $t_{2} - t_{1} \ge t_{}$. Condition 3 holds because the amount of the input of , i.e. , is equal to the amount of its output. Note instead that would not be a consistent update of , since it violates condition 1a on the second input.

Now, let . We verify that is a consistent update of , assuming $t_{3} \ge t_{2}$, $e_1$ as in Example 2, and $e_2 = \mathsf{versig}_{k'_{}}({x_{}})$. Further, let , let $\sigma _2' = s_{}^{}$, and . Conditions 1a and 1b hold, because and are in , and the referred outputs are unspent. Condition 1c holds because the output scripts and against $\sigma _2,\sigma _2'$ and $\sigma _3$ evaluate to true. Condition 2 is satisfied at $t_{3} \ge t_{2} \ge t_{1} \ge t'_{}$. Finally, condition 3 holds because the amount in is equal to the sum of the amounts in and .    $\square$

3 Modelling Bitcoin Contracts

In this section we introduce a formal model of the behavior of the participants in a contract, building upon the model of Bitcoin transactions in [11].

We start by formalising a simple language of expressions, which represent both the messages sent over the network, and the values used in internal computations made by the participants. Hereafter, we assume a set $\mathsf Var$ of variables, and we define the set $\mathsf Val$ of values comprising constants $k_{}\in \mathbb {Z}$, signatures $\sigma$, scripts $\lambda \varvec{z} . e$, transactions , and currency values $v_{}$.

Definition 1

(Contract expressions). We define contract expressions through the following syntax:

where $\varvec{E_{}}$ denotes a finite sequence of expressions (i.e., $\varvec{E_{}} = E_{1} \cdots E_{n}$). We define the function ${\llbracket {\cdot }\rrbracket _{}}$ from (variable-free) contract expressions to values in Fig. 3. As a notational shorthand, we omit the index i in (resp. ) when the signed (resp. verified) transactions have a single input.

Fig. 3.

Semantics of contract expressions.

Intuitively, when $T_{}$ evaluates to a transaction , the expression represents the transaction obtained from by substituting the field with the sequence of values obtained by evaluating $\varvec{E_{}}$. For instance, denotes the transaction obtained from by replacing the witness at index 1 with the signature $\sigma$. Further, evaluates to the signature of the transaction represented by $T_{}$, and represents the m-of-n multi-signature verification of the transaction represented by $T_{}$. Both for the signing and verification, the parameter i represents the index where the signature will be used. We assume a simple type system (not specified here) that rules out ill-formed expressions, like e.g. .

We formalise the behaviour of a participant as an endpoint protocol, i.e. a process where the participant can perform the following actions: (i) send/receive messages to/from other participants; (ii) put a transaction on the ledger; (iii) wait until some transactions appear on the blockchain; (iv) do some internal computation. Note that the last kind of operation allows a participant to craft a transaction before putting it on the blockchain, e.g. setting the field to her signature, and later on adding the signature received from another participant.

Definition 2

(Endpoint protocols). Assume a set of participants (named , , , ...). We define prefixes , and protocols as follows:

We assume that each name has a unique defining equation where the free variables in are included in . We use the following syntactic sugar:

• , the internal action;

• , the terminated protocol (as usual, we omit trailing s);

• ;

• , provided that and $1 \not \in I$;

• , i.e. where $x_{}$ is replaced by $E_{}$.

The behaviour of protocols is defined in terms of a LTS between systems, i.e. the parallel composition of the protocols of all participants, and the blockchain.

Definition 3

(Semantics of protocols). A system is a term of the form , where (i) all the are distinct; (ii) there exists a single component , representing the current state of the blockchain , and the current time t; (iii) systems are up-to commutativity and associativity of . We define the relation $\xrightarrow {}$ between systems in Fig. 4, where is the set of all the transactions in that are equal to , except for the witnesses. When writing we intend that the conditions above are respected.

Fig. 4.

Semantics of endpoint protocols.

Intuitively, a guarded choice can behave as one of the branches . A parallel composition executes concurrently and . All the rules (except the last two) specify how a protocol evolves within a system. Rule [Com] models a message exchange between and : participant sends messages $\varvec{E_{}}$, which are received by on variables . Communication is synchronous, i.e. is blocked until is ready to receive. Rule [Check] allows the branch of a sum to proceed if the condition represented by $E_{}$ is true. Rule [Put] allows to append a transaction to the blockchain, provided that the update is consistent. Rule [Ask] allows the branch of a sum to proceed only when the blockchain contains some transactions obtained by instantiating some $\bot$ fields in $\varvec{T_{}}$ (see Sect. 2). This form of pattern matching is crucial because the value of some fields (e.g., ), may not be known at the time the protocol is written. When the prefix unblocks, the variables in are bound to , so making it possible to inspect their actual fields. Rule [Def] allows a named process to evolve as , assuming a defining equation . The variables $\varvec{x_{}}$ in are substituted with the results of the evaluation of $\varvec{E_{}}$. Such defining equations can be used to specify recursive behaviours. Finally, rule [Delay] allows time to pass³.

Fig. 5.

Transactions of the naïve escrow contract.

Example 4

(Naïve escrow). A buyer wants to buy an item from the seller , but they do not trust each other. So, they would like to use a contract to ensure that will get paid if and only if gets her item. In a naïve attempt to realise this, they use the transactions in Fig. 5, where we assume that used in , is a transaction output redeemable by through her key . The transaction makes deposit , which can be redeemed by a transaction carrying the signatures of both  and . The transactions and redeem , transferring the money to or , respectively.

The protocols of  and are, respectively, and :

First, adds her signature to , and puts it on the blockchain. Then, she internally chooses whether to unblock the deposit for or to request a refund. In the first case, sends to . In the second case, she waits to receive the signature from (saving it in the variable $x_{}$); afterwards, she puts on the blockchain (after setting ) to redeem the deposit. The seller waits to see on the blockchain. Then, he chooses either to receive the signature from  (and then redeem the payment by putting on the blockchain), or to refund , by sending his signature .

This contract is not secure if either or are dishonest. On the one hand, a dishonest can prevent from redeeming the deposit, even if she had already received the item (to do that, it suffices not to send her signature, taking the rightmost branch in ). On the other hand, a dishonest can just avoid to send the item and the signature (taking the leftmost branch in ): in this way, the deposit gets frozen. For instance, let , where contains unredeemed. The scenario where has never received the item, while dishonestly attempts to receive the payment, is modelled as follows:

At this point the computation is stuck, because both and are waiting a message from the other participant. We will show in Sect. 4.3 how to design a secure escrow contract, with the intermediation of a trusted arbiter.

4 A Survey of Smart Contracts on Bitcoin

We now present a comprehensive survey of smart contracts on Bitcoin, comprising those published in the academic literature, and those found online. To this aim we exploit the model of computation introduced in Sect. 3. Remarkably, all the following contracts can be implemented by only using so-called standard transactions⁴, e.g. via the compilation technique in [11]. This is crucial, because non-standard transactions are currently discarded by the Bitcoin network.

4.1 Oracle

In many concrete scenarios one would like to make the execution of a contract depend on some real-world events, e.g. results of football matches for a betting contract, or feeds of flight delays for an insurance contract. However, the evaluation of Bitcoin scripts can not depend on the environment, so in these scenarios one has to resort to a trusted third-party, or oracle [2, 19], who notifies real-world events by providing signatures on certain transactions.

Fig. 6.

Transactions of a contract relying on an oracle.

For example, assume that wants to transfer to only if a certain event, notified by an oracle , happens. To do that, puts on the blockchain the transaction in Fig. 6, which can be redeemed by a transactions carrying the signatures of both  and . Further, instructs the oracle to provide his signature to upon the occurrence of the expected event.

We model the behaviour of as the following protocol:

Here, waits to receive the signature from , then he puts on the blockchain (after setting its ) to redeem . In practice, oracles like the one needed in this contract are available as services in the Bitcoin ecosystem⁵.

Notice that, in case the event certified by the oracle never happens, the within are frozen forever. To avoid this situation, one can add a time constraint to the output script of , e.g. as in the transaction in Fig. 10.

4.2 Crowdfunding

Assume that the curator of a crowdfunding campaign wants to fund a venture by collecting from a set of investors. The investors want to be guaranteed that either the required amount is reached, or they will be able to redeem their funds. To this purpose, can employ the following contract. She starts with a canonical transaction (with empty field) which has a single output of to be redeemed by . Intuitively, each can invest money in the campaign by “filling in” the field of the with a transaction output under their control. To do this, sends to a transaction output , together with the signature $\sigma _i$ required to redeem it. We denote with the value of such output. Notice that, since the signature $\sigma _i$ has been made on , the only valid output is the one of to be redeemed by . Upon the reception of the message from , updates : the provided output is appended to the field, and the signature is added to the corresponding field. If all the outputs are distinct (and not redeemed) and the signatures are valid, when the filled transaction can be put on the blockchain. If collects , the difference $v'_{}- v_{}$ goes to the miners as transaction fee.

The endpoint protocol of the curator is defined as , where:

while the protocol of each investor is the following:

Note that the transactions sent by investors are not known a priori, so they cannot just create the final transaction and sign it. Instead, to allow to complete the transaction without invalidating the signatures, they compute them using the modifier . In this way, only a single input is signed, and when verifying the corresponding signature, the others are neglected.

4.3 Escrow

In Example 4 we have discussed a naïve escrow contract, which is secure only if both the buyer and the seller are honest (so making the contract pointless). Rather, one would like to guarantee that, even if either or (or both) are dishonest, exactly one them will be able to redeem the money: in case they disagree, a trusted participant , who plays the role of arbiter, will decide who gets the money (possibly splitting the initial deposit in two parts) [1, 19].

Fig. 7.

Transactions of the escrow contract.

The output script of the transaction in Fig. 7 is a 2-of-3 multi-signature schema. This means that can be redeemed either with the signatures and (in case they agree), or with the signature of (with key ) and the signature of or that of (in case they disagree). The transaction in Fig. 7 allows the arbiter to issue a partial refund of to , and of to . Instead, to issue a full refund to either or , the arbiter signs, respectively, the transactions or (not shown in the figure). The protocols of and are similar to those in Example 4, except for the part where they ask for an arbitration:

In the summation within , participant internally chooses whether to send her signature to (so allowing to redeem via ), or to proceed with . There, waits to receive either ’s signature (which allows to redeem by putting on the blockchain), or a response from the arbiter, in the process . The three cases in the summation of in correspond, respectively, to the case where gets a full refund ($z_{}=1$), a partial refund ($0< z_{}< 1$), or no refund at all ($z_{}=0$).

The protocol for is dual to that of :

If an arbitration is requested, internally decides (through the $\tau$ actions) who between and can redeem the deposit in , by sending its signature to one of the two participants, or decide for a partial refund of $z_{}$ and $1 - z_{}$ bitcoins, respectively, to and , by sending its signature on to both participants:

Note that, in the unlikely case where both and choose to send their signature to the other participant, the deposit becomes “frozen”. In a more concrete version of this contract, a participant could keep listening for the signature, and attempt to redeem the deposit when (unexpectedly) receiving it.

Fig. 8.

Transactions of the intermediated payment contract.

4.4 Intermediated Payment

Assume that wants to send an indirect payment of to , routing it through an intermediary  who retains a fee of bitcoins. Since does not trust , she wants to use a contract to guarantee that: (i) if is honest, then are transferred to ; (ii) if is not honest, then does not lose money. The contract uses the transactions in Fig. 8: transfers from to , and splits the amount to () and to (). We assume that is a transaction output redeemable by . The behaviour of is as follows:

Here, receives from his signature on , which makes it possible to pay later on. The $\tau$ branch and the $\mathsf {else}$ branch ensure that will correctly terminate also if is dishonest (i.e., does not send anything, or he sends an invalid signature). If receives a valid signature, she puts on the blockchain, adding her signature to the field. Then, she also appends , adding to the field her signature and ’s one. Since takes care of publishing both transactions, the behaviour of consists just in sending his signature on . Therefore, ’s protocol can just be modelled as .

This contract relies on SegWit. In Bitcoin without SegWit, the identifier of is affected by the instantiation of the field. So, when is put on the blockchain, the input in (which was computed before) does not point to it.

4.5 Timed Commitment

Assume that wants to choose a secret $s_{}^{}$, and reveal it after some time—while guaranteeing that the revealed value corresponds to the chosen secret (or paying a penalty otherwise). This can be obtained through a timed commitment [20], a protocol with applications e.g. in gambling games [25, 28, 42], where the secret contains the player move, and the delay in the revelation of the secret is intended to prevent other players from altering the outcome of the game. Here we formalise the version of the timed commitment protocol presented in [8].

Fig. 9.

Transactions of the timed commitment.

Intuitively, starts by exposing the hash of the secret, i.e. , and at the same time depositing some amount in a transaction. The participant has the guarantee that after t time units, he will either know the secret $s_{}^{}$, or he will be able to redeem .

The transactions of the protocol are shown in Fig. 9, where we assume that is a transaction output redeemable by . The behaviour of is modelled as the following protocol:

Participant starts by putting the transaction on the blockchain. Note that within this transaction is committing the hash of the chosen secret: indeed, $h_{}^{}$ is encoded within the output script . Then, sends to her signature on . Note that this transaction can be redeemed by  only when $t_{}$ time units have passed since has been published on the blockchain, because of the relative timelock declared in . After sending her signature on , internally chooses whether to reveal the secret, or do nothing (via the $\tau$ actions). In the first case, must put the transaction on the blockchain. Since it redeems , she needs to write in both the secret $s_{}^{}$ and her signature, so making the former public.

A possible behaviour of the receiver is the following:

In this protocol, first receives from (and saves in $x_{}$) her signature on the transaction . Then, checks if the signature is valid: if not, he aborts the protocol. Even if the signature is valid, cannot put on the blockchain and redeem the deposit immediately, since the transaction has a timelock $t_{}$. Note that cannot change the timelock: indeed, doing so would invalidate ’s signature on . If, after $t_{}$ time units, has not published yet, can proceed to put on the blockchain, writing ’s and his own signatures in the witness. Otherwise, retrieves from the blockchain, from which he can obtain the secret, and use it in .

A variant of this contract, which implements the timeout in , and does not require the signature exchange, is used in Sect. 4.7.

Fig. 10.

Transactions of the micropayment channel contract.

4.6 Micropayment Channels

Assume that wants to make a series of micropayments to , e.g. a small fraction of every few minutes. Doing so with one transaction per payment would result in conspicuous fees⁶, so and use a micropayment channel contract [29]. starts by depositing ; then, she signs a transaction that pays to and back to herself, and she sends that transaction to . Participant can choose to publish that transaction immediately and redeem its payment, or to wait in case sends another transaction with increased value. can stop sending signatures at any time. If redeems, then can get back the remaining amount. If does not cooperate, can redeem all the amount after a timeout.

The protocol of is the following (the transactions are in Fig. 10). publishes the transaction , depositing that can be spent with her signature and that of , or with her signature alone, after time $t_{}$. can redeem the deposit by publishing the transaction . To pay for the service, sends to the amount v she is paying, and her signature on . Then, she can decide to increase v and recur, or to terminate.

The participant waits for to appear on the blockchain, then receives the first value $v_{}$ and ’s signature $\sigma$. Then, checks if $\sigma$ is valid, otherwise he aborts the protocol. At this point, waits for another pair $(v',\sigma ')$, or, after a timeout, he redeems using .

Note that should redeem before the timeout expires, which is not modelled in . This could be obtained by enriching the calculus with time-constraining operators (see Footnote 3).

4.7 Fair Lotteries

A multiparty lottery is a protocol where N players put their bets in a pot, and a winner—uniformly chosen among the players—redeems the whole pot. Various contracts for multiparty lotteries on Bitcoin have been proposed in [8, 9, 12, 14, 16, 36]. These contracts enjoy a fairness property, which roughly guarantees that: (i) each honest player will have (on average) a non-negative payoff, even in the presence of adversaries; (ii) when all the players are honest, the protocol behaves as an ideal lottery: one player wins the whole pot (with probability ), while all the others lose their bets (with probability ).

Here we illustrate the lottery in [8], for $N=2$. Consider two players and who want to bet each. Their protocol is composed of two phases. The first phase is a timed commitment (as in Sect. 4.5): each player chooses a secret ( and ) and commits its hash ( and ). In doing that, both players put a deposit of on the ledger, which is used to compensate the other player in case one chooses not to reveal the secret later on. In the second phase, the two bets are put on the ledger. After that, the players reveal their secrets, and redeem their deposits. Then, the secrets are used to compute the winner of the lottery in a fair manner. Finally, the winner redeems the bets.

Fig. 11.

Transactions of the fair lottery with deposit.

The transactions needed for this lottery are displayed in Fig. 11 (we only show ’s transactions, as those of are similar). The transactions for the commitment phase () are similar to those in Sect. 4.5: they only differ in the script of , which now also checks that the length of the secret is either 128 or 129. This check forces the players to choose their secret so that it has one of these lengths, and reveal it (using ) before the deadline, since otherwise they will lose their deposits (enabling ).

The bets are put using , whose output script computes the winner using the secrets, which can then be revealed. For this, the secret lengths are compared: if equal, wins, otherwise wins. In this way, the lottery is equivalent to a coin toss. Note that, if a malicious player chooses a secret having another length than 128 or 129, the transaction will become stuck, but its opponent will be compensated using the deposit.

The endpoint protocol of player follows (the one for is similar):

Player starts by putting on the blockchain, then she waits for doing the same. If does not cooperate, can safely abort the protocol taking its branch, so redeeming her deposit with (as usual, here with $\tau$ we are modelling a timeout). If commits his secret, executes , extracting the hash of ’s secret, and checking whether it is distinct from . If the hashes are found to be equal, aborts the protocol using . Otherwise, runs . The component attempts to redeem ’s deposit, as soon as the deadline of expires, forcing to timely reveal his secret. Instead, proceeds with the lottery, asking for his signature of . If does not sign, aborts using . Then, runs , finally putting the bets () on the ledger. If this is not possible (e.g., because one of the is already spent), aborts using . After is on the ledger, reveals her secret and redeems her deposit with . In parallel, with she waits for the secret of to be revealed, and then attempts to redeem the pot ().

The fairness of this lottery has been established in [8]. This protocol can be generalised to $N>2$ players [8, 9] but in this case the deposit grows quadratically with N. The works [14, 36] have proposed fair multiparty lotteries that require, respectively, zero and constant ($\ge 0$) deposit. More precisely, [36] devises two variants of the protocol: the first one only relies on SegWit, but requires each player to statically sign $O(2^N)$ transactions; the second variant reduces the number of signatures to $O(N^2)$, at the cost of introducing a custom opcode. Also the protocol in [14] assumes an extension of Bitcoin, i.e. the malleability of in fields, to obtain an ideal fair lottery with O(N) signatures per player (see Sect. 5).

4.8 Contingent Payments

Assume a participant who wants to pay to receive a value s which makes a public predicate p true, where p(s) can be verified efficiently. A seller who knows such s is willing to reveal it to , but only under the guarantee that he will be paid . Similarly, the buyer wants to pay only if guaranteed to obtain s.

A naïve attempt to implement this contract in Bitcoin is the following: creates a transaction such that evaluates to true if and only if $p(x_{})$ holds and $\varsigma _{}$ is a signature of . Hence, can redeem from by revealing s. In practice, though, this approach is arguably useful, since it requires coding p in the Bitcoin scripting language, whose expressiveness is quite limited.

More general contingent payment contracts can be obtained by exploiting zero-knowledge proofs [13, 24, 35]. In this setting, the seller generates a fresh key k, and sends to the buyer the encryption $e_s = E_k(s)$, together with the hash , and a zero-knowledge proof guaranteeing that such messages have the intended form. After verifying this proof, is sure that knows a preimage $k'$ of $h_k$ (by collision resistance, $k'=k$) such that $D_{k'}(e_s)$ satisfies the predicate p, and so she can buy the preimage k of $h_k$ with the naïve protocol, so obtaining the solution s by decrypting $e_s$ with k.

Fig. 12.

Transactions of the contingent payment.

The transactions implementing this contract are displayed in Fig. 12. The clause in allows to redeem if no solution is provided by the deadline $t_{}$. The behaviour of the buyer can be modelled as follows:

Upon receiving $e_s$, $h_k$ and the proof $z_{}$⁷ the buyer verifies $z_{}$. If the verification succeeds, puts on the blockchain. Then, she waits for , from which she can retrieve the key k, and so use the solution $D_{\textit{get}_{k}(x_{})}(e_s)$ in . In this way, can redeem . If does not put , after $t_{}$ time units can get her deposit back through . The protocol of is simple, so it is omitted.

5 Research Challenges and Perspectives

Extensions to Bitcoin. The formal model of smart contracts we have proposed is based on the current mechanisms of Bitcoin; indeed, this makes it possible to translate endpoint protocols into actual implementations interacting with the Bitcoin blockchain. However, constraining smart contracts to perfectly adhere to Bitcoin greatly reduces their expressiveness. Indeed, the Bitcoin scripting language features a very limited set of operations⁸, and over the years many useful (and apparently harmless) opcodes have been disabled without a clear understanding of their alleged insecurity⁹. This is the case e.g., of bitwise logic operators, shift operators, integer multiplication, division and modulus.

For this reason some developers proposed to re-enable some disabled opcodes¹⁰, and some works in the literature proposed extensions to the Bitcoin scripting language so to enhance the expressiveness of smart contracts.

A possible extension is covenants [37], a mechanism that allows an output script to constrain the structure of the redeeming transaction. This is obtained through a new opcode, called CHECKOUTPUTVERIFY, which checks if a given of the redeeming transaction matches a specific pattern. Covenants are also studied in [41], where they are implemented using the opcode CAT (currently disabled) and a new opcode CHECKSIGFROMSTACK which verifies a signature against an arbitrary bitstring on the stack. In both works, covenants can also be recursive, e.g. a covenant can check if the redeeming transaction contains itself. Using recursive covenants allows to implement a state machine through a sequence of transactions that store its state.

Secure cash distribution with penalties [8, 16, 32] is a cryptographic primitive which allows a set of participants to make a deposit, and then provide inputs to a function whose evaluation determines how the deposits are distributed among the participants. This primitive guarantees that dishonest participants (who, e.g., abort the protocol after learning the value of the function) will pay a penalty to the honest participants. This primitive does not seem to be directly implementable in Bitcoin, but it becomes so by extending the scripting language with the opcode CHECKSIGFROMSTACK discussed above. Secure cash distribution with penalties can be instantiated to a variety of smart contracts, e.g. lotteries [8] poker [32], and contingent payments. The latter smart contract can also be obtained through the opcode CHECKKEYPAIRVERIFY in [24], which checks if the two top elements of the stack are a valid key pair.

Another new opcode, called MULTIINPUT [36] consumes from the stack a signature $\sigma$ and a sequence of values , with the following two effects: (i) it verifies the signature $\sigma$ against the redeeming transaction , neglecting ; (ii) it requires to be equal to some of the . Exploiting this opcode, [36] devise a fair N-party lottery which requires zero deposit, and $O(N^2)$ off-chain signed transaction. The first one of these effects can be alternatively obtained by extending, instead of the scripting language, the signature modifiers. More specifically, [14] introduces a new signature modifier, which can set to $\bot$ all the inputs of a transaction (i.e., no input is signed). In this way they obtain a fair multi-party lottery with similar properties to the one in [36].

Another way improve the expressiveness of smart contracts is to replace the Bitcoin scripting language, e.g. with the one in [40]. This would also allow to establish bounds on the computational resources needed to run scripts.

Unfortunately, none of the proposed extensions has been yet included in the main branch of the Bitcoin Core client, and nothing suggests that they will be considered in the near future. Indeed, the development of Bitcoin is extremely conservative, as any change to its protocol requires an overwhelming consensus of the miners. So far, new opcodes can only be empirically assessed through the Elements alpha project¹¹, a testnet for experimenting new Bitcoin features. A significant research challenge would be that of formally proving that new opcodes do not introduce vulnerabilities, exploitable e.g. by Denial-of-Service attacks. For instance, unconstrained uses of the opcode CAT may cause an exponential space blow-up in the verification of transactions.

Formal Methods for Bitcoin Smart Contracts. As witnessed in Sect. 4, designing secure smart contracts on Bitcoin is an error-prone task, similarly to designing secure cryptographic protocols. The reason lies in the fact that, to devise a secure contract, a designer has to anticipate any possible (mis-)behaviour of the other participants. The side effect is that endpoint protocols may be quite convoluted, as they must include compensations at all the points where something can go wrong. Therefore, tools to automate the analysis and verification of smart contracts may be of great help.

Recent works [7] propose to verify Bitcoin smart contracts by modelling the behaviour of participants as timed automata, and then using UPPAAL [15] to check properties against an attacker. This approach correctly captures the time constraints within the contracts. The downside is that encoding this UPPAAL model into an actual implementation with Bitcoin transactions is a complex task. Indeed, a designer without a deep knowledge of Bitcoin technicalities is likely to produce an UPPAAL model that can not be encoded in Bitcoin. A relevant research challenge is to study specification languages for Bitcoin contracts (like e.g. the one in Sect. 3), and techniques to automatically encode them in a model that can be verified by a model checker.

Remarkably, the verification of security properties of smart contracts requires to deal with non-trivial aspects, like temporal constraints and probabilities. This is the case, e.g., for the verification of fairness of lotteries (like e.g. the one discussed in Sect. 4.7); a further problem is that fairness must hold against any adversarial strategy. It is not clear whether in this case it is sufficient to consider a “most powerful” adversary, like e.g. in the symbolic Dolev-Yao model. In case a contract is not secure against arbitrary (PTIME) adversaries, one would like to verify that, at least, it is secure against rational ones [27], which is a relevant research issue. Additional issues arise when considering more concrete models of the Bitcoin blockchain, respect to the one in Sect. 2. This would require to model forks, i.e. the possibility that a recent transaction is removed from the blockchain. This could happen with rational (but dishonest) miners [33].

DSLs for Smart Contracts. As witnessed in Sect. 4, modelling Bitcoin smart contracts is complex and error-prone. A possible way to address this complexity is to devise high-level domain-specific languages (DSLs) for contracts, to be compiled in low-level protocols (e.g., the ones in Sect. 3). Indeed, the recent proliferation of non-Turing complete DSLs for smart contracts [18, 22, 26] suggests that this is an emerging research direction.

A first proposal of an high-level language implemented on top of Bitcoin is Typecoin [23]. This language allows to model the updates of a state machine as affine logic propositions. Users can “run” this machine by putting transactions on the Bitcoin blockchain. The security of the blockchain guarantees that only the legit updates of the machine can be triggered by users. A downside of this approach is that liveness is guaranteed only by assuming cooperation among the participants, i.e., a dishonest participant can make the others unable to complete an execution. Note instead that the smart contracts in Sect. 4 allow honest participants to terminate, regardless of the behaviours of the environment. In some cases, e.g. in the lottery in Sect. 4.7, abandoning the contract may even result in penalties (i.e., loss of the deposit paid upfront to stipulate the contract).