1
0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-26 12:10:14 +00:00

Updated Comments:BIP 0340 (markdown)

Pieter Wuille 2021-03-07 18:38:50 -08:00
parent b036059327
commit fe520d5680

@ -94,4 +94,9 @@ Here is the link to said paper = https://dl.acm.org/doi/10.1145/3372297.3417268
1. https://csrc.nist.gov/publications/detail/fips/186/5/draft
2. https://eprint.iacr.org/2019/023.pdf
2. https://eprint.iacr.org/2019/023.pdf
----
The comments above appear to be misinformed. Nearly all ECDSA implementations today, including all the ones used in Bitcoin software that I know about, already use derandomized RFC6979 nonce generation for secp256k1. BIP340 too specifies such a nonce generation algorithm - one that is inspired by Ed25519's in fact. It permits adding randomness as research has shown this improves resistance to certain fault & side-channel attacks, but the randomness is not critical for security (it is purely additive). Lastly, the entire nonce generation concern is an implementation aspect that's orthogonal for the signature scheme - it can be done well, or badly, either with ECDSA or Schnorr/BIP340. BIP340 chooses to specify it, in the hope that implementations adopt it as a best practice, but circumstances may call for alternative nonce generation algorithms too.