Oddbean new post about | logout
 Schnorr sigs not using RFC6979 is so annoying. Would be able to do so many more things determistically 😭 
 😭 
 personally im a fan of RFC6969 
 Can always count on you 
 YES

#YESTR 
 I don't understand the nostr context, but why can't you use a deterministic nonce generation algorithm? (Unless you're doing musig in which case, yes, you basically can't). Either the bip340 suggestion, without injecting fresh randomness, or rfc6979 even?

Not being rfc6979 shouldn't be a problem, the algorithm is never a matter of consensus with other parties.

Doubtless I missed at least one thing here ... 
 I know you can, but basically every implementation today just generates a random nonce so you can't rely on them being able to do sigs with specific nonces. 
 OK, that makes sense. Doesn't the libsecp API let you specify the additional randomness yourself though? I vaguely remember it does but i wouldn't be surprised if that's a bit fiddly.

A recollection from years ago, I remember gmax telling me he talked to Pornin quite a bit about the RFC6979 spec and that he thought it was unnecessarily complicated (difficult to disagree if you read it!) - the main concept is of course f(privkey, msg) where f acts as a PRNG. Vitalik implemented it wrong in pybitcointools (less of a 'burn' than it might sound, since the error didn't break anything except with negl. prob ... so it's more just an example of how complicated it was). 
 You totally can use RFC6979. 

BIP340 even says how to do it: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#alternative-signing 
 It's not the standard though so you can't rely on it 
 I just added RFC6979 logic to my BIP340 implementation:

https://github.com/conduition/musig2/pulls/2 

Seems reliable enough to me!