 Research
 Open access
 Published:
Atomic crosschain swap based on private key exchange
Cybersecurity volume 7, Article number: 12 (2024)
Abstract
Atomic CrossChain Swap (ACCS) is one important topic in cryptocurrency, where users can securely and trustlessly exchange assets between two different blockchains. However, most known ACCS schemes assume specific scripting functionalities of the underlying blockchains, such as Hash Time Locked Contracts (HTLC). In addition, these schemes are typically only applicable to certain digital signature schemes, like Schnorr or Elliptic Curve Digital Signature Algorithm (ECDSA) signatures. In this paper, we propose a generic ACCS scheme, independent from the underlying blockchains. To the best of our knowledge, this is the first solution of this kind. Our results are as follows. First, we define a formal system model of ACCS. Next, we present a generic ACCS scheme meets our model. This scheme admits atomicity in crosschain swaps without the need for a Trusted Third Party (TTP) and protects users’ privacy. Finally, by using the NonInteractive ZeroKnowledge (NIZK) proof protocol as a tool, we instantiate our generic scheme for Elliptic Curve Discrete Logarithm Problembased (ECDLPbased) signatures. In addition, we implement our scheme, and the experimental results show that our protocol outperforms the existing ACCS schemes, such as the HTLCbased schemes.
Introduction
Atomic crosschain swap (Herlihy 2018) is used to directly exchange assets between two different blockchains without additional trust assumptions, such as trusted hardware or TTP. In ACCS, user A holds asset x on blockchain \(\mathbb {B}_1\), while user B holds asset y on blockchain \(\mathbb {B}_2\), and both intend to exchange their assets. The main goal of ACCS is to ensure that if the swap is successful, user A receives asset y and user B receives asset x. Otherwise, all assets are refunded to both users.
In recent years, with the maturity of blockchain technology, ACCS has gained much attention. The main reason is that in the early stages of blockchain development, the necessity of interoperability between different blockchains was not considered. Therefore, each blockchain operated in isolation, lacking efficient communication mechanisms, which led to what is commonly known as the “blockchain islands” phenomenon. This makes it difficult to exchange data and assets between different blockchains, thereby hindering the further development of blockchain technology. To address this limitation, ACCS emerged as a solution for achieving interoperability between various blockchains. Its primary goal is to enable the transfer and exchange of data and value across different chains. By implementing ACCS, the “blockchain islands” phenomenon has been effectively broken, promoting the continued progress of blockchain technology.
However, with the application of blockchain technology in various industries, such as financial services (Guo and Liang 2016), healthcare (Agbo et al. 2019), and Internet of Things (IoT) (Reyna et al. 2018), the mere circulation of data and value is no longer sufficient to meet the practical requirements for crosschain interactions. Realworld application scenarios present additional requirements for ACCS. For example, different enterprises often choose different blockchain platforms based on their industry characteristics. Therefore, they may require that the ACCS scheme can be used on any blockchain platform. Moreover, the crosschain interaction process often involves sensitive private data. Thus, users or companies typically want to prevent the leakage of sensitive information in ACCS. Finally, for some enterprises with high security requirements, they usually hope to implement ACCS without the need for TTP. These emerging requirements make it meaningful to conduct further research on ACCS.
Related work
Up to now, there were two popular ways to achieve trustless crosschain swaps. The first approach uses onchain scripts to simulate a TTP. It admits atomicity in crosschain swaps through the automatic execution of onchain scripts, such as smart contracts. A seminal early work in this field is the HTLC proposed by TierNolan (2013). Subsequently, in 2016, Poon used HTLC to execute atomic swaps between payment channels in the Lightning Network (Poon and Dryja 2016). Later, in 2018, Herlihy formalized the theory of such ACCS (Herlihy 2018). However, ACCS schemes that rely on onchain scripts may not be compatible with all blockchain platforms, as they depend on specific functionalities provided by each blockchain script. For example, a HTLCbased ACCS scheme requires that both blockchain scripts must support the same hash function. In addition, due to the fact that onchain scripts are public, using them may compromise users’ privacy (Deshpande and Herlihy 2020; Thyagarajan et al. 2022).
In contrast, the second approach uses cryptographic techniques to simulate a TTP. It is more compatible than the first one and can protect users’ privacy. However, it typically relies on more complex cryptographic primitives, such as adaptor signatures (Fournier 2019) or lockable signatures (Thyagarajan and Malavolta 2021). In recent years, the ACCS schemes based on cryptographic techniques have been thoroughly studied, and many practical schemes have been proposed. For example, in 2020, Shlomovits designed a scriptless ACCS scheme (Shlomovits and Leiba 2020), where both players gradually released their private key shares. His scheme protected the users’ privacy, but was limited to blockchains utilizing ECDLPbased signatures. In addition, it required a TTP called Provider to enhance system security. Subsequently, in 2021, Thyagarajan proposed lockable signatures (Thyagarajan and Malavolta 2021), and in 2022, he further presented a generic scriptless ACCS based on lockable signatures (Thyagarajan 2022). His protocol enables fair exchange of coins among any currencies, while only requiring the minimal script from the underlying blockchain to verify payments, i.e. the verification of digital signatures. Unfortunately, his protocol does not provide an efficient solution for blockchains that do not support adaptor signatures (Erwig et al. 2021; Hanzlik et al. 2022).
Tumblebit (Heilman et al. 2017), \(\mathrm{A^2L}\) (Tairi et al. 2021), and BlindHub (Qin et al. 2023) are atomic swap protocols that use an alternate route. In these protocols, a participant exchanges his coins through an untrusted intermediate party. When multiple swaps occur simultaneously, these protocols guarantee that neither intermediary nor any other participant can link the specific coins being exchanged, thereby protecting user privacy. However, Tumblebit relies on the HTLC scripts of the underlying blockchains, which results in poor compatibility and privacy. \(\mathrm{A^2L}\) improved this issue, but a later work (Glaeser et al. 2022) found that \(\mathrm{A^2L}\)’s security model had a gap that allowed key recovery attacks on specific instantiations. Subsequently, Glaeser improved \(\mathrm{A^2L}\) and proposed \(\mathrm{A^2L^+}\) and \(\mathrm{A^2L^{UC}}\) (Glaeser et al. 2022). However, neither of them is compatible with systems that lack adaptor signature support. In addition, since BlindHub also relies on adaptor signatures, it faces a similar compatibility issue (Hanzlik et al. 2022).
Challenges of the the previous work
To summarize, the known ACCS solutions have three limitations thus are desirable to overcome the following challenges:

Generality. It means that the ACCS scheme is independent of the underlying blockchain platforms. The main reason for the formation of blockchain islands is that the underlying architecture and data structure of each blockchain are different. For example, Bitcoin uses the Unspent Transaction Output (UTXO) model (Nakamoto 2008), while Ethereum uses the accountbased transaction model (Buterin 2013). The heterogeneity between blockchains leads to the complexity and incompatibility of crosschain interactions.

Privacy. In ACCS, users’ privacy includes: (i) Onchain data privacy (Deshpande and Herlihy 2020). The process of crosschain swap may leak users’ onchain data. For instance, the utilization of public smart contracts could disclose sensitive information such as transaction amounts or participant identities. (ii) Transaction privacy, which includes transaction unlinkability and transaction indistinguishability. The former means that adversaries who do not participate in ACCS cannot associate two crosschain transactions. For example, HTLCbased ACCS cannot achieve transaction unlinkability, because two crosschain transactions use the same hash value, which makes it easy for adversaries to infer that they may come from the same user. The latter means that observers who do not participate in ACCS cannot distinguish the crosschain transactions from standard transactions (Thyagarajan et al. 2022).

Atomicity without TTP. It means that the scheme admits atomicity in crosschain swaps without relying on a TTP. ACCS can be easily implemented using a TTP. However, introducing TTP contradicts the decentralized nature of blockchain. In addition, TTP may bring additional security threats, such as single point of failure or trust problems. Unfortunately, Zamyatin et al. (2021) pointed out that in the deterministic system model of distributed ledgers, achieving Correct CrossChain Communication (CCC) is impossible in asynchronous settings without a TTP. Therefore, one of the technical challenges in this field is to design an ACCS scheme in which the distributed ledger platform, onchain scripts or cryptographic primitives within the system serve as an implicit TTP, thereby guaranteeing atomicity in crosschain swaps.
Hence, we raise the following question: “Is it possible to design an ACCS scheme without the above three limitations, namely, to meet generality, privacy and atomicity without TTP?”
Our contribution
In this paper, we focus on designing a generic ACCS scheme without TTP, and give an affirmative answer to the above question. Our contributions are summarized as follows:
Model for ACCS. We give a formal system model of ACCS and the corresponding security definitions. Our model is applicable to onetoone ACCS scenarios on any blockchain. To the best of our knowledge, this is the first work in this field.
Generic Atomic CrossChain Swaps Scheme. We present a generic ACCS scheme that solves all abovementioned challenges, namely, generality, privacy and atomicity without TTP. In addition, this scheme has been proven to be secure in our model. We outline the comparison between our scheme and other existing schemes in Table 1. Notably, our scheme is not only applicable to existing blockchain platforms, but can also be adapted to potential future platforms.
New Tool: NIZK for the Correct Commitment of Discrete Logarithm (DL). To show the practicability of our generic scheme, we instantiate it in ECDLPbased blockchains. To achieve this instantiation, we present a NIZK protocol \(\mathsf {\Pi }_{\textsf{CCNIZK}}\) for the correct commitment of DL, which is an effective tool to instantiate our scheme. It is used to verify the correctness of the secret segments released by each player, thereby achieving fair exchange of private key shares. We regard this zeroknowledge proof as an independent property, which may bring other interesting applications.
Technical overview
We briefly review our technical treatments below.
Model for ACCS. In our system model, there are two entities, player \(P_1\) and player \(P_2\), and we focus on a onetoone ACCS between these two entities. To ensure the generality of this model, we represent each blockchain as a distributed ledger, independent of the specific blockchain implementation. To better describe the ACCS in the real world, we divide it into five phases: setup, freeze, exchange, complete and timeout. In terms of security, we consider possible security threats from a malicious adversary, and formally define the security of ACCS. Therefore, once our scheme is proven in this model, it means that the scheme is sufficiently secure.
Generic Construction of Atomic CrossChain Swaps. The technical difficulty in building our generic ACCS scheme lies in solving the three abovementioned challenges, namely generality, privacy and atomicity without TTP.
To solve the first and second challenges, we move private key exchange offchain. Our scheme uses cryptographic techniques instead of onchain scripts, making it independent of the specific blockchain architecture. Specifically, we use a Fair Exchange (FE) protocol to achieve offchain private key exchange, and utilize Verifiable Timed Signatures (VTS) (Thyagarajan et al. 2020) for asset refund. As a result, the crosschain transactions generated by our scheme are indistinguishable from the standard onetoone transactions.
Then, to solve the third challenge, we use the idea of gradual release to achieve fair exchange of private keys. Zamyatin et al. (2021) pointed out the similarity between the ACCS problem and the FE problem (Asokan 1998). Specifically, their properties of effectiveness (Asokan 1998) and timeliness (Zamyatin et al. 2021) are similar, and the fairness (Asokan 1998) in FE is similar to the atomicity (Zamyatin et al. 2021) in ACCS. Therefore, we can regard the atomicity property in ACCS as the fairness property in private key fair exchange. However, unlike the fair exchange of items, in ACCS, the sender does not lose the knowledge of the private key after the swap. Due to the fact that private key represents ownership of asset in blockchain, this will result in both players eventually owning the asset. To solve this problem, we let the players exchange the private key shares rather than the complete private keys. Specifically, we introduce a joint address (Thyagarajan et al. 2022) that is jointly controlled by both players, and each player holds a private key share. Then, they exchange their private key shares fairly to gain ownership of the joint address.
Unfortunately, it has been shown by Cleve (1986) that without a majority of honest parties, it is generally impossible to achieve complete fairness. However, achieving partial fairness (Gordon and Katz 2012) is possible, and gradual release is one of the widely used ideas. It allows both parties to exchange their secrets little by little, where one party can obtain an advantage over the other party, but this advantage is polynomially bounded. Our generic scheme is based on this idea. In our scheme, both players first divide the private key shares into multiple segments, then exchange the commitments of these segments and their corresponding proofs, and finally alternately release each segment. In this way, a player can only have at most one segment advantage over the other player.
Next, we give a highlevel overview of our generic scheme. First, both players transfer their assets to joint addresses. To prevent indefinite locking of assets, we introduce a timeout mechanism for refund. Next, using the FE protocol with gradual release, players exchange their private key shares. Finally, they can reconstruct the complete private keys of the joint addresses to transfer assets. In addition, this scheme is proven to be secure in our system model.
New Tool: NIZK for the Correct Commitment of DL. We borrow the idea from Camacho (Camacho 2013) to build a new zeroknowledge proof protocol. Camacho (2013) proposed a short signature exchange without TTP by gradually releasing the blinding factor of the signature. However, his scheme can only achieve bitbybit private key exchange. We replace the bit commitment proof in the original protocol with Bulletproofs range proof, enabling it to support segmentbysegment private key share exchange.
Preliminaries
In this section, we review some useful notations and notions.
Notations. For \(m,n\in \mathbb {N}\), where \(m<n\), [n] represents the set of integers \(\{1,..., n\}\), and [m..n] represents the set of integers \(\{m,m+1,..., n1,n\}\). Let \(\lambda \in \mathbb {N}\) be a security parameter, \(1^\lambda\) denotes a unary string with \(\lambda\) ones, and p represents a prime number with \(\lambda\) bits. We say that the function \(\textsf{negl}:\mathbb {N}\rightarrow [0,1]\) is negligible in \(\lambda\), if for every polynomial \(q(\cdot )\) there exists \(\lambda _0\) such that \(\forall \lambda >\lambda _0:\textsf{negl}(\lambda )<1/q(\lambda )\). We use \(x{\mathop {\longleftarrow }\limits ^{R}}X\) to represent an element x randomly and uniformly chosen from the set X, and use \(x\leftarrow v\) to represent the variable x assigned the value v. We represent a protocol as \((\mathsf {output_1},\mathsf {output_2})\leftarrow \textsf{Protocol}\langle P_1(\mathsf {input_1}),P_2(\mathsf {input_2})\rangle\), where \(P_1\) inputs \(\mathsf {input_1}\) and obtains output \(\mathsf {output_1}\), and \(P_2\) inputs \(\mathsf {input_2}\) and obtains output \(\mathsf {output_2}\).
Let \(\mathbb {G}\) and \(\mathbb {G}_\textsf{T}\) be two groups with the same prime order p, i.e., \(p=\mathbb {G}=\mathbb {G}_\textsf{T}\), where \(\mathbb {G}\) is an additive group and \(\mathbb {G}_\textsf{T}\) is a multiplication group. Let G represents a random generator in \(\mathbb {G}\), and \(\mathbb {Z}_p\) represents a ring of integer module p. The notation \(\mathbb {Z}_p\backslash \{0\}\) is defined as \(\mathbb {Z}_p^*\).
The vector \(\vec {v}\) is defined as \(\vec {v}=(v_i)_{i\in (n]}\), where each component \(v_i\) represents a value associated with the corresponding index i. If the vector contains elements in \(\mathbb {Z}_p^n\), it can also be written as \(B(\cdot ]=(B[1],B[2],..., B[n])\). We define l and \(\kappa\) as symbols that satisfy \(\kappa =\lceil \frac{\lambda }{l}\rceil\). Let \(\theta \in \mathbb {Z}_p^*\), and the \(\kappa\)Segmentation of \(\theta\) refers to dividing \(\theta\) into \(\kappa\) segments. Each segment has a length of l bits, and if the length is less than l, leading zeros are added. We denote the vector of \(\kappa\)Segmentation of \(\theta\) as \(\theta [\cdot ]=(\theta [1],..., \theta [\kappa ])\), where \(\theta\) can be expressed as \(\theta =\sum _{i\in [\kappa ]}\theta [i]2^{(i1)l}\). Additionally, let \(P(\cdot )\) represent a formal polynomial with coefficients in \(\mathbb {Z}_p\), and \(P[\cdot ]\) represent the vector of its coefficients. If the degree of polynomial \(P(\cdot )\) is denoted as \(d=deg(P)\), then \(P(X)=\sum _{i\in [d+1]}P[i]X^{i1}\).
Number theoretic assumptions
Bilinear Maps. Consider the \(\mathbb {G}\), \(\mathbb {G}_\textsf{T}\), p and G defined above, assuming that ECDLP in \(\mathbb {G}\) and \(\mathbb {G}_\textsf{T}\) is difficult. We define \(e:\mathbb {G}\times \mathbb {G}\rightarrow \mathbb {G}_\textsf{T}\) as a bilinear map, which satisfies the following properties:

Bilinearity: For \(\forall P,Q\in \mathbb {G},a,b\in \mathbb {Z}_p^*\), there is \(e(aP,bQ)=e(P,Q)^{ab}\).

Nondegenerate: Let P be the generator of \(\mathbb {G}\). Then, e(P, P) is the generator of \(\mathbb {G}_\textsf{T}\), which means \(e(P,P)\ne 1\).

Efficiently computable: Let G be the generator of \(\mathbb {G}\), \(\hat{\mathbb {G}}\) and \(\hat{\mathbb {G}_\textsf{T}}\) be groups of size p (p is a prime number of \(\lambda\) bits), with \(\hat{e}\) being an efficient algorithm to compute the map. There exists an algorithm \(\textsf{BMGen}\) that takes as input \(1^\lambda\), and outputs \((p,\hat{\mathbb {G}},\hat{\mathbb {G}_\textsf{T}},\hat{e},G)\). For simplicity, we will not distinguish between \(\hat{\mathbb {G}},\hat{\mathbb {G}_\textsf{T}},\hat{e}\) and \(\mathbb {G},\mathbb {G}_\textsf{T},e\).
Let \(N\in \mathbb {N}\). The common public parameters of the following assumptions are denoted by \(\textsf{pp}=\langle (p,\mathbb {G},\mathbb {G}_\textsf{T},e,G),(G_0,G_1,G_2,..., G_N)\rangle\). For \(i\in [0..N]\), we have \(G_i=s^iG\), where s is randomly chosen from \(\mathbb {Z}_p^*\).
Definition 1
(NDiffieHellman Inversion (NDHI) Assumption (Mitsunari et al. 2002)). The NDHI problem is to compute \(\frac{1}{s}G\) given \(\textsf{pp}\). For any Probabilistic PolynomialTime (PPT) adversary \(\mathcal {A}\), we say that the NDHI assumption holds, if we have:
Definition 2
(NBilinear DiffieHellman Inversion (NBDHI) Assumption). The NBDHI problem is to compute \(e(G,G)^{\frac{1}{s}}\) given \(\textsf{pp}\). For any PPT adversary \(\mathcal {A}\), we say that the NBDHI assumption holds, if we have:
Definition 3
(NStrong DiffieHellman (NSDH) Assumption (Boneh and Boyen 2008)). The NSDH problem is to compute \((c,\frac{1}{s+c}G)\) given \(\textsf{pp}\). For any PPT adversary \(\mathcal {A}\), we say that the NSDH assumption holds, if we have:
Digital signatures schemes
Digital Signatures Scheme. A digital signature scheme \(\mathsf {\Pi }_{\textsf{DS}}\) consists of three algorithms. A key generation algorithm \((\textsf{pk},\textsf{sk}) \leftarrow \textsf{KGen}(1^{\lambda })\) takes as input a security parameter \(1^{\lambda }\), and outputs the publicprivate key pair \((\textsf{pk},\textsf{sk})\). A signature algorithm \(\sigma \leftarrow \textsf{Sign}(\textsf{sk},m)\) takes as input the private key \(\textsf{sk}\) and message \(m\in \{0,1\}^{*}\), and outputs the signature \(\sigma\). A verification algorithm \(0/1 \leftarrow \textsf{Vf}(\textsf{pk},m,\sigma )\), outputs 1 if \(\sigma\) is a valid signature for the message m under the public key \(\textsf{pk}\), otherwise it outputs 0.
Threshold Secret Sharing. A (t, n)threshold secret sharing scheme \(\mathsf {\Pi }_{\textsf{TSS}}\) of a secret x consists of n shares \(x_1,..., x_n\). For any set \(\textsf{S}\ge t+1\), there exists an efficient algorithm \(x\leftarrow \textsf{Recon}(\{x_i\}_{i\in [\textsf{S}]})\) that takes as input \(t+1\) of these shares and outputs the secret x. However, if only t or fewer shares are provided, no information about the secret x will be revealed.
Threshold Signatures. The (t, n)threshold signature scheme \(\mathsf {\Pi }_{\textsf{Th}}\) is used to distribute signatures to a group of n players \(P_1,..., P_n\), such that any at least \(t+1\) players can cogenerate a signature, while t or fewer players cannot. More formally, a (t, n)threshold signature scheme \(\mathsf {\Pi }_{\textsf{Th}}\) for a signature scheme \(\mathsf {\Pi }_{\textsf{DS}}=(\textsf{KGen},\textsf{Sign},\textsf{Vf})\) consists of two parts (Gennaro and Goldfeder 2018):

\((\textsf{pk},\mathsf {sk_1},..., \mathsf {sk_n})\leftarrow \textsf{ThKGen}(1^\lambda ,t,n)\). This distributed key generation protocol takes as input a security parameter \(1^{\lambda }\), and outputs a public key \(\textsf{pk}\) and \(P_i\)’s private key share \(\mathsf {sk_i}\) to each player \(P_i\). The private key shares \(\mathsf {sk_1},..., \mathsf {sk_n}\) form a (t, n)threshold secret sharing of the private key \(\textsf{sk}\).

\(\sigma \leftarrow \textsf{ThSign}\langle \{P_i(\mathsf {sk_i},m)\}_{i\in [\textsf{S}]}\rangle\). For \(\textsf{S}\ge t+1\), this distributed signing protocol takes as public input a message \(m\in \{0,1\}^{*}\) to be signed as well as a private input \(\mathsf {sk_i}\) from each player \(P_i\), and outputs a signature \(\sigma \in \ \{\mathsf {\Pi }_{\textsf{DS}}.\textsf{Sign}(\textsf{sk},m)\}\).
Notice that \(\mathsf {\Pi }_{\textsf{Th}}.\textsf{ThSign}\) will output a valid signature under the centralized signing protocol \(\mathsf {\Pi }_{\textsf{DS}}.\textsf{Sign}\). Therefore, the verification algorithm of both \(\mathsf {\Pi }_{\textsf{Th}}\) and \(\mathsf {\Pi }_{\textsf{DS}}\) remains the same, denoted as \(\mathsf {\Pi }_{\textsf{DS}}.\textsf{Vf}\).
Verifiable Timed Signatures. The VTS algorithm (Thyagarajan et al. 2020) is a variant of verifiably encrypted signatures (Boneh et al. 2003; Hanser et al. 2015), designed to decrypt and reveal the signature without TTP. In VTS, the committer generates a timed commitment C for a signature \(\sigma\) of a message m under the public key \(\textsf{pk}\). This commitment C can only be opened after a predefined time \(\textsf{T}\) (chosen arbitrarily by the committer). In addition, the committer generates a proof \(\pi\) to prove that C contains a valid signature \(\sigma\). Its formal definition is as follows:
Definition 4
(Verifiable Timed Signatures (Thyagarajan et al. 2020)). A VTS scheme \(\mathsf {\Pi }_{\textsf{VTS}}\) for a signature scheme \(\mathsf {\Pi }_{\textsf{DS}}=(\textsf{KGen},\textsf{Sign},\textsf{Vf})\) consists of the following four operations:

\((C,\pi )\leftarrow \textsf{Commit}(\sigma ,\textsf{T})\): This randomized commit algorithm takes as input a signature \(\sigma\) (generated using \(\mathsf {\Pi }_{\textsf{DS}}.\textsf{Sign}(\textsf{sk},m)\)) and a hiding time \(\textsf{T}\), and outputs a commitment C and a proof \(\pi\).

\(0/1\leftarrow \textsf{Verify}(\textsf{pk},m,C,\pi )\): This verify algorithm takes as input a public key \(\textsf{pk}\), a message m, a commitment C of hardness \(\textsf{T}\) and a proof \(\pi\). It outputs 1 if and only if the value \(\sigma\) embedded in C satisfies \(\mathsf {\Pi }_{\textsf{DS}}.\textsf{Vf}(\textsf{pk},m,\sigma )=1\), otherwise it outputs 0.

\((\sigma ,r)\leftarrow \textsf{Open}(C)\): This open algorithm is run by the committer, takes as input a commitment C, and outputs the committed signature \(\sigma\) and the randomness r used in generating C.

\(\sigma \leftarrow \textsf{ForceOp}(C)\): This force open algorithm takes as input a commitment C, and outputs the committed signature \(\sigma\).
Commitment schemes
A commitment scheme \(\mathsf {\Pi }_{\textsf{Com}}\) consists of three algorithms. A generation algorithm \(h \leftarrow \textsf{Gen}(1^{\lambda })\) takes as input a security parameter \(1^{\lambda }\), and outputs a public value h. A commit algorithm \((c,d)\leftarrow \textsf{Com}(h,m)\) takes as input a public value h and a message \(m\in \{0,1\}^{*}\), and outputs a commitment c and an opening value d. A verification algorithm \(0/1 \leftarrow \textsf{Vf}(h,m,c,d)\), outputs 1 if the verification succeeds, otherwise, it outputs 0.
The model of ACCS
In this section, we give the model and the security definitions of ACCS.
System model
Consider two distributed ledgers represented as \(\mathbb {B}_1\) and \(\mathbb {B}_2\). We assume that there are two players, \(P_1\) and \(P_2\), where \(P_1\) owns asset \(v_1\) on \(\mathbb {B}_1\), and \(P_2\) owns asset \(v_2\) on \(\mathbb {B}_2\), and they want to exchange assets. The players communicate using secure and authenticated channels, where messages are public and sent sequentially. We assume the network to be synchronous, which is widely adopted by blockchain protocols (Garay et al. 2015; Zamani et al. 2018; Kiayias et al. 2017; Luu et al. 2016).
In this model, we use the public key to represent the wallet address and the private key to represent asset ownership. Moreover, a transaction is used to represent the process of transferring assets between addresses. For example, \(\textsf{tx}(\textsf{pk},\mathsf {pk'},v)\) denotes the transfer of asset v from the address corresponding to \(\textsf{pk}\) to the address corresponding to \(\mathsf {pk'}\). A valid transaction must be signed by a private key corresponding to the source address of the asset.
Our system model consists of 8 algorithms and 2 protocols:

\(\textsf{pp}\leftarrow \textsf{Setup}(1^{\lambda })\). On input a security parameter \(1^{\lambda }\), the algorithm outputs public parameters \(\textsf{pp}\).

\((\textsf{pk},\textsf{sk})\leftarrow \textsf{KeyGen}(1^{\lambda })\). On input a security parameter \(1^{\lambda }\), the algorithm outputs a publicprivate key pair \((\textsf{pk},\textsf{sk})\).

\((\mathsf {pk'},\mathsf {sk_1'},\mathsf {sk_2'})\leftarrow \textsf{JointKeyGen}(1^{\lambda })\). On input a security parameter \(1^{\lambda }\), the algorithm outputs a public key \(\mathsf {pk'}\) to each player, and a private output \(\mathsf {sk_i'}\) to \(P_i\) as his private key share.

\(\textsf{tx}\leftarrow \textsf{GenTx}(\textsf{pk},\mathsf {pk'},v)\). On input public keys \(\textsf{pk}\), \(\mathsf {pk'}\) and asset v, the algorithm outputs a transaction \(\textsf{tx}\).

\(((\textsf{com},\pi ),(\sigma ))\leftarrow \textsf{CommitRfnd}\langle P_1(\textsf{T},\mathsf {sk_1'},\mathsf {pk'}, \textsf{tx}),P_2(\textsf{T},\mathsf {sk_2'},\mathsf {pk'},\textsf{tx})\rangle\). When \(P_1\) inputs a timed parameter \(\textsf{T}\), a private key share \(\mathsf {sk_1'}\), a public key \(\mathsf {pk'}\) and a transaction \(\textsf{tx}\), and \(P_2\) inputs a timed parameter \(\textsf{T}\), a private key share \(\mathsf {sk_2'}\), a public key \(\mathsf {pk'}\) and a transaction \(\textsf{tx}\), the protocol outputs a timed commitment \(\textsf{com}\), which commits to the signature of the transaction, and its corresponding proof \(\pi\) to \(P_1\). It also outputs a signature \(\sigma\) of the transaction to \(P_2\).

\(0/1\leftarrow \textsf{Verify}(\mathsf {pk'},\textsf{tx},\textsf{com},\pi )\). On input a public key \(\mathsf {pk'}\), a transaction \(\textsf{tx}\), a timed commitment \(\textsf{com}\) and its corresponding proof \(\pi\), the algorithm outputs 0 to indicate validation failure, and outputs 1 to indicate validation success.

\(\sigma '\leftarrow \textsf{Freeze}(\textsf{sk},\mathsf {tx'})\). On input a private key \(\textsf{sk}\) and a transaction \(\mathsf {tx'}\), the algorithm outputs a signature \(\sigma '\) of the transaction.

\(((\mathsf {sk_2''}),(\mathsf {sk_1'}))\leftarrow \textsf{Exchange}\langle P_1(\mathsf {sk_1'}),P_2(\mathsf {sk_2''})\rangle\). When \(P_1\) and \(P_2\) respectively input their private key shares \(\mathsf {sk_1'}\) and \(\mathsf {sk_2''}\), the protocol outputs \(\mathsf {sk_2''}\) to \(P_1\) and \(\mathsf {sk_1'}\) to \(P_2\).

\(\sigma ''\leftarrow \textsf{Complete}(\mathsf {sk_1'},\mathsf {sk_2'},\mathsf {tx''})\). On input private key shares \(\mathsf {sk_1'}\) and \(\mathsf {sk_2'}\), and a transaction \(\mathsf {tx''}\), the algorithm outputs a signature \(\sigma ''\) of the transaction.

\(\sigma \leftarrow \textsf{UnFreeze}(\textsf{com})\). On input a timed commitment \(\textsf{com}\), the algorithm outputs a signature \(\sigma\) embedded in the commitment.
Security definition
In this section, we discuss the security threats and give the formal security definitions of ACCS. We consider a PPT adversary who corrupts one of the players. The corrupt player can deviate from the protocol in any arbitrary manner, e.g., by sending invalid or inconsistent messages, or aborting interactions. We assume that once a player obtains the private key share of joint address from the other player, he will immediately generate a signature of the swap transaction and publish it on distributed ledger to transfer assets in the joint address. We denote the player’s state using a state set \(\textsf{state}=\{0,1\}\), where \(\mathsf {state_A}=0\) represents a failed swap for player A, meaning that player A does not obtain player B’s asset and successfully refund, while \(\mathsf {state_A}=1\) represents a successful swap for player A, meaning that player A obtains player B’s asset and loses his own asset. We now give the formal security definitions as follows.
Definition 5
(Completeness). The completeness of ACCS guarantees that there exists a negligible function \(\textsf{negl}(\lambda )\), such that when all players execute honestly, the execution result of ACCS is:
Intuitively, it means that if both players are honest, then ACCS must end with both players’ states being either all 0 or all 1. To better understand this definition, we discuss two situations: timeout and no timeout. Timeout means that a player fails to complete the asset swap within the predefined time. In this case, the completeness requires the states of both players are 0, i.e., \(\mathsf {state_A}=0 \wedge \mathsf {state_B}=0\). On the contrary, no timeout means that the players complete the asset swap within the predefined time. In this case, the completeness requires the states of both players are 1, i.e., \(\mathsf {state_A}=1 \wedge \mathsf {state_B}=1\).
Definition 6
(Soundness). The soundness of ACCS guarantees that there exists a negligible function \(\textsf{negl}(\lambda )\), such that for all PPT adversaries \(\mathcal {A}\) and all \(\lambda \in \mathbb {N}\), given the correct public key \(\textsf{pk}\), transaction \(\textsf{tx}\) and timed parameter \(\textsf{T}\) generated during protocol execution, we have:
Intuitively, it means that a PPT adversary \(\mathcal {A}\) cannot generate a commitment \(\mathsf {com^*}\) and its corresponding proof \(\pi ^*\) such that they can be successfully verified by the \(\textsf{Verify}\) algorithm. However, when using the \(\textsf{UnFreeze}\) algorithm to open the commitment after the predefined time, the obtained result is not the correct signature.
Definition 7
(Timed Privacy). We use the symbols \(\ll\) to represent “much less than”, and \(\gg\) to represent “much greater than”, where \(b\ll a\) implies that the result of \(a+b\) is approximately equal to a. In addition, the symbol \(\mathsf {const_1}\) represents a constant, specified by the system in the setup phase. We say that an ACCS satisfies timed privacy if both of the following conditions hold:

There exists a negligible function \(\textsf{negl}(\lambda )\) such that for all PPT adversaries \(\mathcal {A}\) with running time \(t\ll \textsf{T}\mathsf {const_1}\), all transaction messages \(m\in \{0,1\}^*\) and all \(\lambda \in \mathbb {N}\), given the correct public key \(\textsf{pk}\) and transaction \(\textsf{tx}\) generated during protocol execution, we have:
$$\begin{aligned} \Pr \begin{bmatrix} \sigma ^*\leftarrow \mathcal {A}(1^{\lambda }): 1 \leftarrow \mathsf {\Pi }_{\textsf{DS}}.\textsf{Vf}(\textsf{pk},\textsf{tx},\sigma ^*)\end{bmatrix} \le \textsf{negl}(\lambda ) \end{aligned}$$ 
There exists a negligible function \(\textsf{negl}(\lambda )\) such that for all honest players A with running time \(t\gg \textsf{T}+\mathsf {const_1}\), all transaction messages \(m\in \{0,1\}^*\) and all \(\lambda \in \mathbb {N}\), given the correct public key \(\textsf{pk}\), transaction \(\textsf{tx}\) and commitment \(\textsf{com}\) generated by the protocol, we have:
$$\begin{aligned} \Pr \begin{bmatrix} \sigma \leftarrow \textsf{UnFreeze}(\textsf{com}): 0 \leftarrow \mathsf {\Pi }_{\textsf{DS}}.\textsf{Vf}(\textsf{pk},\textsf{tx},\sigma )\end{bmatrix}\le \textsf{negl}(\lambda ) \end{aligned}$$
Intuitively, the former condition implies that a PPT adversary \(\mathcal {A}\) cannot obtain a valid signature when the running time t is much less than \(\textsf{T}\mathsf {const_1}\). The latter condition implies that an honest player A will not obtain an invalid signature after running the \(\textsf{UnFreeze}\) algorithm when the running time t is much greater than \(\textsf{T}+\mathsf {const_1}\).
Definition 8
(Partial Fairness). We define the partial fairness of ACCS through the following experiment. Assuming that the adversary \(\mathcal {A}\) corrupts player B. Therefore, player A is honest. If \(\mathcal {A}\) aborts before the end of ACCS, let \(\mathsf {sk^{*}_B}[1...i]\) represents the partial private key share obtained by player A. At this point, we assume that player A will randomly select some elements in the remaining space of size \(2^{\lambda i}\) as B’s tentative private key share, denoted as \(\mathsf {sk^{'}_B}\). Similarly, \(\mathcal {A}\) will also output the tentative private key share of A, denoted as \(\mathsf {sk^{'}_A}\). We use \(\mathsf {const_2}\) to represent a constant, specified by the system in the setup phase.
The partial fairness of ACCS guarantees that there exists a negligible function \(\textsf{negl}(\lambda )\) such that for all PPT adversaries \(\mathcal {A}\), we have:
Our generic atomic crosschain swaps scheme
In this section, first we present a generic scheme for onetoone atomic swap, which shows the feasibility and be seen as a framework for further optimizations. Second, we explain the entire process of an atomic swap between user A and B as a concrete example. Finally, we prove the security of the scheme in our model.
Given the digital signature scheme \(\mathsf {\Pi }_{\textsf{DS}}\), commitment scheme \(\mathsf {\Pi }_{\textsf{Com}}\), threshold signatures scheme \(\mathsf {\Pi }_{\textsf{Th}}\), threshold secret sharing scheme \(\mathsf {\Pi }_{\textsf{TSS}}\), VTS scheme \(\mathsf {\Pi }_{\textsf{VTS}}\), range proofs protocol \(\mathsf {\Pi }_{\textsf{RP}}\) and NIZK protocol \(\mathsf {\Pi }_{\textsf{NIZK}}\), we constructed our generic scheme based on the system model, which consists of 8 algorithms and 2 protocols. The complete generic scheme is shown in Figs. 1 and 2, where the complete \(\textsf{Exchange}\) protocol is postponed to Appendix A.
Here, we provide an example of the generic construction that considers an atomic swap between two users, namely user A and user B. In this scenario, A owns asset \(v_1\) on \(\mathbb {B}_1\), while B owns asset \(v_2\) on \(\mathbb {B}_2\). To simplify the description, we define that the payment from A to B involves the keys, transactions and signatures with (AB), while the payment from B to A involves the keys, transactions and signatures with (BA). The complete process is postponed to Appendix B.
Theorem 1
Assume the underlying digital signature scheme \(\mathsf {\Pi }_{\textsf{DS}}\), commitment scheme \(\mathsf {\Pi }_{\textsf{Com}}\), threshold signatures scheme \(\mathsf {\Pi }_{\textsf{Th}}\), threshold secret sharing scheme \(\mathsf {\Pi }_{\textsf{TSS}}\), VTS scheme \(\mathsf {\Pi }_{\textsf{VTS}}\), range proofs protocol \(\mathsf {\Pi }_{\textsf{RP}}\) and NIZK protocol \(\mathsf {\Pi }_{\textsf{NIZK}}\) are secure, the atomic swap protocol described in Appendix B is secure, and has the properties of completeness, soundness, timed privacy and partial fairness.
The proof is postponed to Appendix C.
NIZK for the correct commitment of DL
In this section, we propose a tool, the NIZK protocol for the correct commitment of DL, to instantiate our generic scheme for ECDLPbased signatures. It is designed to prove that the commitment vector \((C_i)_{i\in [\kappa ]}\) encrypts the \(\kappa\)Segmentation of \(\theta\) without revealing any additional knowledge. Here, \(\theta\) represents the DL of a group element D in the group \(\mathbb {G}\). This proof consists of two parts: the segmented range proof, denoted as \(\mathsf {\Pi }_{\textsf{BulletRP}}\), and the NIZK proof of correct commitment, denoted as \(\mathsf {\Pi }_{\textsf{CCNIZK}}\). Moreover, since our scheme only involves crosschain swap between two parties, the zeroknowledge proof protocol does not need the property of nonmalleability (Sahai 1999).
Segmentation range proofs
Our construction is based on a slight variation of the Pedersen commitment scheme. Consider a common reference string \(\textsf{CRS}=(G,sG,s^2G,..., s^NG)=(G_0,G_1,..., G_N)\), where \(s{\mathop {\longleftarrow }\limits ^{R}}\mathbb {Z}_p^*\) is a trapdoor. Here, we require that s contains a factor \(2^l\). To commit the segment \(\theta [i]\) at position i using the randomness \(r_i\in \mathbb {Z}_p\), we compute \(\textsf{Commit}(\theta [i],r_i,i)=C_i=r_iG+\theta [i]G_i\). The commitment of randomness \(\vec {r}=(r_i)_{i\in [N]}\) to the vector \(\theta [\cdot ]=(\theta [1],..., \theta [N])\) is realized through a vector formed by the commitment to each segment in position i. This vector is denoted as \(\vec {C}=(C_i)_{i\in [N]}\). Alternatively, we can express this relationship as \(\vec {C}=\textsf{Commit}(\theta [\cdot ],\vec {r})\). For each commitment \(C_i\), we use the Bulletproofs range proof \(\mathsf {\Pi }_{\textsf{BulletRP}}\) to prove that it encrypts a segment with a binary length of l (if the length is less than l, we fill in the leading zeros), indicating that the value of the segment falls within the interval \([0,..., 2^l1]\).
Zeroknowledge proof protocol of correct commitment
In this section, we present a NIZK protocol \(\mathsf {\Pi }_{\textsf{CCNIZK}}\). Let \(\theta {\mathop {\longleftarrow }\limits ^{R}}\mathbb {Z}_p^*\). Consider the commitment to the \(\kappa\)Segmentation of \(\theta\). This commitment is denoted as \(\vec {C}=(C_i)_{i\in [\kappa ]}=(r_iG+\theta [i]G_i)_{i\in [\kappa ]}\), where \(r_i\in \mathbb {Z}_p^*\) for each \(i\in [\kappa ]\). Additionally, \(D=\theta G\). \(\mathsf {\Pi }_{\textsf{CCNIZK}}\) is used to prove that each commitment item \(C_i\) at position i indeed encrypts the ith item in the \(\kappa\)Segmentation of \(\theta\). Here, \(\theta\) represents the DL of D, which is denoted as \(D=\theta G\). This proof enables us to create segmented commitments to the private key share of the joint address, and gradually release each segment of the private key share without revealing any additional knowledge. The complete NIZK protocol \(\mathsf {\Pi }_{\textsf{CCNIZK}}\) is shown in Fig. 3.
For the given \(\theta \in \mathbb {Z}_p^*\) and \(\vec {C}=(r_iG+\theta [i]G_i)_{i\in [\kappa ]}\), our proof protocol does as follows:

(1)
The prover computes \(D'=\sum _{i\in [\kappa ]}C_irG=\sum _{i\in [\kappa ]}r_i G+\sum _{i\in [\kappa ]}\theta [i] G_irG\), where \(r=\sum _{i\in [\kappa ]}r_i\). In this step, the prover obtains a compressed representation of the segmented vector commitment, and removing the randomness.

(2)
Using the common reference string \(\textsf{CRS}\) and the segmented vector \(\theta [\cdot ]\), the prover computes \(U=\frac{1}{s}D'=\frac{1}{s}(\sum _{i\in [\kappa ]}\theta [i]G_i)=\sum _{i\in [\kappa ]}\theta [i]G_{i1}\), where \(G_0=G\). This step ensures that once the equation \(e(D',G)=e(U,G_1)\) holds, it can be proven that r is indeed the accumulation of the randomness in the segmented vector commitments. If \(r\ne \sum _{i\in [\kappa ]}r_i\), it would imply a break in certain assumptions, which is impossible.

(3)
The prover lets \(U=\sum _{i\in [\kappa ]}\theta [i]G_{i1}=\sum _{i\in [\kappa ]}\theta [i]s^{i1}G=P(s)G\), where the symbol \(P(\cdot )\) represents the polynomial \(P(X)=\sum _{i\in [\kappa ]}\theta [i]X^{i1}\), and so \(P(2^l)=\sum _{i\in [\kappa ]}\theta [i]2^{l{(i1)}}=\theta\). To prove that the compressed segmented vector commitment \(U=\sum _{i\in [\kappa ]}\theta [i]G_{i1}\) is “equivalent” a single commitment \(\theta G\), the prover needs to prove that \(P(s)P(2^l)=P(s)\theta\) can be divisible by \(s2^l\). Specifically, the prover does:

Computes the coefficients of the formal polynomial \(W(\cdot )\) such that \(P(X)P(2^l)=W(X)(X2^l)\).

Computes \(V=W(s)G\) using the common reference string \(\textsf{CRS}\).
Therefore, once the equation \(e(UD,G)=e(V,G_12^lG)=e(V,(s2^l)G)\) holds, it can be ensured that the coefficients of the polynomial \(P(\cdot )\) correspond to the \(\kappa\)Segmentation of \(\theta\) (that is, \(\theta =P(2^l)\)).

Theorem 2
The protocol in Fig. 3 is a NIZK proof that proves the \(\kappa\)Segments of D’s elliptic curve DL correspond to the committed segment vectors in \((C_i)_{i\in [\kappa ]}\). This NIZK proof has perfect completeness, computational soundness and perfect zeroknowledge under the assumption of \(\kappa\)SDH.
The proof is postponed to Appendix D.
Instantiation: ACCS for ECDLPbased signatures
Instantiation of the generic construction
To show the practicability of our generic construction, we instantiate it in ECDLPbased blockchains. Specifically, we use the ECDSA signature scheme to instantiate it, where we instantiate \(\mathsf {\Pi }_{\textsf{DS}}\) as \(\mathsf {\Pi }_{\textsf{ECDSA}}\). In addition, we instantiate each algorithm in the \(\textsf{Exchange}\) protocol as follows: First, we employ the Bulletproofs range proof protocol (Bünz et al. 2018) to implement the range proof protocol, resulting in \(\mathsf {\Pi }_{\textsf{RP}}\) being instantiated as \(\mathsf {\Pi }_{\textsf{BulletRP}}\). Second, we utilize the Pedersen commitment scheme to implement the commitment scheme, leading to \(\mathsf {\Pi }_{\textsf{Com}}\) being instantiated as \(\mathsf {\Pi }_{\textsf{PedCom}}\). Third, we use the NIZK protocol \(\mathsf {\Pi }_{\textsf{DLNIZK}}\) proposed in (Camenisch and Stadler 1997) to generat the proof \(\pi _{\textsf{pk}}\). Finally, we use the NIZK protocol \(\mathsf {\Pi }_{\textsf{CCNIZK}}\) described in Sect. to generate the proof \(\pi _{cc}\).
Extensions
In this section, we propose some possible extensions of our scheme.
Replace the VTS Algorithm with the Verifiable Timed Discrete Logarithm (VTD) Algorithm. To enhance the efficiency of our scheme, we can replace the VTS algorithm with the VTD algorithm (Thyagarajan et al. 2020). In VTD, the committer no longer needs to prove that the signature of the commitment is valid, but only needs to prove that the commitment value is the DL of a known group element in the group, which is a simpler algebraic statement (Thyagarajan et al. 2022). Therefore, the VTD algorithm is more efficient in commitment generation and verification than VTS, which can significantly improve the efficiency in freeze phase.
In our ECDLPbased ACCS scheme, using the VTD algorithm, players can make a commitment to their own private key share associated with the joint address. Specifically, user B generates a commitment \(\mathsf {com^{(A)}}\) for his private key share \(\mathsf {sk^{(AB)}_B}\) and sends it to user A, while user A generates a commitment \(\mathsf {com^{(B)}}\) for his private key share \(\mathsf {sk^{(BA)}_A}\) and sends it to user B. After timeout, they can forcibly open the commitment to obtain the other user’s private key share. By combining their own private key share with the obtained one, each user can reconstruct the complete private key of the joint address, allowing them to refund their respective assets.
In terms of security, replacing VTS with the VTD algorithm will not compromise the security of our protocol, as both VTS and VTD have the same properties of soundness and privacy (Thyagarajan et al. 2020; Thyagarajan 2022).
MultiAsset Atomic Swaps. The existing HTLC has functional limitations as it only supports onetoone asset swaps. However, the current cryptocurrency prices vary greatly, making it more difficult for two exchanges on different blockchains to match. In addition, there are also many users who have a need for multiasset swaps, such as the exchanges. They hold assets in different blockchains and have different combinations of swap needs. This makes further research on multiasset ACCS meaningful, where A can exchange his Nakamoto (2008), Buterin (2013) and Litecoin (2011) for B’s Noether (2014) and Schwartz et al. (2014) through a single ACCS. Therefore, we provide two ways to achieve multiasset ACCS for our scheme, one is to swap assets on the same curve, and the other is to swap assets cross different curves.

The same curve swaps. First, we consider the case where all coins to be swapped between A and B are on blockchains that use the same elliptic curve. That is, all coins of A are on blockchains that use the elliptic curve cyclic group \(\mathbb {G}_1\), with generator \(G_1\) and prime order value \(p_1\). And all coins of B are on blockchains that use the elliptic curve cyclic group \(\mathbb {G}_2\), with generator \(G_2\) and prime order value \(p_2\). In addition, all coins participating in the swap are on ECDLPbased blockchains. Therefore, if both players use the same private key share to generate the joint addresses on different blockchains, then it can be ensured that multiple coins can be swapped with only once private key share exchange. This greatly improves the efficiency of multiasset ACCS. Moreover, using the same private key share will not compromise the privacy of the players. Because the other player can generate a random private key share, resulting in different final joint addresses and ensuring the unlinkability of crosschain transactions (Deshpande and Herlihy 2020).

Crosscurve swaps. Next, we consider the case where all coins to be swapped between user A and user B are on blockchains that use different elliptic curves. Specifically, all coins of A are on blockchains that use the elliptic curve cyclic groups \((\mathbb {G}_{1i})_{i\in [n]}\), with generators \((G_{1i})_{i\in [n]}\) and prime order values \((p_{1i})_{i\in [n]}\). All coins of B are on blockchains that use the elliptic curve cyclic groups \((\mathbb {G}_{2i})_{i\in [\widetilde{n}]}\), with generators \((G_{2i})_{i\in [\widetilde{n}]}\) and prime order values \((p_{2i})_{i\in [\widetilde{n}]}\). In this case, we can still use the solution employed in the same curve swaps. However, it’s important to note that the parameters of the elliptic curves used for each coin are different, resulting in different generated public key shares even when the same private key share are used. Therefore, it is difficult to verify whether two joint addresses are generated by the same private key share. To deal with this challenge, we introduce an additional zeroknowledge proof to prove that different public key shares on different curves have the same DL (i.e., private key share), thereby ensuring the correctness of the generated joint address. This proof can be implemented using NIZK proof mechanism proposed in Noether (2018) or Chase et al. (2022).
Experimental analysis
In this section, we evaluate and analyze our scheme through experiments. First, we evaluate the performance of our NIZK protocol. Next, we instantiate our ACCS scheme for ECDLPbased signatures, and compare it with other ACCS schemes. All experiments are run on the Windows 10 Enterprise LTSC operating system, utilizing an Intel Core i56200U CPU @ 2.30GHz, with 8GB of memory and a 465GB hard disk capacity.
Performance analysis of NIZK protocol
Implementation details. To evaluate the practical performance of our NIZK protocol \(\mathsf {\Pi }_{\textsf{CCNIZK}}\), we give a reference implementation of python language. It relies on the ecpy library (Midorikawa 2019) for elliptic curve related operations, and the sympy library (Smith 2023) for scientific calculations. The code runs on the elliptic curve secp256k1, which is also used in Bitcoin. The experimental results show that segment lengths longer than 50 bits have no significant impact on the experimental results, so we set the segment length in the range of 1 bit to 50 bits. We measure the average time of over 1000 runs and report our results in milliseconds.
Time costs and communication costs. We evaluate the time costs of the proof phase and verification phase of the NIZK protocol under different segment lengths, considering both cases of 256bit and 128bit private keys. Our experimental results are shown in Fig. 4. The results show that in the case of a 128bit private key, the running time of the proof phase does not exceed 1100 ms, and the verification phase can be completed within 50 ms. In the case of a 256bit private key, the running time of the proof phase does not exceed 2300 ms, and the verification phase can be completed within 80 ms.
In addition, we also calculate the communication cost of our protocol. We measure the communication cost as the amount of information that each party needs to exchange during protocol execution, which in our protocol is the size of the proof \(\pi _{cc}\). Specifically, it includes an element on \(\mathbb {Z}_p^*\) and two elements on \(\mathbb {G}\). When we set the elliptic curve to the secp256k1 curve with a 256bit group order, the experimental results show that the communication cost of our protocol is approximately 160 bytes.
Comparison. Compared with the original protocol proposed by Camacho (Camacho 2013), for the proof phase, our protocol can reduce the time cost by up to about 91.62% (set 128bit private key and 50bit segment length) and 94.56% (set 256bit private key and 50bit segment length). For the verification phase, our protocol can reduce the time cost by up to about 76.28% (set 128bit private key and 45bit segment length) and 86.44% (set 256bit private key and 50bit segment length). In addition, the communication costs of the two protocols are similar. It can be seen that our NIZK protocol greatly reduces the time cost without increasing the communication cost of the original protocol.
Comparison with other schemes
(1) Onchain costs
Implementation details. According to Hanzlik et al. (2022), a typical metric to measure onchain costs is to evaluate the transaction fees associated with all transactions that appear onchain in the protocol. Therefore, we define onchain execution costs measured in USD^{Footnote 1} as the amount of Ethereum transaction fees required to execute each operation: create, redeem and refund. The create operation represents the process of creating an HTLC contract or generating a joint address and depositing assets into it. The redeem operation represents the transfer process of assets in the case of successful swap, and the refund operation represents the transfer process of assets in the case of timeout. We implement and execute our ACCS scheme designed for ECDLPbased signatures on the Ethereum platform, and calculate the gas cost for each operation and an ACCS (including two create operations and two redeem operations). For each experimental result, we conduct 100 tests and take the average.
Comparison. We compare the gas cost of our scheme with other ACCS schemes. Such as, Hatch’s HTLC scheme (Hatch 2019) (denoted as Hat19), Lisi’s ACCS scheme (Lisi et al. 2020), which includes two parts of implementation, one is the payment permission (denoted as LDM20I) and the other is the review reward (denoted as LDM20II), Foundry’s scheme (Foundry 2020) (denoted as Fou20), Tsabary’s MutualAssuredDestruction Hashed TimeLocked Contract (MADHTLC) scheme (Tsabary et al. 2021) (denoted as TYM21), and two implementations of Hoenisch (Hoenisch 2020, 2020) (denoted as Hoe20I and Hoe20II).
The gas costs of three operations for different scheme are shown in Fig. 5, and the gas costs of an ACCS are shown in Fig. 6. The experimental results show that compared with other schemes, our scheme reduces the gas costs by approximately 84.37% to 96.67% in the create operation. In the redeem operation, our scheme reduces gas costs by approximately 39.54% to 77.17%. In the refund operation, our scheme can reduce gas costs by up to approximately 63.83%. When performing an ACCS, compared with other schemes, our scheme reduces gas costs by approximately 77.91% to 94.17%. This is because our ACCS scheme requires only a standard ETH transfer between two players, which is a basic inexpensive operation in Ethereum. However, HTLC implementations often require significant gas costs to perform the create operation. Therefore, compared to existing schemes, the onchain gas costs of our scheme are very low.
(2) Offchain costs
Implementation details. Li et al. (2022) showed that the time costs of ACCS can be roughly divided into onchain transaction confirmation time and other time overhead of offchain protocol execution. Since transaction confirmation time is specific to the blockchain platform used, we only consider the offchain time costs. According to Heilman et al. (2017), we calculate the offchain time costs of our scheme without considering network latency. We use the libsecp256k1 library (Poelstra 2018) to implement bulletproofs range proofs, and the liblhtlp library (Bhat 2020) to implement the VTS scheme. All experimental results are averages of 1000 runs, and we report the results in seconds.
Time costs of Exchange phase. We evaluate the offchain time cost of the Exchange phase under different segment lengths, considering both cases of 256bit and 128bit private keys. Our experimental results are shown in Fig. 7. The results show that when the private key length is 128 bits, the offchain time cost in the Exchange phase does not exceed 2.7 s. When the private key length is 256 bits, the offchain time cost does not exceed 5.3 s.
Comparison I. In the case of a 256bit private key, we compare the offchain time costs of our scheme with other schemes in the Exchange phase. Such as, Li’s ZeroCross scheme (Li et al. 2022) (denoted as LWL22I and LWL22II), Chen’s scheme (Chen et al. 2023) (denoted as CYS23), Qin’s Blindhub scheme and its optimized scheme (Qin et al. 2023) (denoted as QPM23I and QPM23II), Tairi’s \(\mathrm{A^2L}\) scheme (Tairi et al. 2021) (denoted as TMM21), and Hanzlik’s SweepUC scheme (Hanzlik et al. 2022) (denoted as HLT22). Our experimental results are shown in Fig. 8. The results show that the average time cost of our scheme in the Exchange phase is better than other schemes.
Time costs of an ACCS. In the case of a 256bit private key, we calculate the time costs of our scheme to execute an ACCS. The average offchain time cost of our scheme is 16.85 s, which has no significant impact on the efficiency of ACCS according to (Li et al. 2022). Because compared with the onchain transaction confirmation time^{Footnote 2}, the offchain time cost of our scheme is very low. Therefore, its impact on the existing system is very small.
Comparison II. In the case of a 256bit length private key, we compare the offchain time costs of our scheme with other schemes in executing an ACCS. Such as, Qin’s Blindhub scheme and its optimized scheme (Qin et al. 2023) (denoted as QPM23I and QPM23II), Zamyatin’s XCLAIM scheme (Zamyatin et al. 2019) (denoted as ZHL19), and Hanzlik’s SweepUC scheme (Hanzlik et al. 2022) (denoted as HLT22). Our experimental results are shown in Table 2. The results show that the offchain time cost of our scheme is as practical as other schemes.
(3) Experimental conclusion
In summary, although ACCS functionality is easy to be implemented using smart contracts such as HTLC, our protocol is preferable due to its advantages, such as lower onchain overhead, and practical offchain time costs similar to other schemes.
Conclusion
In this paper, we propose a generic ACCS scheme, independent from the underlying blockchains. To the best of our knowledge, this is the first solution of this kind. Our results are as follows. First, we define a formal system model of ACCS. Next, we present a generic ACCS scheme meets our model. This scheme admits atomicity in crosschain swaps without the need for a TTP and protects users’ privacy. Finally, by using the NIZK protocol as a tool, we instantiate our generic scheme for ECDLPbased signatures. In addition, we implement our scheme, and the experimental results show that our protocol outperforms the existing ACCS schemes, such as the HTLCbased schemes.
However, although our research provides some insights into the field of ACCS, we must also acknowledge the limitations and unresolved issues of this research. Therefore, we propose some possible future work here. On the one hand, we will further improve the efficiency of our scheme in the future. The current scheme can meet the requirements of generality, privacy, and atomicity without TTP at the same time. However, there is still room for improvement in efficiency of our scheme. In the future, we will explore more effective crosschain protocols to improve the realtime nature of transactions. On the other hand, we will expand the crosschain functionality of the scheme in the future. Our scheme is mainly applicable to ACCS, however, the transfer of assets and data between different chains is also a common application scenario. Here, we take ACCS as a starting point, and in our future work, we will further study solutions that can achieve other crosschain functions to meet the constantly evolving market demand.
In a word, we believe these future works will contribute to the development of the blockchain and cryptocurrency fields. We encourage more researchers to participate in this field to unlock its potential value and promote its further development.
Availability of data and materials
Not applicable.
Notes
References
Agbo CC, Mahmoud QH, Eklund JM (2019) Blockchain technology in healthcare: a systematic review. Healthcare 7:56
Asokan N (1998) Fairness in electronic commerce
Bentov I, Ji Y, Zhang F, Breidenbach L, Daian P, Juels A (2019) Tesseract: Realtime cryptocurrency exchange using trusted hardware. In: Proceedings of the 2019 ACM SIGSAC conference on computer and communications security, pp. 1521–1538
Bhat A (2020) Linearly homomorphic time lock puzzle library. https://github.com/verifiabletimedsignatures/liblhtlp
Boneh D, Boyen X (2008) Short signatures without random oracles and the SDH assumption in bilinear groups. J Cryptol 21(2):149–177
Boneh D, Gentry C, Lynn, B, Shacham H (2003) Aggregate and verifiably encrypted signatures from bilinear maps. In: Advances in CryptologyEUROCRYPT 2003: international conference on the theory and applications of cryptographic techniques, Warsaw, 2003 Proceedings 22, pp. 416–432. Springer
Buterin V (2013) Ethereum white paper. GitHub Repository 1:22–23
Bünz B, Bootle J, Boneh D, Poelstra A, Wuille P, Maxwell G (2018) Bulletproofs: short proofs for confidential transactions and more. In: 2018 IEEE symposium on security and privacy (SP), pp. 315–334. IEEE
Camacho P (2013) Fair exchange of short signatures without trusted third party. In: Topics in cryptology–CTRSA 2013: the cryptographers’ track at the RSA conference 2013, San Francisco. Proceedings, pp. 34–49 . Springer
Camenisch J, Stadler M (1997) Proof systems for general statements about discrete logarithms. Technical Report/ETH Zurich, Department of Computer Science 260
Chase M, Orrù M, Perrin T, Zaverucha G (2022) Proofs of discrete logarithm equality across groups. Cryptology ePrint Archive
Chen L, Yao Z, Si X, Zhang Q (2023) Threestage crosschain protocol based on notary group. Electronics 12(13):2804
Cleve R (1986) Limits on the security of coin flips when half the processors are faulty. In: Proceedings of the eighteenth annual ACM symposium on theory of computing, pp. 364–369
Deshpande A, Herlihy M (2020) Privacypreserving crosschain atomic swaps. In: International conference on financial cryptography and data security, pp. 540–549. Springer
Erwig A, Faust S, Hostáková K, Maitra M, Riahi S (2021) Twoparty adaptor signatures from identification schemes. In: IACR international conference on publickey cryptography, pp. 451–480. Springer
Foundry F (2020) HTLC solidity implementation. https://github.com/functionalfoundry/ethereumhtlc
Fournier L (2019) Onetime verifiably encrypted signatures aka adaptor signatures
Garay J, Kiayias A, Leonardos N (2015) The bitcoin backbone protocol: analysis and applications. In: Annual international conference on the theory and applications of cryptographic techniques, pp. 281–310. Springer
Gennaro R, Goldfeder S (2018) Fast multiparty threshold ECDSA with fast trustless setup. In: Proceedings of the 2018 ACM SIGSAC conference on computer and communications security, pp. 1179–1194
Glaeser N, Maffei M, Malavolta G, MorenoSanchez P, Tairi E, Thyagarajan SAK (2022) Foundations of coin mixing services. In: Proceedings of the 2022 ACM SIGSAC conference on computer and communications security, pp. 1259–1273
Gordon SD, Katz J (2012) Partial fairness in secure twoparty computation. J Cryptol 25(1):14–40
Gugger J (2020) Bitcoinmonero crosschain atomic swap. Cryptology ePrint Archive
Guo Y, Liang C (2016) Blockchain application and outlook in the banking industry. Financ Innov 2:1–12
Hanser C, Rabkin M, Schröder D (2015) Verifiably encrypted signatures: security revisited and a new construction. In: Computer Security–ESORICS 2015: 20th European symposium on research in computer security, Vienna, 2015, Proceedings, Part I 20, pp. 146–164 . Springer
Hanzlik L, Loss J, Thyagarajan SA, Wagner B (2022) Sweepuc: swapping coins privately. Cryptology ePrint Archive
Hatch C (2019) Hashed timelock contract ethereum. https://github.com/chatch/hashedtimelockcontractethereum
Hei Y, Li D, Zhang C, Liu J, Liu Y, Wu Q (2022) Practical AgentChain: a compatible crosschain exchange system. Futur Gener Comput Syst 130:207–218
Heilman E, Alshenibr L, Baldimtsi F, Scafuro A, Goldberg S (2017) Tumblebit: an untrusted bitcoincompatible anonymous payment hub. In: Network and distributed system security symposium
Herlihy M (2018) Atomic crosschain swaps. In: Proceedings of the 2018 ACM symposium on principles of distributed computing, pp. 245–254
Herlihy M, Liskov B, Shrira L (2019) Crosschain deals and adversarial commerce. arXiv preprint arXiv:1905.09743
Hoenisch P, Mazumdar S, MorenoSanchez P, Ruj S (2022) Lightswap: an atomic swap does not require timeouts at both blockchains. In: International workshop on data privacy management, pp. 219–235. Springer
Hoenisch P, Pino LS (2021) Atomic swaps between bitcoin and monero. arXiv preprint arXiv:2101.12332
Hoenisch P (2020) COMIT contracts. https://github.com/comitnetwork/blockchaincontracts/blob/82cf33c0d01e445f2bd05bf3eb32a0143e672ab5/src/ethereum/rfc003/ether_htlc.rs
Hoenisch P (2020) COMIT contracts. https://github.com/comitnetwork/blockchaincontracts/blob/82cf33c0d01e445f2bd05bf3eb32a0143e672ab5/src/ethereum/rfc003/erc20_htlc.rs
Kiayias A, Russell A, David B, Oliynykov R (2017) Ouroboros: a provably secure proofofstake blockchain protocol. In: Annual international cryptology conference, pp. 357–388 . Springer
Li Y, Weng J, Li M, Wu W, Weng J, Liu JN, Hu S (2022) ZeroCross: a sidechainbased privacypreserving crosschain solution for Monero. J Parallel Distrib Comput 169:301–316
Lisi A, De Salve A, Mori P, Ricci L (2020) Practical application and evaluation of atomic swaps for blockchainbased recommender systems. In: Proceedings of the 2020 3rd international conference on blockchain technology and applications, pp. 67–74
Litecoin (2011) https://litecoin.com/en/
Luu L, Narayanan V, Zheng C, Baweja K, Gilbert S, Saxena P (2016) A secure sharding protocol for open blockchains. In: Proceedings of the 2016 ACM SIGSAC conference on computer and communications security, pp. 17–30
Manevich Y, Akavia A (2022) Cross chain atomic swaps in the absence of time via attribute verifiable timed commitments. In: 2022 IEEE 7th european symposium on security and privacy (EuroS &P), pp. 606–625. IEEE
Mazumdar S (2022) Towards faster settlement in HTLCbased crosschain atomic swaps. In: 2022 IEEE 4th international conference on trust, privacy and security in intelligent systems, and applications (TPSISA), pp. 295–304. IEEE
Midorikawa S (2019) EllipticCurve Cryptography Library. https://github.com/ellipticshiho/ecpy
Mitsunari S, Sakai R, Kasahara M (2002) A new traitor tracing. IEICE Trans Fundam Electron Commun Comput Sci 85(2):481–484
Nakamoto S (2008) Bitcoin whitepaper. URL: https://bitcoin. org/bitcoin. pdf(: 17.07. 2019)
Noether S (2014) Review of cryptonote white paper. HYPERLINK http://monero.cc/downloads/whitepaper_review.pdf
Noether S (2018) Discrete logarithm equality across groups
Poelstra A (2018) Library for EC operations on curve secp256k1. https://github.com/apoelstra/secp256k1zkp
Poon J, Dryja T (2016) The bitcoin lightning network: scalable offchain instant payments
Qin X, Pan S, Mirzaei A, Sui Z, Ersoy O, Sakzad A, Esgin MF, Liu JK, Yu J, Yuen TH (2023) Blindhub: Bitcoincompatible privacypreserving payment channel hubs supporting variable amounts. In: 2023 IEEE symposium on security and privacy (SP), pp. 2462–2480. IEEE
Reyna A, Martín C, Chen J, Soler E, Díaz M (2018) On blockchain and its integration with IoT. Challenges and opportunities. Future Gener Comput Syst 88:173–190
Sahai A (1999) Nonmalleable noninteractive zero knowledge and adaptive chosenciphertext security. In: 40th annual symposium on foundations of computer science (Cat. No. 99CB37039), pp. 543–553. IEEE
Schwartz D, Youngs N, Britto A (2014) The ripple protocol consensus algorithm. Ripple Labs Inc White Paper 5(8):151
Shlomovits O, Leiba O (2020) Jugglingswap: scriptless atomic crosschain swaps. arXiv preprint arXiv:2007.14423
Smith C (2023) SymPy. https://github.com/sympy/sympy
Tairi E, MorenoSanchez P, Maffei M (2021) A\(^2\)l: Anonymous atomic locks for scalability in payment channel hubs. In: 2021 IEEE symposium on security and privacy (SP), pp. 1834–1851. IEEE
Thyagarajan SAK, Malavolta G (2021) Lockable signatures for blockchains: scriptless scripts for all signatures. In: 2021 IEEE symposium on security and privacy (SP), pp. 937–954. IEEE
Thyagarajan SA (2022) Cryptographic locks for scriptless cryptocurrency payments. PhD thesis, FriedrichAlexanderUniversität ErlangenNürnberg (FAU)
Thyagarajan SAK, Bhat A, Malavolta G, Döttling N, Kate A, Schröder D (2020) Verifiable timed signatures made practical. In: Proceedings of the 2020 ACM SIGSAC conference on computer and communications security, pp. 1733–1750
Thyagarajan SA, Malavolta G, MorenoSanchez P (2022) Universal atomic swaps: secure exchange of coins across all blockchains. In: 2022 IEEE symposium on security and privacy (SP), pp. 1299–1316. IEEE
TierNolan (2013) Atomic Swap  Bitcoin Wiki. https://en.bitcoin.it/wiki/Atomic_swap
Tsabary I, Yechieli M, Manuskin A, Eyal I (2021) MADHTLC: because htlc is crazycheap to attack. In: 2021 IEEE symposium on security and privacy (SP), pp. 1230–1248. IEEE
Wang G, Nixon M (2021) Intertrust: towards an efficient blockchain interoperability architecture with trusted services. In: 2021 IEEE international conference on blockchain (Blockchain), pp. 150–159 . IEEE
Zamani M, Movahedi M, Raykova M (2018) Rapidchain: scaling blockchain via full sharding. In: Proceedings of the 2018 ACM SIGSAC conference on computer and communications security, pp. 931–948
Zamyatin A, AlBassam M, Zindros D, KokorisKogias E, MorenoSanchez P, Kiayias A, Knottenbelt WJ (2021) Sok: communication across distributed ledgers. In: Financial cryptography and data security: 25th international conference, FC 2021, Virtual Event, Part II 25, pp. 3–36. Springer
Zamyatin A, Harz D, Lind J, Panayiotou P, Gervais A, Knottenbelt W (2019) Xclaim: trustless, interoperable, cryptocurrencybacked assets. In: 2019 IEEE symposium on security and privacy (SP), pp. 193–210. IEEE
Acknowledgements
The authors would like to thank the anonymous reviewers for their valuable comments.
Funding
This work was supported by National Natural Science Foundation of China (Nos. 62172404, 62172411, 61972094, 62202458).
Author information
Authors and Affiliations
Contributions
The author(s) read and approved the final manuscript.
Corresponding author
Ethics declarations
Competing interests
The authors declare that they have no competing interests.
Additional information
Publisher’s Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Appendices
Appendix A Exchange protocol
The \(\textsf{Exchange}\) protocol consists of 6 algorithms.

\(\mathsf {sk_1}[\cdot ]\leftarrow \textsf{DivideSegment}(\mathsf {sk_1},l,\kappa )\). Given a private key share \(\mathsf {sk_1}\), the algorithm divides it into \(\kappa\) segments, denoted as \(\mathsf {sk_1}[\cdot ]=(\mathsf {sk_1}[1],..., \mathsf {sk_1}[\kappa ])\). Each segment’s length is l bits (with leading zeros added if the length is less than l).

\((\vec {r},\vec {\textsf{com}},(\pi _{rpi})_{i\in [\kappa ]},\pi _{cc},\pi _{\textsf{pk}})\leftarrow \textsf{ComProofGen}(\mathsf {sk_1}[\cdot ])\). Given \(\kappa\)Segmentation of \(\mathsf {sk_1}\), the algorithm outputs a commitment vector \(\vec {\textsf{com}}\) for each segment in \(\mathsf {sk_1}[\cdot ]\), its corresponding range proofs \((\pi _{rpi})_{i\in [\kappa ]}\), a correct commitment proof \(\pi _{cc}\), and a ZeroKnowledge Proof of Knowledge (ZKPoK) for the private key share \(\mathsf {sk_1}\), denoted as \(\pi _{\textsf{pk}}\). Specifically, the algorithm does the following:

1.
For each \(i\in [\kappa ]\), runs \((\mathsf {com_i},(\mathsf {sk_1}[i],r_i)) \leftarrow \mathsf {\Pi }_{\textsf{Com}}.\textsf{Com}(h,\mathsf {sk_1}[i])\) to generate commitment \(\mathsf {com_i}\) for the ith segment of the private key share. Next, it runs \(\pi _{rpi} \leftarrow \mathsf {\Pi }_{\textsf{RP}}.\textsf{Proof}(\mathsf {com_i})\) to generate a range proof \(\pi _{rpi}\) for the ith commitment. This range proof is used to verify that the commitment \(\mathsf {com_i}\) encrypts a segment with a binary length of l (if the length is less than l, leading zeros are filled).

2.
Let \(\vec {\textsf{com}}=(\mathsf {com_i})_{i\in [\kappa ]}\) and \(\vec {r}=(r)_{i\in [\kappa ]}\). Next, runs \(\pi _{cc} \leftarrow \mathsf {\Pi }_{\textsf{NIZK}}.\textsf{Proof}(\vec {\textsf{com}})\) to generate a proof of correct commitment. This proof is used to verify that each commitment item \(\mathsf {com_i}\) at position i indeed encrypts the ith item in the \(\kappa\)Segmentation of \(\mathsf {sk_1}\).

3.
Runs \(\pi _{\textsf{pk}} \leftarrow \mathsf {\Pi }_{\textsf{NIZK}}.\textsf{Proof}(\mathsf {sk_1})\) to generate a ZKPoK for \(\mathsf {sk_1}\), where \(\mathsf {sk_1}\) is the correct private key share corresponding to the public key.

4.
Takes \((\vec {r},\vec {\textsf{com}},(\pi _{rpi})_{i\in [\kappa ]},\pi _{cc},\pi _{\textsf{pk}})\) as the output.

1.

\(0/1\leftarrow \textsf{ComProofCheck}((\pi _{rpi})_{i\in [\kappa ]},\pi _{cc},\pi _{\textsf{pk}})\). Given range proofs \((\pi _{rpi})_{i\in [\kappa ]}\), a correct commitment proof \(\pi _{cc}\), and a ZKPoK \(\pi _{\textsf{pk}}\), the algorithm outputs 0 to indicate validation failure and outputs 1 to indicate validation success. Specifically, the algorithm does the following:

1.
For each \(i\in [\kappa ]\), runs \(0/1 \leftarrow \mathsf {\Pi }_{\textsf{RP}}.\textsf{Verify}(\pi _{rpi})\), if it outputs 0, aborts and returns 0 as output.

2.
Runs \(0/1 \leftarrow \mathsf {\Pi }_{\textsf{NIZK}}.\textsf{Verify}(\pi _{cc})\), if it outputs 0, aborts and returns 0 as output.

3.
Runs \(0/1 \leftarrow \mathsf {\Pi }_{\textsf{NIZK}}.\textsf{Verify}(\pi _{\textsf{pk}})\), if it outputs 0, aborts and returns 0 as output.

4.
Returns 1 as output.

1.

\((\mathsf {sk_1}[i],r_i)\leftarrow \textsf{SegComOpen}(\mathsf {sk_1},\vec {r},i)\). Given a private key share \(\mathsf {sk_1}\), a random value vector \(\vec {r}\), and the index i of the commitment to be opened, the algorithm outputs the opening value \((\mathsf {sk_1}[i],r_i)\) of the commitment.

\(0/1\leftarrow \textsf{SegComCheck}(h,\mathsf {sk_1}[i],\textsf{com},(\mathsf {sk_1}[i],r_i))\). Given a public value h of the commitment, the ith segment of a private key share, a commitment \(\textsf{com}\), and a corresponding opening value \((\mathsf {sk_1}[i],r_i)\), the algorithm runs \(0/1 \leftarrow \mathsf {\Pi }_{\textsf{Com}}.\textsf{Vf}(h,\mathsf {sk_1}[i],\textsf{com},(\mathsf {sk_1}[i],r_i))\) and outputs the result.

\(\mathsf {sk_1}\leftarrow \textsf{ConnectSegment}(\mathsf {sk_1}[\cdot ])\). Given \(\mathsf {sk_1}\)’s \(\kappa\)Segmentation, the algorithm outputs \(\mathsf {sk_1}\).
Appendix B Onetoone ACCS protocol
Our ACCS protocol can be divided into five phases: setup phase, freezing phase, exchange phase, complete phase and timeout phase. The complete onetoone ACCS protocol is shown in Fig. 9 and 10.
Appendix C Proof of Theorem 1
Completeness. To prove the correctness of the protocol in Appendix B, we discuss two scenarios: timeout and no timeout.
 1.:

No timeout. Assuming that both users participating in ACCS follow the protocol, in the case of no timeout, they freeze their assets to the joint addresses and successfully exchange their private key shares. Therefore, they can sign the swap transactions and publish the signatures to swap their assets. This results in both users’ states being 1 at the end of the protocol, i.e., \(\mathsf {state_A}=1 \wedge \mathsf {state_B}=1\).
 2.:

Timeout. Assuming that both users participating in ACCS follow the protocol, the timeout is usually caused by one user being offline, resulting in the failure of the \(\textsf{Exchange}\) protocol. In the case of timeout, users will be unable to reconstruct the complete private key corresponding to the joint address. Consequently, they will not execute the complete phase but execute the unfreeze phase to obtain the signature of the refund transaction, and then publish it for refund. This results in both users’ states being 0 at the end of the protocol, i.e., \(\mathsf {state_A}=0 \wedge \mathsf {state_B}=0\).
Soundness. We use proof by contradiction to prove that the protocol in Appendix B satisfies the soundness property. Assuming that an adversary \(\mathcal {A}\) generates a commitment \(\mathsf {com^*}\) and its corresponding proof \(\pi ^*\), such that the output of the \(\textsf{Verify}\) algorithm is 1, but the output of the \(\mathsf {\Pi }_{\textsf{DS}}.\textsf{Vf}\) algorithm is 0. This would imply that the adversary has broken the soundness property of the underlying VTS module \(\mathsf {\Pi }_{\textsf{VTS}}\) (Thyagarajan et al. 2020; Thyagarajan 2022).
Timed Privacy. We use proof by contradiction to prove that the protocol in Appendix B satisfies the timed privacy property. Assuming a PPT adversary \(\mathcal {A}\) with running time \(t\ll \textsf{T}\mathsf {const_1}\) generates a valid signature \(\sigma ^*\), resulting in the output of the \(\mathsf {\Pi }_{\textsf{DS}}.\textsf{Vf}\) algorithm being 1. This implies that the adversary has broken the privacy property of the underlying VTS module \(\mathsf {\Pi }_{\textsf{VTS}}\) (Thyagarajan et al. 2020; Thyagarajan 2022). Similarly, if an honest user A with running time \(t \gg \textsf{T}+\mathsf {const_1}\) executes the \(\textsf{UnFreeze}\) algorithm and obtains an invalid signature \(\sigma\), resulting in the output of the \(\mathsf {\Pi }_{\textsf{DS}}.\textsf{Vf}\) algorithm being 0. It also indicates that the adversary has broken the privacy property of the underlying VTS module \(\mathsf {\Pi }_{\textsf{VTS}}\) (Thyagarajan et al. 2020; Thyagarajan 2022).
Partial Fairness. The partial fairness property of the protocol ensures that the following situation is impossible: \(\Pr [\mathsf {sk^{(AB)}_A}=\mathsf {sk^{'}_A}]\Pr [\mathsf {sk^{(BA)}_B}=\mathsf {sk^{'}_B}]\) is greater than \(\frac{2^{\mathsf {const_2}}}{2^{\lambda i}}+\textsf{negl}(\lambda )\), where \(\lambda =\mathsf {sk^{(AB)}_A}=\mathsf {sk^{(BA)}_B}\) is the security parameter representing the length of the private key share. Here, i represents the prefix bit length of the private key share \(\mathsf {sk^{(BA)}_B}\) obtained by user A when the \(\textsf{Exchange}\) protocol aborts, and \(\mathsf {const_2}=l\) represents the segment bit length specified by the system in the setup phase.
Let \(\mathcal {A}\) be an adversary who breaks the partial fairness property of our protocol. To prove that the protocol in Appendix B satisfies the partial fairness property, we distinguish between two types of adversaries. Type I represents an adversary \(\mathcal {A}\) that cannot lie. This type of adversary follows the protocol but may abort prematurely. Type II represents an adversary \(\mathcal {A}\) that can lie, meaning they may forge range proofs, NIZK proofs, and/or segment commitments.
 1.:

Type I  User A is corrupted. In this case, the adversary \(\mathcal {A}\) may choose to abort the \(\textsf{Exchange}\) protocol either before or after user B sends the opening value of a segment commitment during the protocol execution. First, we assume that the adversary \(\mathcal {A}\) aborts the \(\textsf{Exchange}\) protocol before user B sends the opening value of a segment commitment during the protocol execution. At this point, the adversary \(\mathcal {A}\) obtains the first i bits of \(\mathsf {sk^{(BA)}_B}\), and user B obtains the first \(i+l\) bits of \(\mathsf {sk^{(AB)}_A}\). Thus, we have \(\Pr [\mathsf {sk^{(AB)}_A}=\mathsf {sk^{'}_A}]=\frac{1}{2^{\lambda il}}\) and \(\Pr [\mathsf {sk^{(BA)}_B}=\mathsf {sk^{'}_B}]=\frac{1}{2^{\lambda i}}\), which leads to \(\Pr [\mathsf {sk^{(AB)}_A}=\mathsf {sk^{(AB )'}_A}]\Pr [\mathsf {sk^{(BA)}_B}=\mathsf {sk^{'}_B}]=\frac{2^l1}{2^{\lambda i}}\le \frac{2^l}{2^{\lambda i}}+\textsf{negl}(\lambda )\). Therefore, in this case, our protocol satisfies the property of partial fairness. Next, we assume that the adversary \(\mathcal {A}\) aborts the \(\textsf{Exchange}\) protocol after user B sends the opening value of a segment commitment during the protocol execution. At this point, the adversary \(\mathcal {A}\) obtains the first i bits of \(\mathsf {sk^{(BA)}_B}\), and user B also obtains the first i bits of \(\mathsf {sk^{(AB)}_A}\). Thus, we have \(\Pr [\mathsf {sk^{(AB)}_A}=\mathsf {sk^{'}_A}]=\Pr [\mathsf {sk^{(BA)}_B}=\mathsf {sk^{'}_B}]=\frac{1 }{2^{\lambda i}}\), which results in \(\Pr [\mathsf {sk^{(AB)}_A}=\mathsf {sk^{'}_A}]\Pr [\mathsf {sk^{(BA)}_B}=\mathsf {sk ^{(BA)'}_B}]=0\le \frac{2^l}{2^{\lambda i}}+\textsf{negl}(\lambda )\). Therefore, in this case, our protocol satisfies the property of partial fairness.
 2.:

Type I  User B is corrupted. In this case, the adversary \(\mathcal {A}\) may choose to abort the \(\textsf{Exchange}\) protocol either before or after user A sends the opening value of a segment commitment during the protocol execution. First, we assume that the adversary \(\mathcal {A}\) aborts the \(\textsf{Exchange}\) protocol before user A sends the opening value of a segment commitment during the protocol execution. At this point, the user A obtains the first i bits of \(\mathsf {sk^{(BA)}_B}\), and adversary \(\mathcal {A}\) also obtains the first i bits of \(\mathsf {sk^{(AB)}_A}\). Thus, we have \(\Pr [\mathsf {sk^{(AB)}_A}=\mathsf {sk^{'}_A}]=\Pr [\mathsf {sk^{(BA)}_B}=\mathsf {sk^{'}_B}]=\frac{1 }{2^{\lambda i}}\), which leads to \(\Pr [\mathsf {sk^{(AB)}_A}=\mathsf {sk^{'}_A}]\Pr [\mathsf {sk^{(BA)}_B}=\mathsf {sk ^{(BA)'}_B}]=0\le \frac{2^l}{2^{\lambda i}}+\textsf{negl}(\lambda )\). Therefore, in this case, our protocol satisfies the property of partial fairness. Next, we assume that the adversary \(\mathcal {A}\) aborts the \(\textsf{Exchange}\) protocol after user A sends the opening value of a segment commitment during the protocol execution. At this point, the user A obtains the first i bits of \(\mathsf {sk^{(BA)}_B}\), and adversary \(\mathcal {A}\) obtains the first \(i+l\) bits of \(\mathsf {sk^{(AB)}_A}\). Thus, we have \(\Pr [\mathsf {sk^{(AB)}_A}=\mathsf {sk^{'}_A}]=\frac{1}{2^{\lambda il}}\) and \(\Pr [\mathsf {sk^{(BA)}_B}=\mathsf {sk^{'}_B}]=\frac{1}{2^{\lambda i}}\), which results in \(\Pr [\mathsf {sk^{(AB)}_A}=\mathsf {sk^{(AB )'}_A}]\Pr [\mathsf {sk^{(BA)}_B}=\mathsf {sk^{'}_B}]=\frac{2^l1}{2^{\lambda i}}\le \frac{2^l}{2^{\lambda i}}+\textsf{negl}(\lambda )\). Therefore, in this case, our protocol satisfies the property of partial fairness.
 3.:

Type II. For Type II, We use proof by contradiction to prove that the protocol in Appendix B satisfies the partial fairness property. Assuming that an adversary \(\mathcal {A}\) forges a range proof \(\pi _1^*\), a NIZK proof \(\pi _2^*\) and/or a segment commitment \(\mathsf {com^*}\) that can pass the \(\textsf{ComProofCheck}\) and \(\textsf{SegComCheck}\) algorithms. This implies that the adversary has broken the soundness property of the underlying zeroknowledge proof module \(\mathsf {\Pi }_{\textsf{RP}}\) and/or \(\mathsf {\Pi }_{\textsf{NIZK}}\), and/or the binding property of the underlying commitment scheme module \(\mathsf {\Pi }_{\textsf{Com}}\).
Appendix D Proof of Theorem 2
Before proceeding with formal proof, we first emphasize the role of range proofs, which use Bulletproofs for efficient instantiation. To intuitively understand the reasons behind this, first we describe a possible attack. Subsequently, we will explain why Bulletproofs range proofs can effectively resist such attack.
The zeroknowledge proof protocol of correct commitment proves that \(C_i\) encrypts \(\theta [i]\), such that \(P(2^l)=\sum _{i\in [\kappa ]}\theta [i]2^{l{(i1)}}=\theta\), where \(\theta\) is the DL of D. However, this alone does not guarantee the correctness of the protocol, as there exists a simple attack that involves generating commitments for shifted segments, such that \(C_i\) encrypts plaintext that shifts \(\theta [i]\). In this attack, the final sum of plaintext remains the same, i.e., \(\theta\), but each \(C_i\) will be opened incorrectly. Specifically, the meaning of this attack is that if the malicious user A aborts during the gradual release of secret segments, then the honest user B will have nothing, while A will have all the correct secret segments that have already been released by B.
We use an example to illustrate the harm of this attack. Assuming that the adversary only changes two secret segments, namely the ith segment and the \(i+1\)th segment. The modified values are \(\theta [i]'=\theta [i]+b[i]\) and \(\theta [i+1]'=\theta [i+1]+b[i+1]\). After modification, the commitment value for the ith segment becomes \(C_i'=r_iG+\theta [i]'G_i=r_iG+(\theta [i]+b[i])G_i\), and the commitment value for the \(i+1\)th segment becomes \(C_{i+1}'=r_{i+1}G+\theta [i+1]'G_{i+1}=r_{i+1}G+(\theta [i+1]+b[i+1])G_{i+1}\). During the gradual release of secret segments, the adversary sends \(\theta [i]'\) and \(\theta [i+1]'\) to the verifier, claiming that they are \(\theta [i]\) and \(\theta [i+1]\). The verifier can only check whether the commitment has been opened correctly, but cannot determine whether the opened plaintext is the correct secret segment \(\theta [i]\), or a shift of it, i.e., \(\theta [i]'=\theta [i]+b[i]\). As a result, the commitments of both secret segments are opened to incorrect values. Specifically, the ith segment is opened to \(\theta [i]+b[i]\ne \theta [i]\), and the \(i+1\)th segment is opened to \(\theta [i+1]+b[i+1]\ne \theta [i+1]\).
However, this attack can be avoided with a high probability by generating Bulletproofs range proof for commitment \(C_i\). Next, we show how Bulletproofs range proofs prevent this specific attack, and extend it to all possible changes to the encrypted segments \(\theta [\cdot ]\). There are four cases of this attack:

1.
\(\theta [i]'\in [0,..., 2^l1] \wedge \theta [i+1]'\in [0,..., 2^l1]\).

2.
\(\theta [i]'\notin [0,..., 2^l1] \wedge \theta [i+1]'\in [0,..., 2^l1]\).

3.
\(\theta [i]'\in [0,...,2^l1] \wedge \theta [i+1]'\notin [0,..., 2^l1]\).

4.
\(\theta [i]'\notin [0,..., 2^l1] \wedge \theta [i+1]'\notin [0,..., 2^l1]\).
For the latter three cases, there is a high probability that at least one Bulletproofs range proof cannot be verified. In the first case, in order to pass the verification of the zeroknowledge proof protocol of correct commitment, it is necessary to satisfy \(\sum _{i\in [\kappa ]}b[i]2^{l{(i1)}}+\sum _{i\in [\kappa ]}b[i+1]2^{l{(i1)}}=np\), where np is a multiple of the order. Every option except \(n=0\) and \(b[i]=b[i+1]=0\) will cause b[i] and \(b[i+1]\) to be out of the interval \([0,..., 2^l1]\) with a very high probability.
Perfect Completeness. Since the prover knows the common reference string \(\textsf{CRS}\) and the segment vector \(\theta [\cdot ]\), he can compute \(U=\frac{1}{s}(\sum _{i\in [\kappa ]}C_irG)\) without knowing s. Here, \(U=\sum _{i\in [\kappa ]}\theta [i]G_{i1}\). Similarly, since the prover knows the common reference string \(\textsf{CRS}\) and the coefficients of the formal polynomial \(W(\cdot )\), he can compute V. Here, \(V=\sum _{i\in [\kappa 1 ]}W[i]G_{i1}\).
Computational Soundness. We assume that the one who breaks the soundness of the protocol is the PPT adversary \(\mathcal {A}\), and \(\mathcal {B}\) is an adversary we built. \(\mathcal {B}\) receives \((G_0,G_1,G_2,..., G_\kappa )\) and uses this tuple as the \(\textsf{CRS}\), then sends it to \(\mathcal {A}\). \(\mathcal {A}\) returns the following values:

\(\theta \in \mathbb {Z}_p^*\).

\(\theta ^*\in \mathbb {Z}_p^*\) such that \(D=\theta ^*G\) and \(\theta \ne \theta ^*\).

For each \(i\in [\kappa ]\) there exist \((r_i,\theta [i])\in (\mathbb {Z}_p^*\times \mathbb {Z}_p^*)^\kappa\) such that \(\vec {C}=(C_i)_{i\in \kappa }\), where \(C_i=r_iG+\theta [i]G_i\).

\(\pi =(r,U,V)\in \mathbb {Z}_p^*\times \mathbb {G}\times \mathbb {G}\).
The proof is divided into two steps. First we assume that \(r\ne \sum _{i\in [\kappa ]}r_i\,mod\,p\). In this case, we can deduce that \(U=\frac{1}{s}((\sum _{i\in [\kappa ]}r_ir)G+\sum _{i\in [\kappa ]}\theta [i]s^iG)\). Since \(\theta [i]\) is known, \(\mathcal {B}\) can compute \(\frac{1}{s}\theta [i]s^iG=\theta [i]s^{i1}G=\theta [i]G_{i1}\). Consequently, \(\mathcal {B}\) can deduce \(\frac{\sum _{i\in [\kappa ]}r_ir}{s}G\). Given that \(\delta =\sum _{i\in [\kappa ]}r_ir\ne 0\,mod\,p\) is known, \(\frac{1}{s}G=\frac{1}{\delta }(U\theta [i]G_{i1})\) can be easily computed, thus breaking the \(\kappa\)DHI assumption.
Next, we assume that \(\sum _{i\in [\kappa ]}r_i=r\). When the verification of V passes, it implies that we have \(V=\frac{\sum _{i\in [\kappa ]}(\theta [i]s^{i1}\theta ^*[i]2^{l(i1)})}{s2^l}G\). If the adversary \(\mathcal {A}\) wins, it means that there exists some \(j\in [\kappa ]\) such that \(\theta [j]\ne \theta ^*[j]\). Further analysis reveals that Bulletproofs guarantee the length of \(\theta [i]\) and \(\theta ^*[i]\) to be l, making it impossible to encrypt shifted segment. Thus, we have \(\bigtriangleup =\sum _{i\in [\kappa ]}2^{l(i1)}(\theta [i]\theta ^*[i])\ne 0\,mod\,p\). We can rephrase V as \(V=(\frac{\bigtriangleup }{s2^l}+\frac{\sum _{i\in [\kappa ]}\theta [i]s^{i1}\theta [i]2^{l(i1)}}{s2^l})G=(\frac{\bigtriangleup }{s2^l}+\frac{\sum _{i\in [\kappa ]}\theta [i](s^{i1}2^{l(i1)})}{s2^l})G=(\frac{\bigtriangleup }{s2^l}+Z(s))G\). Because \(\forall i\in [\kappa ]:s2^ls^{i1}2^{l(i1)}\) (where s is required to contain a factor \(2^l\)), \(\mathcal {B}\) can efficiently compute the coefficients of the polynomial \(Z(\cdot )\). Furthermore, because \(\bigtriangleup \in \mathbb {Z}_p^*\) is also known, this allows \(\mathcal {B}\) to compute \(\frac{1}{s2^l}G=\frac{1}{\bigtriangleup }(VZ(s)G)\), thus breaking the \(\kappa\)SDH assumption.
Perfect ZeroKnowledge. The simulator correctly generates the common reference string \(\textsf{CRS}\) and saves the trapdoor s. For the given statements D and \(\vec {C}=(C_i)_{i\in [\kappa ]}\), the simulator chooses a random number \(r'\in \mathbb {Z}_p^*\), and reveal it as the randomness of \(\sum _{i\in [\kappa ]}C_i\). Then, the simulator computes \(U'=\frac{1}{s}(\sum _{i\in [\kappa ]}C_ir'G)\) and \(V'=\frac{1}{s2}(U'D)\). The following shows that the \(r',U',V'\) generated by the simulator are indistinguishable from the r, U, V in the real experiment:

\(r'\) is uniformly distributed as well as r.

Let the function \(f_1:\mathbb {G}\rightarrow \mathbb {G}\) be defined as \(f_1(x)=\sum _{i\in [\kappa ]}C_ixG\). In the simulated experiment, \(D'=f_1(r')\), and in the real experiment, \(D'=f_1(r)\).

Let the function \(f_2:\mathbb {G}\rightarrow \mathbb {G}\) be defined as \(f_2(x)=\frac{1}{s}f_1(x)\). In the simulated experiment, \(U'=f_2(r')\), and in the real experiment, \(U=f_2(r)\).

Let the function \(f_3:\mathbb {G}\rightarrow \mathbb {G}\) be defined as \(f_3(x)=\frac{1}{s2}(f_2(x)D)\). In the simulated experiment, \(V'=f_3(r')\), and in the real experiment, \(V=f_3(r)\).
Rights and permissions
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.
About this article
Cite this article
Zhu, Z., Zhang, R. & Tao, Y. Atomic crosschain swap based on private key exchange. Cybersecurity 7, 12 (2024). https://doi.org/10.1186/s42400023002028
Received:
Accepted:
Published:
DOI: https://doi.org/10.1186/s42400023002028