One of the most powerful tricks unlocked by Schnorr Signatures is the concept of Adaptor Signatures. They are a quintessential building block of modern Bitcoin scriptless contract design, used in off-chain payment channels, atomic swaps, and Discreet Log Contracts.

Adaptor Signatures have been thoroughly covered in numerous other resources. In my opinion, the best resource for the detail-oriented reader is this paper by Lloyd Fournier, although the original post by Andrew Poelstra is still very interesting. Bitcoin Optech has an article on adaptor signatures as well.

This horse has already been kicked well beyond death. Others have done a much better job than I could in covering the mechanics of adaptor signatures. The unique take I would like to bring to the table are some questions (and solutions) regarding how adaptor signatures work in different edgecases common to modern Bitcoin contract design.

When designing scriptless smart contracts on Bitcoin, perhaps one might wonder:

- How would we use adaptor signatures in aggregated multisignature schemes like MuSig?
- How do we use adaptor signatures to reveal multiple secrets at once instead of only one?
- How can an adaptor signature be meaningfully revoked?

In this article, I’ll give a review of the math governing adaptor signatures, and then use this as a springboard to answer those burning questions. Let’s dive in.

# Review

It wouldn’t be right for me to just assume everyone knows what an adaptor signature is, so I’ll briefly describe how they work mechanically. If you are already familiar with adaptor signature basics, click here to skip ahead.

The ECC math behind adaptor signatures is pretty simple. If you know the difference between a *point* and a *scalar*, you should be fine. If you don’t, then before continuing, I would very much suggest a perusal of my elliptic curve cryptography resources, should you not already happen to be familiar with elliptic curves.

## The VES Concept

An adaptor signature is also known (perhaps more intuitively) as a *verifiably encrypted signature*, or VES. In the context of most modern Bitcoin usage, it is a Schnorr signature made by a given key on a message, but *encrypted* so that it will only be considered valid by other Bitcoin clients if some special secret number is added to the signature.

Signatures can be *encrypted* in this way in an asymmetric fashion, such that one only needs a public key, called an adaptor point, to encrypt a signature.

While the signature is not valid under the traditional Schnorr verification algorithm, it retains the very useful property of still being verifiable, just not as a normal Schnorr signature would be. This allows a party who receives an adaptor signature to be 100% confident that if they receive the decryption key, they’ll have a valid signature.

The signature and the decryption key are also bound together. If one is revealed, so is the other. This is very useful for use cases on Bitcoin and other cryptocurrencies, where signatures tend to be broadcast onto a *public* blockchain.

We’ll be constructing our adaptor signatures using Schnorr signature algorithms. Before continuing, if you’re not already familiar with Schnorr signatures, I would highly recommend reading my article on Schnorr which explains how Schnorr signatures are created normally.

## Procedure

- Let
be the secp256k1 curve generator point. - Let
be the order of the curve. - Let
be the set of integers mod . - Let
denote sampling a random scalar from . - Let
be a cryptographically secure hash function, specifically used for computing Schnorr signature hashes. - Let
be the message to be signed. - Let
be the private key of the signer, Alice. - Let
be Alice’s public key. - Let
be the adaptor point, AKA the encryption key which Alice will use to lock her signature. - Let
be the discrete log (secret key) of , such that . **Alice does not need to know**.

Alice wants to create a verifiably encrypted signature (VES) on some message

To create an adaptor signature, Alice follows the same the protocol as to create a normal Schnorr Signature, except she modifies her nonce so that the signature won’t be considered valid by itself.

She starts by sampling a random nonce

However, unlike a traditional Schnorr signature, we will denote the public nonce point as *encrypted*.

Next, Alice computes the true *adapted* public nonce point, by adding the adaptor point

Alice computes the encrypted Schnorr signature by committing the challenge *adapted public nonce*.

Alice can now distribute the VES, AKA the adaptor signature,

## Exploration

By setting

To see why, try to verify the encrypted signature

But Alice computed her challenge *adapted public nonce*

This verification will fail because

Okay, what if we add *public key* it should not be hard to learn. Will the signature verify correctly then?

This does not pass verification either, but this time we observe how we could adjust

We can denote the correct *adapted* signature as

## Verification

Say Alice creates a Bitcoin transaction with an adaptor signature

However, what if Bob does *not yet know* *verify* that

If given the adaptor point

If this check passes, Bob is certain that upon learning *adapt* Alice’s signature

## Revealing

Adaptor signatures have a property which is very useful for any public-ledger cryptocurrency like Bitcoin. If a decrypted signatures *encrypted* signature

This helpful property is exploited heavily in Bitcoin scriptless smart contract design. I won’t go into any examples for now as I believe there are plenty of other resources on the subject. Check out the Bitcoin Optech article for more relevant links.

## Deferred Encryption

It is also possible to encrypt a valid Schnorr signature

If we know

# Multisignature

How do adaptor signatures work for multisignature contexts?

Say Alice and Bob have some funds locked in a simple 2-of-2 multisignature contract which is spendable if Alice and Bob both sign the transaction. Alice knows the adaptor point

In this section we’ll examine how to use adaptor signatures to address this scenario in both legacy and modern multisignature protocols.

## On-Chain (legacy)

In legacy Bitcoin contracts, it was common practice to use on-chain multisig script opcodes, such as `OP_CHECKMULTISIG`

. Anyone claiming the contract would submit a threshold number of ECDSA signatures from a selection of keys hardcoded into the locking script.

To use an adaptor signature in our example scenario context is relatively straightforward. Alice simply signs whatever transaction she wants to lock behind the adaptor point

If Bob uses

## Off-Chain (modern)

With support for Schnorr signatures now active in Bitcoin’s Mainnet for several years, this practice is being phased out in favor of off-chain aggregated multisignature protocols like MuSig and FROST. Signatures created by aggregation appear to be normal Schnorr signatures: completely indistinct from signatures created by solo-signers. This is a huge boost to user privacy, because it makes all transactions more fungible. One cannot tell from simply observing the public blockchain whether a Schnorr signature was the product of aggregating hundreds of signatures from disparate parties, or the signature of a single person.

But if her signature is aggregated with Bob’s, how can Alice learn

### Example

Let’s walk through an example signing session with MuSig1 to find out how an adaptor signature is created with MuSig. If you’re not already familiar with MuSig, check out my article to learn how and why this approach works.

- Let
be Bob’s secret key, with corresponding public key .

- Alice and Bob compute their aggregated public key
.

- Alice and Bob sample their random nonces
and .

- Alice and Bob compute their public nonces
and .

- Alice and Bob send each other their nonce commitments
and

Alice and Bob agree on a message

to sign. Once they have received each other’s commitments, Alice and Bob send each other their nonces

and .

**ADAPTOR STUFF STARTS HERE.**

- Alice and Bob can independently compute the aggregated encrypted public nonce
, and the *adapted*public nonce.

- Alice and Bob each use the adapted public nonce to independently compute the challenge hash
.

- Alice and Bob both compute their partial signatures
and on the message.

- Each co-signer can now (cautiously) share their partial signatures and aggregate them to produce the aggregated encrypted signature scalar
.

The final aggregated adaptor signature can now be computed as

The adapted signature

The encrypted signature

### Free Option Problem

**Care must be taken at the final step.** Whichever party shares their partial signature first might *lose the ability to learn the adaptor secret *

For example if Alice were to send

Bob can publish *Alice never learned Bob’s partial signature * and so cannot compute

In an adversarial multisignature scenario where one party - Bob, in our example - already knows, or is expected to learn the adaptor secret

Bob should have no problem doing this. If Bob generated

If both parties expect to learn

## Generalizing

The same essential principle of this approach holds for any other aggregated multisignature schemes like MuSig2 or FROST: We follow the same steps as the normal protocol, but *adapt* the aggregated nonce *before* hashing it. Everyone in the signing group who does this will generate partial signatures which, once aggregated, will only be valid if the adaptor secret

## Cooperation

If some in the signing group are unaware of the adaptor point *are* using the adaptor point

It is important that every co-signer cooperates and is aware of the same adaptor point

Technically it is possible for one co-signer to surreptitiously adapt their public nonce before committing to and sharing it with other co-signers. In the above example, Alice could compute her public nonce as

However, if other co-signers are not aware of this, they will lay blame on the individual who did so without the consent of the rest of the signing cohort. Alice’s partial signature

Here we see there is a slight disadvantage to using an aggregated multisignature approach with adaptor signatures: * We require interactive cooperation from other signers* to be able to construct valid adaptor signatures. Otherwise, the construction is quite simple.

# Multi-Adaptors

A single adaptor signature usually corresponds to a single adaptor point and secret pair

But what if we want a single adaptor signature to require knowledge of *two* separate secrets *either* secret to be sufficient?

## The “And” Case

Let’s consider a case where Bob knows two secrets

This approach is simple: Merely aggregate the two secrets together and use the sum

Alice and Bob can then construct an adaptor signature with the adaptor point

This is a one-way trick though. When the adapted signature scalar

Perhaps we *want* the adaptor signature bearer to learn both *hint* to let them compute

Yes we can!

## The “Or” Case

As the adaptor signature bearer, Alice know the relationship *would* be if she had a second equation, which is what Bob can give to her.

Although, by giving this hint, Bob must relax his earlier requirement that the Alice would need *both* secrets *either* secret

Bob generates a *hint*

When Bob sends Alice his partial signature, Bob can pass the hint

Alice receives

Such a *hint* is a special bonus for Alice. It means she now only needs to know *one* of the two secrets

Let’s say Alice learns

The same is true if Alice learns

By extension, Alice also learns both component secrets

### Exclusivity

If we wanted to adjust our construction so that *either* secret could decrypt the signature, but only *one* of them is revealed by learning

## Generalizing

The above methods can be generalized to any number of secrets

The “And” case is straightforward: sum all the component adaptor secrets together to form the aggregated adaptor secret

The “Or” case requires more thought. If we have *hints* which can be used to systematically reconstruct every adaptor secret, including the sum

# Revocation

Consider a situation where Alice and Bob have both jointly signed a transaction, and that signature is encrypted with the point *not* broadcast the transaction?

As broadcasting the transaction would reveal *publication secret* in these contexts, because it is revealed by *publishing* a specific transaction.

A revocation key in combination with its corresponding publication secret provides compact proof that someone published a transaction which they claimed they would never publish. In payment channels, peers build their transactions with *punishment paths* which allow a wronged party to sweep the money of the misbehaving peer, if they can provide such proof.

## Key Exposure Threat

But what about situations where Bob has no money on the line in the first place? Bob cannot be punished financially if he has nothing available to forfeit.

We can still punish Bob if he commits to exposing something he doesn’t want to be public knowledge: his *private key.*

There are numerous ways to enforce exposure of a private key, and not all of them depend on adaptor signatures. I’ll briefly cover a few.

### Revealing the Nonce

This method is not directly related to adaptor signatures, but I figured I should mention it anyway.

- Let
be a private key. - Let
be a private random nonce. - Let
be the public nonce . - Let
be the public key . - Let
be some challenge hash on a message .

Consider the simple Schnorr signature

If we are given *and* the secret nonce

Clearly then, if the private key

Suppose we are given the public nonce *in advance,* and told to expect either:

- A valid signature scalar
, such that , OR - The secret nonce
, such that .

We could be reasonably confident (if the owner of *one* of those values from the owner of the key

We can use this to revoke an adaptor signature.

Suppose Bob gives Alice an adaptor signature

Alice knows the *true* public nonce will be

If Bob reveals the value *never* reveal the signature

_{If Bob reveals the signature :}

_{If Bob reveals the adaptor secret :}

Given

### Secret Hint

The above method hints toward a more general approach. We can directly link knowledge of the adaptor secret

Let *hint* towards

Bob computes a hint

Alice can verify the hint if she knows the public key of the secret,

Alice then knows if she can learn

## Committing to a Key

Perhaps Bob can convince us that he’ll forfeit a private key if he misbehaves. But private keys are just random numbers, and there are absurdly many of them. Bob can generate new ones on demand at any time. Bob’s commitment to expose

This leads us to a new question: How can Bob *meaningfully* convince ALice that this key

Most commonly, *financial commitment* is the de-facto standard. Bob must intentionally place himself at risk of losing money if

Bob might commit to forfeit money directly to Alice, or Bob might commit to *burning* funds if he misbehaves. Although direct compensation to Alice would be preferable, the threat of burning funds is better than no threat at all, and can sometimes be more practical to implement.

## Conclusion

Adaptor signatures are a small and simple tool, but they are incredibly flexible.

I believe we’re only just seeing the tip of the iceberg of adaptor signature use cases.