key: cord-0045125-fssrnl9a
authors: Bartoletti, Massimo; Murgia, Maurizio; Zunino, Roberto
title: Renegotiation and Recursion in Bitcoin Contracts
date: 2020-05-13
journal: Coordination Models and Languages
DOI: 10.1007/978-3-030-50029-0_17
sha: 36fa2a2d2db68998a28dcb39a58386bf86a17010
doc_id: 45125
cord_uid: fssrnl9a

BitML is a process calculus to express smart contracts that can be run on Bitcoin. One of its current limitations is that, once a contract has been stipulated, the participants cannot renegotiate its terms: this prevents expressing common financial contracts, where funds have to be added by participants at run-time. In this paper, we extend BitML with a new primitive for contract renegotiation. At the same time, the new primitive can be used to write recursive contracts, which was not possible in the original BitML. We show that, despite the increased expressiveness, it is still possible to execute BitML on standard Bitcoin, preserving the security guarantees of BitML.

Smart contracts-computer protocols that regulate the exchange of assets in trustless environments-have become popular with the growth of interest in blockchain technologies. Mainstream blockchain platforms like Ethereum, Libra, and Cardano, feature expressive high-level languages for programming smart contracts. This flexibility has a drawback in that it may open the door to attacks that steal or tamper with the assets controlled by vulnerable contracts [4, 22] .

An alternative approach, pursued first by Bitcoin and more recently also by Algorand, is to sacrifice the expressiveness of smart contracts to reduce the attack surface. For instance, Bitcoin has a minimal language for transaction redeem scripts, containing only a limited set of logic, arithmetic, and cryptographic operations. Despite the limited expressiveness of these scripts, it is possible to encode a variety of smart contracts (like gambling games, escrow services, crowdfunding systems, etc.) by suitably chaining transactions [1] [2] [3] 5, 8, 10, 13, [18] [19] [20] [21] 23] . The common trait of these works is that they render contracts as cryptographic protocols, where participants can exchange/sign messages, read the blockchain, and append transactions. Verifying the correctness of these protocols is hard, since it requires to reason in a computational model, where participants can manipulate arbitrary bitstrings, only being constrained to use PPTIME algorithms.

Departing from this approach, BitML [11] allows to write Bitcoin contracts in a high-level, process-algebraic language. BitML features a compiler that translates contracts into sets of standard Bitcoin transactions, and a sound and complete verification technique of relevant trace properties [12] . The computational soundness of the compiler guarantees that the execution of the compiled contract is coherent with the semantics of the source BitML specification, even in the presence of adversaries. Although BitML can express many of the Bitcoin contracts presented in the literature, it is not "Bitcoin-complete", i.e. there exist contracts that can be executed on Bitcoin, but are not expressible in BitML [6] .

For instance, consider a zero-coupon bond [17] , where an investor A pays 1B upfront to a bank B, and receives back 2B after a maturity date (say, year 2030). We can express this contract in BitML as follows. First, as a precondition to the stipulation of the contract, we require both A and B to provide a deposit: A's deposit is 1B, while B's deposit is 2B. In BitML, we write this precondition as:

where x 1 and x 2 are the identifiers of transactions containing the required amount of bitcoins (B) . Under this precondition, we can specify the zero-coupon bond contract ZCB as follows:

Upon stipulation, all the deposits required in the preconditions pass under the control of ZCB , and can no longer be spent by A and B. The contract splits these funds in two parts: 1B, that can be withdrawn by B at any moment, and 2B, that can be withdrawn by A after the maturity date.

Although ZCB correctly implements the functionality of zero-coupon bounds, it is quite impractical: for the whole period from the stipulation to the maturity date, 2B are frozen within the contract, and cannot be used by the bank in any way. Although this is a desirable feature for the investor, since it guarantees that he will receive 2B even if the bank fails, it is quite undesirable for the bank. In the real world, the bank would be free to use its own funds, together with those of investors, to make further financial transactions through which to repay the investments. The risk that the bank fails is mitigated by external mechanisms, like insurances or government intervention.

In this paper we propose an extension of BitML that overcomes this issue. The idea is to allow the contract participants to renegotiate it after stipulation, in a controlled way. Renegotiation makes it possible to inject in the contract new funds, that were not specified in the original precondition. We can use this feature to solve the issue with the ZCB contract. The new precondition is A: 1B x 1 , i.e. we only require A's deposit. The revised contract is:

As before, the bank can withdraw 1B at any moment after stipulation. In the second part of the , the participants renegotiate the contract: if they both agree, 0B pass under the control of the contract . The precondition of requires the bank to provide 2B in a fresh deposit; upon renegotiation, A can withdraw 2B after the maturity date. The crucial difference with ZCB is that the deposit variable d is instantiated at renegotiation time, unlike x, which must be fixed at stipulation time.

The revised contract ZCB2 solves the problem of ZCB , in that it no longer freezes 2B for the whole duration of the bond: the bank could choose to renegotiate the contract, paying 2B, just before the maturity date. This flexibility comes at a cost, since A loses the guarantee to eventually receive 2B. To address this issue we need to add, as in the real world, an external mechanism. More specifically, we assume an insurance company I that, for an annual premium of pB paid by the bank, covers a face amount of f B (with 2 > f > 10p):

We revise the bond contract as follows:

The contract starts by transferring 1B to the bank, and the first year of the premium to the insurer. The remaining f B are transferred to the renegotiated contract 1 , or, if the renegotiation is not completed by 2021, to the investor.

We remark that the pattern D + t : D , where D requires some authorizations but D does not, is rather common in BitML, as it ensures that the contract can proceed even if the authorizations are not provided. Indeed, in such case an honest participant is enough to execute D after time t. By suitably exploiting this pattern, it is possible to guarantee that a BitML contract enjoys liveness, by just assuming that at least one participant is honest.

The contracts n , for n ∈ 1..9, allow the insurer to receive the annual premium until 2030: if the bank does not renegotiate the contract for the following year (paying the corresponding premium), then the investor can redeem the face amount of f B. Finally, the contract 10 can be triggered if the bank deposits the 2B: when this happens, the face amount is given back to the insurer, and the investor can redeem 2B after the maturity date.

Compared to ZCB2 , the contract ZCB3 offers more protection to the investor. To see why, we must evaluate A's payoff for all the possible behaviours of the other participants. If B and I are both honest, then A will redeem 2B, as in the ideal contract ZCB . Instead, if either B or I do not accept to renegotiate some n , then A can redeem f B as a partial compensation (unlike in ZCB2 , where A just loses 1B). In the real world, A could use this compensation to cover the legal fee to sue the bank in court; also, I could e.g. increase the premium for future interactions with B. By further refining the contract, we could model these real-world mechanisms as oracles, which sanction dishonest participants according to the evidence collected in the blockchain and in messages broadcast by participants. For instance, if B and I accept the renegotiation n but A does not, then the oracle would be able to detect A's dishonesty by inspecting the authorizations broadcast in year 2021 + n. The sanction could consist e.g. in blacklisting A, so to prevent her from buying other bonds from B.

We summarise our main contributions as follows:

-We extend BitML with the renegotiation primitive * :

, suitably adapting the language syntax and semantics. The new primitive increases the expressiveness of BitML: besides allowing participants to provide new deposits and secrets at run-time, it also allows for unbounded recursion.

-We extend the BitML compiler to the new primitive, making it possible to execute renegotiations on Bitcoin. We accordingly extend the computational soundness result in [11] , guaranteeing that the BitML semantics is coherent with the actual Bitcoin executions, also in the presence of adversaries. -We exploit renegotiation to design a new gambling game where two players repeatedly flip coins, and whoever wins twice in a row takes the pot (a form of unbounded recursion). We prove the game to be fair. -We introduce alternative renegotiation primitives, which allow participants to choose some parameters (e.g. the amounts to be deposited) at renegotiation time, and to change the set of participants involved in the renegotiated contract. We show that both primitives can be executed on Bitcoin as is.

We also introduce a primitive that, at the price of minor Bitcoin extensions, supports non-consensual renegotiations, which are automatically triggered by the contract without requiring the participants' agreement.

Because of space constraints, we relegate part of the technicalities to [9] .

We start by formalising contract preconditions. We use A, B, . . . to range over participants. We assume a set of deposit names x, y, . . ., a set of deposit variables d, e, . . ., and a set of secret names a, b, . . .. We use χ, χ , . . . to range over deposit names and variables, and v, v to range over non-negative values.

Contract preconditions have the following syntax (the deposits χ in a contract precondition G must be distinct):

The precondition A: v χ requires A to own vB in a deposit χ, and to spend it for stipulating the contract. The precondition A :

a requires A to generate a secret a, and commit to it before the contract starts. After stipulation, A can choose whether to disclose the secret a, or not.

To define contracts, we assume a set of recursion variables, ranged over by , , . . ., and a language of static expressions E, E , . . ., formed by integer constants k, integer variables α, β, . . ., and the usual arithmetic operators. We omit to define the syntax and semantics of static expressions, since they are standard. We assume that a closed static expression evaluates to a 32-bit value. We use the bold notation for sequences, e.g. x denotes a finite sequence of deposit names. Fig. 1 , where: (i) each recursion variable has a unique defining equation

E have the correct number of arguments;(iii) the names a in a p are distinct, and they include those occurring in p; (iv) in a prefix v → C , the sequences v and C have the same length. We denote with 0 the empty sum. We assume that the order of decorations is immaterial, e.g.,

A contract C is a choice among guarded contracts D i . A guarded contract a p. C continues as C once all the secrets a have been revealed and satisfy the predicate p. The guarded contract

A transfers the whole balance to A. When enabled, the above actions can be fired by anyone at anytime. To restrict who can execute a branch and when, one can use the decoration A : D, requiring to wait for A's authorization, and the decoration E : D, requiring to wait until the time specified by the static expression E. The action * :

E allows the participants involved in the contract to renegotiate it. Intuitively, if (α) = {G}C , then the contract continues as C { E /α } if all the participants give their authorization, and satisfy the precondition G.

The second condition is used to guarantee that the contract is stipulated only if all the involved participants give their authorizations. The last condition is only used to simplify the technical development. We outline in Sect. 5 how to relax it, by allowing renegotiations to exclude some participants, or to include new ones, which were not among those who originally stipulated the contract.

We now extend the reduction semantics of BitML [11] , by focussing on the new renegotiation primitive. Because of space limitations, here we just provide the underlying intuition, relegating the full formalisation to [9] . We start by defining the configurations of the semantics. 

We denote with Γ | t a timed configuration, where t ∈ N is a global time.

We illustrate configurations and their semantics through a series of examples.

A deposit A, v x can be subject to several operations, like e.g. split into two smaller deposits, join with another deposit, transfer to another participant, or destroy. In all cases A must authorise the operation. For instance, to authorize the join of two deposits, A can perform the following step:

After A also provides the dual authorization to spend y, anyone can actually join the deposits:

Advertisement. Any participant can broadcast a new contract advertisement {G}C , provided that all the deposits mentioned in G exist in the current configuration, and that the names of the secrets declared in G are fresh.

To stipulate an advertised contract {G}C , all the participants mentioned in it must fulfill the preconditions, and authorise the stipulation. For instance, let G = A: 1 x | B: 1 y | A : a, and let C be an arbitrary contract involving only A and B. The stipulation starts from a configuration containing the advertisement and the participants' deposits:

At this point the participants must commit to their secrets (in this case, only A has a secret). This is rendered as a sequence of steps:

represent ending the commitment phase (these steps might seem redundant, but they are useful to obtain a step-by-step correspondence between BitML executions and Bitcoin executions).

After that, A and B must perform an additional sequence of steps to authorize the transfer of their deposits x, y to the contract: At this point all the needed authorizations have been given, so the advertisement can be turned into an active contract. This step consumes the deposits and all the authorizations, and creates an active contract, with a fresh name z:

a, and C is an arbitrary contract involving only A and B, and possibly containing the integer variable α in static expressions. Here, G requires A and B to spend two 1B deposits, and A to commit to a secret. Unlike in the case of contract stipulation above, deposits names are unknown before renegotiation, so we use the deposit variables d, e to refer to them.

Consider a configuration * :

where C contains the branches alternative to the renegotiation. A possible execution of the action * :

k starts as follows: * :

where the advertisement {G } x C is obtained by transforming {G}C as follows: (i) variables d, e are renamed into fresh ones d , e , and similarly the secret name a into a ,(ii) the static expressions in C are evaluated, assuming α = k, and replaced with their results.The superscript x in the advertisement is used to record that, when the renegotiation is concluded, the contract x must be reduced.

In the subsequent steps participants choose the actual deposit names, and A commits to her secret. If A owns in Γ a deposit A, 1 y , she can choose d = y to satisfy the precondition G. Similarly, B can choose e = z if he owns such a deposit in Γ. These choices are performed as follows:

At this point, participants must authorise spending their deposits and the balance of the contract at x. This is done through a series of steps:

Finally, the new contract is stipulated. This closes the old contract, and transfers its balance to the newly generated one, with a fresh name x :

Note that the branches in C are discarded only in the last step above, where we complete the renegotiation. Before this step, it would have been possible to take one of the branches in C , aborting the renegotiation.

A transfers the whole contract balance to A:

After the execution, the alternative branch C is discarded, and a fresh deposit of vB for A is created. Note that the active contract x is terminated.

Split. The primitive divides the contract balance in n parts, each one controlled by its own contract. For instance, if n = 2:

After this step, the new spawned contracts C 1 and C 2 are executed concurrently.

Reveal. The prefix a p can be fired if all the committed secrets a have been revealed, and satisfy the guard p. For instance, if Γ = A : a#N | B : b#N :

The terms A : a#N and B : b#N represent the fact that the secrets a and b have been revealed. Crucially, only the participant who performed the commitment can add the corresponding term to the configuration.

A branch decorated by A : · · · can be taken only if the participant A has provided her authorization. For instance:

The leftmost configuration contains the term A[x A : B], which represents A's authorization to take the branch B. This enables the step to be taken. When multiple authorizations are required, the branch can be taken only after all of them occur in the configuration.

We represent time in configurations as Γ | t, where Γ is the untimed part of the configuration and t is the current time. We always allow the time to advance through the rule Γ | t − → Γ | t + δ, for all δ > 0. A branch decorated with d can be taken only if time d has passed. For instance:

For the branches not guarded by , we lift transitions from untimed to timed configurations: namely, for an untimed transition Γ − → Γ , we also have the timed transition Γ | t − → Γ | t. This reflects the assumption that participants can always meet deadlines, if they want to.

To execute a BitML contract, participants first compile it to a set of Bitcoin transactions, and then append these transactions to the blockchain, each following their own strategy. Participants' strategies can involve other actions besides appending transactions, like e.g. broadcasting signatures on given transactions (which corresponds, in BitML, to add an authorization to the configuration), revealing secrets, and waiting some time (see Definition 16 in [11] ). The coherence between the BitML semantics and the execution on Bitcoin is guaranteed by a step-by-step correspondence between the transitions of the BitML semantics and the actions performed by participants on the Bitcoin network.

In this section we illustrate the compiler and the execution protocol through a couple of examples, focussing on the new renegotiation primitive. The needed background on Bitcoin will be introduced along with these examples. We relegate the formal definition of the compilation rules to [9] .

Zero-Coupon Bond. Recall the ZCB contract from Sect. 1:

The precondition A: 1 x 1 | B: 2 x 2 requires A to deposit 1B in the contract, and B to deposit 2B. In Bitcoin, this precondition corresponds to requiring two unspent transactions redeemable by A and B, and containing the required amounts. We represent these transactions as follows, using the notation in [7] : Tx 1 in : · · · wit : · · · out : (λx.versig K(A) (x), 1B) Tx 2 in : · · · wit : · · · out : (λx.versig K(B) (x), 2B)

The transaction T x1 is a record with three fields (T x2 is similar). The in field points to one or more previous transactions in the blockchain. The field out is a pair, whose first element is a boolean predicate (with parameter x), and the second element, 1B, is the amount that a subsequent transaction satisfying the predicate can redeem from T x1 . Here, the predicate versig K(A) (x) is true when x is a signature of A on the redeeming transaction (i.e., one having T x1 as in). The contract ZCB is compiled into the transactions in Fig. 2 . The first one that can be appended to the blockchain is T init . This requires a few conditions to be met: (i) T x1 and T x2 are unspent on the blockchain, i.e. no other transactions spend them; (ii) the amount specified in the out field of T init does not exceed the sum of the amounts in T x1 and T x2 ;(iii) the predicates in the out fields of T x1 and T x2 are true, after replacing the formal parameters with the signatures sig K(A) and sig K(B) , contained in the wit field of T init .The contract ZCB becomes stipulated once T init is on the blockchain.

After that, the action can be performed by either A or B, by redeeming T init with T split . This transaction uses K(ZCB , {A, B}), a set of two key pairs, each one owned by each participant. These keys are only used in this step, to ensure that no transaction but T split can redeem T init .

The transaction T split creates two unspent outputs (indexed by 0 and 1), corresponding to the two parallel components of the , each with its own balance. These outputs can be redeemed independently, by different transactions. The output at index 0 can only be redeemed by T B (note that T B 's in field refers to the output 0 of T split ), transferring 1B to B. No other redemption is possible, since such output requires a signature with a specific key set, i.e. K( B, {A, B}), which is not used for any other purpose. Further, the output of T B can be redeemed with B's key, without A's one. Similarly, the output 1 of T split can be redeemed by T A , which in turns transfers 2B to A. The absLock field in T A ensures that this may only happen after time 2030.

The stipulation protocol followed by participants requires that all the signatures needed to append the transactions in Fig. 2 are exchanged before T init is appended. This is obtained by exchanging the signatures of T init after all the other signatures. This ensures that, once the execution of ZCB starts, any honest participant can make it proceed, by appending a transaction that correspond to any of the enabled BitML actions.

In general, to guarantee that such liveness property holds, the contract must be suitably crafted, using the D + t : D pattern discussed in Sect. 1. In Sect. 6 we discuss techniques to statically verify this property. Once these three transactions are on the blockchain, the only enabled action in the corresponding BitML contract is * :

, which asks 2B from B as a precondition. At the Bitcoin level, satisfying this precondition requires B to broadcast the identifier of a transaction T y holding 2B and redeemable by himself. In BitML, this corresponds to choosing the deposit name y for the deposit variable The renegotiation succeeds once T init is on the blockchain. After that, any participant can perform the A, by appending T A to the blockchain. As shown by this example, the compiler handles renegotiation as follows: -at stipulation time, it does not produce transactions for any * :

; -at renegotiation time, the participants broadcast the identifiers of their new deposits, and the commitments of their new secrets. Static expressions are then evaluated, and replaced by their value. Finally, the new contract is compiled as usual, with the exception that the new initial transaction has an extra input, which transfers the balance of the caller contract to the callee (in the ZCB2 example, this extra input is (T split , 1) within T init ).

Computational Soundness. The main result of [11] is computational soundness, which ensures that each execution trace at the Bitcoin level has a corresponding one in the semantics of BitML. This was achieved by formalizing the semantics of Bitcoin using a computational model, where participants can exchange bitstrings as messages, and append transactions to the blockchain. Then, a coherence relation was defined to relate symbolic runs to computational ones, essentially matching symbolic moves with their implementation in Bitcoin.

Our extension of BitML with renegotiation still enjoys computational soundness. The argument is similar, and requires extending the coherence relation to the new primitive. In particular, the reduction:

corresponds, in Bitcoin, to A broadcasting a message which contains the hashes of her secrets and the transaction identifiers that she wishes to use as deposits.

Instead, the reduction:

corresponds to A signing all the transactions obtained by compiling the new contract, and broadcasting the signatures. A participant signs T init only after receiving the signatures of the other transactions from all the other participants.

Computational soundness requires that each contract involves at least one participant, say A, who follows the Bitcoin implementation of BitML. In particular, A follows the stipulation and renegotiation protocols correctly, i.e. signing nothing but the protocol messages, and signing T init last. We also make the usual assumptions on computational adversaries: they can only run PPTIME algorithms, and they can break the underlying cryptography with negligible probability, only. Consequently, we only consider computational runs of polynomial length (with respect to the security parameter). This is because in longer runs the adversary would be able to break the cryptography by brute force.

Below, we provide an intuitive statement of computational soundness. The formal statement is in [9] .

Bitcoin-level computational run has a corresponding coherent BitML run, with overwhelming probability.

To illustrate recursion in our extended BitML, we introduce a simple game where two players repeatedly flip coins, and the one who wins two consecutive flips takes the pot. The precondition requires each player to deposit 3B and choose a secret:

The contract CFG (Fig. 3) asks B to reveal his secret first: if B waits too much, A can withdraw the contract funds after time 1. Then, it is A's turn to reveal (before time 2, otherwise B can withdraw the funds). The current flip winner is A if the secrets of A and B are equal, otherwise it is B. At this point, the contract can be renegotiated as A 1 or B 1 , depending on the flip winner (the parameter 1 represents the round). If players do not agree on the renegotiation, then the funds are split fairly, according to the current expected win.

The contract A n requires A and B to generate fresh secrets for the n-th turn. If A wins again, she can withdraw the pot, otherwise the contract can be renegotiated as B n + 1 . If the players do not agree on the renegotiation, the pot is split fairly between them. The contract B is similar.

The following theorem states that our coin flipping game is fair. Fairness ensures that the expected payoff of a rational player is always non-negative, notwithstanding the behaviour of the other player. Rational players must choose random secrets in {0, 1}. Indeed, non uniformly distributed secrets can make the adversary bias the coin flip in her favour. Further, choosing a secret different from 0 or 1 would decrease the player payoff. Indeed, B would be prevented from revealing his secrets (by the predicate in the b), and so A could win after the timeout. If A chooses a secret different from 0 or 1, she makes B win the round (since B wins when the secrets are different). Rationality also requires to reveal secrets in time (before the alternative branch is enabled), and to take the Split branch if restipulation does not occur in time. This ensures that, when renegotiation happens, there is still time to reveal the round secrets. Indeed, a late renegotiation could enable the other player to win by timeout.

Proof (Sketch). First, we consider the case where renegotiation always happens. A rational player wins each coin flip with probability 1/2, at least: so, the probability of winning the whole game is also 1/2, at least. In the general case, the renegotiation at the end of each round may fail. When this happens, the rational player takes the Split branch, distributing the pot according to the expected payoff in the current game state, thus ensuring the fairness of the whole game. The player who won the last coin flip is expected to win pB, with p = 1 /2 · 6 + 1 /2 · ( 1 /2 · p + 1 /2 · 0), giving p = 4. Accordingly, the Split contracts transfer 4B to the winner of the last flip and (6 − 4)B = 2B to the other player.

The renegotiation primitive we have proposed for BitML is motivated by its simplicity, and by the possibility of compiling into standard Bitcoin transactions. By adding some degree of complexity, we can devise more general primitives, which could be useful in certain scenarios. We discuss below some alternatives.

Renegotiation-Time Parameters. The primitive * :

E allows participants to choose at run-time only the deposit variables used in the renegotiated contracts, and to commit to new secrets. A possible extension is to allow participants to choose at run-time arbitrary values for the renegotiation parameters E.

For instance, consider a mortgage payment, where a buyer A must pay 10B to a bank B in 10 installments. After A has paid the first five installments (of 1B each), the bank might propose to renegotiate the contract, varying the amount of the installment. Using the BitML renegotiation primitive presented in Sect. 2, we could not model this contract, since the new amount and the number of installments are unknown at the time of the original stipulation. Technically, the issue is that the primitive * :

E only involves static expressions E, the value of which is determined at stipulation time.

To cope with non-statically known values, we could extend guarded contracts with terms of the form * :

B : v , declaring that the value v is to be chosen by B at renegotiation time. For instance, this would allow to model our installments payment plan as 1 , with the following defining equations:

where in 5 , the bank chooses the number of installments k, as well as the amount v of each installment. Note that if A does not agree with these values, the renegotiation fails. A more refined version of the contract should take this possibility into account, by adding suitable compensation branches. Although adding the new primitive would moderately increase the complexity of the semantics and of the compiler, this extension can still be implemented on top of standard Bitcoin, preserving our computational soundness result.

Renegotiation with a Given set of Participants. As we have remarked in Sect. 2, a renegotiation can be performed only if all the participants of the contract agree. To generalise, we could require the agreement of a given set of participants (possibly, not among those who originally stipulated the contract).

For instance, consider an escrow service between a buyer A and a seller B for the purchase of an item worth 1B. The normal case is that the buyer authorizes the transfer of 1B after receiving the item, but it may happen that a dishonest seller never sends the item, or that a dishonest buyer never authorizes the payment. To cope with these cases, the participants can renegotiate the contract, including an escrow service M which mediates the dispute, as follows: A means that only A and M need to agree in order for the contract A to be executed, resolving the dispute. In this case it is crucial that the renegotiation is possible even without the agreement between A and B. Indeed, if M decides to refund A (by authorizing A ), it is not to be expected that also B agrees. Similarly to the one discussed before, also this extension can be implemented on-top of Bitcoin. The computational soundness property is preserved, under the assumption that at least one participant in any renegotiation is honest, i.e. it follows the renegotiation protocol. Crucially, if a renegotiation only involves dishonest participants, the renegotiated contract could be anything, not necessarily that prescribed in the original contract.

Non-consensual Renegotiation. In the variants of * : discussed before, renegotiation requires one or more participants to agree. Hence, each use of * : must include suitable alternative branches, to be fired in case the renegotiation fails. In certain scenarios, we may want to renegotiate the contract without the participants having to agree. To this purpose, we can introduce a new primitive , which continues as without requiring anyone to agree. For simplicity, we assume the defining equations of this primitive of the form (α) = {v}C , where v represents the amount of B added to the contract, by anyone.

We exemplify the new primitive to design a two-players game which starts with a bet of 1B from A, and a bet of 2B from B. Then, starting from A, players take turns adding 2B each to the pot. The first one who is not able to provide the additional 2B within a given time loses the game, allowing the other player to take the whole pot. The contract is as follows:

Unlike * : , the action can be fired without the authorizations of all the players: it just requires that the authorization to gather 2B is provided, by anyone. Even though the sender of these 2B is not specified in the contract, it is implicit in the game mechanism: for instance, when A n calls B n + 1 , only B is incentivized to add 2B, since not doing so will make A win.

Implementing the primitive on top of Bitcoin seems unfeasible: even if it were possible to use complex off-chain multiparty computation protocols [16] , doing so might be impractical. Rather, we would like to extend Bitcoin as much as needed for the new primitive. In our implementation of BitML, we compile contracts to sets of transactions and make participants sign them. In standard BitML this is doable since, at stipulation time, we can finitely overapproximate the reducts of the original contract. Recursion can make this set infinite, e.g. A 2 , A 3 , . . ., hence impossible to compile and sign statically. A way to cope with this is to extend Bitcoin with malleable signatures which only cover the part of the transaction not affected by the parameter n in B n . Further, signatures must not cover the in fields of transactions, since they change as recursion unfolds. In this way, the same signature can be reused for each call.

Adding malleability provides flexibility, but poses some risks. For instance, instead of redeeming the transaction corresponding to A n with the transaction of B n + 1 one could instead use the transaction of B n + 100 , since the two transactions have the same signature. To overcome this problem, we could add a new opcode to allow the output script of B n to access the parameter in the redeeming transaction, so to verify that it is indeed n + 1 as intended. Similarly, to check that we have 2B more in the new transaction, an opcode could provide the value of the new output. The same goal could be achieved by adapting the techniques used in [24, 25] to realize covenants.

We have investigated linguistic primitives to renegotiate BitML contracts, and their implementation on standard Bitcoin. More expressive primitives could be devised by relaxing this constraint, e.g. assuming the extended UTXO model [14] .

The existing verification technique for BitML [12] is based on a sound and complete abstraction of the state space of contracts. Since this abstraction is finite-state, it can be model-checked to verify the required properties. The same technique can be directly applied to BitML contracts featuring renegotiation (but without recursion), since the abstraction would remain finite. Instead, the same abstraction on recursive contracts would lead to infinitely many states. Even if we could exploit the fact that Bitcoin uses 32-bit integers to make the state space finite, it would still be too large for verification to be practical.

If we assume that integers are unbounded, and that participants always accept renegotiations, the extension of BitML presented in Sect. 2 can simulate a counter machine, so making BitML Turing-complete. Hence, verification cannot be sound and complete. Alternative techniques to model checking (e.g., type-based approaches [15] ) could be used to analyse relevant contract properties.

Fair two-party computations via Bitcoin deposits

Secure multiparty computations on Bitcoin

Secure multiparty computations on Bitcoin

A survey of attacks on ethereum smart contracts (SoK)

SoK: unraveling Bitcoin smart contracts

Developing secure Bitcoin contracts with BitML

A formal model of Bitcoin transactions

Efficient zero-knowledge contingent payments in cryptocurrencies without scripts

Renegotiation and recursion in Bitcoin contracts

Constant-deposit multiparty lotteries on Bitcoin

BitML: a calculus for Bitcoin smart contracts

Verifying liquidity of Bitcoin contracts

How to use Bitcoin to design fair protocols

The extended UTXO model

Resource-aware session types for digital contracts

Sok: Off the chain transactions. IACR Cryptology ePrint Archive

Composing contracts: an adventure in financial engineering, functional pearl

How to use Bitcoin to incentivize correct computations

Amortizing secure computation with penalties

How to use Bitcoin to play decentralized poker

Improvements to secure computation with penalties

Making smart contracts smarter

Zero-collateral lotteries in Bitcoin and Ethereum

Bitcoin covenants

Enhancing Bitcoin transactions with covenants