<p>To perform an atomic swap, both assets need to be locked up to ensure the eponymous atomic execution of both payments or neither. Traditionally, this uses a complex output script that has two outcomes. On both chains, funds are locked such that either the receiving party signs with their private key while also revealing a preimage, or the original owner can take back the funds themselves after a timeout has passed by signing with their private key. This way, whenever one of the two parties reveals the preimage to take the funds, the other party can immediately take the funds on the other network. The drawbacks of this approach are that the two transactions are easy to link due to featuring the same lock hash, that the script is fairly heavy and that everyone sees what is going on.</p>

<p>Atomic swaps can be improved with Schnorr signatures both regarding their privacy and their blockchain footprint.
Instead of the previously described output script, the funds are locked to a 2-of-2 multisig address with a timeout condition to return the funds. To ensure atomicity, one of the two parties creates transactions on both networks that make use of "adaptor signatures". These transactions are fully valid except that the creating party's signature is damaged by a linear offset. The creating party provides a zero-knowledge proof to the counterparty that they are both damaged by the same value and that they otherwise would be valid. After the counterparty also signs both transactions, either party can fix the damage on one of the signatures to make the transaction valid, revealing to the other party the original offset and thus enabling them to fix the other.</p>

<p>Due to Schnorr's compact multisignature the 2-of-2 multisig address with the timeout fallback looks like a standard 1-of-1 Pay-to-Schnorr-public-key-hash address, and the 2-of-2 transaction spending from it also looks indistinguishable from any other standard transaction. The transactions are not visibly linked, third parties cannot tell which public keys were involved, and since it would be trivial to recreate the damage after having the two valid signatures, it's difficult for either party to prove that this exchange ever took place.</p>

<p>In result, Schnorr allows to perform atomic swaps by creating two standard transactions on each network, whereas previous atomic swap constructions made use of 2-of-2 multisig addresses and HTLC contracts which were much heavier and easily distinguishable.</p>

<p>For this to work, at least one of the two networks has to support Schnorr signatures (preferably both). </p>

<p><sup>H/T Pieter for feedback and for linking me to this more comprehensive writeup by Kanzure: <a href="http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/" rel="nofollow noreferrer">http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/</a></sup></p>

CC BY-SA 4.0
2018-07-13T23:35:08.030Z
Technical nit: this has nothing to do with signature aggregation, but with Schnorr multisignatures. The distinction is that signature aggregation is about combining multiple signatures on distinct messages (and in Bitcoin context refers to aggregating across different inputs), and multisignatures is about multiple participants signing the same message. In fact, the usage of (cross-input) signature aggregation conflicts with the adaptor signature approach you're explaining here.
Pieter Wuille
CC BY-SA 4.0
2018-07-14T00:04:30.883Z
@PieterWuille: I've amended my posts.
Murch
CC BY-SA 4.0
2018-07-13T23:15:04.480Z
2018-07-16T16:39:57.223Z
2018-07-16T16:39:57.223Z
Murch
<p>A slightly different take: if you have Schnorr signatures, then you can build payment channels based on aggregated multisignatures. Such payment channels look indistinguishable from regular p2pkh on the blockchain.</p>

<p>With any payment channel, you can <a href="https://gist.github.com/markblundeberg/ee027cb12b1e882145bebcd658a1630f" rel="nofollow noreferrer">hide hash-locked atomic swaps inside</a>. In contrast to the traditional on-chain atomic swaps, such in-channel atomic swaps are anyway faster to set up, more secure, and support high frequency trading between the parties. In the case of a cooperative closure, the HTLC secret never hits the blockchain and it looks like a regular payment channel. And with schnorr, as just mentioned, a regular payment channel looks like any other transaction. So you get a hash-locked atomic swap that is "totally invisible", or at least looks unremarkable.</p>

<p>Since this uses entirely standard hash lock techniques, it lets you do trading even when the two blockchains don't use the same elliptic curve (in contrast to adaptors).</p>

CC BY-SA 4.0
2019-01-08T06:21:02.837Z
2019-01-08T06:21:02.837Z
Mark Lundeberg
<p>How does the availability of Schnorr signatures improve the ability to perform cross-chain atomic swaps?</p>

<schnorr-signatures><atomic-swap>
How is the construction of atomic swaps improved by Schnorr?
Murch
# How is the construction of atomic swaps improved by Schnorr?

(Asked by: username_0 on 2018-07-13)

How does the availability of Schnorr signatures improve the ability to perform cross-chain atomic swaps?

**Tags:** schnorr-signatures, atomic-swap


---

## 2 answers

### Answer by username_0 on 2018-07-13. Score: 5

To perform an atomic swap, both assets need to be locked up to ensure the eponymous atomic execution of both payments or neither. Traditionally, this uses a complex output script that has two outcomes. On both chains, funds are locked such that either the receiving party signs with their private key while also revealing a preimage, or the original owner can take back the funds themselves after a timeout has passed by signing with their private key. This way, whenever one of the two parties reveals the preimage to take the funds, the other party can immediately take the funds on the other network. The drawbacks of this approach are that the two transactions are easy to link due to featuring the same lock hash, that the script is fairly heavy and that everyone sees what is going on.

Atomic swaps can be improved with Schnorr signatures both regarding their privacy and their blockchain footprint.
Instead of the previously described output script, the funds are locked to a 2-of-2 multisig address with a timeout condition to return the funds. To ensure atomicity, one of the two parties creates transactions on both networks that make use of "adaptor signatures". These transactions are fully valid except that the creating party's signature is damaged by a linear offset. The creating party provides a zero-knowledge proof to the counterparty that they are both damaged by the same value and that they otherwise would be valid. After the counterparty also signs both transactions, either party can fix the damage on one of the signatures to make the transaction valid, revealing to the other party the original offset and thus enabling them to fix the other.

Due to Schnorr's compact multisignature the 2-of-2 multisig address with the timeout fallback looks like a standard 1-of-1 Pay-to-Schnorr-public-key-hash address, and the 2-of-2 transaction spending from it also looks indistinguishable from any other standard transaction. The transactions are not visibly linked, third parties cannot tell which public keys were involved, and since it would be trivial to recreate the damage after having the two valid signatures, it's difficult for either party to prove that this exchange ever took place.

In result, Schnorr allows to perform atomic swaps by creating two standard transactions on each network, whereas previous atomic swap constructions made use of 2-of-2 multisig addresses and HTLC contracts which were much heavier and easily distinguishable.

For this to work, at least one of the two networks has to support Schnorr signatures (preferably both).

H/T username_1 for feedback and for linking me to this more comprehensive writeup by Kanzure: <http://diyhpl.us/wiki/transcripts/layer2-summit/2018/scriptless-scripts/>

> **Comments:**
> **username_1**: Technical nit: this has nothing to do with signature aggregation, but with Schnorr multisignatures. The distinction is that signature aggregation is about combining multiple signatures on distinct messages (and in Bitcoin context refers to aggregating across different inputs), and multisignatures is about multiple participants signing the same message. In fact, the usage of (cross-input) signature aggregation conflicts with the adaptor signature approach you're explaining here.  
> **username_0**: @username_1: I've amended my posts.  

---

### Answer by username_2 on 2019-01-08. Score: 2

A slightly different take: if you have Schnorr signatures, then you can build payment channels based on aggregated multisignatures. Such payment channels look indistinguishable from regular p2pkh on the blockchain.

With any payment channel, you can [hide hash-locked atomic swaps inside](https://gist.github.com/markblundeberg/ee027cb12b1e882145bebcd658a1630f). In contrast to the traditional on-chain atomic swaps, such in-channel atomic swaps are anyway faster to set up, more secure, and support high frequency trading between the parties. In the case of a cooperative closure, the HTLC secret never hits the blockchain and it looks like a regular payment channel. And with schnorr, as just mentioned, a regular payment channel looks like any other transaction. So you get a hash-locked atomic swap that is "totally invisible", or at least looks unremarkable.

Since this uses entirely standard hash lock techniques, it lets you do trading even when the two blockchains don't use the same elliptic curve (in contrast to adaptors).


---

