1 Introduction

Cryptographic currencies (also dubbed the cryptocurrencies) are a very interesting concept that emerged in the last few years. The most prominent of them, and by far the largest one (in terms of capitalization), is Bitcoin, introduced in 2009 [32]. The main property of these currencies is that their security does not rely on any single trusted third party. The list of transactions in the system is written on a public ledger that is maintained jointly by the users. Another reason why these currencies are so interesting is that they allow the users to perform much more than simple money transfers between each other. Namely, several cryptocurrencies, including the Bitcoin, implement an idea of the so-called smart-contracts. Such contracts can be viewed as distributed protocols executed between a number of parties. Typically, they have financial consequences, i.e., the users contribute money to them, and these funds are later distributed among the participants according to contract rules. Moreover, these contracts are “self-enforcing”, which means that their execution is guaranteed by the rules of the underlying cryptocurrency. In particular, once a party enters into such a contract she cannot “change her mind” and withdraw her invested funds unless the contract specifically allows her to do so.

To be more specific, consider a contract called the Zero Knowledge Contingent Payment [16], which is an example on how Bitcoin contracts can provide a solution for the so-called fair exchange problem (see, e.g., [34]). It is executed between two parties: the Seller and the Buyer. The Buyer is looking for a value \(x \in \{0,1\}^{*}\), that he does not know, but he is able to specify the conditions of x that make it valuable for him. Namely, he can describe a function \(f:\{0,1\}^* \rightarrow \{\mathsf {true},\mathsf {false}\}\) (in a form of a polynomial-time computer program, say), such that every x satisfying \(f(x) = \mathsf {true}\), has a value for him (here “” denotes Bitcoin currency unit). Obviously (assuming that P \(\ne \) NP), finding x such that \(f(x) = \mathsf {true}\) is much harder than verifying that \(f(x)=\mathsf {true}\) holds. Hence, in many cases it makes a lot of sense for the Buyer to pay for x. As an example: think of a Buyer that wants to buy a factorization p, q of an RSA modulus N. He would then define \(f: \mathbb {N} \times \mathbb {N} \rightarrow \{\mathsf {true},\mathsf {false}\}\) as \(f(p,q) := \mathsf {true}\text { iff } ((p \cdot q = N) \wedge p \ne 1 \wedge q \ne 1)\).

Imagine now that the Buyer is approached by a Seller, who is claiming that he knows x such that \(f(x) = \mathsf {true}\) and he is willing to sell it. If this happens over the Internet, and the parties do not trust each other then they face the following problem: shall the Seller first send x to the Buyer who later pays to him (after verifying that indeed f(x)), or the other way around: shall the Buyer first pay and get x from the Seller? Clearly in the first case a malicious Buyer can refuse to pay to the Seller (after receiving x), and in the latter a malicious Seller may not send x to the Buyer (after receiving the payment). Is there a way to sell x in such a way that none of the parties can cheat the other one? Unfortunately, it turns out (see, e.g., [33]), that this fundamental problem, called the fair exchange cannot be in general solved without a trusted third party. This is exactly where the contracts come to play. Intuitively, thanks to this feature of the cryptocurrencies, the users can use the ledger as a trusted entity that allows them to perform the exchange x for simultaneously. Technically (but still very informally), this is done by placing a contract C on the ledger that has the following semantics: “The Buyer has to put aside . This money can be claimed by the Seller only by posting x such that \(f(x) = \mathsf {true}\) on the ledger. If he does not do it within time t , then goes back to the Buyer.” Now, everybody who observes the ledger can easily verify if the contract obligations were respected by the parties, and decide whether should be now “transferred” from the Buyer to the Seller or not.

Another interesting example of a contract is so-called trading across chains [12] where users can exchange in a secure and fair way money between different cryptographic currencies. More advanced examples include, the rapidly-adjusted micro-payments, the assurance contracts [12], the multiparty lotteries [4, 6], or general secure multiparty computation protocols [2, 11, 27]. Some experts predict that the smart contracts will revolutionize the digital economy. It is even envisioned that in the future these contracts may be used to maintain large distributed autonomous corporations that would operate without any trusted party control [22].

1.1 Contracts: From Theory to Practice

The above description ignores many technical details, and in particular it does not mention how the contracts are written. The transactions that are used in the contracts contain the so-called scripts. In Bitcoin the scripts are written in the so-called Bitcoin script language [13], which is not Turing-complete, and hence not every condition can be expressed in it. A serious obstacle when implementing the Bitcoin contracts in real life is that in practice it is currently very hard to post on the ledger a transaction corresponding to a non-trivial contract. Technically, to write a transaction on the ledger one broadcasts it over Bitcoin network and hopes that one of the miners (which are the entities that are maintaining the ledger) will include it into a new block that he mines. This gives the miners power to decide which transactions are included into the blockchain and which are not. Unfortunately, currently most of the miners do not include more complicated transactions into the blockchain. The reasons for this are: (1) such transactions tend to be longer than the “standard” ones, and space in the block is scarce, and (2) writing the transactions is tricky and error-prone, and most of the mining pool operators agreed to disallow them in order to prevent the users from loosing money. Technically deciding whether to accept a transaction or not is done by computing a boolean function isStandard() that evaluates to \(\mathsf {true}\) only if the transaction is “standard”, and otherwise it evaluates to \(\mathsf {false}\). The vast majority of the miners will include a transaction T in a new block only if isStandard( T ) \(=\mathsf {true}\) (more on this can be found, e.g., in [5], Chap. 5). Up to our knowledge, the only mining pool that currently accepts the non-standard transactions is Eligius that mines less than 1 % of blocks.

Another problem with running the smart contracts in Bitcoin is that the Bitcoin scripting language contains a feature, called the transaction malleability, that makes it tricky to implement several natural contracts (for more on this see the extended version of this paper [7], or, e.g., [3]). Although some techniques of dealing with this problem are known [3], they are often hard to use, since they make the contracts unnecessarily complicated (and make the transactions longer), and sometimes force the parties to invest more money than would normally be needed (by requiring them to put aside so-called deposits). One interesting new tool for dealing with this problem is the \(\mathsf {OP\_CHECKLOCKTIMEVERIFY}\) instruction [38] that was recently deployed.

After Bitcoin was deployed several other cryptocurrencies were proposed. The most interesting one from the point of view of the smart contracts, is Ethereum, which permits to use the Turing-complete scripts. The aforementioned problem of the high time consumption associated with the evaluation of the complicated scripts is solved in Ethereum in the following way. Each step of the computation of a script costs some small amount of money (the currency used for this is called ether), and the script evaluates as long as there are enough funds for this. Ethereum has recently been deployed in real life. It is, however, still a very young project and it is unclear how successful it will be in the real life. Moreover, as recently observed by Luu et al. [29] Ethereum may be susceptible to attacks where the adversary wastes miners’ computational resources, which, in turn means that the miners might have incentives not to verify the correctness of the scripts. This, at least in theory, puts the whole Ethereum security model at risk.

Some of the other new cryptocurrencies go in the opposite direction by removing the possibility of having scripts at all. Sometimes this is a price for having additional interesting features in a currency. One example is the Zerocash [10], where the key new feature is the real anonymity (obtained by using the zero-knowledge techniques). Another, slightly different example is the Lightning system, which is a new proposal for micropayments constructed on top of the Bitcoin financial system, that also allows only standard transactions between the parties.

1.2 Our Contribution: Contracts Without Scripts

These observations lead to the following natural question: can we efficiently construct non-trivial contracts using only the standard transactions? In this paper we answer this affirmatively. We show (in Sect. 3.2) a general technique for efficiently solving the Zero-Knowledge Contingent Payment problem using only standard transactions for any f such that the corresponding language \(\{x: f(x) = \mathsf {true}\}\) has an efficient zero-knowledge proof of knowledge of a special (but very broad) form, that, in particular, includes the sigma-protocols (see, e.g., [20]). We define this class of protocols in Sect. 3.3, but for a moment let us only say that it includes many natural languages. As an example we show an efficient protocol for selling a factorization of an RSA modulus, which is a problem that we already discussed at the beginning of this section. We implemented our protocol and confirmed its efficiency (see Sect. 3.4). In our construction we do not rely on any costly cryptographic mechanisms such as the generic secure multiparty computation protocols, or the generic zero-knowledge schemes. Instead, we use the standard and simple cut-and-choose technique. Our techniques can also be used to solve, in a similar way, the “trading across chains” problem. Because of the lack of space this is shown in the extended version of this paper [7].

Our protocols are proven secure in the random oracle model, and are based on standard cryptographic assumptions, an assumption that time-lock encryption of [37] is secure, plus one additional assumption about the strong unforgeability of the Elliptic Curve DSA (ECDSA) signatures used in Bitcoin. We describe this assumption in more detail in Sect. 2. Our protocols have an exponentially small probability of error (i.e.: the probability that the adversary cheats), assuming that we are allowed to use so-called multisig transactions, i.e., transactions that can be spent by providing signatures with respect to k public keys (out of \(n\ge k\) possible public keys). Currently such transactions are considered standard for \(n \le 15\). We note that if one does not want to use such transactions, then our solution also works, but the error probability is inversely proportional to the running time of the parties.

Related work. As already mentioned, the Zero-Knowledge Contingent Payment protocol has been described before in [16] and recently implemented [31] for selling a proof of a sudoku solution. When viewed abstractly, our construction is a bit similar to the one of [16]. There are some important differences, though. Firstly, the protocol of [16] uses some non-standard scripts. Secondly, it is vulnerable to the “malleability attacks”: the refund transaction depends on an identifier of the txn transaction, and becomes meaningless if txn is mauled. Finally, the protocol of [16] uses generic zero knowledge protocols, or can be used only for very simple problems (like selling the sudoku solution), while we rely on much simpler and more efficient methods (in particular: the cut-and-choose technique).

2 Preliminaries

Definitions. We will sometimes model the hash functions as random oracles, see [9]. A signature scheme consists of a key generation algorithm \(\mathsf {SignGen}\), a signing algorithm \(\mathsf {Sign}\), and a verification algorithm \(\mathsf {Vrfy}\). For a formal definition of a signature scheme see [26], or the extended version of this paper [7]. The standard security notion for signatures is the existential unforgeability under a chosen message attack. In this paper we need a stronger security definition, namely the strong existential unforgeability under a chosen message attack. This is formally defined in [1, 18]. Essentially, the definition is as follows. Consider the standard chosen-message attack during which the adversary interacts with a signing oracle that knows some secret key \( sk \). We say that \({\mathcal {A}}\) mauls a signature if he is able to produce an output \((\hat{z},\hat{\sigma })\) such that \(\hat{\sigma }\) is a valid signature on \(\hat{z}\) with respect to the public key \( pk \) (that corresponds to \( sk \)), and \(\hat{\sigma }\) has not been sent to \({\mathcal {A}}\) before. A signature scheme is existentially strongly unforgeable under a chosen message attack (or: non-malleable) if for any polynomial-time adversary the probability that he mauls a signature is negligible.

We will use (public key and private key) encryption schemes, defined in a standard way (see [26] or [7].) We say that a public-key encryption scheme is additively homomorphic if for every valid public key \( pk \) and private key \( sk \) the set of valid messages for \( pk \) is an additive group \((\mathbb {H}_{ pk },+)\). Moreover, we require that there exists an operation \(\otimes : \{0,1\}^* \times \{0,1\}^* \rightarrow \{0,1\}^* \cup \{\bot \}\), such that for every valid \(( pk , sk )\) and every pair \(z_0,z_1 \in \mathbb {H}_{ pk }\) we have that \(\mathsf {Dec}_{ sk }(\mathsf {Enc}_{ pk }(z_0) \otimes \mathsf {Enc}_{ pk }(z_1)) = z_0 + z_1\) (where \(\mathsf {Enc}\) and \(\mathsf {Dec}\) are the encryption and decryption algorithms, respectively).

Our protocols also rely on the time-lock commitment schemes [17, 37] (for the definition of the standard commitment schemes see, e.g., [26], or [7]). Informally, \((\mathsf {Commit},\mathsf {Open})\) is a time-locked commitment if it is a standard commitment scheme, except that the receiver can open the commitment by himself (even if the sender is not cooperating). Such forced opening requires a significant computational effort. Moreover it is required that this process cannot be parallelized. Every time-lock commitment comes with two parameters: \(\tau _0\) and \(\tau _1\) (with \(\tau _0 \le \tau _1\)), where \(\tau _0\) denotes the time (in seconds, say) that everybody, including very powerful adversaries, needs to force open the commitment, and \(\tau _1\) denotes time needed by the honest users to force open the commitment. We will call such a commitment scheme \((\tau _0,\tau _1)\)-secure. Of course, this is not a formal mathematical definition (as it refers to “real time”), but for the purpose of this paper we can stay on this informal level. Later, in Sect. 3.4 we assume that \(\tau _1 = 10 \cdot \tau _0\), but this choice is slightly arbitrary, and for real practical applications one would need to perform a more careful analysis of what is the reasonable ratio between \(\tau _0\) and \(\tau _1\) that one can assume.

For a description of the area of zero-knowledge the reader may consult, e.g., [24] (a brief introduction also appears in [7]). In our paper we actually need a stronger notion, namely the zero-knowledge proofs of knowledge [8]. Such proofs are defined only if L is in NP, and hence for every \(x \in L\) there exists an NP-witness w that serves as a proof that \(x \in L\). We assume that P knows x and require that the prover not only proves that \(x \in L\), but also convinces the verifier that he knows the corresponding witness w. Defining formally the property of a prover “knowing” some value is a bit tricky, and we do not do it here (see, e.g., [24] for such a definition). Very informally, it is usually defined as follows: for every (possibly malicious) prover \(P^*\) there exists a polynomial-time machine, called the knowledge extractor, that can interact with \(P^*\) (possibly even rewinding it), and at the end it outputs x. The definition that we use here is more restrictive. First, suppose without loss of generality, that the last two messages in the protocol are: a challenge c sent by the verifier to the prover, and provers response r. We require (cf. Sect. 3.3) that the extractor extracts the witness after being given transcripts of two accepting executions that are identical except that that the challenge messages are different (and the response messages may also be different). This class of protocols includes our protocol for selling the factorization of the RSA modulus. It is also similar to the sigma-protocols (see, e.g., [20]), except that it may have more rounds than 3, but on the other hand we require that the zero-knowledge property holds also against the malicious verifier. Note that some sigma-protocols, including the Schnorr protocol, are conjectured to be secure also in this case. Observe also that we can easily get rid of the “honest verifier” assumption by requiring the verifier to make his message equal to a hash of some message (chosen by him) [21]. Hence, our method can be used also to efficiently “sell” a witness of any relation for which an efficient sigma-protocol exists.

Instantiations. As explained in the introduction, Bitcoin uses an Elliptic Curve Digital Signature Algorithm (ECDSA) [19, 25], which is a variant of the Digital Signature Algorithm (DSA). More concretely, it uses the Secp256k1 curve [14], but to be able to state our theorems in an asymptotic way we will be more general and define our protocol over arbitrary elliptic curve. The description of this algorithm appears in [7].

As it turns out, these signatures are not strongly unforgeable: if (r, s) is a valid signature on some message z, then also \((r,-s \bmod p)\) (where p is the order over which the elliptic curve \(\mathbb {G}\) is defined) is a valid signature with respect the same public key (see, e.g., [7] for more on this). In order to make our signature scheme strongly-unforgeable we follow the guidelines from [39]. Namely, we assume that the only “legal” signatures have a form (r, s) such that \(s \le (p-1)/2\). To this end, we simply assume that, whenever our protocol gets as input an ECDSA signature (r, s) with \(s>(p-1)/2\), it converts it to one with \(s\le (p-1)/2\) by computing \(s:= - s \bmod p\). An ECDSA scheme with only “legal” signatures being the ones with \(s \le (p-1)/2\) will be called a positive ECDSA.

We can now informally state our strong unforgeability assumption as follows: “The positive ECDSA defined over Secp256k1 is strongly unforgeable under chosen-message attack” (or equivalently: the only way to maul the signatures defined over Secp256k1 is to negate the s). Note that this statement is informal, and in order to formalize it we would need to express it in an asymptotic way. See [7] for more on this, and on the general issue of the malleability of Bitcoin transactions.

We will use the additively-homomorphic public key encryption scheme introduced by Pascal Paillier [35]. Below, we describe only the properties of this scheme that are needed in this work. For more details the reader can consult, e.g., [35]. The public key \( pk \) of this encryption scheme contains a modulus \(n = p\cdot q\), where p and q are large distinct random primes of the same length. The Paillier encryption scheme is homomorphic over \(({\mathbb {Z}}_n,+)\). It is semantically secure under the Decisional composite residuosity assumption [35]. In the sequel we will assume that \((\mathsf {AddHomGen},\mathsf {AddHomEnc},\mathsf {AddHomDec})\) is a Paillier encryption scheme. The elements on which we will perform the addition operations will be the exponents in the elliptic curve group of the ECDSA scheme. Hence, we need \({\mathbb {Z}}_n\) to be larger than \({\mathbb {G}}\), and, for the reasons that will become clear later, it will be convenient to have \(n \gg {\left| {\mathbb {G}}\right| }\). We therefore assume that on input \(1^\lambda \) the algorithm \(\mathsf {AddHomGen}\) produces as output \(( pk , sk )\) such that the corresponding group \({\mathbb {Z}}_n\) satisfies \(n > 2 \cdot {\left| {\mathbb {G}}\right| }^4\).

We use very standard commitment schemes that are based on the hash functions, and are secure in the random oracle model. Let H be a hash function. In order to commit to \(x \in \{0,1\}^*\) the committer chooses random \(r \in \{0,1\}^\lambda \) (where \(1^\lambda \) is the security parameter) and produces as output \(\mathsf {Commit}(x) = H(x||r)\). In order to open the commitment it is enough to reveal (x, r). The fact that the scheme is binding follows from the collision-resistance of H. The hiding property follows from the fact that we model H as the random oracle (and hence H(x||r) does not reveal any information about x).

We use the classic timed commitments of [37]. In order to commit to a message \(x \in \{0,1\}^\ell \) (for some \(\ell \)) the committer chooses an RSA modulus n, i.e., he selects two random primes p and q of length \(\lambda \) (where \(1^\lambda \) is the security parameter) and sets \(n=pq\). He then computes \(\varphi (n) = (p-1)(q-1)\). Let t be some parameter. The committer takes random \(y \in Z_n^*\) and computes \(z:= y^{2^t} \bmod n\). Since he knows \(\varphi (n)\) he can compute it efficiently by first computing \(e = 2^t \bmod \varphi (n)\) (doing this using the standard square-and-multiply algorithm takes \(\log _2 t\) squaring modulo n), and then letting \(z:= y^e \bmod n\). Finally, he computes H(z) and outputs y and \(H(z) \oplus x\), where \(H: {\mathbb {Z}}_n^* \rightarrow \{0,1\}^\ell \) is a hash function. On the other hand, it is conjectured [37] that an adversary, who does not know \(\varphi (n)\) needs to perform t squarings to compute z (and hence to compute x). Also, no practical methods of parallelizing the problem of computing z is known. It is also easy to see that this algorithm is a commitment in a standard sense, i.e., if the committer is cooperating with the receiver then he can open the commitment efficiently (by sending (p, q) to the receiver). To set the parameter t let c be the number of squarings that the honest receiver can do in one second. We then let \(t = \tau _1 \cdot c\) (where \(\tau _1\) is the parameter of the timed commitment scheme).

A short description of the Bitcoin transaction syntax. We now briefly describe the syntax of the Bitcoin transactions. A more complete description can be found, e.g., in [5, 7, 15]. Since we do not use the non-standard transactions we will provide a simplified description that ignores this feature of Bitcoin. The users in Bitcoin are identified by their public keys in the ECDSA signature scheme \((\mathsf {SignGen},\mathsf {Sign},\mathsf {Vrfy})\). Each such a key \( pk \) is called an address. In the simplest case transaction T simply sends some amount (where x can be smaller than one) from an address \( pk _0\) (called an input of T) to an address \( pk _1\) (called the output of T). The amount will also be called the value of T. Transaction T must contain a pointer to another transaction \(T'\) that appeared earlier on the ledger and has value at least , and whose destination is \( pk _0\). We say that T redeems \(T'\). Transaction T is valid only if \(T'\) has not been redeemed by some other transaction before. Hence, in the simplest case a transaction contains a following tuple , where \(\mathtt {TXid}(T')\) denotes the identifier of \(T'\) (we will define it in a moment), and [T] is called a simplified transaction T. Of course, in order for [T] to have any meaning it needs to be signed with the private key \( sk _0\) corresponding to \( pk _0\). Hence, the complete transaction T has a form \(([T],\mathsf {Sign}_{ sk _0}([T]))\), and is valid if all the conditions described above hold, and the signature on [T] is valid with respect to \( pk _0\). The \(\mathtt {TXid}(T)\) is defined simply as a SHA256 hash of \(([T],\mathsf {Sign}_{ sk _0}([T])))\).

Another standard type of the transactions are the so-called multisig transactions. In this case [T] has a form where \(n \le 15\). It is signed by \( pk _0\). It can be spent by a transaction \(T''\) that is signed by k signatures with respect to k different public keys from the set \( pk _1,\ldots , pk _n\). More precisely the transaction \(T''\) has to have a form \(([T''], \sigma _{i_1},\ldots ,\sigma _{i_k})\), where \(1 \le i_1< \cdots < i_k \le n\) and for every \(1 \le j \le k\) holds \(\mathsf {Vrfy}_{ pk _{i_j}}([T''], \sigma _{i_j}) \) \(= {\mathsf {ok}}\).

3 The Protocols

Our model. We will consider two-party protocols, executed between a Buyer B and a Seller S. If a party is malicious then she may not follow the protocol (in other words: we consider the active security settings). The parties are connected by a secure (i.e. secret and authenticated) channel. Such a channel can be easily obtained using the standard techniques, provided that the parties know each others public keys. Observe that in order to do any financial transfers in Bitcoin they anyway need to know each other keys (let \(( sk _B, pk _B)\) be the ECDSA key pair of the Buyer, and let \(( sk _S, pk _S)\) the key pair of the Seller), and the participating parties can use the same key pairs for establishing the secure channel between each other. How exactly these public keys \( pk _B\) and \( pk _S\) are exchanged is beyond the scope of this paper.

The security definition. We now outline a construction of our protocol in which the Seller sells to the Buyer x such that \(f(x) = \mathsf {true}\) (for some public \(f: \{0,1\}^* \rightarrow \{\mathsf {true},\mathsf {false}\}\)). We assume that the “price” of x is , and that, before an execution of the protocol starts, there is some unspent transaction \(T_0\) on the blockchain whose value is , and whose output is \( pk _B\) (i.e.: it can be spent by the Buyer). The parties initially share the following common input: a security parameter \(1^\lambda \), a price for the secret x, parameters \(a,b \in {\mathbb {N}}\) such that \(a > b\), an elliptic curve group \(({\mathbb {G}},{\mathcal {O}},g,+)\) for an ECDSA signature scheme, such that \(\lceil \log _2{\left| {\mathbb {G}}\right| } \rceil = \lambda \), and parameters \((\tau _0, \tau _1)\). We say that the \(\mathsf {SellWitness}_f\) protocol is \(\epsilon \) -secure if the following properties hold: (1) except with probability \(\epsilon + \mu (\lambda )\) (where \(\mu \) is negligible), if an honest Buyer loses his funds then he learns \(x'\) s.t. \(f(x') = \mathsf {true}\), (2) except with negligible probability, if an honest Seller does not get Buyer’s funds then the Buyer learns no information about x. We construct a protocol \(\mathsf {SellWitness}_f\) (for a large class of functions f) in Sect. 3.3. First, however, we give an outline of our construction. The necessary ingredients are defined and constructed in Sects. 3.1 and 3.2.

Outline of the construction. Our protocol consists of several stages. The main idea can be described as follows (we start with describing an “idealized” protocol and then we show how to modify it to make it efficient and practical). Imagine that the parties first create, in a distributed way, an ECDSA key pair \(( sk , pk )\) such that the private key \( sk \) is secret-shared between the parties, and the public key \( pk \) is known to both of them. Then, the Buyer prepares a transaction \(T_1\) that sends the output of \(T_0\) to the public key \( pk \). Obviously for a moment the Buyer has to keep \(T_1\) private, as posting \(T_1\) on the ledger would put his money at risk (as spending money from \(T_1\) requires cooperation of the Seller). He now creates a simplified transactionFootnote 1 \([T_2]\) that redeems \(T_1\) and sends the output to the public key \( pk _S\) of the Seller. Then, the parties jointly sign \([T_2]\) with the shared private key \( sk \) in such a way that the signature \(\sigma = \mathsf {Sign}_{ sk }([T_2])\) is known only to the Seller. Note that this is possible without revealing \(T_1\) to the Seller, as the only thing that is needed from \(T_1\) is its transaction identifier, which happens to be equal to the hash \(H(T_1)\) of \(T_1\) (in the random oracle model \(H(T_1)\) clearly reveals no information about \(T_1\)).

Let us now briefly analyze the situation after these steps are executed: the Buyer knows \(T_1\), and the Seller knows \(T_2\) that spends \(T_1\) (but she does not know \(T_1\), so for a moment she cannot make any use of \(T_2\)). The key idea now is: the Seller will make a commitment to the signature \(\sigma \) in such a way that opening this commitment will automatically reveal x (and she will convince the Buyer that the commitment was formed in this way). Now the Buyer can post \(T_1\) on the ledger, and wait until the Seller redeems it. The only way in which she can do it, is to publish \(\sigma \) (here we use the assumption that the signatures are strongly unforgeable), so the Buyer can be sure that he learns x.

This construction is similar to the one described in [16]. Unfortunately, in practice there are several problems with it. Firstly, there is no way for the Buyer to “force” the Seller to publish \(\sigma \), and hence the Buyer’s money can be locked forever in \(T_1\). We solve this problem using the time-locked commitments. The Seller has to commit with such a commitment to her private share of \( sk \), so that it can be unlocked by the Buyer after some time. In this way he can get his money back by signing a transaction \(T_2'\) that redeems \(T_1\) and sends the money to his key \( pk _B\). As described in Sect. 1, an alternative solution is to use the \(\mathsf {OP\_CHECKLOCKTIMEVERIFY}\) instruction. We describe this solution in the extended version of this paper [7].

Secondly, the currently-known protocols for distributed signing with the ECDSA signatures are rather complicated and involve costly generic zero-knowledge techniques [30] (see also [23]). Also, the generic zero-knowledge would need to be used to prove that the timed commitment above is indeed a commitment to Seller’s share in \( sk \).

Our solution to this problem is to use the standard technique, called cut-and-choose (see, e.g., [28]). Informally, the idea here is to perform a number a of independent executions of a protocol. Then the Buyer tells the Seller to “uncover” \(a-b\) (for some parameter \(b<a\)) of them, by opening all her commitments related to these executions. It is easy to see that, if all the opened commitments were correct, then most probably a significant fraction of the remaining b (“non-uncovered”) executions will also be correct. Since some executions may still be incorrect, we will thus create \(T_1\) as a multisig transaction (so it can be spent with less than b signatures). This is done in Sects. 3.1 and 3.2. Thirdly, we need to describe how to create the commitment to \(\sigma \) in the last step that requires proving that “opening this commitment will automatically reveal x”. We do it as follows: we require that the Seller commits to \(F(\sigma )\) (where F is some hash function), and then we use again the cut-and-choose technique (on the elements of \(F(\sigma )\)) to prove that if the whole \(F(\sigma )\) is opened then x is revealed. Technically, this is done by showing that revealing \(F(\sigma )\) opens commitments to messages from a zero-knowledge proof of knowledge of x. For the details see Sect. 3.3. The outline of the \(\mathsf {SellWitness}_f\) protocol and the subprotocols is presented on Fig. 1.

Fig. 1.
figure 1

The outline of the \(\mathsf {SellWitness}_f\) protocol and the subprotocols.

Full size image

3.1 The Two-Party ECDSA Key Generation Protocol

The first ingredient of our scheme is a protocol in which two parties, the Seller and the Buyer, generate a (public key, private key) key pair for the ECDSA signatures, in such a way that the secret key is secret-shared between the Seller and the Buyer. To be more precise, fix an elliptic curve \(({\mathbb {G}},{\mathcal {O}},g,+)\) constructed over a field \({\mathbb {Z}}_p\) and recall that the secret key in the ECDSA signatures is a private integer \(d \in {\mathbb {Z}}_{{\left| {\mathbb {G}}\right| }}\). We construct a two-party protocol, that we call \(\mathsf {SharedKGen}\), in which both parties take as input a security parameter \(1^\lambda \) and at the end they both know an ECDSA public key \( pk = d \cdot g\) (where d is secret), and additionally the Seller knows \(d_S \in {\mathbb {Z}}_{{\left| {\mathbb {G}}\right| }}\) and the Buyer knows \(d_B \in {\mathbb {Z}}_{{\left| {\mathbb {G}}\right| }}\) such that \(d_S \cdot d_B = d \pmod {{\left| {\mathbb {G}}\right| }}\) is a secret-sharing. The protocol is very similar to the classic actively-secure key generation protocols for the discrete log signatures [36]. Because of the lack of space it is presented in the extended version of this paper [7].

3.2 The Unique Signature Generation Protocol

After the parties generate a key pairs \((sk^{1},pk^{1}), \ldots , (sk^{a},pk^{a})\) using the \(\mathsf {SharedKGen}\) protocol, they perform an additional procedure, called unique signature generation ( \(\mathsf {USG}\) ) protocol, whose goal is to sign a message \(z \in \{0,1\}^*\) with respect to these keys. The message z is chosen by the Buyer and may depend on the public keys that were generated in the \(\mathsf {SharedKGen}\) phase, and on the Buyer’s private randomness. During the execution of the \(\mathsf {USG}\) protocol \(a-b\) private keys are “uncovered” (here \(b < a\) is some parameter), i.e., they are reconstructed by the parties. At the end of the execution they are discarded and the output of the protocol depends only on the key pairs whose private keys were not uncovered. Let \(({\hat{sk}}_1,{\hat{pk}}_1), \ldots ,({\hat{sk}}_b,{\hat{pk}}_b)\) denote these key pairs. Each \({\hat{pk}}_i\) is known to both parties, and each \({\hat{sk}}_i\) remains secret and is shared between the parties (as a pair \((\hat{d}^i_S,\hat{d}^i_B)\) of shares). Moreover the Seller knows the ECDSA signatures \({\hat{\sigma }}_1,\ldots ,{\hat{\sigma }}_b\) on z with respect to \({\hat{ pk }}_1,\ldots ,{\hat{ pk }}_b\) (respectively). The Buyer does not know these signatures, but we require that the Seller is committed (again: using \(\mathsf {COM}\)) to each \(F({\hat{\sigma }}_i)\), where F is a hash function (modeled as a random oracle). Let \(\varGamma _1,\ldots ,\varGamma _b\) denote the commitments created this way. Finally, we want the Buyer to be able to “force open” the values \(\hat{d}^1_S,\ldots ,\hat{d}^b_S\) after some time \(\tau _1\), so that he can reconstruct the private keys \({\hat{ sk }}_1,\ldots ,{\hat{ sk }}_b\) and sign any message that he wants using these keys. This is achieved using a \((\tau _0,\tau _1)\)-secure time-locked commitment scheme \(\mathsf {TLCOM}= (\mathsf {TLCommit},\mathsf {TLForceOpen})\). Let \(\varPhi _1,\ldots ,\varPhi _b\) denote the timed-commitments that were created this way.

To explain informally our security requirements, first let us say what are the goals of a malicious Seller. One obvious goal is to produce a signature on some message \(z^* \ne z\) (with respect to some \({\hat{ pk }}_i\)). A more subtle (and more specific to our applications) goal for the Seller is to learn some signature \(\sigma ^*_i\) on z (with respect to one of \({\hat{ pk }}_1,\ldots ,{\hat{ pk }}_b\)) other than \({\hat{\sigma }}_1,\ldots ,{\hat{\sigma }}_b\). Finally, she could try to time-commit to some value other than \(\hat{d}^i_S\) (so that, after time \(\tau _1\) passes, the Buyer cannot reconstruct \({\hat{ sk }}_i\)). Formally, we say that the malicious Seller \(S^*\) breaks the key i (for \(i=1,\ldots ,b\) ) if the Buyer did not abort the protocol and one of the following holds:

  • after the execution of the protocol \(S^*\) produces as output \(({\hat{\sigma }}^*_i, \hat{z}_i)\) such that \({\hat{\sigma }}^*_i\) is a valid signature on \(\hat{z}_i \ne z\) with respect to \({\hat{ pk }}_i\),

  • after the execution of the protocol \(S^*\) produces as output \({\hat{\sigma }}^*_i\) such that \({\hat{\sigma }}^*_i\) is a valid signature on z with respect to \({\hat{ pk }}_i\), and \(S^*\) opens the commitment \(\varGamma _i\) to a value different than \(F({\hat{\sigma }}^*_i)\),

  • the value \(d^{i *}_B\) that results from forced opening of \(\varPhi _i\) is such that \( \hat{d}^i_S \cdot d^{i *}_B \ne \hat{d}^i\).

Now, consider a malicious Buyer. Informally, his goal is to learn any valid signature on z with respect to any key \({\hat{ pk }}_1,\ldots ,{\hat{ pk }}_b\). If he does not succeed in this, then another goal that he could try to achieve is to learn at least one of the \(F({\hat{\sigma }}_i)\)’s. Recall also that the secrets of the Seller are time-locked. Hence after time \(\tau _0\) the Buyer can easily “break” the protocol, and our definition has to take care of it. Formally, we say that a malicious Buyer \(B^*\) wins if the Seller did not abort the protocol and before time \(\tau _0\) one of the following holds:

  • the \(B^*\) produces as output a signature on \(z^*\) (either \(z^* = z\) or \(z^* \ne z\)) that is valid with respect to one of the \({\hat{ pk }}_i\)’s,

  • the \(B^*\) learns some information about one of the \(F({\hat{\sigma }}_i)\)’s.

We say that a \(\mathsf {USG}\) protocol is \((\epsilon ,\hat{b})\) -secure if (a) for every polynomial-time malicious Seller the probability that she breaks at least \(\hat{b}\) keys is at most \(\epsilon + \mu (\lambda )\), where \(\mu \) is negligible, and (b) for every polynomial-time malicious Buyer the probability that he wins is negligible.

The implementation of the \({\mathbf {\mathsf{{USG}}}}\) protocol. Our \(\mathsf {USG}\) protocol is depicted on Fig. 2. We assume that before it is executed the parties run the \(\mathsf {SharedKGen}\) procedure a times (on input \(1^\lambda \)). We denote these executions as \(\mathsf {SharedKGen}^i(1^\lambda )\) for \(i = 1, \ldots , a\). As a result of each execution \(\mathsf {SharedKGen}^i\), both parties learn the public keys \( pk ^i\) and they secret-share the corresponding secret keys \( sk ^i\) (let \((d_S^i,d_B^i)\) be the respective shares).

The \(\mathsf {USG}\) protocol uses as a subroutine the protocol \(\mathsf {KSignGen}\) from Fig. 3. This protocol allows the parties to sign a message z using the secret key that is secret shared \(d = d_S \cdot d_B\). First they jointly create signing randomness K. Then the Seller creates a new key in the Paillier encryption scheme and sends the encryption of his share \(d_S\) of the signing key d to the Buyer. The Buyer calculates the encryption of the unfinished signature (using the homomorphic properties of the Paillier cryptosystem) and sends it to the Seller. Then the Seller decrypts it and completes the signature \(\sigma \). At the end the Seller commits to \(F(\sigma )\) and creates a timed commitment to \(d_S\). We now have the following lemma, its proof appears in [7].

Lemma 1

Suppose Paillier encryption is semantically secure, \(\mathsf {COM}\) and \(\mathsf {TLCOM}\) are secure commitment schemes, and the ECDSA scheme used in the construction of the \(\mathsf {USG}\) is Strongly Unforgeable signature scheme. Then the \(\mathsf {USG}\) protocol constructed on Fig. 2 is \((\epsilon , \hat{b})\)-secure for \(\epsilon = \left( b/a \right) ^{\hat{b}}\).

Fig. 2.
figure 2

The \(\mathsf {USG}\) protocol.

Full size image
Fig. 3.
figure 3

The \(\mathsf {KSignGen}(1^\lambda )\) procedure. Recall that \({\mathbb {G}}\) is an elliptic curve group for ECDSA, and \((\mathsf {AddHomGen},\mathsf {AddHomEnc},\mathsf {AddHomDec})\) is a Paillier encryption scheme which is additively homomorphic over \({\mathbb {Z}}_n\), where \(n > 2 \cdot {\left| {\mathbb {G}}\right| }^4\).

Full size image

3.3 The Construction of the \(\mathsf {SellWitness}_f\) Protocol

In this section we show how to use the \(\mathsf {USG}\) protocol to construct the \(\mathsf {SellWitness}_f\) protocol (defined in Sect. 3). Our assumption is that f has a zero-knowledge proof of knowledge protocol, that we denote \({\mathcal {F}}\), in which the Seller can prove that she knows an x such that \(f(x) = \mathsf {true}\). Additionally \({\mathcal {F}}\) consist of two phases: \(\mathsf {Setup}_{\mathcal {F}}\) and \(\mathsf {Challenge}_{\mathcal {F}}\). Let the values \(A_{\mathcal {F}}\) and \(B_{\mathcal {F}}\) denote the views of the Seller and the Buyer (respectively) after executing the \(\mathsf {Setup}_{\mathcal {F}}\) phase. In the \(\mathsf {Challenge}_{\mathcal {F}}\) phase the Buyer generates a challenge message \(c_{\mathcal {F}}= \mathsf {GenChallenge}_{\mathcal {F}}(B_{\mathcal {F}})\) and sends it to the Seller. Then the Seller calculates the response \(r_{\mathcal {F}}= \mathsf {GenResponse}_{\mathcal {F}}(x, A_{\mathcal {F}}, c_{\mathcal {F}})\) and sends it to the Buyer. At the end the Buyer accepts according to the output of the function \(\mathsf {VerifyResponse}_{\mathcal {F}}(B_{\mathcal {F}}, c_{\mathcal {F}}, r_{\mathcal {F}}) \in \{\mathsf {true}, \mathsf {false}\}\). The fact that \({\mathcal {F}}\) is a proof of knowledge is formalized as follows: we require that there is also a function \(\mathsf {Extract}_{\mathcal {F}}\) s.t. \(\mathsf {Extract}_{\mathcal {F}}(B_{\mathcal {F}}, c^1_{\mathcal {F}}, r^1_{\mathcal {F}}, c^2_{\mathcal {F}}, r^2_{\mathcal {F}}) = x'\) and \(f(x') = \mathsf {true}\) if only \(\mathsf {VerifyResponse}_{\mathcal {F}}\) \((B_{\mathcal {F}}, c^i_{\mathcal {F}}, r^i_{\mathcal {F}}) = \mathsf {true}\) for \(i = 1, 2\) and \(c^1_{\mathcal {F}}\ne c^2_{\mathcal {F}}\). That means that the witness \(x'\) can be computed from the correct answers to two different challenges. We also assume that from the point of view of the Seller the challenge \(c_{\mathcal {F}}\) is chosen uniformly from the set \(X_{A_{\mathcal {F}}}\). Without loss of generality we also assume that \(X_{A_{\mathcal {F}}} = \{0,1\}\).

The parties use the \(\mathsf {USG}\) protocol, so we have to describe how the Buyer produces the message z to be signed. Given the public keys \(\hat{ pk _1}, \ldots , \hat{ pk _b}\) the Buyer first creates a transaction \(T_1\) that takes from his funds and sends them to a multisig escrow using public keys \(\hat{ pk _1}, \ldots , \hat{ pk _b}\) and \(b-1\) times his own public key \( pk _B\). The Buyer does not broadcast \(T_1\) yet. Then he creates a transaction \(T_2\) that spends the transaction \(T_1\) and sends all the funds ( minus fee) to the public key \( pk _S\) owned by the Seller. The simplified transaction \(z:= [T_2]\) is the message that the parties later sign. We call this procedure \(\mathsf {GenMsg}_T\). We assume that each \(S^i\) from the \(\mathsf {USG}\) protocol is divided into \(2 \lambda \) parts \(S^{i, 1}, \ldots , S^{i, 2\lambda }\) each of size \(\lambda \). Additionally we assume that each part \(S^{i, j}\) is committed separately. To explain the idea behind our protocol assume for simplicity that \(b = 1\). Recall that at the end of the \(\mathsf {USG}\) protocol the Buyer knows the transaction \(T_1\) that sends his funds to the key secret-shared between the Seller and the Buyer. Both parties know the transaction \(T_2\) that is redeeming the transaction \(T_1\) and sends the money to the Seller. The Seller knows the signature \(\sigma \) on \(T_2\), but she cannot use \(T_2\) yet, because the Buyer did not broadcast \(T_1\). When the Buyer learns \(\sigma \) then he will be able to learn the secret random values \(S^1, \ldots , S^{2\lambda }\) to which the Seller is committed. Additionally after some (long) time the Buyer will learn the secret key needed to redeem \(T_1\) when only he force-opens the time-locked puzzle hiding \(d_S\).

Now the Seller and the Buyer will use cut-and-choose technique again. They run \(2 \lambda \) times the first part \(\mathsf {Setup}_{\mathcal {F}}\) of the zero knowledge proof of knowledge \({\mathcal {F}}\) of the x satisfying f. Each time the Seller calculates the responses \(r^i_0\) and \(r^i_1\) to the challenges \(c = 0\) and \(c = 1\). The Seller encrypts \(r^i_0\) and \(r^i_1\) using the same key \(S^i\) to get \(\gamma ^i_0\) and \(\gamma ^i_1\) and she commits to each ciphertext. Then the Buyer selects \(\lambda \) indices \(j_1, \ldots , j_\lambda \) and challenges the Seller on them using \(c_1, \ldots , c_\lambda \in \{0,1\}\). The Seller opens commitments to \(S^{j_1}, \ldots , S^{j_\lambda }\) and to \(\gamma ^{j_1}_{c_1}, \ldots , \gamma ^{j_\lambda }_{c_\lambda }\) (the Seller opens only one of \(\gamma ^{j_k}_0, \gamma ^{j_k}_1\)) and the Buyer uses secrets \(S^{j_k}\) to decrypt \(\gamma ^{j_k}_{c_k}\) and verify the response. If the Buyer verifies everything without an error, then the Seller opens the commitments to \(\gamma ^k_0\) and \(\gamma ^k_1\) (but not \(S^k\)) for \(k \ne j_1, \ldots , j_\lambda \).

Now the Buyer broadcasts the transaction \(T_1\). The Seller can spend it by revealing \(\sigma \) — in that case the Buyer can compute \(S^k\), decrypt \(\gamma ^k_0\) and \(\gamma ^k_1\) to learn responses \(r^k_0\) and \(r^k_1\) and from them extract the value x. And if the Seller does nothing then after some time the Buyer will solve his time-locked puzzle, learn the secret key and take his funds back. The \(\mathsf {SellWitness}_f\) protocol is depicted on Fig. 4. We have the following lemma, its proof appears in [7].

Lemma 2

Suppose Paillier encryption and symmetric encryption are semantically secure, \(\mathsf {COM}\) and \(\mathsf {TLCOM}\) are secure commitment schemes, and the ECDSA scheme used in the construction of the \(\mathsf {USG}\) is Strongly Unforgeable signature scheme. Assume additionally that there is a zero knowledge proof \({\mathcal {F}}\) of knowledge of x s.t. \(f(x) = \mathsf {true}\) of the required form. Then the \(\mathsf {SellWitness}_f\) constructed on Fig. 4 is \(\epsilon \)-secure for \(\epsilon = \left( \frac{b}{a} \right) ^{b}\).

Fig. 4.
figure 4

The \(\mathsf {SellWitness}_f\) protocol.

Full size image
Fig. 5.
figure 5

The \(\mathsf {ZKFactorization}(n)\) protocol

Full size image

3.4 Protocol for Selling a Factorization of an RSA Modulus

In this section we use the \(\mathsf {SellWitness}\) protocol to construct the protocol for selling a factorization of an RSA modulus. To do it, we introduce the \(\mathsf {ZKFactorization}\) protocol depicted on Fig. 5 — a zero knowledge proof of knowledge of the factorization of the RSA modulus. We now have the following lemma, whose proof appears in [7].

Lemma 3

Assume that the commitment scheme is hash based and we model the hash function as a programmable oracle. Then the protocol \(\mathsf {ZKFactorization}\) depicted on Fig. 5 is a zero knowledge proof of knowledge of the factorization of the RSA modulus.

Fig. 6.
figure 6

The running time of the Step 1 and the probability that the Seller successfully cheats the Buyer in the Step 1 of the \(\mathsf {SellWitness}\) protocol for the following fixed parameters: (i) \(\lambda = 1024\) and \(b=1\) (i.e. using only standard single-signature transactions), and (ii) \(\lambda = 512\) and \(b=8\) (i.e. using multi-signature transactions with the greatest parameters that are standard in Bitcoin) and different values of a. The running time of Step 1 is proportional to a and does not depend on other parameters. Using greater b gives much better security.

Full size image

Implementation of the protocol for selling a factorization of an RSA modulus. We have created a prototype implementation of the protocol for selling a factorization of an RSA modulus. The main part of the protocol is written in C++, it is using the Crypto++ library for cryptographic functions. The Bitcoin related functionality is written in Java using the bitocinj library. The communication between C++ and Java is operated by Apache Thrift. The implementation is only a proof of concept but we were able to verify the feasibility and efficiency of the protocol. The current version of the protocol can be found on github.com/SellWitness/ZKFactorization. When using the \(\mathsf {ZKFactorization}\) protocol in the \(\mathsf {SellWitness}\) protocol we were able to simplify the main protocol a little. In the \(\mathsf {ZKFactorization}\) protocol the Seller sends the commitments to the square roots of y but now it is not necessary because we do similar step in the \(\mathsf {SellWitness}\) protocol. This is why the only messages exchanged between the parties before the Buyer sends the challenge are: first the Buyer sends \(y^{i,j}\), then the Seller calculates the square roots \(r^{i,j}_0, r^{i,j}_1\) of y, encrypts them \(\gamma ^{i,j}_k = Enc_{S^{i,j}}(r^{i,j}_k)\) and commits to both \(r^{i,j}_k\). In the implementation we use the following parameters: \(a = 512\), \(b = 8\) and \(\lambda = 1024\). We use \(b=8\) because it means multisig transactions, and this kind of multisig transaction are standard in Bitcoin (for greater b they would be non-standard). We set \(\lambda = 1024\), so the \(\mathsf {ZKFactorization}\) protocol is executed \(b \cdot 2\lambda = 8 \cdot 2048\) times. Fortunately this phase does not require any costly public key cryptography operations and therefore it is still very efficient. We set \(a = 512\) and \(b = 8\), and hence the probability of cheating is at most \(\left( b/a\right) ^b = 2^{-48}\). The running time of our protocol (i.e. the time until the Buyer broadcasts \(T_1\)) for this configuration (and primes of size about 512 bits each) is about 1 min — the running time of the \(\mathsf {USG}\) protocol is about 33 s and Step 2 in the \(\mathsf {SellWitness}_f\) protocol takes about 28 s. The numbers are an average over 10 runs of the algorithm using a single thread on a standard personal computer. We note that the running time could be improved by using multiple threads. Additional measurements are presented on Figs. 6 and 7.

Fig. 7.
figure 7

The running time of the Step 2 of the \(\mathsf {SellWitness}\) protocol for the following fixed parameter: (i) \(a = 512\) and \(b=1\) (i.e. using only standard single-signature transactions), and (ii) \(a = 1024\), and \(b=8\) (i.e. using multi-signature transactions with the greatest parameters that are standard in Bitcoin) and different values of \(\lambda \). The running time of Step 2 is proportional to \(b \cdot \lambda \) and does not depend on a. The probability of successfully cheating (by either the Buyer or the Seller) in step 2 is negligible in \(\lambda \).

Full size image

We run our protocol on a single machine, and local testing blockchain (testnet-box) and hence posting on blockchain, and communication between the parties was almost immediate (our current implementation takes 12 rounds, and the total communication size is about 60 MB). However, since we use the time-lock commitment schemes we need a conservative estimate on how much time would the execution of our protocol take on real blockchain, and when the parties are running in different physical locations. As in our protocol the parties have to wait for two transactions to be included into the blockchain, we have to assume that the whole protocol may take up to two hoursFootnote 2. Taking into account time needed to post messages on the blockchain the running our protocol takes on average 2 h, we have to have at least \(\tau _0 = 5\) h, so \(\tau _1\) should be set to 50 h. Our tests has shown that an honest user (on an standard personal computer) can compute about \(2^{19}\) squares (modulo n of size \(\lambda = 1024\) bits) per second. That is why in our protocol we set the hardness of the timed commitment to \(t = 2^{37}\).