Thread by @librehash

1/ I published a public comment for BIP340 a few months ago on the official Bitcoin GitHub

After publishing said comment, it was later removed (censored) by Gregory Maxwell (@Blockstream CTO "formerly"; listed as a co-founder of @Blockstream as well).

github.com/bitcoin/bips/b…

2/ To start off, what Gregory Maxwell wrote is a demonstrable lie - full stop.

You can view my original comment here - github.com/bitcoin/bips/w…

As screenshots, what I wrote was comprehensive, to the point + included numerous references to published (peer-reviewed)

3/ Before getting into all of that, let me address Gregory Maxwell's claim that my comment was "linked elsewhere while the comments below are ignored"; this is actually false.

4/ On May 22nd, 2021 (more than a week before Maxwell's false update), I updated my public Telegram channel to inform everyone of my comment and *included* Peter Wiulle's response to my comment as well.

5/ Additionally, Peter Wiulle conceded *numerous* points I made above in his response (read it closely).

Additionally though - Wiulle is *100% wrong in many of his responses here*; I'll go through those briefly.

6/ Peter claimed that nearly all Bitcoin wallets adhere to RFC6979 nonce generation specs ; this is not true.

Example here - github.com/bitpay/bitcore…

Issue still open here - github.com/bitpay/bitcore…

7/ Elliptic curve coord. pairings (x, y) are co-factors plotted over a finite field; 'x' (private key) has a direct relationship to 'y' (pubkey)

The 'order' (n) = lowest prime order cyclic subgroup ; this is the order of the curve base point ('G')

8/ Given the above, for signatures we can create a proof via taking a random value (k), multiplying it by the curve base point (G) to arrive at a diff 'y' (R) on the elliptic curve [R=kG]; thus the corresponding priv. key is R*x, where x = private key

8a/ There's a nuance in RFC6979 for those attempting to generate *deterministic* ecdsa (secp256k1) keys that goes further than simply deriving the value 'k' from HMAC'ing (h+x)

We'll get to that in a second.

9/ From this point you can create a proof that says

's' = k^(-1) * (h + r*x)(modulo 'n')
‘s’ is determined by the [inverse of ‘k’] multiplied by [hash of the message output when XOR’d with ‘r*x’] which is modulo'd with 'n' ; 'n' = lowest prime order of cyclic subgroup

10/ Perhaps Gregory Maxwell decided to censor my comment on BIP340 because I called @Blockstream and @adam3us out about a recent whitepaper, in which researchers outlined how they were able to *successfully recover funds from Bitcoin wallets*

https://twitter.com/librehash/status/1397092118380916737?s=20

11/ In that thread, I cite the name of the study, "Biased Nonce Sense: Lattice Attacks Against Weak ECDSA Signatures in Cryptocurrencies"

Curiously, the researchers documented conversations they had *directly* with Gregory Maxwell about this issue.

12/ Skipping to the point here - I think Wiulle's confusion stemmed from my use of the word "random". For the *generator*, these values should not be random (in a deterministic setting), yes.

But to the *outside world*, it absolutely should (obviously).

13/ The researchers make it clear *in the Abstract*, "If this nonce is not generated uniformly at random, an attacker can potentially exploit this bias to compute the long-term signing key."

eprint.iacr.org/2019/023.pdf

14/Continuing - "We also calculated 1,296 private keys from repeated signature nonces. These keys had generated 4,295,141 signatures."

Also, "Some of the transactions using k = (n-1)/2 are with withdrawing from addresses derived from easily guessable brainwallet passwords."

14a/ The researchers explicitly state they reached out to Greg Maxwell about these nuances in secp256k1 nonce generation on the blockchain (and they record his response noting an out-of-bound, 'SHA1' hash is used to "sweep 'dust' transactions" <-- is this even documented?

15/ The researchers note the fact Bitcoin switched to "deterministic nonces" back in 2015/2016; however as we can see in the study's excerpt attached to this tweet - that did not mitigate this problem entirely (by any means)

16/ Revisiting RFC 6979 is critical here, bc the nonce is *supposed* to be deterministic now for Bitcoin (this change was made in '15), last pic is most relevant - "performing a simple modular reduction would induce biases that would be detrimental to signature security."

16a/ Knowing that's true, I wonder if that's what is causing the leakage of nonce values - bc the full signature proof is: k^-1 * (h + r * privKey)(mod 'n') ; 'n' = prime curve order

16b/ Looking to verify signature; you'll notice that the random point used during signing is supposed to be recoverable to check the proof ; however doing so requires deriving the modulo inverse of 's'...

16c/ IF one were to use the regular formula (k^-1 rep. the modulo by 'n' ; n = lowest prime order of the curve), then you end up with 'k' outright. 'k' in rfc6979 = h+privKey

The attached screenshot is from libsecp256k1 ; I wonder if this spec. (mandating mod.) is the culprit

17/ In either case, it should be abundantly clear that my comment on BIP340 was far from "misinformation" and that Gregory Maxwell and @Blockstream are completely full of shit. Full stop.