Secure Multiparty Computations on Bitcoin
Marcin Andrychowicz, Stefan Dziembowski
∗
, Daniel Malinowski, Łukasz Mazurek
University of Warsaw, Poland
{marcin.andrychowicz, stefan.dziembowski, daniel.malinowski, lukasz.mazurek}@crypto.edu.pl
∗
on leave from Sapienza University of Rome
Abstract
Bitcoin is a decentralized digital currency, introduced in 2008, that has recently gained noticeable popularity. Its main features
are: (a) it lacks a central authority that controls the transactions, (b) the list of transactions is publicly available, and (c) its syntax
allows more advanced transactions than simply transferring the money. The goal of this paper is to show how these properties of
Bitcoin can be used in the area of secure multiparty computation protocols (MPCs).
Firstly, we show that the Bitcoin system provides an attractive way to construct a version of “timed commitments”, where the
committer has to reveal his secret within a certain time frame, or to pay a fine. This, in turn, can be used to obtain fairness in
some multiparty protocols. Secondly, we introduce a concept of multiparty protocols that work “directly on Bitcoin”. Recall that
the standard definition of the MPCs guarantees only that the protocol “emulates the trusted third party”. Hence ensuring that the
inputs are correct, and the outcome is respected is beyond the scope of the definition. Our observation is that the Bitcoin system
can be used to go beyond the standard “emulation-based” definition, by constructing protocols that link their inputs and the outputs
with the real Bitcoin transactions.
As an instantiation of this idea we construct protocols for secure multiparty lotteries using the Bitcoin currency, without relying
on a trusted authority (one of these protocols uses the Bitcoin-based timed commitments mentioned above). Our protocols guarantee
fairness for the honest parties no matter how the loser behaves. For example: if one party interrupts the protocol then her money
is transferred to the honest participants. Our protocols are practical (to demonstrate it we performed their transactions in the actual
Bitcoin system), and can be used in real life as a replacement for the online gambling sites. We think that this paradigm can have
also other applications. We discuss some of them.
Keywords
bitcoin; multiparty; lottery;
I. INTRODUCTION
Secure multiparty computation (MPC) protocols, originating from the seminal works of Yao [41] and Goldreich et al. [29],
allow a group of mutually distrusting parties to compute a joint function f on their private inputs. Typically, the security of such
protocols is defined with respect to the ideal model where f is computed by a trusted party T
f
. More precisely: it is required
that during the execution of a protocol the parties cannot learn more information about the inputs of the other participants than
they would learn if f was computed by T
f
who: (a) receives the inputs from the parties, (b) computes f , and (c) sends the
output back to the parties. Moreover, even if some parties misbehave and do not follow the protocol, they should not be able to
influence the output of the honest parties more than they could in the ideal model by modifying their own inputs.
As an illustration of the practical meaning of such security definition consider the case when there are only two participants,
called Alice and Bob, and the function that they compute is a conjunction f
∧
(a, b) = a ∧ b, where a, b ∈ {0, 1} are Boolean
variables denoting the inputs of Alice and Bob, respectively. This is sometimes called the marriage proposal problem, since one
can interpret the input of each party as a declaration if she/he wants to marry the other one. More precisely: suppose a = 1 if
and only if Alice wants to marry Bob, and b = 1 if and only if Bob wants to marry Alice. In this case f
∧
(a, b) = 1 if and only
if both parties want to marry each other, and hence, if, e.g., b = 0 then Bob has no information about Alice’s input. Therefore
the privacy of Alice is protected.
One can also consider randomized functions f, the simplest example being the coin tossing problem [9] where the computed
function f
rnd
: {⊥} × {⊥} → {0, 1} takes no inputs, and outputs a uniformly random bit. Yet another generalization are the
so-called reactive functionalities where the trusted party T maintains a state and the parties can interact with T in several rounds.
One example of such a functionality is the mental poker [39] where T simulates a card game, i.e. she first deals a deck of cards
and then ensures that the players play the game according to the rules.
It was shown in [29] that for any efficiently-computable function f (or, more general, any reactive functionality) there exists
an efficient protocol that securely computes it, assuming the existence of the trapdoor-permutations. If the minority of the parties
is malicious (i.e. does not follow the protocol) then the protocol always terminates, and the output is known to each honest
participant. If not, then the malicious parties can terminate the protocol after learning the output, preventing the honest parties
from learning it. It turns out [20] that in general this problem, called the lack of fairness, is unavoidable, although there has
been some effort to overcome this impossibility result by relaxing the security requirements [30], [15], [6], [35]. Note that in
case of the two-player protocols it makes no sense to assume that the majority of the players is honest, as this would simply
mean that none of the players is malicious. Hence, the two-party protocols in general do not provide complete fairness (unless
the security definition is weakened).
Since the introduction of the MPCs there has been a significant effort to make these protocols efficient [32], [7], [22]
and sometimes even to use them in the real-life applications such as, e.g., the online auctions [10]. On the other hand, perhaps
surprisingly, the MPCs have not been used in many other areas where seemingly they would fit perfectly. One prominent example
is the internet gambling: it may be intriguing that currently gambling over the internet is done almost entirely with the help
of the web-sites that play the roles of the “trusted parties”, instead of using the coin flipping or the mental poker protocols.
This situation is clearly unsatisfactory from the security point of view, especially since in the past there were cases when the
operators of these sites abused their privileged position for their own financial gain (see e.g. [36]). Hence, it may look like the
multiparty techniques that eliminate the need for a trusted party would be a perfect replacement for the traditional gambling sites
(an additional benefit would be a reduced cost of gambling, since the gambling sites typically charge fees for their service).
In our opinion there are at least two main reasons why the MPCs are not used for online gambling. The first reason is that
the multiparty protocols do not provide fairness in case there is no honest majority among the participants. Consider for example
a simple two-party lottery based on the coin-tossing protocol: the parties first compute a random bit b, if b = 0 then Alice pays
$1 to Bob, if b = 1 then Bob pays $1 to Alice, and if the protocol did not terminate correctly then the parties do not pay
any money to each other. In this case a malicious party, say Alice, could prevent Bob from learning the output if it is equal
to 0, making 1 the only possible output of a protocol. Since this easily generalizes to the multiparty case, it is clear that the
gambling protocol would work only if the majority is honest, which is not a realistic assumption in the fully distributed internet
environment (there are many reasons for this, one of them being the sybil attacks [23] where one malicious party creates and
controls several “fake” identities, easily obtaining the “majority” among the participants).
The second reason is even more fundamental, as it comes directly from the inherent limitations of the MPC security definition,
namely: such protocols do not provide security beyond the trusted-party emulation. This drawback of the MPCs is rarely mentioned
in the literature as it seems obvious that in most of the real-life applications cryptography cannot be “responsible” for controlling
that the users provide the “real” input to the protocol and that they respect the output. Consider for example the marriage proposal
problem: it is clear that even in the ideal model there is no technological way to ensure that the users honestly provide their
input to the trusted party, i.e. nothing prevents one party, say Bob, to lie about his feelings, and to set b = 1 in order to learn
Alice’s input a. Similarly, forcing both parties to respect the outcome of the protocol and indeed marry cannot be guaranteed in
a cryptographic way. This problem is especially important in the gambling applications: even in the simplest “two-party lottery”
example described above, there exists no cryptographic method to force the loser to transfer the money to the winner.
One pragmatic solution to this problem, both in the digital and the non-digital world is to use the concept of “reputation”:
a party caught on cheating (i.e. providing the wrong input or not respecting the outcome of the game) damages her reputation
and next time may have trouble finding another party willing to gamble with her. Reputation systems have been constructed and
analyzed in several papers (see, e.g. [37] for an overview), however they seem too cumbersome to use in many applications, one
reason being that it is unclear how to define the reputation of the new users in the scenarios when the users are allowed to pick
new names whenever they want [26].
Another option is to exploit the fact that the financial transactions are done electronically, and hence one could try to
“incorporate” the final transaction (transferring $1 from the loser to the winner) into the protocol, in such a way that the parties
learn who won the game only when the transaction has already been performed. It is unfortunately not obvious how to do it
within the framework of the existing electronic cash systems. Obviously, since the parties do not trust each other, we cannot
accept solutions where the winning party learns e.g. the credit card number, or the account password of the loser. One possible
solution would be to design a multiparty protocol that simulates, in a secure way, a simultaneous access to all the online accounts
of the participants and executes a wire transfers in their name.
1
Even if theoretically possible, this solution is clearly very hard
to implement in real life, especially since the protocol would need to be adapted to several banks used by the players (and
would need to be updated whenever they change). The same problems occur obviously also if above we replace the “bank”
with some other financial service (like PayPal). One could consider using Chaum’s Ecash [17], or one of its variants [18], [16].
Unfortunately, none of these systems got widely adopted in real-life. Moreover, they are also bank-dependent, meaning that even
if they get popular, one would face a challenge of designing a protocol that simulates the interaction of a real user with a bank,
and make it work for several different banks.
We therefore turn our attention to Bitcoin, which is a decentralized digital currency introduced in 2008 by Satoshi Nakamoto
2
[34]. Bitcoin has recently gained a noticeable popularity (its current market capitalization is over $5 billion) mostly due to its
distributed nature and the lack of a central authority that controls the transactions. Because of that it is infeasible for anyone
to take control over the system, create large amounts of coins (to generate inflation), or shut it down. The money is transferred
directly between two parties — they do not have to trust anyone else and transaction fees are zero or very small. Another
advantage is pseudonymity
3
— the users are only identified by their public keys that can be easily created, and hence it is hard
1
Note that this would require, in particular, “simulating” the web-browser and the SSL sessions, since each individual user should not learn the contents of
the communication between the “protocol” and his bank, as otherwise he could interrupt the communication whenever he realizes that the “protocol” ordered a
wire transfer from his account. Moreover, one would need to assume that the transactions cannot be cancelled once they were ordered.
2
This name is widely believed to be a pseudonym.
3
A very interesting modification of Bitcoin that provides real cryptographic anonymity has been recently proposed in [33].
to link the real person with the virtual party spending the money. However, since all the transactions and the connections between
them are publicly known there are several ways to extract some information about Bitcoin users from the block chain, see e.g.
[38].
In Section II we describe the main design principles of Bitcoin, focusing only on the most relevant parts of this system.
A more detailed description can be found in Nakamoto’s original paper [34], the Bitcoin wiki webpage en.bitcoin.it (sections
particularly relevant to our work are: “Transactions” and “Contracts”), or other papers on Bitcoin [33], [19], [5], [38]. In the
sequel “B” denotes the Bitcoin currency symbol.
A. Our contribution
We study how to do “MPCs on Bitcoin”. First of all, we show that the Bitcoin system provides an attractive way to construct
a version of “timed commitments” [11], [27], where the committer has to reveal his secret within a certain time frame, or to pay
a fine. This, in turn, can be used to obtain fairness in certain multiparty protocols. Hence it can be viewed as an “application of
Bitcoin to the MPCs”.
What is probably more interesting is our second idea, which in some inverts the previous one by showing an “application
of the MPCs to Bitcoin”, namely we introduce a concept of multiparty protocols that work directly on Bitcoin. As explained
above, the standard definition of the MPCs guarantees only that the protocol “emulates the trusted third party”. Hence ensuring
that the inputs are correct, and the outcome is respected is beyond the scope of the definition. Our observation is that the Bitcoin
system can be used to go beyond the standard “emulation-based” definition, by constructing protocols that link the inputs and
the outputs with the real Bitcoin transactions. This is possible since the Bitcoin lacks a central authority, the list of transactions
is public, and its syntax allows more advanced transactions than simply transferring the money.
As an instantiation of this idea we construct protocols for secure multiparty lotteries using the Bitcoin currency, without
relying on a trusted authority. By “lottery” we mean a protocol in which a group of parties initially invests some money, and at
the end one of them, chosen randomly, gets all the invested money (called the pot). Our protocols can work in purely peer-to-peer
environment, and can be executed between players that are anonymous and do not trust each other. Our constructions come with
a very strong security guarantee: no matter how the dishonest parties behave, the honest parties will never get cheated. More
precisely, each honest party can be sure that, once the game starts, it will always terminate and will be fair.
Our two main constructions are as follows. The first protocol (Section IV) can be executed between any number of parties.
Its security is obtained via the so-called deposits: each user is required to initially put aside a certain amount of money, which
will be paid back to her once she completes the protocol honestly. Otherwise the deposit is given to the other parties and
“compensates” them the fact that the game terminated prematurely. This protocol uses the timed commitment scheme described
above. A certain drawback of this protocol is that the deposits need to be relatively large, especially if the protocol is executed
among larger groups of players. More precisely to achieve security the deposit of each player needs to be N(N − 1) times the
size of the bet (observe that for the two-party case it simply means that the deposit is twice the size of the bet).
We also describe (in Section V) a protocol that does not require the use of deposits at all. This comes at a price: the protocol
works only for two parties, and its security relies on an additional assumption (see Section V for more details).
The only cost that the participants need to pay in our protocols are the Bitcoin transaction fees. The typical Bitcoin transactions
are currently free. However, the participants of our protocols need to make a small number of non-standard transactions (so-called
“strange transactions”, see Section II), for which there is usually some small fee (currently around 0.00005B ≈ $0.03). To keep
the exposition simple we initially present our results assuming that the fees are zero, and later, in Section VI, argue how to
extend the definitions and security statements to take into account also the non-zero fees. For the sake of simplicity we also
assume that the bets in the lotteries are equal to 1 B. It should be straightforward to see how to generalize our protocols to other
values of the bets.
Our constructions are based on the coin-tossing protocol of Blum [9]. We managed to adapt this protocol to our model, without
the need to modify the current Bitcoin system. We do not use any generic methods like the MPC or zero-knowledge compilers, and
hence the protocols are very efficient. The only cryptographic primitives that we use are the commitment schemes, implemented
using the hash functions (which are standard Bitcoin primitives). Our protocols rely strongly on the advanced features of the
Bitcoin (in particular: the so-called “transaction scripts”, and “time-locks”). Because of the lack of space we only sketch the
formal security definitions. The security proofs will appear in an extended version of this paper. We executed our transactions
on the real Bitcoin. We provide a description of these transactions and a reference to them in the Bitcoin chain.
B. Applications and future work
Although, as argued in Section I-C below, it may actually make economic sense to use our protocols in practice, we view
gambling mostly as a motivating example for introducing a concept that can be called “MPCs on Bitcoin”, and which will
hopefully have other applications. One (rather theoretical) example of such application is the “millionaires problem” where Alice
and Bob want to establish who is richer.
4
It is easy to see that Alice and Bob can (inefficiently) determine who has more coins
4
The formal definition is as follows: let a, b ∈ N denote the amount of coins that Alice and Bob respectively own. In this case the parties compute the
function f
mill
: N × N → {A, B} defined as: f
mill
(a, b) = A if and only if a ≥ b and f
mill
(a, b) = B otherwise.
by applying the generic MPC and zero-knowledge techniques. This is possible since the only inputs that are needed are (a) the
contents of the Bitcoin ledger (more precisely: its subset consisting of the non-redeemed transactions), which is public, and (b)
Alice’s and Bob’s private keys used as their respective private inputs (see Section II for the definitions of these terms). Obviously,
using this protocol makes sense only if, for some reason, each party is interested in proving that she is the richer one. This is
because every participant can easily pretend to be poorer than she really is and “hide” his money by transferring it to some
other address (that he also controls). Since we do not think that this protocol is particularly relevant to practical applications, we
do not describe it in detail here. Let us only observe that, interestingly, this protocol is in some sense dual to the coin-tossing
protocol, as it uses the Bitcoin system to verify the correctness of the inputs, instead guaranteeing that the outcome is respected
(as it is the case with the coin-tossing)
5
.
We think that analyzing what functionalities can be computed this way (taking into account the problem of the participants
“pretending to be poorer than they really are”) may be an interesting research direction. Other possible future research directions
are: constructing protocols secure against “malleability attacks” and “eavesdropping attacks” (see Sec. V for more details) that
do not require the deposits, providing a more formal framework to analyze the deposit-based technique (this can probably be
done using the tools from the “rational cryptography” literature [31], [1], [28]).
C. Economic analysis
Besides of being conceptually interesting, we think that our protocols can have direct practical applications in the online
gambling, which is a significant market: it is estimated that there are currently 1,700 gambling sites worldwide handling bets
worth over $4 billion per year [25]. Some of these sites are using Bitcoin. The largest of them, SatoshiDice, has been recently
sold for over $12 million [14]. All of the popular sites charge a fee for their service, called the house edge (on top of the Bitcoin
transaction fees). Currently, the honesty of these sites can be verified only ex post facto: they commit to their randomness before
the game starts and later prove to the public that they did not cheat. Hence, nothing prevents them from cheating and then
disappearing from the market (using the MPC terminology: such protocols provide security only against the “covert adversaries”
[40]). Of course, this means that the users need to continually monitor the behavior of the gambling sites in order to identify the
honest ones. This system, called the “mathematically provable fairness” is described in a recent article [13], where it is advised
to look on a particular page, called Mem’s Bitcoin Gambling List, to check the gambling sites’ reputation. This simple reputation
system can of course be attacked in various ways. Moreover, one can expect that the sites with more established reputation
will have a higher house edge, and indeed the SatoshiDice site charges more than the other, less well-known, sites. Currently
SatoshiDice house edge is around 2% [13].
Compared to the gambling sites, our protocols have the following advantage. First of all, the security guarantee is stronger,
as it does not depend on the honesty of any trusted party. Secondly, in our protocols there is obviously no “house edge”. On
a negative side, the Bitcoin transaction fees can be slightly larger in our case than in the case of the gambling sites (since we
have more transactions, and some of them are “strange”). At the moment of writing this paper, using our solution is cheaper
than using SatoshiDice for bets larger than, say, $5, but of course whether our protocols become really widely used in practice
depends on several factors that are hard to predict, like the value of the fees for the “strange transactions”.
We also note that, although our initial motivation was the peer-to-peer lottery, it can actually make a lot of sense for the
online gambling services to use our solutions, especially the two-party protocol. Of course the business model of such services
makes sense only if there is non-zero house edge. This is not a problem since our protocols can be easily used in lotteries where
the expected payoff is positive for one party (in this case: the gambling service) and it is negative for the other one (the client).
Such “provably guaranteed fairness” can be actually a good selling line for some of these services.
D. Previous, concurrent and subsequent work
Some of the related work has been already described in the earlier sections. Previous papers on Bitcoin analyze the Bitcoin
transaction graph [38], or suggest improvements of the current version of the system. This includes important work of Barber et
al. [5] who study various security aspects of Bitcoin and Miers et al. [33] who propose a Bitcoin system with provable anonymity.
Our paper does not belong to this category, and in particular our solutions are fully compatible with the current version of Bitcoin
(except of the ,,malleability” and ,,eavesdropping” problem concerning the last protocol, Section V).
Usage of Bitcoin to create a secure and fair two-player lottery has been independently proposed by Adam Back and Iddo
Bentov in [4]. Similarly to our solution, their protocol makes use of the time-locked transactions, but the purpose they are used
for is slightly different. Their protocol uses time-locks to get the deposit back if the protocol is interrupted, while this paper uses
time-locks to make a financial compensation to an honest party, whenever the other party misbehaves. Additionally, protocol
from [4] is not resilient to the malleability attacks, while our main schemes (Section III and IV) are.
Another work relevant to ours is Section 7.1 of [5] where the authors construct a secure “mixer”, that allows two parties to
securely “mix” their coins in order to obtain unlinkability of the transactions. They also construct commitment schemes with
time-locks, which are similar to these from [4]. Also, the main motivation of this work is different: the goal of [5] is to fix an
5
The reader may be tempted to think that a similar protocol could be used with the eCash [17]. This is not the case, as in eCash there is no method of proving
in zero-knowledge that the money has not been spent (since the list of transactions is not public).
existing problem in Bitcoin (“linkability”), while our goal is to use Bitcoin to perform tasks that are hard (or impossible) to
perform by other methods.
Commitments in the context of the Bitcoin were also considered in [19], however, the construction and its applications are
different — the main idea of [19] is to use the Bitcoin system as a replacement of a trusted third party in time-stamping.
The notion of “deposits” has already been used in Bitcoin (see en.bitcoin.it/wiki/Contracts, Section “Example 1”
6
), but the
application described there is different: the “deposit” is a method for a party with no reputation to prove that she is not a
spambot by temporarily sacrificing some of her money.
In the subsequent work [2], [3] we show how to extend the ideas from this paper in order to construct a fair two-party
protocol for any functionality. Similar ideas were developed independently by Iddo Bentov and Ranjit Kumaresan [8].
E. Acknowledgments
We would like to thank Iddo Bentov and Ranjit Kumaresan for fruitful discussions and for pointing out an error in a previous
version of our lottery (see footnote 18 on page 12).
This work was supported by the WELCOME/2010-4/2 grant founded within the framework of the EU Innovative Economy
(National Cohesion Strategy) Operational Programme.
II. A SHORT DESCRIPTION OF BITCOIN
Bitcoin works as a peer-to-peer network in which the participants jointly emulate the central server that controls the correctness
of transactions. In this sense it is similar to the concept of the multiparty computation protocols. Recall that, as described above,
a fundamental problem with the traditional MPCs is that they cannot provide fairness if there is no honest majority among
the participants, which is particularly difficult to guarantee in the peer-to-peer networks where the sybil attacks are possible.
The Bitcoin system overcomes this problem in the following way: the honest majority is defined in terms of the “majority of
computing power”. In other words: in order to break the system, the adversary needs to control machines whose total computing
power is comparable with the combined computing power of all the other participants of the protocol. Hence, e.g., the sybil
attack does not work, as creating a lot of fake identities in the network does not help the adversary. In a moment we will explain
how this is implemented, but let us first discuss the functionality of the trusted party that is emulated by the users.
One of the main problems with the digital currency is the potential double spending: if coins are just strings of bits then
the owner of a coin can spend it multiple times. Clearly this risk could be avoided if the users had access to a trusted ledger
with the list of all the transactions. In this case a transaction would be considered valid only if it is posted on the board. For
example suppose the transactions are of a form: “user X transfers to user Y the money that he got in some previous transaction
T
y
”, signed by the user X. In this case each user can verify if money from transaction T
y
has not been already spent by X. The
functionality of the trusted party emulated by the Bitcoin network does precisely this: it maintains a full list of transactions that
happened in the system. The format of the Bitcoin transactions is in fact more complex than in the example above. Since it is
of a special interest for us, we describe it in more detail in Section II-A.
The Bitcoin ledger is implemented using the concept of the Proofs of Work (PoWs) [24] in the following clever way. The
users maintain a chain of blocks. The first block B
0
, called the genesis block, was generated by the designers of the system in
January 2009. Each new block B
i
contains a list T
i
of new transactions, the cryptographic hash of the previous block H(B
i−1
),
and some random salt R. The key point is that not every R works for given T
i
and H(B
i−1
). In fact, the system is designed in
such a way that it is moderately hard to find a valid R. Technically it is done be requiring that the binary representation of the
hash of (T
i
||H(B
i−1
)||R) starts with a certain number m of zeros (the procedure of extending the chain is called mining, and
the machines performing it are called miners). The hardness of finding the right R depends of course on m, and this parameter
is periodically adjusted to the current computing power of the participants in such a way that the extension happens an average
each 10 minutes. The system contains an incentive to work on finding the new blocks. We will not go into the details of this,
but let us only say that one of the side-effects of this incentive system is the creation of new coins
7
.
The idea of the block chain is that the longest chain C is accepted as the proper one. If some transaction is contained in a
block B
i
and there are several new blocks on top of it, then it is infeasible for an adversary with less than a half of the total
computating power of the Bitcoin network to revert it — he would have to mine a new chain C
0
bifurcating from C at block
B
i−1
(or earlier), and C
0
would have to be longer than C. The difficulty of that grows exponentially with number of new blocks
on top of B
i
. In practice the transactions need 10 to 20 minutes (i.e. 1-2 new blocks) for reasonably strong confirmation and 60
minutes (6 blocks) for almost absolute certainty that they are irreversible.
To sum up, when a user wants to pay somebody in bitcoins, he creates a transaction and broadcasts it to other nodes in the
network. They validate this transaction, send it further and add it to the block they are mining. When some node solves the
mining problem, it broadcasts its block to the network. Nodes obtain a new block, validate transactions in it and its hash and
accept it by mining on top of it. Presence of the transaction in the block is a confirmation of this transaction, but some users
may choose to wait for several blocks on top of it to get more assurance.
6
Accessed on 13.11.2013.
7
The number of coins that are created in the system is however limited, and therefore Bitcoin is expected to have no inflation.
