Did you know that Dryja's discreet log contracts are fundamentally unsound?
OK now the click has been well and truly baited, I'll try to contextualize: DLCs are unsound in a theoretical sense that I'll explain; it's enough that it matters, but probably not enough that any real-world implementation would actually get attacked.
To explain the cryptographic-unsoundness without going into mathematics, I think it probably helps to explain a concept "UF-CMA": unforgeability against chosen message attack. The idea is this: you want your signing algorithm to be strong enough that this, specifically, holds: if someone asks me to sign a message and (this is after all, quite common), I'm willing to oblige and sign their message, then there's no way they can craft their message-to-be-signed such that my signature on *that* message allows them to *forge* my signature on a different message. Obviously we imagine this scenario repeated, e.g. they get me to sign 16 different messages, all of which they carefully choose, before using all of that as input to create a forgery. We clearly do not want this to be true in a general purpose signing algorithm. You can prove EUF-CMA for plain vanilla Schnorr signatures: here the "E" is about the idea of them creating a signature on *any* new message, at all. EUF-CMA is generally treated as a requirement.
DLCs don't use vanilla-Schnorr[1]. What they use is a variant: R is set *in advance*. A refresher on R: there is a one-time used secret value k, called a nonce, in a Schnorr-type signature, and R is the "pubkey" of k: R = kG. DLC doesn't violate the "one-time" and "secret" nature of k. It changes the protocol in a more subtle way, by publishing and therefore fixing R, before the message to be signed arrives. It turns out that this loses UF-CMA due to something called the Wagner attack (or ROS attack). I will spare you the details, but imagine just that it means: because an attacker can know in advance the inputs to the hash function, he can create a forgery by summing signatures he's given, **as long as he can control what gets signed**. (that's why knowing R matters; if he couldn't predict R, he would be unable to execute the attack because the hash output wouldn't be predictable from the message). If your DLC oracle will sign literally anything (so it has published a huge number of Rs for a huge number of outcomes), then in N (large) signatures on messages *you control*, he'll actually allow a forgery of his signature on *any message at all* (even a bitcoin transaction, should you store money at the same key as the signing oracle, unlikely I guess).
Sounds pretty bad, right? Cryptographically, it is. But in practice, in the nature of what oracles are is that they control what they sign carefully. If they only sign "true" or "false" then that's not enough information to squeeze in random values that the attacker needs to squeeze in, *even if* the attacker can fully control whether the output is true or false. Even in the more plausible scenarios like, an oracle signs a price measured to 6 decimal places, there's more information for the attacker to "squeeze in" but it's all the more impractical for an attacker to control the outcome that exactly. The oracle has to be prepared to attest to some huge number of outcomes, *and* the attacker has to be able to fully force the output he wants. And to repeat this process.
So this leaves us in a funny situation: it is reasonable to assume security of the construct from the point of view of "the oracle can be trusted not to sign just anything, or some large number of weird message that don't correspond to reality (real price, real temperature), and that's why we trust it's not going to get hacked", that is, your trust is not in the cryptography, but in the identity behind it. But that's the "oracle problem" anyway; even if the cryptography didn't have this weakness, you'd still have that same trust. I *do* think it's dubious, though; such a theoretical hole is very undesirable. Attacks *tend* to improve over time.
The rest is more techincal, feel free to skip:
Postscript: you might be thinking, damn, this Wagner attack is scary, if you can just make a forgery from a bunch of pre-existing signatures .. maybe you can do that with normal Schnorr like in BIP340? The answer is: using *deterministic nonces* elegantly avoids this attack, even if making fresh and unpredictable nonces didn't (it does). If the nonce is generated from a hash of the message and the private key it cannot be derived in advance in any way by the attacker without knowledge of the private key, which makes the attack moot. The only other "nonces are pre-prepared and handed out" case is that of MuSig2 (and iirc FROST); in those cases the defence is specifically connected with a clever "contextualized nonce" : R1 + bR2 where b hashes the *context* of the signing event, including the message, which prevents grinding. This extra defence was created *specifically* to address the Wagner threat, which otherwise would be even worse for the collaborative protocols than the single signer one.
What you should take away is: default Schnorr is tremendously nonce-fragile: it's not even enough for it to be random; it has to be secret before the signing event!
[1] You can say that it does, but I beg to differ. Vanilla Schnorr is the canonical sigma protocol and follows the pattern: commit, challenge, response, with R being the "commit" step and "P" being the public context of the protocol execution. In DLC R is part of the public context, and what is the commit step? (there isn't one, I guess). Obviously this is very abstract but it's probably the right way to understand why the security hole exists.
OK now the click has been well and truly baited, I'll try to contextualize: DLCs are unsound in a theoretical sense that I'll explain; it's enough that it matters, but probably not enough that any real-world implementation would actually get attacked.
To explain the cryptographic-unsoundness without going into mathematics, I think it probably helps to explain a concept "UF-CMA": unforgeability against chosen message attack. The idea is this: you want your signing algorithm to be strong enough that this, specifically, holds: if someone asks me to sign a message and (this is after all, quite common), I'm willing to oblige and sign their message, then there's no way they can craft their message-to-be-signed such that my signature on *that* message allows them to *forge* my signature on a different message. Obviously we imagine this scenario repeated, e.g. they get me to sign 16 different messages, all of which they carefully choose, before using all of that as input to create a forgery. We clearly do not want this to be true in a general purpose signing algorithm. You can prove EUF-CMA for plain vanilla Schnorr signatures: here the "E" is about the idea of them creating a signature on *any* new message, at all. EUF-CMA is generally treated as a requirement.
DLCs don't use vanilla-Schnorr[1]. What they use is a variant: R is set *in advance*. A refresher on R: there is a one-time used secret value k, called a nonce, in a Schnorr-type signature, and R is the "pubkey" of k: R = kG. DLC doesn't violate the "one-time" and "secret" nature of k. It changes the protocol in a more subtle way, by publishing and therefore fixing R, before the message to be signed arrives. It turns out that this loses UF-CMA due to something called the Wagner attack (or ROS attack). I will spare you the details, but imagine just that it means: because an attacker can know in advance the inputs to the hash function, he can create a forgery by summing signatures he's given, **as long as he can control what gets signed**. (that's why knowing R matters; if he couldn't predict R, he would be unable to execute the attack because the hash output wouldn't be predictable from the message). If your DLC oracle will sign literally anything (so it has published a huge number of Rs for a huge number of outcomes), then in N (large) signatures on messages *you control*, he'll actually allow a forgery of his signature on *any message at all* (even a bitcoin transaction, should you store money at the same key as the signing oracle, unlikely I guess).
Sounds pretty bad, right? Cryptographically, it is. But in practice, in the nature of what oracles are is that they control what they sign carefully. If they only sign "true" or "false" then that's not enough information to squeeze in random values that the attacker needs to squeeze in, *even if* the attacker can fully control whether the output is true or false. Even in the more plausible scenarios like, an oracle signs a price measured to 6 decimal places, there's more information for the attacker to "squeeze in" but it's all the more impractical for an attacker to control the outcome that exactly. The oracle has to be prepared to attest to some huge number of outcomes, *and* the attacker has to be able to fully force the output he wants. And to repeat this process.
So this leaves us in a funny situation: it is reasonable to assume security of the construct from the point of view of "the oracle can be trusted not to sign just anything, or some large number of weird message that don't correspond to reality (real price, real temperature), and that's why we trust it's not going to get hacked", that is, your trust is not in the cryptography, but in the identity behind it. But that's the "oracle problem" anyway; even if the cryptography didn't have this weakness, you'd still have that same trust. I *do* think it's dubious, though; such a theoretical hole is very undesirable. Attacks *tend* to improve over time.
The rest is more techincal, feel free to skip:
Postscript: you might be thinking, damn, this Wagner attack is scary, if you can just make a forgery from a bunch of pre-existing signatures .. maybe you can do that with normal Schnorr like in BIP340? The answer is: using *deterministic nonces* elegantly avoids this attack, even if making fresh and unpredictable nonces didn't (it does). If the nonce is generated from a hash of the message and the private key it cannot be derived in advance in any way by the attacker without knowledge of the private key, which makes the attack moot. The only other "nonces are pre-prepared and handed out" case is that of MuSig2 (and iirc FROST); in those cases the defence is specifically connected with a clever "contextualized nonce" : R1 + bR2 where b hashes the *context* of the signing event, including the message, which prevents grinding. This extra defence was created *specifically* to address the Wagner threat, which otherwise would be even worse for the collaborative protocols than the single signer one.
What you should take away is: default Schnorr is tremendously nonce-fragile: it's not even enough for it to be random; it has to be secret before the signing event!
[1] You can say that it does, but I beg to differ. Vanilla Schnorr is the canonical sigma protocol and follows the pattern: commit, challenge, response, with R being the "commit" step and "P" being the public context of the protocol execution. In DLC R is part of the public context, and what is the commit step? (there isn't one, I guess). Obviously this is very abstract but it's probably the right way to understand why the security hole exists.
3❤️4🤙3❤️1👀1🤔1
