BIP 340 and RFC 6979 and variable length messages about btcd

[Roasbeef]

It does not accept variable length messages, and it does not contain the extra 4 tests added to it that test this capability.

Hi correct that this isn't fully implemented. We never implemented as:

1. Typically in Bitcoin situations, we're always signing a 32-byte sighash.
2. No opcodes today in Bitcoin actually use the variable length message signing.

Going over the test vectors it is clear that in fact, normally RFC6979 should not be used with Bitcoin (and Nostr) Schnorr signatures at all, since the security flaw this RFC aims to eliminate is handled by the BIP 340 tagged nonces.

I'm not sure what you mean by this, see the section on "alternative signing": https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#user-content-Alternative_Signing

This can be most reliably accomplished by not reusing the same private key across different signing schemes. For example, if the rand value was computed as per RFC6979 and the same secret key is used in deterministic ECDSA with RFC6979, the signatures can leak the secret key through nonce reuse.

We counteract this by using a distinct RFC6979 tag for the ECDSA and Schnorr signatures. IMO RFC6979 is still an improvement to the ergonomics of the scheme, as it does away with the requirement to generate secure randomness for each signature.

[mleku]

I'm completely unable to respond to this. I won't bother in future, my experience with your dev group is pretty consistent.