Schnorr Adaptor Signature

Table of contents

What it is

An adaptor signature is a modified signature that only verifies if it’s updated by applying a secret value. Once the signature is updated, the verification succeeds which also results in the secret value being publicly visible.

Adaptor signatures are oftentimes used in Blockchain protocols to implement ”Scriptless Scripts” which are rules that can solely be implemented and enforced with digital signatures.

One such implementation is an atomic swap in which two parties who don’t trust each other want to exchange pre-determined values of currency with one another.

We’ll be using the example of an atomic swap throughout this post to explain how adaptor signatures work. However it’s important to note that atomic swaps are just one implementation in which adaptor signatures can be used. Adaptor signatures are a generic construction which can be used to solve problems outside the Cryptocurrency realm.

Before diving straight into specifics we should briefly talk about the problem we’re trying to solve with adaptor signatures.

In our case we have two actors, Alice and Bob. Both want to transact with each other and both have agreed on the amount of currency they want to exchange. The problem is that Alice only wants to pay Bob the agreed amount if she knows for sure that Bob pays her the correct amount.

While this problem could be solved via a trusted third party (an escrow) that custodies the funds and ensures that both parties transfer the agreed on amount to each other, we can use adaptor signatures to sign transactions that enforce this contractual agreement without any dependency on a trusted entity.

How it works

Given that this post describes adaptor signatures based on Schnorr Signatures, it’s useful to have a basic understanding of those before continuing.

We’ll be working with an Elliptic Curve $E$ that is of order $q$ and has a generator $G$. All calculations are done $\bmod\ q$ if not stated otherwise.

Note: If not stated otherwise, we’ll be using the subscript $_1$ for parameters generated by Alice and the subscript $_2$ for parameters generated by Bob.

Setup

The first step is the same as with a regular Schnorr Signature. Alice and Bob both generate their private keys $a$ and $b$ by sampling a random value from $\mathbb{Z}_q$. Next up, they compute their public keys by multiplying their private keys with the generator $G$.

In addition to that, Alice and Bob both separately generate their random secret nonce value $r_1$ and $r_2$ as well as its public derivative $R_1$ and $R_2$:

Both then share their public keys $A$ and $B$ as well as their public values $R_1$ and $R_2$ with each other.

Adaptor Generation (Alice)

In this example, Alice goes first and wants to send Bob a signature over a transaction $m_1$ that shows him, that Alice will transfer the correct amount of currency to him.

Remember that in a regular Schnorr Signature Alice would commit to her nonce $R_1$, her public key $A$ and the transaction $m_1$ by computing $c_1 = H(R_1 \mathbin\Vert A \mathbin\Vert m_1)$. She’d then calculate $s_1 = r_1 + c_1a$ which results in the signature tuple $(s_1, R_1)$.

The problem is that this is already a valid signature which won’t just show Bob that he gets paid but will pay him if broadcasted given that $s_1G \overset{?}{=} R_1 + c_1A$ is true:

Is there a way Alice can modify the signature such that it still shows Bob that he gets paid but doesn’t allow him to simply broadcast it to get paid immediately?

As it turns out, there’s a way to modify the signature such that the intent (Alice pays Bob amount $X$) is preserved and visible while requiring a secret value to turn the modified signature into one that verifies successfully (and therefore pays Bob).

To do so, Alice generates a secret value $t$ by randomly sampling a value from $\mathbb{Z}_q$. She also derives it’s public value $T$ by multiplying $t$ with the generator $G$.

One can think of this as just another key pair that Alice generates. Given that $t$ will be used as another private key, she also keeps that value to herself and doesn’t share it with Bob.

Next up, Alice follows the Schnorr Signature protocol and generates $c_1$ and $s_1'$. However she deviates slightly from the protocol by adding $t$ to $r_1$ and $T$ to $R_1$ respectively.

She also calculates $s_1$ which removes the secret value $t$ from $s_1'$:

Note that given this modification, a valid signature tuple would be $(s_1 + t, R_1 + T)$.

Alice now shares $s_1$ and $T$ with Bob.

Adaptor Verification

Upon receiving $s_1$ and $T$ Bob can check that Alice generated a modified signature that will pay him.

To do so he calculates $c_1 = H(R_1 + T \mathbin\Vert A \mathbin\Vert m_1)$ and checks $s_1G \overset{?}{=} R_1 + c_1A$:

Adaptor Generation (Bob)

Note that while Bob can verify that the adapted signature he received from Alice is correct, he can’t publish it to get paid as the $s_1$ value he got from Alice doesn’t include her secret value $t$ which is necessary to turn the adapted signature into a valid one ($t$ is necessary because Alice committed to both $R_1$ and $T$ in $c_1$ by calculating $R_1 + T$. More on that later).

Given that Bob has access to the public value $T$ that is linked to the secret $t$ that only Alice knows, he can create another, adapted signature with the help of $T$ over a transaction $m_2$ that pays Alice.

To do so, Bob calculates $c_2$ and $s_2$:

Bob then sends $s_2$ to Alice.

Signature Generation (Alice)

For Alice to get paid, she now needs to use Bob’s adapted signature and her secret value $t$ to turn it into a signature that ensures that $(s_2 + t)G \overset{?}{=} R_2 + T + c_2B$.

Once the signature is validated on-chain Bob can learn $t$.

Signature Generation (Bob)

By observing the Blockchain and therefore learning Alice’s published signature $s_2 + t$ that pays her, Bob can extract the secret value $t$ by calculating $t = (\cancel{s_2} + t) - \cancel{s_2}$.

Equipped with the value $t$, Bob can now update the adapted signature he got from Alice to turn it into one that verifies by doing the same Alice did:

That way Bob get’s paid by Alice as well.

Why it works

The key ingredient that turns a regular Schnorr Signature into an adaptor signature is the usage of the secret $t$ and its public value $T$ in the calculation of $c$ and $s$.

To see the difference, let’s quickly recap how a regular Schnorr Signature works.

Given a secret key $x$ with its corresponding public key $X$, a random nonce $r$ with its corresponding value $R$ and a message $m$ we can generate a signature by calculating $c$ and $s$ as follows:

Verification is done by checking if $sG \overset{?}{=} R + cX$:

To turn a regular Schnorr Signature into an adaptor signature one needs to include the secret $t$ and its public value $T$ in a way that the signature is only valid if both values are known.

To do so, the calculation of $c$ is updated to add $T$ to $R$:

Trying to verify the signature as before would fail because we haven’t used the secret value $t$ yet:

However by knowing $t$ we can add it to $s$ to ensure that the signature verification succeeds:

References

The following resources have been invaluable for me to learn the concepts discussed in this article.

You should definitely give them a read if you want to dive deeper into the topic.

• Wikipedia - Schnorr Signature
• Andrew Poelstra - Lightning in Scriptless Scripts
• Bitcoin Optech - Adaptor Signatures
• Conduition - A Dive Into the Math Behind Bitcoin Schnorr Signatures
• Conduition - The Riddles of Adaptor Signatures
• YouTube - Generalized Channels from Limited Blockchain Scripts and Adaptor Signatures
• Ichiro Kuwahara - Adaptor Signature - Schnorr Signature and ECDSA
• Ichiro Kuwahara - Adaptor Signature on Schnorr - Cross Chain Atomic Swaps
• Ichiro Kuwahara - Adaptor Signature on Schnorr - Lightning Network