<blockquote>
<p>How do BLS signatures (or other pairing-based schemes) compare to Schnorr signatures in terms of cryptographic assumptions?</p>
</blockquote>
<p>BLS needs a pairing-compatible elliptic curve, which imposes additional structure on the curve. The elliptic curve used for cryptography in Bitcoin today (both for ECDSA and Schnorr), secp256k1, is not pairing-compatible.</p>
<p>This additional structure may be concerning. See it this way: normally when picking an elliptic curve for cryptographic purposes, there are a number of &quot;gotchas&quot; to avoid - properties that, if present, are either known or suspected to aid attackers to break its security. One of those properties is having a &quot;low embedding degree&quot;:</p>
<ul>
<li>A very low embedding degree (say, up to 3) gives a trivial way to compute private keys from public keys.</li>
<li>A sufficiently high embedding degree (say, 10 or more) is likely not a problem, in the sense that no way to exploit that is known.</li>
<li>A very high embedding degree (similar in magnitude to the order of the group itself) is almost certainly unexploitable (as otherwise every elliptic curve would be vulnerable).</li>
</ul>
<p>secp256k1 has embedding degree 19298681539552699237261830834781317975472927379845817397100860523586360249056 (exactly 1/6 of the number of points on the curve).</p>
<p>Pairing-compatible curves however <em>need</em> a relatively small embedding degree; small enough to be tractable for computation (because signature verification actually involves computing this embedding), but also large enough to not result in making private keys easy to find. Currently popular pairing curves use embedding degree 12.</p>
<p>So, BLS requires curves that are from a traditional perspective &quot;risky&quot;. It's not that this risk is unmanageable: obviously actual curves are constructed in such a way that there is no way to exploit this structure, but it is walking a fine line. The concern is that perhaps in the future other ways are discovered to exploit it. And us having selected parameters such that all known attacks fail isn't sufficient when new attacks get discovered.</p>
<p>Of course, that's not fundamentally different from other elliptic curve security, or cryptographic security in general. We <em>always</em> select parameters/curves/... in such a way that all known ways of attacking fail, and when new attacks get discovered, those parameters may not be sufficient anymore. But in the case of generic ECC, that's just one set of attacks to avoid. In the case of pairing-based cryptography, there is an entirely separate added newer set of attacks to worry about as well.</p>
<p>As for what this means for Bitcoin: I don't know. The question is just whether the Bitcoin community, as a whole, is ok with this added set of security assumptions that BLS would bring. And it isn't sufficient that it's optional; if (hypothetically) I personally would be uncomfortable with BLS's security outlook, I wouldn't want a large fraction of the BTC supply to become subject to it, as a break of pairing-based cryptography may threaten the currency's value overall, including my non-BLS-encumbered coins. So I believe this means the bar for adding new security assumptions is fairly high.</p>
<blockquote>
<p>Is it faster to verify, say 100 (non-interactively) aggregated BLS signatures than 100 aggregated Schnorr signatures?</p>
</blockquote>
<p>They're a few times slower per non-batched signature verification (aggregated or not). Batching (the act of verifying multiple pubkey/signature/message triplet simultaneously, only learning whether all or not all of them are valid) with sufficiently large batches however counteracts most of that slowdown.</p>
<blockquote>
<p>Apart from relying on different assumptions, why wouldn't BLS signatures be interesting for Bitcoin?</p>
</blockquote>
<p>They'd certainly be interesting. Lots of complications around multisignatures (see all the MuSig schemes) and multi-party spending in general are largely non-existent for BLS signatures. They're smaller too. The question is mostly one around acceptability of the added security assumptions, in my opinion.</p>
<p>There is one other (rather weak) argument against them I'm aware of. Schnorr (and ECDSA) signatures support <em>adaptor</em> signatures. These are a construction that makes it possible to use the publication of a signature to trigger revealing a pre-agreed secret, and are the basis for unlinkable atomic swap protocols that are indistinguishable from normal payments, and for PTLCs (a more private replacement for Lightning's HTLCs). BLS signatures however inherently don't support adaptor signatures—there is just no space in them to reveal anything. This means that in a world where everyone has migrated to BLS for nearly everything, these adaptor signature constructions would need to stick to Schnorr/ECDSA, and thus stand out and no longer be indistinguishable from normal payments.</p>

CC BY-SA 4.0
2022-12-30T19:25:23.447Z
Thanks for the detailed answer. Isn't it possible using taproot's MAST to allow for similar functionality (private atomic swaps, PTLCs, etc) w/o adaptor signatures?
Son Kaos999
CC BY-SA 4.0
2022-12-30T19:29:26.377Z
No, because the point is exactly not using those. If the MAST (script tree) is used, you're revealing the script. The amazing property of adaptor signatures isn't just that they're small - it's that all that ends up on chain is just a signature, which looks exactly like every other signature.
Pieter Wuille
CC BY-SA 4.0
2022-12-30T19:40:18.270Z
AFAIK in the cooperative case all that ends up in the blockchain is a signature too
Son Kaos999
CC BY-SA 4.0
2022-12-30T19:47:33.440Z
Yes, that's what I'm talking about. You can't use the script tree to reveal something in the cooperative case, because no script is revealed. If you have to reveal a script in the cooperative case, it's no longer indistinguishable from a single signature.
Pieter Wuille
CC BY-SA 4.0
2022-12-30T16:29:46.287Z
2022-12-30T17:10:06.763Z
2022-12-30T17:10:06.763Z
Pieter Wuille
<p>How do BLS signatures (or other pairing-based schemes) compare to Schnorr signatures in terms of cryptographic assumptions?</p>
<p>Is it faster to verify, say 100 (non-interactively) aggregated BLS signatures than 100 aggregated Schnorr signatures?</p>
<p>Apart from relying on different assumptions, why wouldn't BLS signatures be interesting for Bitcoin?</p>

<signature><schnorr-signatures><boneh-lynn-shacham-signatures>
BLS signatures vs Schnorr
Son Kaos999
# BLS signatures vs Schnorr

(Asked by: username_0 on 2022-12-29)

How do BLS signatures (or other pairing-based schemes) compare to Schnorr signatures in terms of cryptographic assumptions?

Is it faster to verify, say 100 (non-interactively) aggregated BLS signatures than 100 aggregated Schnorr signatures?

Apart from relying on different assumptions, why wouldn't BLS signatures be interesting for Bitcoin?

**Tags:** signature, schnorr-signatures, boneh-lynn-shacham-signatures


---

## 1 answers

### Answer by username_1 on 2022-12-30. Score: 11 | Accepted answer

> How do BLS signatures (or other pairing-based schemes) compare to Schnorr signatures in terms of cryptographic assumptions?

BLS needs a pairing-compatible elliptic curve, which imposes additional structure on the curve. The elliptic curve used for cryptography in Bitcoin today (both for ECDSA and Schnorr), secp256k1, is not pairing-compatible.

This additional structure may be concerning. See it this way: normally when picking an elliptic curve for cryptographic purposes, there are a number of "gotchas" to avoid - properties that, if present, are either known or suspected to aid attackers to break its security. One of those properties is having a "low embedding degree":

* A very low embedding degree (say, up to 3) gives a trivial way to compute private keys from public keys.
* A sufficiently high embedding degree (say, 10 or more) is likely not a problem, in the sense that no way to exploit that is known.
* A very high embedding degree (similar in magnitude to the order of the group itself) is almost certainly unexploitable (as otherwise every elliptic curve would be vulnerable).

secp256k1 has embedding degree 19298681539552699237261830834781317975472927379845817397100860523586360249056 (exactly 1/6 of the number of points on the curve).

Pairing-compatible curves however *need* a relatively small embedding degree; small enough to be tractable for computation (because signature verification actually involves computing this embedding), but also large enough to not result in making private keys easy to find. Currently popular pairing curves use embedding degree 12.

So, BLS requires curves that are from a traditional perspective "risky". It's not that this risk is unmanageable: obviously actual curves are constructed in such a way that there is no way to exploit this structure, but it is walking a fine line. The concern is that perhaps in the future other ways are discovered to exploit it. And us having selected parameters such that all known attacks fail isn't sufficient when new attacks get discovered.

Of course, that's not fundamentally different from other elliptic curve security, or cryptographic security in general. We *always* select parameters/curves/... in such a way that all known ways of attacking fail, and when new attacks get discovered, those parameters may not be sufficient anymore. But in the case of generic ECC, that's just one set of attacks to avoid. In the case of pairing-based cryptography, there is an entirely separate added newer set of attacks to worry about as well.

As for what this means for Bitcoin: I don't know. The question is just whether the Bitcoin community, as a whole, is ok with this added set of security assumptions that BLS would bring. And it isn't sufficient that it's optional; if (hypothetically) I personally would be uncomfortable with BLS's security outlook, I wouldn't want a large fraction of the BTC supply to become subject to it, as a break of pairing-based cryptography may threaten the currency's value overall, including my non-BLS-encumbered coins. So I believe this means the bar for adding new security assumptions is fairly high.

> Is it faster to verify, say 100 (non-interactively) aggregated BLS signatures than 100 aggregated Schnorr signatures?

They're a few times slower per non-batched signature verification (aggregated or not). Batching (the act of verifying multiple pubkey/signature/message triplet simultaneously, only learning whether all or not all of them are valid) with sufficiently large batches however counteracts most of that slowdown.

> Apart from relying on different assumptions, why wouldn't BLS signatures be interesting for Bitcoin?

They'd certainly be interesting. Lots of complications around multisignatures (see all the MuSig schemes) and multi-party spending in general are largely non-existent for BLS signatures. They're smaller too. The question is mostly one around acceptability of the added security assumptions, in my opinion.

There is one other (rather weak) argument against them I'm aware of. Schnorr (and ECDSA) signatures support *adaptor* signatures. These are a construction that makes it possible to use the publication of a signature to trigger revealing a pre-agreed secret, and are the basis for unlinkable atomic swap protocols that are indistinguishable from normal payments, and for PTLCs (a more private replacement for Lightning's HTLCs). BLS signatures however inherently don't support adaptor signatures—there is just no space in them to reveal anything. This means that in a world where everyone has migrated to BLS for nearly everything, these adaptor signature constructions would need to stick to Schnorr/ECDSA, and thus stand out and no longer be indistinguishable from normal payments.

> **Comments:**
> **username_0**: Thanks for the detailed answer. Isn't it possible using taproot's MAST to allow for similar functionality (private atomic swaps, PTLCs, etc) w/o adaptor signatures?  
> **username_1**: No, because the point is exactly not using those. If the MAST (script tree) is used, you're revealing the script. The amazing property of adaptor signatures isn't just that they're small - it's that all that ends up on chain is just a signature, which looks exactly like every other signature.  
> **username_0**: AFAIK in the cooperative case all that ends up in the blockchain is a signature too  
> **username_1**: Yes, that's what I'm talking about. You can't use the script tree to reveal something in the cooperative case, because no script is revealed. If you have to reveal a script in the cooperative case, it's no longer indistinguishable from a single signature.  

---

