1 Introduction

Private e-voting is a special case of secure multi-party (MPC) computation [9] which allows a group of people to jointly make a decision such that individual opinion can be kept private. However, the MPC framework only guarantees that the outcome is received by everyone, whose privacy is also protected. When the decision is financially related, it is not obvious how to ensure that the outcome is respected. For instance, a dishonest party may simply run away with his money.

Bitcoin [15] provides new tools for tackling this problem. Although it was originally intended for money transfer, surprisingly it can also be used to enforce a contract such that money transfer is guaranteed once the outcome is known, without the need of a trusted third party.

Our Problem. We study the bitcoin voting problem. There are n voters \(P_1, \ldots , P_n\), each of which wishes to fund exactly one of two candidates A and B with Footnote 1. The winning candidate is determined by majority voting (assuming n is odd) and receives the total prize . The voting protocol should satisfy the following basic properties:

  • Privacy and Verifiability. Only the number of votes received by each candidate is known, while individual votes are kept private.

  • Irrevocability. Once the final outcome of the voting is revealed, the winner is guaranteed to receive the total sum .

In order to incentivize voters to follow the protocol, each voter needs extra bitcoins as deposit, which will be refunded if he follows the protocol, but will be used as compensation if he deviates from the protocol. The candidates A and B also need to participate in the protocol to collect the prize, however they do not need to own bitcoins initially.

Our Approach. In voting, each voter \(P_i\) has a private vote \(O_i \in \{0,1\}\) (0, 1 stands for A, B respectively), and the sum \(\sum _i O_i\) reveals the winning candidate, where the \(O_i\)’s must be kept private. Our voting protocol consists of two parts:

  • Vote Commitment. The n voters generate n random numbers \(R_i\)’s summing to 0 (mod N) using a distributed protocol, where \(R_i\) is kept secret and commitments to \(R_i\) and the masked vote \(\widehat{O}_i=R_i+O_i\) are public known, together with a zero-knowledge proof which proves the values are generated correctly. By using zero-knowledge proofs we enforce the voters to obey the protocol.

  • Vote Casting. This part of the protocol utilizes the bitcoin system for the voters to reveal their \(\widehat{O}_i\)’s, which also guarantees that the winner can receive the prize and any voter that does not reveal his masked vote is penalized. In Sect. 3.2, we use the claim-or-refund technique as in [8] to design a protocol in which the voters reveal their masked votes sequentially. As a result, this protocol takes \(\varTheta (n)\) rounds and \(\varTheta (n^2)\) bytes in the bitcoin network. In Sect. 3.3, improved upon the previous section, we use the idea of a joint transaction as in [4, 13] to reveal the masked votes, where only constant number of rounds and O(n) bytes in the bitcoin network are used.

Previous Security Issue and Our Fix. In vote casting, we use a similar idea as that of [4]. As pointed out in [4], the way timed-commitment is used presents a serious security flaw because the compensation is paid with a transaction depending on the hash of a (unconfirmed) joint transaction. In the protocol described in [4], an adversarial party could create an alternate joint transaction with a different hash by resigning it. The details are discussed in Sect. 3.3 of our full paper [16]. The cause of this issue is that the joint transaction is signed by each voter individually, who has the ability to produce a different signature. We resolve this issue by using a threshold signature scheme [10] in which a valid signature can only be produced by all voters together, which prevents the previous attack.

Our Constribution. In this paper, we propose a protocol that solves the bitcoin voting problem.

  • We design a vote commitment scheme that hides individual votes in random numbers, where verifiability and privacy are guaranteed by using zero-knowledge proofs. This part can be used independent of the bitcoin network.

  • We design vote casting schemes that place transactions in the bitcoin network in a carefully designed way. Such that any adversaries deviating from the protocol will be punished.

  • We point out a security issue from previous protocol, which we fix by using threshold signature schemes.

The rest of the paper is organized as follows: In Sect. 2, we define Bitcoin and related cryptographic primitives. In Sect. 3, we present our protocol, which contains vote commitment and vote casting. In Sect. 4, we discuss implementation details and the performance of our protocols.

1.1 Other Related Work

The bitcoin protocol [15] has inspired many lines of research since its introduction in 2008. Some researchers have worked on identifying the protocol’s weakness [5]. Other researchers have designed new crypto-currency with more features. For instance, zero-knowledge proofs and accumulators have been used to improve the currency’s anonymity [6, 14]. In [6], a new system is designed such that the proof-of-work to mine new coins is achieved by storage consumption, as opposed to computation power in bitcoin.

Another line of research, including this paper, is to design protocols that are compatible with the existing bitcoin system. Since bitcoin is still by far the most popular crypto-currency, protocols that can be deployed in the current bitcoin system have the most practical impact. For instance, a lottery protocol [4] was proposed, in which a group of gamblers transfer all their money to a randomly selected winner. General secure multi-party computation protocols [8, 13] were also considered, in which bitcoin provides a way to penalize dishonest users.

Basic functionalities has been implemented in the bitcoin system that can serve as building blocks for more complicated protocols. In [8], the claim-or-refund mechanism is designed to enforce the promise made by party P that he will pay party Q a certain amount, provided that Q (publicly) reveals a certain secret before a certain time. As utilized in this paper, this mechanism allows a protocol in which parties reveal their secrets sequentially such that the first party that deviates from the protocol has to compensate the parties that have already revealed their secrets.

In [4], the timed-commitment mechanism is designed to enforce the promise made by party P that he will pay party Q a certain amount, unless he (publicly) reveals a certain secret before a certain time. In [13], the timed-commitment mechanism is extended for multiple-parties to reveal their secrets together. However, as mentioned in [4], their implementation of the timed-commitment mechanism has a security issue such that an adversary could prevent the compensation from being paid even when a party does not reveal his secret before the deadline.

2 Preliminaries

Bitcoin. We use the same terminology for Bitcoin [15] as in [4]. Bitcoin consists of a block of transactions known as the blockchain, which is maintained and synchronized at each peer. New transactions are packed into block and linked at the end of the blockchain at a fixed time interval. Each transaction contains multiple inputs, outputs and an optional locktime, and is indexed by its hash called \(\mathsf {txid} \).

Validation of Transactions. An output of a transaction specify a program indicating how the coin (unspent output) can be redeemed. Each input must refer to an unspent output which is specified by its \(\mathsf {txid} \) and the output index. The input contains an input-script which servers as parameters of the referred output (as a program). For the transaction to validate, the referred output (as a program) must evaluates to true on all the inputs, all referred outputs must be unspent, and the current time must be no earlier than the locktime.

For a detailed description of the Bitcoin network, please see our full paper [16].

Zero-Knowledge Proof. We utilize the zero-knowledge Succinct Non-interactive ARgument of Knowledge (zk-SNARKs) [7]. Zero-knowledge proof allows a party to convince others that he knows a secret witness w such that \(C(x,w)=1\), where x is known by all parties. E.g., “I know an w such that \(\mathsf {sha256}(w) = x\)”. The use of zk-SNARKs is to guarantee that the voters cannot deviate from the protocol. We use the definition for zk-SNARKs from [7]. Informally, zk-SNARKs is a triple of (randomized) algorithms (G, P, V), where G is the key generator which runs only once universally and outputs the key-pairs (pk, vk), P(pk, x, w) is the prover and \(V(vk,x,\pi )\) is the verifier.

We informally summarize the properties satisfied by zk-SNARKs.

  • Completeness. Prover P can produce a proof that is accepted by V.

  • Soundness and Proof of Knowledge. No polynomial-time adversary can fake a proof for x, without knowing its witness w.

  • Efficiency. The algorithms runs in time polynomial in the sizes of their inputs and the given security parameter.

  • Zero-knowledge. The proof leaks no information other than the statement itself.

Commitment Schemes. Commitment schemes allow one party to hide to a secret value which is opened in a later phase to another party, where the other party is convinced that the opened value is the original one. As it turns out, the Bitcoin protocol is restricted to certain operations, which limits the choice of commitment schemes. In Sect. 2.3 of our full paper [16], we give the formal definition and discuss commitment schemes that is compatible with the Bitcoin protocol.

Security Model. In this paper, we assume that the blockchain is unique (no branching) and one block is grown at a fixed time interval known as round. The only ways to interact with the blockchain are submitting transactions and reading transaction histories. No one can affect the blockchain by other “nonstandard” ways. We assume that the blockchain is always publicly accessible. However, we do not assume such access is private. At the time a transaction is submitted, it is publicly known. A submitted transaction may or may not appear on the blockchain, depending on its validity. If a transaction is valid, it will be confirmed one round later, otherwise it will be rejected. If conflicting transactions are submitted in the same round, only one of them will be confirmed. Hence, if an adversary is able to create a different input-script for a (newly submitted) unconfirmed transaction. He could submit another transaction with the modified input-script within the same round. In such case, either transaction could appear in the final blockchain.

A type of attack called signature malleability needs to be considered. Briefly, it means creating a valid signature from an existing one, without the corresponding plain text. Many protocols [4, 13] suffers from this attack especially when a joint transaction is concerned. For a detailed discussion of malleability attack, please see our full paper [16]. We tackle this issue by using a threshold signature scheme, which we describe in details through the protocols.

Peers (voters and candidates) need to communicate in the protocol. We assume there exists a secure private channel between any pair of participants. We also assume there exists a public broadcast channel among all participants.

3 Our Protocols

We present our protocol for bitcoin voting. Apart from a (universal) one-time setup using zk-SNARKs [7], our protocol works in a peer-to-peer fashion without a centralized server. Suppose N is the least power of 2 that is greater than the number n of voters. We use \(\mathbb {Z}_N\) to denote the group of integers modulo N. We choose N to be a power of 2 to simplify the implementation of modulo arithmetic.

On a high level, our protocol consists of two components.

  • Vote Commitment. In this phase, each voter \({P}_i\) has a private vote \(O_i \in \{0,1\}\), where 0 indicates candidate A and 1 indicates candidate B. Each voter \(P_i\) receives a secret random number \(R_i\), which is constructed in a distributed fashion such that \(\sum _{j} R_j = 0\).

    At the end of this phase, each voter \(P_i\) makes commitment \(C_i\) to \(R_i\), and commitment \(\widehat{C}_i\) to his masked vote \(\widehat{O}_i := O_i + R_i\). The commitments \(C_i\) and \(\widehat{C}_i\) are broadcast publicly, while the underlying values and opening keys remain secret.

    Every participant convinces others that he follows the protocol using zero-knowledge proofs. In particular, everyone is convinced that \(\sum _i R_i=0\) and \(\widehat{O}_i-O_i\in \{0,1\}\) with respect to the commitments. This part is described in Sect. 3.1.

  • Vote Casting. In this phase, the votes are cast using transactions in the bitcoin protocol, which are responsible for revealing the outcome and guaranteeing money transfer to the winning candidate. After each voter \(P_i\) reveals his masked vote \(\widehat{O}_i\), the outcome \(\sum _i \widehat{O}_i\) (the number of votes supporting B) is known, and the winning candidate is guaranteed to receive .

    Moreover, parties that deviate from the protocol are penalized. We have two versions for vote casting, which have different consequences for the penalty and the funding outcome for the candidates when a voter deviates from the protocol.

    1. (a)

      The first version is based on the lottery protocol in [8] using a claim-or-refund functionality. The voters reveal their masked votes in the order: \(P_1, P_2, \ldots , P_n\). If voter \(P_i\) is the first to deviate from the protocol, he pays a penalty to each voter that has already revealed his masked vote. Everyone else gets his deposit back, and the protocol terminates while neither candidate A nor B gets any money.

    2. (b)

      The second version is an improvement over other protocols [4, 13] using joint transaction to incentivize fair computation via the bitcoin system. Each voter \(P_i\) places into the bitcoin system, where is for paying the winning candidate and is for deposit. If a voter reveals his masked vote \(\widehat{O}_i\), he can get back the deposit . For each voter that does not reveal his masked vote within some time period, his deposit will be used as compensation. For instance, with \(d=2n\), the deposit can be shared between the candidates A and B.

    The two versions are described in Sects. 3.2 and 3.3, respectively.

3.1 Vote Commitment

Recall that we wish to uniformly generate random numbers \(R_i\)’s that sum to 0 such that for each i, only voter \(P_i\) receives \(R_i\). Moreover, the commitments to \(R_i\) and \(\widehat{O}_i=(R_i+O_i)\) are public.

We first give a high level idea of the procedure. Imagine that there is an \(n \times n\) matrix \([r_{ij}]\) whose entries contain elements from \(\mathbb {Z}_N\). The protocol can be described in terms of the matrix as follows.

  1. 1.

    For each i, voter \({P}_i\) generates the i-th row whose sum \(\sum _{j} r_{ij}\) is zero. This is done by generating \(n-1\) random numbers and derive the last.

  2. 2.

    For each i and j, voter \({P}_i\) sends \(r_{ij}\) to \(P_j\) via the secret channel.

  3. 3.

    For each i, voter \(P_i\) knows the i-th column. Hence, he computes and commits to both \(R_i := \sum _{j} r_{ji}\) and the masked vote \(\widehat{O}_i := O_i + R_i\).

The trick here is that commitment schemes and zero-knowledge proofs are used to ensure that every party follows the protocol, while maintaining the secrecy of the random numbers. For a step-by-step description of the algorithm please see Fig. 2.

Security Analysis. The security of the vote commitment protocol follows readily from the security of commitment schemes [11] and zero-knowledge proofs from zk-SNARKs [7]. Observe that as long as at least one party generate his random numbers uniformly at random, the resulting \(R_i\)’s will still be uniform. Hence no private information is leaked by revealing \(\widehat{O}_i\)’s. Using commitment schemes and zero-knowledge-proofs, each \(P_i\) commits to both \(R_i\) and the masked vote \(\widehat{O}_i := R_i + O_i\), and convinces everyone that \(\widehat{O}_i - R_i \in \{0,1\}\), while keeping them secret.

3.2 Vote Casting via Claim-or-Refund

This version of the vote casting protocol is based on the lottery protocol in [8] that makes use of bitcoin transactions to guarantee money transfer. The protocol is not symmetric among the voters, and the voters are supposed to reveal their masked votes in the order: \(P_1, P_2, \ldots , P_n\). In order to participate in the protocol, for \(i \in [n-1]\), voter \(P_i\) needs to place into the system, and voter \(P_n\) needs to place into the system. This protocol requires a linear number of bitcoin rounds, as opposed to constant number of rounds in the protocol that is given in Sect. 3.3. The protocol in this section guarantees the following:

  • If every voter reveals his masked vote, the net effect is that each voter pays to the winning candidate.

  • If voter \(P_i\) is the first that does not reveal his masked vote, the net effect is that he pays to each voter that has already revealed his masked vote. Neither candidate receives any money in this case.

We make use of the claim-or-refund (COR) functionality which is first introduced in [8]. It can be used for “conditionally transfer of coins”. Briefly, COR protocol between two parties X and Y guarantees that, after a deposit phase, either X reveals some secret (predetermined by X and Y) to Y, or Y is compensated after some time interval. We assume the readers are familiar with it and the description is omitted from here.

Vote Casting via COR. We show how the vote casting protocol can be implemented with a sequence of COR instances in Figs. 5 and 6. The idea is similar to that in [13]. For n voters, there are 2n COR instances. The deposit transactions of the COR instances are placed in the reversed order as the claim transactions are broadcast to reveal the masked votes.

Correctness. The correctness of the protocol is analyzed in the same way as [13]. The voters are supposed to reveal their masked votes in the order: \(P_1, P_2, \ldots , P_n\). At the moment just after voters \(P_1, P_2, \ldots , P_i\) have revealed their masked votes in the corresponding claim transactions, the net effect is that \(P_{i+1}\) has paid each of the previous voters . Hence, if \(P_{i+1}\) does not reveal his masked vote, eventually all outstanding COR instances will expire and the protocol terminates.

On the other hand, if everyone follows the protocol, then at the end all the masked votes can be summed up to determine the winner, who can collect from \(P_n\).

3.3 Vote Casting via Joint Transaction

The protocol in Sect. 3.2 requires a linear number of bitcoin rounds. In this section, we give an alternative protocol that only needs constant number of bitcoin rounds. Also, our protocol has the advantage of small total transaction size. The total size of the transactions in the protocol is \(\varTheta (n)\) bytes, instead of \(\varTheta (n^2)\) from previous protocol.

Loosely speaking, we achieve this by locking all bitcoins involved in a transaction that is jointly signed by all voters. The protocol is symmetric among the n voters. In the protocol, each voter \(P_i\) needs , of which is to be paid to the winning candidate if everyone reveals his masked vote and the remaining is for deposit that will be used for compensation if \(P_i\) does not reveal his masked vote. The timed-commitment technique in [4] can be used to handle the deposit and compensation.

The protocol guarantees the following:

  • If a voter reveals his masked vote, he can get back the deposit .

  • If every voter reveals his masked vote, the sum \(\sum _i \widehat{O}_i\) determines the winner who receives .

  • If at least one voter does not reveal his masked vote, the originally intended for the winner will be locked. For each voter that does not reveal his masked vote, his deposit will be used for compensation. Here are several options:

    1. (a)

      For \(d=2n\), the deposit can be shared between candidates A and B. We shall concentrate on this option in this section.

    2. (b)

      For \(d=n\), the deposit can be distributed among all voters in a similar way.

There is a potential problem in the “joint transactions” described in [4, 13]. We fix this problem by using threshold signature schemes. The detail of the problem is discussed in our full paper [16].

Description of Vote Casting Protocol.

Key Setup. We use the threshold signature scheme [10] for ECDSA. The n voters jointly generate a group address such that voter \(P_i\) learns the group public key \(\widehat{\mathsf {pk}}\) and his share \(\widehat{\mathsf {sk}}_i\) of the private key. No party knows the underlying secret key \(\widehat{\mathsf {sk}}\), which could be reconstructed from all parties’ secret shares. Each party also has his own bitcoin address, whose key pairs are denoted by \(({\mathsf {pk}}_i, {\mathsf {sk}}_i)\).

Coin Lock. Eventually, the n voters will sign some transaction \(\mathsf {JOIN}\) together, whose inputs are contributed by the n voters. We introduce a protocol that locks the contribution from each voter in a state such that only with all voters’ permission can it be redeemed. This ensures that only one version of the \(\mathsf {JOIN}\) transaction can use these coins later. On the other hand, if the protocol ends prematurely and the \(\mathsf {JOIN}\) transaction is not created successfully, we wish to let each voter \(P_i\) get back his contribution with the transaction \(\mathsf {BACK} _i\). The coin lock protocol is described in Fig. 3.

Joint Transaction. In the next step, the n voters shall jointly sign a transaction \(\mathsf {JOIN} \) using the threshold signature scheme, each with his private key share \(\widehat{\mathsf {sk}}_i\). The \(\mathsf {JOIN} \) transaction has n inputs referring to the \(\mathsf {LOCK} _i\)’s, each of which contributes . It has \((n+1)\) outputs, of which out-prize delivers to the winning candidate, while each out-deposit \(_i\) of the remaining n outputs handles the deposit of each voter.

Using the timed-commitment technique as in [4], the output out-deposit \(_i\) can be redeemed by a transaction that either (1) reveals the masked vote \(\widehat{O}_i\) and is signed with the key associated with \(P_i\), or (2) is signed with the group key. Hence, before \(\mathsf {JOIN} \) takes effect (by appearing in the blockchain), a transaction \(\mathsf {PAY} _i\) with some timelock that can redeem out-deposit \(_i\) needs to be created and signed using the threshold signature scheme, in case \(P_i\) does not reveal his masked vote and his deposit is used for compensation. The details are in Fig. 4.

Outcome Revealing Phase. After \(\mathsf {JOIN} \) appears on the blockchain, each voter \(P_i\) can collect his deposit (from the output out-deposit \(_i\)) by submitting a CLAIM \(_i\) transaction that provides the opening key \(\widehat{K}_i\) to reveal his masked vote \(\widehat{O}_i\). If all voters have submitted their transactions CLAIM \(_i\)’s, the winning candidate is determined and can redeem from out-prize with his signature.

On the other hand, if some voter i does not reveal his masked vote, then the from out-prize cannot be accessed anymore. However, since \(\mathsf {PAY} _i\) is publicly known, after time \(t_2\), the from out-deposit \(_i\) can be redeemed by \(\mathsf {PAY} _i\) as compensation.

Correctness. After the coin lock protocol, all the transactions \(\mathsf {LOCK} _i\)’s remain secret, while their hashes and the \(\mathsf {BACK} _i\)’s are publicly known. Observe that before the transaction \(\mathsf {JOIN} \) appears on the blockchain, any voter can terminate the whole protocol without losing any money by submitting \(\mathsf {BACK} _i\) to the bitcoin system. On the other hand, once \(\mathsf {JOIN} \) has appeared on the block chain, no voter can terminate the protocol without either revealing his masked vote or losing his deposit .

4 Experiment

We describe our implementation of the proposed protocols below.

Vote Commitment. We have implemented vote commitment protocol Sect. 3.1. For zk-SNAKRs [7], we choose snarkfront [12]. We translated the required relation into circuits. We run the program using a computer with 4G RAM and Intel Core i5-3570 CPU. The key generator typically takes 5 times longer than the time to generate proofs. However, since it only needs to be run once universally, we omit its running time here as it is not a performance concern. In Fig. 1, we report the time to generate proofs for different number of users. We consider three kinds of proofs: (1) to prove n numbers sum to 0, (2) to prove n numbers sum to the \((n+1)\)-st number, (3) to prove the subtraction of a number from another is either 0 or 1.

Fig. 1.
figure 1

Performance of zk-SNARKs

Full size image

In zk-SNARKs, the time for verification is only linear in the size of the input (and the security parameter). Typically, it takes less than 0.1 s.

Vote Casting. As a proof of concept, we have executed the protocols in bitcoin (testnet) network [2]. We use bitcoinj Java library to create and send the transactions.

Below we present \(\mathsf {txid}\) of the transactions. There are 9 voters in our protocol. One may read the full transaction data on chain.so website.

For the protocol using claim-or-refund in Sect. 3.2, we first create a transaction with multiple outputs, each of which acts as the source address of each claim-or-refund transaction. The source of each claim-or-refund transaction can be found with index \(0-17\) at:

https://chain.so/tx/BTCTEST/d3f62d6dfd9722699938a3d7457e23ba786a3e 8d14615d128847ad7ca56b7a1a d3f62d6dfd9722699938a3d7457e23ba786a3e8d14615d128847ad7ca56b7a1a.

All following transactions can be found following the outputs. Another execution in which an adversary terminated the protocol and was punished is here:

https://chain.so/tx/BTCTEST/8d4031dfa71bf9b1a296b6f67c3cb1d801e899 d4ff7d1ee6dd6751622032b60f 8d4031dfa71bf9b1a296b6f67c3cb1d801e899d4ff7d1ee6dd6751622032b60f.

For the protocol using joint transaction in Sect. 3.3, the \(\mathsf {JOIN} \) transaction of a successful execution is here:

https://chain.so/tx/BTCTEST/ca42f58d2a7eadc4360029ea31e6f2224c9b7f4 7c18ef985a9b477ac869822c7 ca42f58d2a7eadc4360029ea31e6f2224c9b7f47c18ef985a9b477ac869822c7.

All claim transactions can be found by following the outputs.

A \(\mathsf {JOIN} \) transaction of an unsuccessful (terminated by adversary) execution is here:

https://chain.so/tx/BTCTEST/6506857a75b1f25b930a923e6bd8274cbccb42 339425e21f29cf5ba2ce389738

6506857a75b1f25b930a923e6bd8274cbccb42339425e21f29cf5ba2ce389738.

All CLAIM \(_i\) and \(\mathsf {PAY} _i\) transactions can be found by following the outputs.

5 Conclusion

We present protocols that solve the bitcoin voting problem and run directly on the current bitcoin network. Our protocols consist of two phases. The first phase generates a masked vote for each voter. We guarantee that the generated masks are publicly verifiable by the use of zero-knowledge proofs. The second phase takes the masked votes and put transactions on the blockchain, so that the winner is guaranteed to receive the prize digitally. The protocols of the two phases are of independent interest and we hope our work will inspire other applications of bitcoin.