Building Trust on Bitcoin: A Look at How Pre-Signed Transaction Trees Secure Contracts

Table of Links Abstract and 1. Introduction Abstract and 1. Introduction On-chain contracts Off-chain contracts Conclusions and References On-chain contracts On-chain contracts Off-chain contracts Off-chain contracts Conclusions and References Conclusions and References 2. On-chain contracts We represent contracts C as trees of transactions, as in Figure 1. Transactions highlighted in yellow are those already on the blockchain. We will assume that every participant of the contract (denoted with A, B, · · · ) spends at least one of their transaction output into the first transaction of the contract. Edges in the tree represent requirements that need to be satisfied in order for a transaction to be redeemed. Such restrictions are either set by the script of the “parent” transaction (for instance asking to sign the redeeming transaction with a specific key, or to reveal the preimage of a given hash), or they can be set within the redeeming transaction itself, like in the case of timelocks, that force the transaction to wait for a certain amount of blocks before it can be appended. We assume that all the edges represented with solid lines implicitly ask for a signature of every contract participant in addition to the signatures specified along the edges. These extra signatures are crucial to the contract stipulation protocol: we will refer to them as implicit signatures. In fact, this requirement ensures that if at least one participant is honest (i.e. wants to abide by the original semantics of the contract), then the others can not deviate from the intended behaviour of the contract, since doing so would require a signature from every participant (including the honest ones). implicit signatures To stipulate a contract, participants first exchange messages containing every transaction in the tree. Then, they exchange all the implicit signatures on each transaction. Finally, they exchange the signatures for the root transaction T0 and put it on the blockchain, ending the stipulation phase. We stress that the whole tree must be signed before T0 is. Not doing so would allow an adversary to put a part of the tree on chain and then prevent the rest of the contract to be executed by refusing to sign the continuation. Once T0 is on the blockchain, participants can execute the contract by following a branch of the tree. At each step they have to satisfy the requirements shown on the edges of the tree, and then put the corresponding transaction on chain. Note that, during the execution of the contract, the implicit requirements are already satisfied, since those signatures have already been exchanged during the stipulation phase. Example: Best-of-3 Bet We illustrate the on-chain execution of a contract through an example. The tree of transactions presented in Figure 2 implements a best-of-three bet between Alice and Bob, on some kind of recurring match between two teams. Before the competition starts, an oracle commits the hashes of six secret messages: three of them denote that the first team won a match, while the other three denote that it lost [1]. After each match the oracle certifies the victory or loss of the team by revealing the suitable secret message. These secrets can then be used by Alice and Bob to update the state of the contract, appending a new transaction to the blockchain. Transactions in the contract are named to represent the win-loss record associated to the corresponding state, from the point of view of the first team, meaning that W?? represents the state in which the first team has won once, and two matches still have to be played, while LWL represents the state in which the first team has lost, then won, then lost again. The contract ends when either team has won two out of three matches, or when both Alice and Bob agree to an early payout, terminating the bet before the three matches have been played. The contract has 10 possible terminations, shown in the tree as 10 leaves. Authors: (1) Dario Maddaloni, Università degli studi di Trento (dariomaddaloni.6@gmail.com); (2) Riccardo Marchesin, Università degli studi di Trento (riccardo.marchesin@unitn.it); (3) Roberto Zunino, Università degli studi di Trento (roberto.zunino@unitn.it). Authors: Authors: (1) Dario Maddaloni, Università degli studi di Trento (dariomaddaloni.6@gmail.com); (2) Riccardo Marchesin, Università degli studi di Trento (riccardo.marchesin@unitn.it); (3) Roberto Zunino, Università degli studi di Trento (roberto.zunino@unitn.it). This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv available on arxiv [1] The 6 messages contain the strings 𝑊1, 𝑊2, 𝑊3, 𝐿1, 𝐿2, 𝐿3 and are padded with a nonce for security. Note that the oracle is not a contract participant, and does not need to be aware of the bet between Alice and Bob. Indeed its role could be performed by three distinct oracles, one for each match.