Analysis of Bitcoin and Layer2 asset cross-chain technology

Original title: Adaptor Signatures and Its Application to Cross-Chain Atomic Swaps

Original link: https://blog.bitlayer.org/Adaptor_Signatures_and_Its_Application_to_Cross-Chain_Atomic_Swaps/

Original author: mutourend, lynndell

1 Introduction

With the rapid development of Bitcoins Layer 2 scaling solution, the frequency of cross-chain asset transfers between Bitcoin and its Layer 2 counterpart has increased significantly. This trend is driven by the higher scalability, lower transaction fees, and high throughput provided by Layer 2 technologies such as Bitlayer. These advances facilitate more efficient and economical transactions, thereby promoting the wider adoption and integration of Bitcoin in various applications. As a result, interoperability between Bitcoin and Layer 2 networks is becoming a key component of the cryptocurrency ecosystem, driving innovation and providing users with more diverse and powerful financial tools.

As shown in Table 1, there are three typical solutions for cross-chain transactions between Bitcoin and Layer 2, namely centralized cross-chain transactions, BitVM cross-chain bridge, and cross-chain atomic swaps. These three technologies differ in terms of trust assumptions, security, convenience, transaction amounts, etc., and can meet different application requirements.

Table 1. Comparison of cross-chain transaction technologies

Centralized cross-chain transactions: Users first pay Bitcoin to a centralized institution (such as a project party or exchange), and the centralized institution pays the equivalent assets to the address specified by the user on the Layer 2 network, thereby completing the cross-chain asset transfer. The advantage of this technology is that it is fast and the matching process is relatively easy because the centralized institution can quickly confirm and process the transaction. However, the security of this method depends entirely on the reliability and reputation of the centralized institution. If the centralized institution encounters technical failures, malicious attacks, or defaults, the users funds are at high risk. In addition, centralized cross-chain transactions may also leak user privacy, and users need to consider carefully when choosing this method. Therefore, although its convenience and efficiency provide great convenience to users, security and trust are the main challenges facing centralized cross-chain transactions.

BitVM cross-chain bridge: This technology is relatively complex. First, in the Peg-in phase, users pay Bitcoin to the multi-signature address controlled by the BitVM Alliance to lock Bitcoin. The corresponding number of tokens is minted in Layer 2, and the token is used to implement Layer 2 transactions and applications. When the user destroys the Layer 2 token, the Operator will advance the payment. Subsequently, the Operator reimburses the corresponding number of Bitcoins to the multi-signature pool controlled by the BitVM Alliance. To prevent the Operator from doing evil, the reimbursement process adopts an optimistic challenge mechanism, that is, any third party can challenge malicious reimbursement behavior and thwart the evil behavior. This technology introduces an optimistic challenge mechanism, so the technology is relatively complex. In addition, the optimistic challenge mechanism involves a large number of challenge and response transactions, and the transaction fee is high. Therefore, the BitVM cross-chain bridge is only suitable for ultra-large transactions, similar to the issuance of U, and thus has a low frequency of use.

Cross-chain atomic swap: An atomic swap is a contract that enables decentralized cryptocurrency transactions. In this context, atomic means that a change in ownership of one asset actually means a change in ownership of another asset. The concept was first proposed by TierNolan on the Bitcointalk forum in 2013. For 4 years, atomic swaps remained in the theoretical realm. It was not until 2017 that Decred and Litecoin became the first blockchain systems to successfully complete atomic swaps. An atomic swap must involve two parties, and no third party can interrupt or interfere with the exchange process. This means that the technology is decentralized, uncensorable, has good privacy protection, and can achieve high-frequency cross-chain transactions, which is widely used in decentralized exchanges. Currently, cross-chain atomic swaps require 4 transactions, and some schemes try to compress the number of transactions to 2, but this will increase the real-time online requirements for both parties of the exchange. Finally, cross-chain atomic swap technology mainly includes hash time locks and adapter signatures.

Cross-chain atomic swaps based on hash time locks (HTLCs): The first project to successfully implement cross-chain atomic swaps is Decred, which uses hash locks and time locks to implement the atomic swap proposed by TierNolan with the help of on-chain scripts (or smart contracts). HTLC allows two users to conduct time-limited cryptocurrency transactions, that is, the recipient must submit a cryptographic proof (secret) to the contract within a specified time (determined by the number of blocks or block height), otherwise the funds will be returned to the sender. If the recipient confirms the payment, the transaction is successful. Therefore, both participating blockchains are required to have hash lock and time lock functions.

While HTLC atomic swaps are a major breakthrough in the field of decentralized exchange technology, there are the following issues. These atomic swap transactions and the data associated with them are all conducted on-chain, resulting in user privacy leakage. In other words, every time a swap occurs, the same hash value appears on both blockchains, only a few blocks apart. This means that an observer can link the currencies involved in the swap by finding the same hash value in blocks close to each other (TimeStamp-wise). When tracking currencies across chains, it is easy to determine the source. Although this analysis does not reveal any relevant identity data, third parties can easily infer the identities of the participants involved.

Cross-chain atomic swaps based on adapter signatures: The second type of swap offered by BasicSwap is called an adapter signature atomic swap, based on a 2020 paper by Monero developer Joël Gugger titled Bitcoin–Monero Cross-chain Atomic Swap . The paper can be said to be an implementation of Lloyd Fourniers 2019 paper One-Time Verifiably Encrypted Signatures, AKA Adaptor Signatures . An adapter signature is an additional signature that is combined with the initial signature to reveal secret data, allowing two parties to reveal two pieces of data to each other at the same time, and is a key component of the scriptless protocol that makes Monero atomic swap pairs possible.

Compared with HTLC atomic swaps, adapter-signature-based atomic swaps have three advantages: First, the adapter-signature swap scheme replaces the on-chain scripts that the secret hash swap relies on, including time locks and hash locks. In other words, the secret and secret hash in the HTLC swap have no direct correspondence in the adapter-signature swap. Therefore, it is called scriptless scripts in the Bitcoin research community. In addition, since such scripts are not involved, the space occupied on the chain is reduced, making adapter-signature-based atomic swaps lighter and cheaper. Finally, HTLC requires each chain to use the same hash value, while the transactions involved in the adapter-signature atomic swap cannot be linked to achieve privacy protection.

This article first introduces the Schnorr/ECDSA adapter signature and the principle of cross-chain atomic swap. Then, it analyzes the random number security issues in the adapter signature and the system heterogeneity and algorithm heterogeneity problems in the cross-chain scenario, and gives solutions. Finally, the adapter signature is extended and applied to realize non-interactive digital asset custody.

2. Adapter Signatures and Cross-Chain Atomic Swaps

2.1 Schnorr Adapter Signatures and Atomic Swaps

2.2 ECDSA Adapter Signature and Atomic Swap

2.2.1 Zero-knowledge proof zk{v | Ṽ = v ᐧ G, V = v ᐧ Y}

3. Security issues and solutions

3.1 Random Number Problems and Solutions

3.1.1 Random number leakage problem

The pre-signature of the Schnorr/ECDSA adapter signature commits to the random number $r$Ȓ = r ᐧ G. In addition, the zero-knowledge proof commits to the random number $v$ as $Ṽ=v ᐧ G, V=v ᐧ Y$. If the random number is leaked, the private key will be leaked.

Specifically, in the Schnorr protocol, if the random number $r$ is leaked, it can be recovered according to the equation

$ŝ = r + c x.$

Calculate the private key $x$.

Similarly, in the ECDSA protocol, if the random number $r$ is leaked, it can be obtained according to the equation

$ŝ = r^{-1 }(hash(m)+R_x x).$

Calculate the private key $x$.

Finally, in the zero-knowledge proof protocol, if the random number $v$ is leaked, it can be obtained according to the equation

$z := v + c r.$

Calculate the random number $r$, and then further calculate the private key $x$ based on the random number $r$. Therefore, the random number must be deleted immediately after use.

3.1.2 Random number reuse problem

For any two cross-chain transactions, if the adapter signature protocol uses the same random number, it will lead to private key leakage. Specifically, in the Schnorr protocol, if the same random number $r$ is used, only $r$ and $x$ are unknown in the following system of equations:

$ŝ_ 1 =r + c_ 1 x, $

$ ŝ_ 2 = r + c_ 2 x. $

Therefore, the system of equations can be solved to obtain the private key $x$.

Similarly, in the ECDSA adapter signature protocol, if the same random number $r$ is used, only $r$ and $x$ are unknown in the following system of equations:

$ ŝ_ 1 = r^{-1 }(hash(m_ 1)+R_x x),$

$ ŝ_ 2 = r^{-1 }(hash(m_ 2)+R_x x).$

Therefore, the system of equations can be solved to obtain the private key $x$.

Finally, in the zero-knowledge proof protocol, if the same random number $v$ is used, only $v$ and $r$ are unknown in the following system of equations:

$z_ 1 = v+c_ 1 r, $

$ z_ 2 = v+c_ 2 r. $

Therefore, the system of equations can be solved to obtain the random number $r$, and then the system of equations can be further solved to obtain the private key $x$.

Similarly, if different users use the same random number, the private key will also be leaked. In other words, two users who use the same random number can solve the equations and obtain each others private key. Therefore, RFC 6979 should be used to solve the random number reuse problem.

3.1.3 Solution: RFC 6979

RFC 6979 specifies a method for generating deterministic digital signatures using DSA and ECDSA that addresses security issues associated with generating a random value k. Traditional DSA and ECDSA signatures rely on a random number k that is randomly generated for each signing operation. If this random number is reused or generated improperly, the security of the private key is compromised. RFC 6979 eliminates the need to generate a random number by deterministically deriving $k$ from the private key and the message to be signed. This ensures that when the same private key is used to sign the same message, the signature is always the same, thereby enhancing reproducibility and predictability. Specifically, the deterministic $k$ is generated by HMAC. The process involves a hash function (such as SHA 256) computing a hash value over the private key, the message, and a counter.

$k = SHA 256(sk, msg, counter).$

In the above equation, for simplicity, only the private key sk, the message msg and the counter counter are hashed. The actual calculation process in RFC 6979 involves more hash calculations. This equation ensures that k is unique for each message, while being reproducible for the same input, and reduces the risk of private key exposure associated with weak or compromised random number generators. Therefore, RFC 6979 provides a powerful framework for deterministic digital signatures using DSA and ECDSA, solves major security issues related to random number generation, and enhances the reliability and predictability of digital signatures. This makes it a valuable standard for applications that require high security and meet strict operational requirements. Schnorr/ECDSA signatures have random number defects that need to be prevented using RFC 6979. Therefore, Schnorr/ECDSA-based adapter signatures also have these problems, and the RFC 6979 specification is also needed to solve these problems.

3.2 Cross-chain scenario problems and solutions

3.2.1 UTXO and Account Model System Heterogeneity Problems and Solutions

As shown in Figure 1, Bitcoin uses the UTXO model and implements native ECDSA signatures based on the Secp 256k1 curve. Bitlayer is an EVM-compatible Bitcoin L2 chain that uses the Secp 256k1 curve and supports native ECDSA signatures. The adapter signature implements the logic required for BTC exchange, while the Bitlayer exchange counterpart is supported by the powerful functions of Ethereum smart contracts.

Cross-chain atomic swaps based on adapter signatures, or at least semi-scriptless adapter signature schemes designed for ECDSA curves, are incompatible with Ethereum. The reason is that Ethereum is an account model, not a UTXO model. Specifically, adapter-signature-based atomic swaps require refund transactions to be pre-signed. However, in the Ethereum system, transactions cannot be pre-signed without knowing the nonce. Therefore, one party can send a transaction between the completion of the pre-signature and the execution of the transaction – which will invalidate the pre-signed transaction (because the nonce has been used and cannot be reused).

Additionally, from a privacy perspective, this means that Bitlayer swaps are more anonymous than HTLCs (the contract is available to both parties in the swap). However, the need for one party to have a public contract makes Bitlayer swaps less anonymous than adapter signatures. On the side without the contract, the swap transaction looks like any other transaction. However, on the side with the EVM contract, the transaction is clearly for an asset swap. Although one party has a public contract, it is impossible to trace it back to another chain, even with sophisticated chain analysis tools.

Figure 1. UTXO and account model heterogeneous system cross-chain atomic swap

Bitlayer currently supports native ECDSA signatures, and can also implement Schnorr signature verification through smart contracts. If native Bitlayer transactions are used, refund transactions in atomic swaps cannot be pre-signed; Bitlayer smart contract transactions are required to implement atomic swaps. However, this process sacrifices privacy, that is, transactions participating in atomic swaps in the Bitlayer system are traceable, but cannot be traced back to transactions in the BTC system. Dapp applications such as Tornado Cash can be designed on the Bitlayer side to provide privacy services for transactions on the Bitlayer side in atomic swaps between BTC and Bitlayer.

3.2.2 Same curve, different algorithm, adapter signature security

As shown in Figure 2, assume that both Bitcoin and Bitlayer use the Secp 256 k 1 curve, but Bitcoin uses Schnorr signatures, while Bitlayer uses ECDSA. In this case, the adapter signature based on Schnorr and ECDSA is provably secure. Assuming that given the ECDSA and Schnorr signature oracles, a simulator S can be constructed to break ECDSA, then given only the ECDSA signature oracle, a simulator S can be constructed to break ECDSA. However, ECDSA is secure. Similarly, assuming that given the ECDSA and Schnorr signature oracles, a simulator S can be constructed to break Schnorr signatures, then given only the ECDSA signature oracle, a simulator S can be constructed to break Schnorr signatures. However, Schnorr signatures are secure. Therefore, in the cross-chain scenario, the adapter signature uses the same curve, but the signature algorithm is different, which is secure. In other words, the adapter signature allows one end to use ECDSA and the other end to use Schnorr signatures.

Figure 2. Same curve, different algorithm, adapter signature

3.2.3 Different curves, unsafe adapter signatures

Assume that Bitcoin uses the Secp 256 k 1 curve and ECDSA signature, while Bitlayer uses the ed 25519 curve and Schnorr signature. In this case, the adapter signature cannot be used. Due to the different curves, the order of the elliptic curve group is different, that is, the modular coefficient is different. When Bob adapts $y$ to the ECDSA signature in the Bitcoin system, he calculates $s:= ŝ+y$. At this time, the value space of $y$ is the scalar space of the Secp 256 k 1 elliptic curve group. Subsequently, Alice needs to use $y$ to perform Schnorr signature on the ed 25519 elliptic curve group. However, the cofactor of the ed 25519 curve is 8, and the modular coefficient is not equal to the modular coefficient of the Secp 256 k 1 elliptic curve group. Therefore, it is unsafe to use $y$ to perform Schnorr signature on the ed 25519 curve.

4. Digital asset custody application

There are three parties involved in digital asset custody: Alice the buyer, Bob the seller, and the custodian. Using adapter signatures enables non-interactive threshold digital asset custody and instantiates a subset of threshold spending strategies without interaction. This subset consists of two types of participants: participants who participate in initialization and participants who do not participate in initialization, the latter of which is called the custodian. The custodian cannot sign arbitrary transactions, but only sends secrets to one of the supported parties.

On the one hand, the custodian can only choose among several fixed settlement transactions and cannot sign a new transaction with one of the other parties. Therefore, this secret release mechanism makes non-interactive threshold custody less flexible than threshold Schnorr signature. On the other hand, a 2-of-3 spending strategy can be set using threshold Schnorr signature. However, the threshold Schnorr signature protocol requires three parties to run a decentralized key generation protocol. Therefore, the asset custody protocol based on adapter signature has the advantage of being non-interactive.

4.1 Non-interactive asset custody based on adapter signature

Figure 3. Non-interactive asset custody based on adapter signature

As shown in Figure 3, Alice and Bob want to create a 2-of-3 transaction output with a stealth policy that includes a custodian. Depending on the condition $c$, Alice or Bob can spend the transaction output. If there is a dispute between Alice and Bob, the custodian (public key is $E$, private key is $e$) decides whether Alice or Bob gets the asset.

• Create an unsigned funding transaction to send BTC to a 2-of-2 MuSig output between Alice and Bob.

• Alice chooses a random value $t_A$ and sends a Schnorr pre-signature $(hat{R}_A,hat{s}_A)$ of a transaction with an adapator of $t_A ᐧ G$ to Bob. This transaction sends the funding output to Bob. Alice also sends Bob a ciphertext that contains a verifiably encrypted $C = Enc(E_c, t_A)$ of the secret $t_A$ and adjusts the escrow public key $E$ to $E_c = E + hash(E, c)G$. During this process, after Bob receives Alices pre-signature, he adds his own signature, which does not satisfy 2-of-2 MuSig and cannot spend the funding output. The funding output can only be spent if Bob knows $t_A$ (provided by the escrow party) or Alice signs a full signature and sends it to Bob.

• Correspondingly, Bob repeats step (2) based on his adaptor secret $t_B$. At this time, the transaction signed by Bob sends the funding output to Alice.

• Alice and Bob both verify the validity of the received ciphertext, confirm that the ciphertext is an encryption of the secret $E_c$, and then sign and broadcast the funding transaction. Verifiable encryption eliminates the need for a custodian to participate in the setup phase and does not require a public contract $c$.

• When there is a dispute, Alice and Bob can send the ciphertext and condition c to the custodian, who can then make a judgment based on the actual situation and use the adjusted private key $e+hash(E, c)$ to decrypt and send $t_A/t_B$ to Bob/Alice.

If there is no dispute, Alice and Bob can spend the 2-of-2 MuSig output as they wish. If there is a dispute, either party can contact the custodian and request its adaptor secret $t_A$ or $t_B$. Then, one of the parties, with the help of the custodian, can complete the adapter signature and broadcast the settlement transaction.

4.2 Verifiable Encryption

Practical Verifiable Encryption and Decryption of Discrete Logarithms cannot be used with Secp 256 k 1 adaptors because they only support verification of specially structured groups.

Currently, there are two promising ways to do verifiable encryption based on Secp 256k1 discrete logarithm, namely Purify and Juggling .

Purify was originally proposed to create a MuSig protocol with a deterministic nonce (DN), requiring each signer to use zero-knowledge proof that their nonce is the result of correctly applying a pseudo-random function (PRF) to the public key and message. Purify PRF can be efficiently implemented in the arithmetic circuit of the Bulletproofs zero-knowledge protocol to create a verifiable encryption scheme for discrete logarithms on Secp 256 k 1. In other words, verifiable encryption is achieved using zkSnark.

Juggling encryption consists of four steps: (1) Divide the discrete logarithm $x$ into multiple segments $x_k$ of length $l$, such that $x = sum _k 2 ^{(k-1)l} x_k$; (2) Use the public key $Y$ to perform ElGamal encryption ${ D_k, E_k} = { x_k ᐧ G + r_k ᐧ Y, r_k ᐧ G }$ on the segment $x_k ᐧ G$; (3) Create a range proof for each $x_k ᐧ G$ to prove that $D_k$ is a Pedersen commitment $x_k ᐧ G + r_k ᐧ Y$, and its value is less than $ 2 ^l$; (4) Use the sigma protocol to prove that ${sum D_k, sum E_k}$ is the correct encryption of $x_k ᐧ G$.

During the decryption process, ${D_k, E_k}$ is decrypted to obtain each $x_k ᐧ G$, and then $x_k$ (with a value range of $[ 0, 2 ^l)$) is exhaustively searched.

Purify needs to execute a PRF in Bulletproofs, which is relatively complicated, while Juggling is theoretically simpler. In addition, the difference between the two in proof size, proof time, and verification time is very small.

5. Conclusion

This article describes the principles of Schnorr/ECDSA adapter signatures and cross-chain atomic swaps in detail. It deeply analyzes the random number leakage and duplication problems of adapter signatures, and proposes to use RFC 6979 to solve these problems. In addition, it analyzes in detail the differences between the blockchains UTXO model and the account model in cross-chain application scenarios, and also considers whether the adapter signature supports different algorithms and curves. Finally, the adapter signature is extended to realize non-interactive digital asset custody, and the involved cryptographic primitives – verifiable encryption are briefly introduced.

references

• Gugger J. Bitcoin-monero cross-chain atomic swap[J]. Cryptology ePrint Archive, 2020.

• Fournier L. One-time verifiably encrypted signatures aka adapter signatures[J]. 2019, 2019.

• https://crypto-in-action.github.io/ecdsa-blockchain-dangers/190816-secp256k1-ecdsa-dangers.pdf

• Pornin T. Deterministic usage of the digital signature algorithm (DSA) and elliptic curve digital signature algorithm (ECDSA)[R]. 2013.

• Komlo C, Goldberg I. FROST: flexible round-optimized Schnorr threshold signatures[C]//Selected Areas in Cryptography: 27th International Conference, Halifax, NS, Canada (Virtual Event), October 21-23, 2020, Revised Selected Papers 27. Springer International Publishing, 2021: 34-65.

• https://github.com/BlockstreamResearch/scriptless-scripts/blob/master/md/NITE.md

• https://particl.news/the-dex-revolution-basicswap-and-private-ethereum-swaps/

• Camenisch J, Shoup V. Practical verifiable encryption and decryption of discrete logarithms[C]//Annual International Cryptology Conference. Berlin, Heidelberg: Springer Berlin Heidelberg, 2003: 126-144.

• Nick J, Ruffing T, Seurin Y, et al. MuSig-DN: Schnorr multi-signatures with verifiably deterministic nonces[C]//Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security. 2020: 1717-1731.

• Shlomovits O, Leiba O. Jugglingswap: scriptless atomic cross-chain swaps[J]. arXiv preprint arXiv: 2007.14423, 2020.

This article is sourced from the internet: Analysis of Bitcoin and Layer2 asset cross-chain technology

Related: Full of cash, take stock of the brilliant achievements of Warren Buffett, the Master of Escape, over the past 20 years

Original title: Buffetts amazing move again! Berkshires cash surpasses Ethereums market value, reviewing his 20-year brilliant record of escaping the top Original author: James, BlockTempo Berkshire Hathaway, an investment company owned by Warren Buffett, released its second-quarter 2024 financial report last Saturday, showing that the company cut its Apple stake by nearly 50% in Q2 and its cash position soared by US$276.9 billion, setting a new historical high. At the time, some analysts believed that Buffetts massive sale of Apple shares was likely due to his pessimism about the stock market and economic prospects, so he chose to go all in with cash. Now, with the collapse of U.S. and Asian stock markets in recent days, the community has once again admired Buffetts acumen in successfully escaping the top. Interestingly,…