1 Introduction
1.1 Background
The problem of fair exchange is how two mutually distrusting parties can jointly exchange digital assets such that each party receives the other party’s input or neither does. There exist a variety of fair exchange protocols in the literature, all with their own specifications and system model. We divide fair exchange protocols to three categories:

Trusted Third Party: fair exchange becomes trivial if both parties can agree on a mutual trusted third party. The parties will send the trusted party the digital assets. The trusted party will verify correctness and redistribute to the counterparty. To make it a more scalable solution there is a line of research to design optimistically fair protocols, such that the trusted third party gets involved only in case of disputes which are assumed to be rare [opt_fair_1, opt_fair_2, opt_fair_3].

Gradual Release of Secrets: This method achieves partial fairness such that one party can get advantage over the other party but this advantage is polynomially bounded. The idea is to enable each party to release their secret bit by bit in alternation [grad_rel].

Monetary Penalties: parties are incentivized to complete the protocol fairly, and if one party receives its output but aborts before the other party does, the cheating party will have to pay a penalty [escrow, kumaresan15poker, lindell_legal].
Focusing on blockchains, fair exchange is a precursor for escrow protocols with cryptocurrencies [escrow], markets, auctions, games [kumaresan15poker] and atomic crosschain swaps (ACCS).
An ACCS is a task in which multiple parties wish to exchange digital assets from possibly distinct blockchains, in such a manner where all parties receive their desired output from another party, or neither does. In this paper we consider specifically the twoparty setting.
Blockchains are decentralized by nature, therefore a core challenge is to design protocols without a single point of failure in the form of a trusted third party which takes full custody of users’ funds. Early ACCS protocols leveraged the blockchain itself as a decentralized trusted party that can lock and release funds according to preprogrammed rules.
The first successful atomic crosschain swap construction is credited to TierNolan [nolan]. It leverages Bitcoinlike script for creating conditional transactions by the two exchanging parties: each party locks its funds such that the counterparty can spend them by using the preimage of an agreed hash value. When one party spends a transaction, it reveals the secret to the other party which can use it to spend the other conditional transaction on the other blockchain. There is also a timeout after which the funds can be refunded if not redeemed by the counterparty. Such conditional spending is termed Hashed Timelock Contract (HTLC) and has been specified and extended in [LN] and [bip199]. Herlihy in [accs] has formalized the theory of such atomic crosschain swaps. Poelstra [poelstra2017scriptless] has introduced the notion of scriptless scripts and described how to achieve atomic swaps without the need of explicit scripting within transactions. Instead, Schnorr signatures [schnorr1991efficient] are used: the spending of a transaction reveals a secret merely by the unlocking signature itself, and only to the counterparty. This has many benefits to blockchains throughput, efficiency of swap protocols and also to fungibility and privacy. Malavolta et al. [malavolta2019anonymous] has extended this technique to ECDSA. The latter two studies have opened the door for scriptless atomic crosschain swaps for a variety of existing blockchains. However, they are still limited to blockchains which support either Schnorr or ECDSA signatures that share the same elliptic curve parameters, namely  the same group generated from the same fixed generator.
1.2 Our Contribution
Our solution, the JugglingSwap ACCS protocol, is based on gradual release of secrets. We observe that there are two ways to transfer value in a blockchain:

A transaction backed by a digital signature.

A transfer of a secret key.
To the best of our knowledge, all existing exchange methods use the first method. The first method naturally has more constraints to it: either it depends on the scripting capabilities of the underlying blockchain [accs, nolan, bip199] or on specific mechanics of the underlying signature scheme [poelstra2017scriptless, malavolta2019anonymous]
. The second method is purely cryptographydependent with small variance between blockchains and thus can fit
and be reused for many chains architectures.The vast majority of blockchains tie funds to key pairs of an elliptic curve group where the elliptic curve discrete logarithm problem (ECDLP) is considered hard. Exchanging between two chains in that case comes down to encrypting the secret key with the other party’s public key. The two problems that arise:

When one party transfers a secret key to a second party it does not lose knowledge of this secret key. The transfer is like a ”copy” whereas in a transaction based swap the transfer is like a ”cut”: the sending party loses access to the funds. The undesired result is that both sending and receiving parties can use the secret key at the end of the transfer.

The exchange is not fair. The first to send the encryption will risk the other party to not complete the protocol.
We address these issues in the following way: first, we add a layer of threshold cryptography for secret key management. The crosschain interoperability remains and we get better security. We start our protocol assuming that each of the two trading parties, the owners, has a joint twooutoftwo () address with the same centralized provider.
Second, we introduce and use a new building block we call Juggling: a novel verifiable encryption [cs03] construction for transferring segments of a discrete logarithm. It allows a prover to encrypt a secret in parts and prove that each resulting ciphertext is indeed an encryption of a segment of a secret key of some known public key, under some known encryption key.
Combining these two building blocks, the ACCS protocol goes as follows:

The two owners and the provider generate two addresses: one on each of the two blockchains. Each party keeps a local secret key share.

Each owner deposits funds into the address of its source blockchain.

The two owners start executing two interleaving Juggling protocols, in order to achieve a partial fair exchange of their respective secret shares of the two addresses. In other words  they gradually release their secret shares, segment by segment. Eventually both owners hold 2 shares of their counterparty’s address and only 1 share of their own address.

Each owner cosigns with the provider in order to withdraw the funds from the counterparty’s address to its own wallet.
During the execution of the Juggling protocol (step 3), in case one party decides to cheat, the maximal advantage is to be one segment ahead. For small enough segment bit size this is acceptable.
The provider’s role can theoretically be played by a trusted execution environment (TEE).
The resulting ACCS protocol is scriptless. The blockchain footprint of our method is between one to two regular transactions on each blockchain. Therefore, it offers similar benefits as the ACCS protocols in [poelstra2017scriptless, malavolta2019anonymous] in terms of improved blockchain throughput and more efficient swaps (cheaper than their scriptdependant alternatives), as well as in fungibility and privacy. On top of that, because Juggling is applicable on arbitrary groups, JugglingSwap has weak assumptions on the participating blockchains: it only requires that (1) a threshold variant exists for the underlying signature algorithm and (2) it is based on ECDLP. Therefore, the set of pairs of blockchains supported by our protocol strictly contains the set of possible pairs by prior art, so it offers a higher degree of interoperability.
Finally, We believe that the Juggling protocol can be of separate interest and used as a building block for other constructions as well.
1.3 Related Work
1.3.1 Gradual Release of Secrets:
The notion of partial fairness, originated in [partial1, partial2], was proposed as a way to overcome the impossibility result of perfect fairness in a setting without a trusted third party [cleve]. Several protocols, such as [damgard, damgard2], were built on top of this security notion. Previous works are mainly focused on bit by bit release of either the secret itself or a digital signature from the secret and are not generalizable to elliptic curves DLog. Our protocol is aimed for gradually releasing a ciphertext encrypting an ECDLog, where the encryption correctness is publicly verified for every segment and segment size is configurable.
1.3.2 Crypto Asset Exchange:
Several types of exchange methods exist, most of them are used in practice today. In centralizedcustodial exchanges (e.g. [binance]
), the exchange is a trusted third party. Funds are deposited to the exchange platform, trading is done within the platform and finally the funds can be withdrawn to a private wallet. From the moment of the deposit and until the withdrawal the funds are owned by the exchange which at any moment can be hacked, stop working or become malicious and steal all the funds currently held by the platform.
Centralized but noncustodial trading systems (e.g. [shapeshift]) are platforms that guarantee security before and after the trade but not in the middle: after funds have been sent to the system by the user and before they are returned, the user must trust the trading platform, which again can be hacked, suffer denial of service (DoS) or become malicious and steal the funds. The presence of such a single point of trust clearly does not match well the decentralized nature of blockchain technology.
Another form of exchange is decentralized exchanges (or ”DEXes”, e.g. [zerox, uniswap]). These are trustless platforms that settle trades on the blockchain. They can suffer from security issues such as frontrunning and transaction reordering [frontrun, daian19flash]. The onchain trading makes scalability another issue. Lastly, as they typically utilize smart contracts, they are limited to support only the assets of the specific blockchain the contracts are deployed on.
Tesseract [tess] is using Intel SGX enclave as a trusted execution engine to provide a better trusted centralized custodial exchange. The problem with this method is that SGX can suffer from security vulnerabilities as shown recently [sgx]. Arwen’s [heilman2020arwen] protocol offers centralized noncustodial approach based on building blocks that are used in the Lightning network protocol [LN], namely an escrow service with offchain trading and onchain settlement. The problems with this protocol are the same as the problems with the Lightning network, for example: (1) limited capacity, (2) an exchange needs to have many coins tied up to escrow channels, (3) fits only blockchains with specific features such as expiry time transactions and (4) requires a new implementation for every blockchain added.
2 Preliminaries
Here we provide high level informal definitions for Threshold Signatures, Verifiable Encryption and Bulletproofs range proofs. For a more detailed treatment we refer to the original papers.
2.1 Threshold Signatures
Let =(KeyGen, Sign, Ver) be a signature scheme. Following [dss96] A threshold signature scheme for is a pair of protocols (ThreshKeyGen, ThreshSign) for the set of parties . ThreshKeyGen is a distributed key generation protocol used by the players to jointly generate a pair of public/private keys on input a security parameter . At the end of the protocol, the private output of party is a value such that the values form a threshold secret sharing of . The public output of the protocol contains the public key . Public/private key pairs
are produced by ThreshKeyGen with the same probability distribution as if they were generated by the KeyGen protocol of the regular signature scheme
. ThreshSign is the distributed signature protocol. The private input of is the value . The public inputs consist of a message and the public key . The output of the protocol is a value Sign. The verification algorithm for a threshold signature scheme is, therefore, the same as in the regular centralized signature schemeDefinition 1
We say that a threshold signature scheme =(ThreshKeyGen,ThreshSign) is unforgeable, if no malicious adversary who corrupts at most players can produce, with nonnegligible (in ) probability, the signature on any new (i.e., previously unsigned) message , given the view of the protocol ThreshKeyGen and of the protocol ThreshSign on input messages which the adversary adaptively chose.
This is analogous to the notion of existential unforgeability under chosen message
attack as defined by [digsig]. Notice that now the
adversary does not just see the signatures of messages adaptively chosen, but
also the internal state of the corrupted players and the public communication of
the protocols.
We call the special case of , namely a protocol which allows a group of signers to produce a short, joint
signature on a common message where all participants are required to be honest, a multisignature.
2.2 Verifiable Encryption
Loosely speaking, verifiable encryption [cs03] for a relation is a protocol that allows a prover to convince
a verifier that a given ciphertext is an encryption under a given public key of a value such that
for a given .
Let (Gen, Enc, Dec) be a public key encryption scheme, and let be a key pair.
A verifiable encryption scheme proves that a ciphertext encrypts a plaintext satisfying a certain
relation . The relation is defined by a generator algorithm which on input outputs a
description , of a binary relation on . We require that the sets and
are easy to recognize (given ). For , an element such that is called a witness for . The idea is that the encryptor will be given a value , a witness for , and then encrypts yielding a ciphertext . After this, the encryptor may prove to
another party that decrypts to a witness for . In carrying out the proof, the encryptor
will of course need to make use of the random coins that were used by the encryption algorithm: we denote by Enc’, m) the pair (, ), where is the output of Enc and are
the random coins used by Enc to compute .
In such a proof system, the (honest) verifier will output 0 or 1, with 1 signifying “accept.”
We require that the proof system is sound, in the sense that if a verifier accepts a proof, then with overwhelming probability, indeed decrypts to a witness for . However,
it is convenient, and adequate for many applications, to take a more relaxed approach: instead
of requiring that decrypts to a witness, we only require that a witness can be easily
reconstructed from the plaintext using some efficient reconstruction algorithm. Such an algorithm
takes as input a public key , a relation description , , an element , and a
message m , and outputs .
Definition 2
A proof system , together with mutually compatible encryption scheme , relation generator , and reconstruction algorithm , form a verifiable encryption scheme, if Correctness, Soundness and Special honestverifier zero knowledge properties hold as defined in [cs03].
2.3 Bulletproofs Range Proofs
Range proofs are proofs that a secret value, which has been encrypted or committed to, lies in a certain interval. Range proofs do not leak any information about the secret value, other than the fact that they lie in the interval. Bulletproofs [bulletproof] can be used as an efficient instantiation of range proofs and work on Pedersen commitments [pedersen]. Formally, let group element be a Pedersen commitment to value using randomness . The proof system will convince the verifier that . Bulletproofs are based on Inner Product Argument and maintain perfect completeness, perfect special honest verifier zeroknowledge, and computational witness extended emulation, defined in [bulletproof].
3 The Juggling Protocol
3.1 Specification and Definitions
Let be an elliptic curve group of prime order with base point (generator) . Party knows discrete log (DLog) such that .
Definition 3
mSegmentation of is the division of to segments such that where for segment length in bits .
Definition 4
We say that a proof is a proof of correct encrypted ksegment if it is a publicly verifiable zero knowledge proof for encryption scheme , public key , value , relation , ciphertext and parameters such that is the encryption of using public key , where is the ’th segment of mSegmentation of a witness such that .
Definition 5
A proof system , together with mutually compatible encryption scheme and parameter is a SegmentedVerifiable Encryption (SVE) if (a) it is a VE for witness and (b) the witness can be mSegmented such that for each segment the prover can prove correct encrypted ksegment for the same witness .
Definition 6
Juggling protocol is SVE implementation where the witness is an elliptic curve DLog and segment encryptions and proofs are being released serially.
It is assumed that there exists a PKI such that all public keys are registered. If it is not the case, all participants will add a setup phase for key pairs generation and registration.
3.2 Auxiliary Proofs
All proofs are for public EC parameters .
3.2.1 Proof of ECDDH membership:
This is a proof of membership that a tuple is an Elliptic Curve Decisional Diffie Hellman (DDH) tuple: . This proof is an adaptation of the proof in [cp93] for elliptic curves. Proof for the following relation: the witness is , the statement is . The relation outputs if and .
The protocol works as follows:

The prover sends and to the verifier with

The verifier sends a random challenge

The prover responds with

The verifier checks that and
See [cp93] for the formal proof.
3.2.2 Proof of correct encryption:
This is a proof of knowledge that a pair of group elements form a valid homomorphic ElGamal encryption (”in the exponent”) [elgamal] using public key . Specifically, the witness is , the statement is . The relation outputs if , .

The prover chooses , computes and sends to the verifier .

The verifier picks a challenge .

The prover computes and .

The verifier accepts if and .
3.2.3 Proof of correct encryption of DLog:
This is a version of the previous proof where we also know public key and want to prove that is homomorphic ElGamal encryption that encrypts the DLog of , specifically. This is a proof for the following relation: the witness is , the statement is . The relation outputs if , , . To prove this the prover needs (a) to prove knowledge of the DLog of in base and (b) to prove that is a DDH tuple. The proof can be optimized by using the same challenge as follows:

The prover chooses , computes and sends to the verifier.

The verifier picks a challenge .

The prover computes and .

The verifier accepts if and and .
The protocols can become noninteractive using FiatShamir transform. Both Constructions: proof of correct encryption and proof of correct Encryption of DLog are Sigma protocols [carmit] with straight forward security proofs. We provide the proofs in Appendix A.
3.3 Construction
We observe that SVE can be implemented using an encryption scheme with homomorphic properties. We choose homomorphic ElGamal encryption as the base encryption scheme [elgamal]. Figure 1 shows a sequence diagram of the protocol.
[userdefinedwidth = 12.3cm]

Key Generation:
For EC parameters and security parameter every party chooses random for secret key and computes for public key. All public keys are registered. 
Encryption:
Upon input where are public keys and is a secret key such that the encryptor (interchangeably will be called the prover, depends on operation) divides toequal segments (last segment can be padded with zeros). The segments
should be small enough to allow extraction of from in polynomial time in the security parameter.
For every segment : the encryptor computes the homomorphic ElGamal encryption : for random .

The encryptor publishes together with Bulletproofs ([bulletproof], noninteractive zero knowledge range proofs) proving that every is a Pedersen commitment [pedersen] with value smaller than (*).

The encryptor publishes and plays the prover in proof of correct encryption of DLog (3.2.2) with witness and statement , where .

An encryption for a segment will be full once the encryptor publishes of this segment together with a proof of correct encryption (3.2.3).


Decryption:
Given a secret key , for every pair , can be decrypted by extracting from using algorithm for breaking DLog. After all segments are decrypted can be reconstructed.
(*) Except to the MSB segment which is tightly bounded to the most significant bits of .
Juggling Scheme
3.4 Security Analysis
In this section we show that the construction is following the specifications.
Lemma 1
If DDH is hard relative to , then the scheme {Key Generation, Encryption, Decryption} is CPAsecure encryption scheme.
Proof sketch: ElGamal encryption in the exponent, like standard ElGamal encryption is CPAsecure under DDH [intro_to_crypto, elgamal]. is ElGamal encryption in the exponent with randomness . Because the randomness is changed for every encryption the different encryptions are unrelated.
Lemma 2
The proof system in protocol together with homomorphic ElGamal encryption scheme is a proof of correct encrypted ksegment of DLog of , with parameters k, m, Y and security parameter .
Proof sketch: The proof system consists of proofs given in a specific order and correspond to gradual release of the ciphertext:

Bulletproofs.

Proof of correct encryption of DLog.

Proof of correct encryption for first segment

…

Proof of correct encryption for the ’th segment
the order of the last proofs can be different and it is easy to show that it does not effect security.
The security proof shows that only proofs are needed to proof correct encrypted ksegment. Specifically, for segment there is no use for the proofs of correct encryption for the other segments.
Correctness:
This part of the proof is where we need range proofs, which are efficiently instantiated by Bulletproofs. To intuitively understand why, let us first describe a possible attack and why bulletproofs can mitigate it. Proof of correct encryption for the ’th segment proves to the verifier that is homomorphic ElGamal encryption using public key . The general proof of correct encryption proves to the verifier a statement about the shifted sum () of the ’s and ’s. Namely, that is Homomorphic ElGamal encryption of under public key . A simple attack would be to encrypt biased segments such that the shifted sum will remain the same but each segment encryption will be decrypted wrong. W.l.o.g let us change only two segments: for segment to encrypt the point and for segment to encrypt the point . After decryption, value extraction and segment summation the result would remain the same and equal to but both segment encryptions would have extracted to wrong values. In particular the ’th segment will be extracted to . The implication of such attack is that if a prover aborts in the middle of the gradual release, then the decryptor will remain with nothing while it was expected that it will have all the already published segments of the secret. We now show how assuming Bulletproof security prevents this specific attack and then generalize it to all possible changes to encrypted segments . In our attack there are four cases: one case where both are in range and three cases where at least one of are not in the range . For the last three cases it is easy to see that at least one Bulletproof range proof will not verify with high probability. For the first case in order for the proof of correct Encryption of DLog to pass we require the sum , to equal a multiple of , the order of the curve. Every option other than and will result in at least one of out of range with high probability.
We are now ready to generalize this argument:
Claim 1. For any segment ciphertext not in the form with independent of verification will pass with probability.
Proof: Assuming correctness of bulletproofs, proof of correct encryption of DLog and proof of correct encryption of segment, if the ’th ciphertext is of different form it means that at least one other segment must encrypt an additional compensating element in the ’th segment to cancel the change. This additional element would have cause the range proof for this segment to fail with probability .
Claim 2. For any segment ciphertext in the form , if verification will pass with probability.
Proof: The following must hold: If for some at least one of the ’s will lead to . Assume to the contrary that for all : and . Combining this equations we get . We assume for simplicity that the most significant segment of is allones. Usually this will restrict the secret key to a very small number such that for random secret key there is negligible probability that the equation will hold. If the secret key is not chosen randomly or if we want to make the probability lower we can simply use secret keys with most significant bit fixed and equal to (This will not effect security, see discussion in [lindell17] on using secret key ). This can be also proven in Encryption time by providing a range proof on . Now the most significant segment can be range proofed to be in the range such that is negative and therefore assuming bulletproof security, this is possible with only probability.
Soundness: Soundness comes from the soundness of proof of correct encryption of DLog. There exist algorithm that given and two transcripts of this proof with two different challenges outputs such that . This is enough because algorithm for soundness of the proof of correct encrypted ksegment of DLog can use and output the ’th segment of the result.
Special honest verifier ZK: All three types of proofs: bulletproof, proof of correct encryption of DLog and proof of correct encryption have the special HVZK security property, meaning there exist a simulator that can output computational indistinguishable distribution by calling the special HVZK simulators of the underlying relevant proofs.
Theorem 3.1
Proof sketch: The proofs of correct encryption combined form a VE of witness and DLog relation if . The prover cannot change witness from the range proof to the proof of correct encryption of DLog since otherwise the prover would have broken the binding property of as a commitment, which is equivalent to finding the DLog of which assume to be hard. Same is true for changing witness from proof of correct encryption of DLog to the proofs of correct encryption. Property 2 of SVE definition holds because Lemma 2 is true for all in the mSegmentation of . Assuming DDH is hard: The encryption scheme is CPA secure (lemma 1) and bulletproof is zero knowledge range proof ([bulletproof] Definition 13).
4 Atomic CrossChain Swap Protocol
4.1 Background
Without many exceptions, all blockchains today are using a digital signature algorithm that has an existing variant for threshold signing. Most dominant are ECDSA and Schnorr based signatures (including EdDSA) [boneh17, lindell17, doerner, goldfeder18, lindell18, maxwell, cosi]. In addition BLS signatures show great promise for the blockchain use case [boneh18]. A wallet is a user interfacing software that generates and manages private keys, constructs and signs messages (transactions) for the relevant cryptocurrencies. Our wallet design is based on ThreshKeyGen and ThreshSign with minimal amount of participants. We aim to fit it to a simple clientserver communication model and therefore take . For the fair exchange protocol we will need a threshold signature scheme. We assume that multiple cryptocurrencies are supported by this wallet.
4.2 Roles and Network
We define two roles: owner and provider. The owner is the end user who owns the funds in the account and holds one secret share of the secret key. The provider is another share holder of the secret key but does not provide funds to the shared account. Its role is to provide the additional security in the system aiding and enabling the owner to generate keys and transact in distributed fashion. From network perspective, one provider is connected to many owners which together maintain the provider, for example paying its cost in transaction fees. The provider can run on any machine: from a Trusted Execution Environment (TEE) to a machine operated by an incentivized human operator. Multiple providers can compete for owners. Access to a full node can be done either by both parties locally or outsourced to a number of other parties.
4.3 Setup
The provider and owner will run ThreshKeyGen. Public keys are used to generate blockchain addresses.
It is assumed that two parties, and , that are sharing the same provider (both run ThreshKeyGen with the provider) wish to conduct an exchange between two assets on two different chains. In details, each party holds funds (i.e. tokens) on the blockchain they wish to swap from, , in an input address we denote . The amount of funds held by each party should be at least the amount they wish to swap, denoted as .
Each party would also have a withdraw address we denote , on the blockchain they wish to swap to, . This address is not necessarily generated in advance and can be generated later as the protocol progresses, but for sake of simplicity we define it in the setup phase. Note: we provide a description in terms of addresses but an exact description holds with respect to unspent transaction outputs (UTXOs).
The amounts and maker/taker roles are matched by a public matching engine.
4.4 The Protocol
[userdefinedwidth = 12.3cm]

Party runs Juggling.KeyGen to create a decryption/encryption key pair and ( and ). The parties then exchange each other’s public (encryption) keys and .

run ThreshKeyGen: The output is public key and secret shares to each party. We call the local public key of party if is the elliptic curve DLog of . is used to derive address in blockchain .

run ThreshKeyGen again with outputs and for the local public keys. is used to derive address in blockchain .

runs ThreshSign with the provider to transfer from an amount of tokens to . The provider will broadcast the two signed transactions to the two blockchains simultaneously.

and run Juggling.Encryption with inputs and respectively. Encryption is done with segmentation enabled: and run Juggling.Encryption up to step (d). If one of the previous steps failed  abort.
Repeat for :
sends (encryption of ) and corresponding proof of correct encryption.

and verify proof of correct encryption (aborts if false) and decrypt the segment encryption. and send back (encryption of ) and corresponding proof of correct encryption.

and verify proof of correct encryption (abort if false) and decrypt the segment


After decryption is done and run {3,3}ThreshSign to sign the withdraw transaction which empties into .
The transaction can now be broadcast by either or .
5 Analysis
In this section we give informal discussion on security aspects of the protocol. First, we show correctness of the scheme. Second, we show that the protocol guarantees robustness against malicious adversaries and in particular we show that users of the underlying key management infrastructure do not need to make any additional security assumptions when conducting a swap. Finally, we discuss practical aspects such as cost and privacy.
5.1 Use of Juggling
The security of the scheme relies on the security of Juggling scheme: The protocol consists basically of two interleaving Juggling protocols, where the two trading parties are switching the roles of the encryptor and the decryptor. Key generation is done as part of the creation of addresses. Encryptor encrypts its secret share of the public key with . The segmentation property of the encryption together with the publicly verifiable proofs are taking care of the partial fairness of the exchange: if segment is false both parties will either have the same amount of already decrypted segments or one of the parties will have one less decrypted segment. Assuming small segments and that the protocol stopped at a stage where extraction of the rest of the secret share is possible, both parties will need the same resources to get the full secret share. We discuss later the case where one party aborts very early in the protocol such that full extraction is not possible.
After all encrypted segments were transferred to the other party and decrypted, the addresses are effectively degenerated into addresses between the provider and the counterparty which is the new owner. The owner can eventually spend from these addresses using the ThreshSign algorithm by contributing its own secret share created at the key generation phase and the counterparty’s secret share it has successfully decrypted, together with the provider’s secret share.
5.2 The Role of the Provider
The provider can serve as a PKI because it is a centralized authority used by all owners to derive public keys. This can be strengthened in several ways. For example: assuming public key is known to all, can generate a certificate for every address that it takes part in generating. This certificate can be checked by the participating parties in a swap as well as by an external matching engine.
Furthermore, The provider can be decentralized (i.e. broken into multiple signing parties) or run on a TEE. Upon detection of a flawed segment encryption by one of the parties, can revoke the party from using the swap service or even from the wallet service.
A provider may be financially incentivized and charge fees for providing the additional security and enabling the fair exchange protocol.
The provider is trusted for:

Availability.

Fair submission of deposit transactions  in step 4 in the protocol the provider is required to submit both deposit transactions which fund and , or none in case one of the owners did not send its own transaction.
If assumption (1) is not satisfied, the protocol would not be able to progress and in most scenarios both parties’ funds would be kept locked. In particular, if the provider would interact in a ThreshSign with one party but not with the other, then the latter would have its funds locked but the one which was able to get the signature has actually succeeded to complete the trade and got the counterparty’s deposit.
If assumption (2) is not satisfied, one party might lock funds by having its deposit transaction submitted by the provider and confirmed, while the other party has aborted and did not stake anything. We should also wrap within this same assumption the requirement that the provider will not collude with a party to revert an unconfirmed deposit transaction, which would lead to the same described situation. Since the input addresses created by ThreshKeyGen with the provider, it is able to prevent specifically such attempt.
However, it is important to highlight that in terms of potential outcomes for the dishonest provider: the provider can freeze funds but it cannot steal funds. The latter means that it cannot extract secret keys nor trick participants to move funds to an arbitrary address of its choice. Also note that violations of the aforementioned trust assumptions can be publicly verifiable  an owner may accuse a provider by presenting a transcript of the threshold key generation protocols and optionally the Juggling gradual release protocol, so that an external observer of the relevant blockchains can witness that only one deposit or withdraw transaction has been submitted. That way the provider can be held accountable for denying service from the owner.
Combined with the economical incentive potential for an honest behavior, these points may give further justification for the trust assumptions.
5.3 Adversary Model
Our goal is to not add additional assumptions on adversarial behavior on top of what we already assume for a wallet design with an owner and a provider, namely: (1) the provider can stop the service, (2) the provider cannot steal secret keys. The first assumption is dealt outside the scope of this paper: we assume that each party has a recovery method for addresses, independent of the provider, to reclaim the full secret key. In our protocol, the provider is assumed to be trusted for the specific points detailed in Section 5.2, namely, availability and fair submission of deposit transactions which preserve the aforementioned adversarial behavior limitations (and is not trusted for anything else e.g., for integrity). The owners can possibly turn malicious at any point.
In case one of the owners become malicious, the publicly verifiable nature of the encryption is used to catch the bad actor.
The provider can play the role of one of the parties. Without loss of generality, say that plays the role of (or colludes with) . In such a case, note that will not start the Juggling protocol (i.e. the gradual release secret exchange protocol) until it verifies a confirmed transaction transferring the expected amount () into the expected address on the destination blockchain . has participated in the creation of this specific address through the ThreshKeyGen algorithm. Therefore, the provider will be able to get ’s secret share only if it has funded with sufficient funds which are redeemable by . This is equivalent to the honest case where a counterparty doesn’t collude with the server and deposits the needed funds.
Lastly, a malicious party may try to withdraw both of the deposits from and . W.l.o.g. say it is . Here, has a secret share it has contributed to the second ThreshKeyGen, which is required for a successful ThreshSign and is not revealed to any other party (even not through the Juggling protocol’s gradual release). So even when the provider colludes with , they will not be able to withdraw funds from without ’s cooperation.
5.4 Practical Aspects
It is important to note that unlike other ACCS protocols, in this protocol we do not make any assumptions on the blockchains in the trade. This means that in the general case either both parties completed the trade or that both parties did not complete the trade: there is no going back and the funds will stay locked. If the blockchains used have a time lock mechanism it can smoothly be plugged in the protocol: and the parties will sign funding transactions with time locks such that once they are published if one party decides to go back both parties will get the refund after the time locks are over.
In terms of interoperability, the protocol enables swaps between popular ECDSA blockchains, e.g. Bitcoin and Ethereum, and emerging EdDSA blockchains such as Facebook’s Libra, Algorand and Tezos^{1}^{1}1Tezos does have support for ECDSA under the curve Secp256k1 as in Bitcoin and Ethereum, but exchanging into an address of a different signing algorithm may not be ideal in terms of wallets and tools support..
This is not possible with existing scriptless ACCS protocols [poelstra2017scriptless, malavolta2019anonymous] that require both blockchains to use one of Schnorr or ECDSA signature schemes that share the same elliptic curve group generated by the same fixed generator.
The footprint of the protocol on the blockchain is two standard transactions on and two standard transactions on . The cost of the protocol is two standard transactions for every party. Using the scheme to swap assets on the same blockchain or using it twice to complete the path will result in a mixing solution.
6 Implementation
As a proof of concept we show an atomic swap between Bitcoin and Ethereum. For key management system we implemented Lindell’s [lindell17] ECDSA key generation and signing protocols (protocols and in [lindell17]) for Elliptic curve Secp256k1. This is the digital signature scheme and elliptic curve used by both Bitcoin and Ethereum. Our code abstracts both the elliptic curve layer and the digital signature layer such that other types of elliptic curves and digital signatures can be plugged in easily. We tested it with curve25519 and library we wrote for multi party Schnorr signatures based on [micali].
We used segments of bits for the 256 bit keys. We used bruteforce to find the DLogs which is not optimal and in practice one of known protocols that can achieve time should be used.
We implemented the fair exchange protocol for the case where the provider is not allowed to play or . This allows to relax the requirement on the of addresses and use only Threshkeygeneration and Signing.
The cryptography layer is written in Rust. The wrapping communication layer between the parties and their blockchain nodes are written in JavaScript (Node.js)
. It is open source and can be found in
[atomicswaps].6.1 Future Work
We plan to add support for more blockchains: connecting other types of elliptic curves and threshold signature algorithms to the system. For thresholdECDSA we will switch to a newer protocol [goldfeder18] with support for addresses. We wish to run experiments to set up optimal system parameters (i.e. optimal bit length ) and to measure performance.
References
Appendix 0.A Security for Auxiliary Proofs
Here we provide security proofs that the auxiliary proofs from section 3.2 are secure.
0.a.1 Proof of Correct Encryption:

Completeness: .

Special Soundness: Given two transcripts and
it is easy to extract from and the from . 
Special HVZK: Given the statement and , choose random and compute . Choose random , and compute .
0.a.2 Proof of Correct Encryption of DLog:

Completeness: , ,

Special Soundness: Given two transcripts and
it is easy to extract from and the from . 
Special HVZK: Given the statement and , choose random and compute , . Choose random , and compute .
Comments
There are no comments yet.