Signing/verifying BIP340 Schnorr when the message is not 32 bytes

[randombit]

If I'm understanding the API correctly, it's not currently possible to use this crate to sign or verify BIP340 messages that are not exactly 32 bytes long. Is this correct? If so is there any change of adding such support? It seems libsecp256k1 already supports this, using secp256k1_schnorrsig_sign_custom, and for verification the plain secp256k1_schnorrsig_verify accepts any input length.

[elichai]

We actually talked about it on IRC today,
We should probably change the API to accept &[u8], if we want to reduce breakage we can accept impl AsRef<[u8]> and impl that for Message

[apoelstra]

I think we may just have to eat the breakage -- we want to discourage people to directly use Message, by instead accepting Into<Message> for the ECDSA signer (and telling people downstream to implement this only for sighashes and nothing else).

We are also planning to drop the ThirtyTwoByteHash trait in favor of Into<Message>...so I think this fits in well to a single "break the signing API" release that hopefully will be beneficial enough for people to be worth the breakage.

[Kixunil]

Please confirm if my understanding is correct. Schnorr signature needs tagged_hash(r || pk || m) where m is the message. And we supply Message so we're effectively forcing pre-hashing as mentioned in the BIP?

[elichai]

Please confirm if my understanding is correct. Schnorr signature needs tagged_hash(r || pk || m) where m is the message. And we supply Message so we're effectively forcing pre-hashing as mentioned in the BIP?

Basically yes. as a previous version of the BIP only supported pre-hashing

[apoelstra]

@Kixunil yep, exactly. And as @elichai says, the history here is that the BIP used to only support this mode (and this mode is what Bitcoin uses in the post-Taproot CHECKSIG opcode).

[wolfmcnally]

Please publish the merged fix soon.
@ChristopherA

[apoelstra]

@wolfmcnally #750