The Riddles of Adaptor Signatures

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 . She wants the signature to only be usable by someone who knows (the discrete log of the adaptor point ). Maybe Alice knows herself, or maybe not - depends on the use-case.

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 , with the little hat signifying that this public nonce is 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 to the adapted public nonce.

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

Exploration

By setting , Alice locks the signature scalar to , such that it will only be canonically valid if we also add to it. Nobody will be able to use the signature until they know .

To see why, try to verify the encrypted signature on the public key using the standard Schnorr signature verification equation.

But Alice computed her challenge using the adapted public nonce , not the encrypted nonce .

This verification will fail because , so .

Okay, what if we add to the encrypted nonce , and try to verify the signature as ? Since is a 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 to make the signature valid. Alice computed as , but the right side of the equation clearly expects to be included. A valid signature scalar should thus be . This would pass verification, combined with the adapted public nonce .

We can denote the correct adapted signature as . This signature appears to any outside observer to be a normal, valid, Schnorr signature.

Verification

Say Alice creates a Bitcoin transaction with an adaptor signature and gives it to Bob. Bob will be able to use to publish the transaction if he knows , and can compute .

However, what if Bob does not yet know , but can expect to learn it in the future? might only be revealed through some future event. Bob must be able to verify that will become usable if he learns . This is where the “verifiably” in “verifiably encrypted signatures” comes in.

If given the adaptor point , Bob can verify is a valid adaptor signature from Alice’s key on the message .

If this check passes, Bob is certain that upon learning , he can adapt Alice’s signature into a valid signature .

Revealing

Adaptor signatures have a property which is very useful for any public-ledger cryptocurrency like Bitcoin. If a decrypted signatures is revealed to someone who knows the encrypted signature such as Alice, that party can compute the adaptor secret .

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 after the fact, without access to the private key which created it, as long as we know the adaptor secret .

If we know , we can simply reverse the decryption process to compute an encrypted signature.

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 and wants to give Bob an adaptor signature which he can use to claim the funds if Bob learns the adaptor secret . If Bob does use to decrypt the signature and publish the transaction, Alice wants to be able to also learn .

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 using the adaptor-signing protocol I described above. Alice forwards this signature to Bob and she’s done.

If Bob uses to decrypt the signature and publish the transaction, Alice can easily identify it on the blockchain and learn from her decrypted signature, as the adapted signature scalar will be included right there plain-as-day in the spending script.

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 when Bob reveals the whole signature?

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 .

1. Alice and Bob compute their aggregated public key .

2. Alice and Bob sample their random nonces and .

3. Alice and Bob compute their public nonces and .

4. Alice and Bob send each other their nonce commitments and

5. Alice and Bob agree on a message to sign.

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

ADAPTOR STUFF STARTS HERE.

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

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

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

10. 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 , which is effectively the same as any other adaptor signature from a solo-signer. Once Bob knows , he can adapt it by computing

The adapted signature will verify correctly, just as with a regular MuSig signature.

The encrypted signature can even be independently verified by someone who knows .

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 first to Bob, then Bob might take Alice’s partial signature and refuse to give his own to Alice. Bob could wait to learn and once he does, he can use it to compute the adapted signature scalar .

Bob can publish to the blockchain, but upon seeing , Alice won’t be able to compute from it, because 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 first, it is crucial for his counterparty Alice to enforce that Bob must give his partial signature first.

Bob should have no problem doing this. If Bob generated , he can be sure Alice does not yet know , and thus she cannot adapt his signature to make use of it on-chain without further help from Bob. Similarly, if Bob expects to learn the adaptor secret through a private channel which Alice cannot eavesdrop on, he can be reasonably confident his partial signature will not be of material benefit to Alice without Bob’s cooperation.

If both parties expect to learn simultaneously at the same time in the future, such as through a Discreet Log Contract Oracle, then the order of signature sharing is not as important.

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 with the adaptor point 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 is added to the final aggregated signature.

Cooperation

If some in the signing group are unaware of the adaptor point and do not cooperate to construct the aggregated adaptor signature, they will instead compute the challenge hash as . Signatures created in this way will be just like a standard (non-adaptor) partial signature, and won’t be compatible with the partial signatures created by those who are using the adaptor point .

It is important that every co-signer cooperates and is aware of the same adaptor point which should be used to adapt the aggregated nonce.

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 without Bob knowing. Alice and Bob’s partial signatures would then sum to the same aggregated adaptor signature .

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 will not be considered valid by the rest of the group, who may not be aware of the adaptor point .

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 . Revealing the adaptor secret reveals the signature scalar , and vice-versa.

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

The “And” Case

Let’s consider a case where Bob knows two secrets and , and wants to give Alice an adaptor signature which requires her to know both AND to decrypt Bob’s signature.

This approach is simple: Merely aggregate the two secrets together and use the sum as the adaptor secret.

Alice and Bob can then construct an adaptor signature with the adaptor point . Alice would need to know both and to compute and thus decrypt the signature successfully. Alice could verify that , confirming that learning the secrets and would give her , and thus the means to decrypt the signature. If and are unrelated random secrets, then learning or individually would reveal no information about the sum adaptor secret .

This is a one-way trick though. When the adapted signature scalar is revealed, an observer who knows only the encrypted signature would learn only , without learning anything about its composite values or .

Perhaps we want the adaptor signature bearer to learn both and when the decrypted signature is broadcast. Can we give the adaptor signature holder some extra hint to let them compute and ?

Yes we can!

The “Or” Case

As the adaptor signature bearer, Alice know the relationship , but does not know or . This gives her one equation with two unknowns. As is, this is not solvable, but it 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 and to recover the adaptor secret . He must instead allow either secret OR to be sufficient to recover .

Bob generates a hint which he can give to Alice. He computes it as the difference between and .

When Bob sends Alice his partial signature, Bob can pass the hint to give Alice a second equation to work with.

Alice receives and can verify Bob computed it correctly.

Such a hint is a special bonus for Alice. It means she now only needs to know one of the two secrets OR to decrypt an adaptor signature encrypted with .

Let’s say Alice learns . She can use the hint to compute the full adaptor secret by solving a system of equations.

The same is true if Alice learns .

By extension, Alice also learns both component secrets and if either one is revealed.

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 , we can simply create two entirely separate adaptor signatures - one for either adaptor secret - with distinct nonces on each.

Generalizing

The above methods can be generalized to any number of secrets , not just two.

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 secrets, any of which should suffice to decrypt a signature, but all of which must be revealed if the signature is revealed, then we must supply 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 . Bob knows the adaptor secret . Alice is aware that Bob knows and could broadcast the transaction any time he wishes. Is there anything Bob can do to convince Alice that he will not broadcast the transaction?

As broadcasting the transaction would reveal , Bob could give Alice some way of punishing him if he reveals . This is a common practice in some newer off-chain payment channel designs, where a channel peer can revoke old channel state transactions by revealing a revocation key. The adaptor secret is sometimes referred to as a 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 , where .

If we are given and the secret nonce , we can compute the key which made the signature.

Clearly then, if the private key is secret and sensitive, its bearer will not want to reveal both and , because knowing both is equivalent to knowing 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 cares about their private key’s secrecy) that we will only learn 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 to which he knows the adaptor secret .

Alice knows the true public nonce will be , where is the public adaptor point .

If Bob reveals the value , then Alice can be confident that Bob will never reveal the signature OR the adaptor secret . Alice learns nothing about Bob’s private key or adaptor secret by learning , except that if we reveal or , then either would in turn reveal our private key .

_{If Bob reveals the signature :}

_{If Bob reveals the adaptor secret :}

Given , Alice can easily verify its authenticity against the adaptor signature.

Secret Hint

The above method hints toward a more general approach. We can directly link knowledge of the adaptor secret to knowledge of a private key, or of any other arbitrary secret for that matter.

Let be that arbitrary secret. Bob can give Alice a hint towards , as a way of committing the adaptor secret to also reveal . If Alice learns , she learns , and vice-versa.

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 , either by Bob broadcasting a transaction and revealing through adaptor signatures, or entirely independently, then Alice will also 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 is hollow unless he can also convince Alice that he has something to lose by exposing it.

This leads us to a new question: How can Bob meaningfully convince ALice that this key is valuable to him, and that he doesn’t want to expose it? This is a complex topic, worth discussing in a separate article.

Most commonly, financial commitment is the de-facto standard. Bob must intentionally place himself at risk of losing money if is exposed. This will help convince Alice that, provided Bob is a rational actor, he won’t attempt to cheat.

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.

Sources

• One-Time Verifiably Encrypted Signatures AKA Adaptor Signatures - Lloyd Fournier
• Generalized Channels from Limited Blockchain Scripts and Adaptor Signatures - Aumayr et al
• Lightning in Scriptless Scripts - Andrew Poelstra