Libre Blockchain

2021-06-16 00:10:47 Maybe the Issue Went Over Wiulle's Head The claim here is not that the 'k' isn't generated "deterministically", actually. If this was stated in a sentence (peripherally), then that's just something I misstated - it definitely doesn't invalidate the main… Open / Comment

2021-06-16 00:10:31 Maybe the Issue Went Over Wiulle's Head

The claim here is not that the 'k' isn't generated "deterministically", actually.

If this was stated in a sentence (peripherally), then that's just something I misstated - it definitely doesn't invalidate the main point here though.

In saying that signatures are generated deterministically, that means that your private key should produce the same signature for the same message. This is addressed w RFC6979, yes - but the issue that I'm addressing here is the fact that the signature produced is sometimes derived from a 'predictable' / 'guessable' unknown value - which puts user funds at risk.

Use of the Word 'Random'

Maybe that's the confusion here because I use the word 'random' a lot in my comment, and I think they interpreted that to mean I was suggesting that the 'k' chosen is done so randomly for each signature regardless of the message (although this is a latent possibility since there exists no finite standard for how private keys are generated, let alone the damn signature).

Back to the Main Point

I included a mathematical formula in here for signature generation on Bitcoin (via ecdsa). This formula cannot produce non-deterministic signatures.

So how the fuck can Peter Wiulle state that this is what I'm implying Bitcoin does? The 'k' is part of a proof that involves the sha256 hash of a message; sha256 is a one-way, deterministic hash - so there shouldn't be more than one 'k'.

> Plot Twist: There actually can be more than one 'k' per signature - even if the message is the same, due to the way that ecdsa is constructed, period (which, again, goes to the weakness of using ecdsa as the primitive for key generation on Bitcoin) Open / Comment

2021-06-16 00:01:22 As recently as November 2020, there has been reference & movement on the first issue that I mentioned re: Bitcoin private key generation

If the private keys are generated differently (or w variability), then w/o a doubt, transactions are too. Open / Comment

2021-06-15 23:49:53 I'm not saying there's no room to disagree with what I wrote, but to dismiss it as misinformation as if what I wrote was some preposterous mumbo-jumbo designed to instill fear that Bitcoin will be compromised or something is bullshit. I make no claim that… Open / Comment

2021-06-15 23:49:08 I'm not saying there's no room to disagree with what I wrote, but to dismiss it as misinformation as if what I wrote was some preposterous mumbo-jumbo designed to instill fear that Bitcoin will be compromised or something is bullshit.

I make no claim that this will compromise Bitcoin, destroy the project, or something like that.

Schnorr's is a signature scheme, not a cryptographic primitive. So my issue is not with Schnorr's itself but rather the cryptographic primitive (secp256k1) that the scheme is being applied to.

Peter Wiulle argued that I was misguided in my idea that signatures are not generated deterministically for Bitcoin - but I'm not.

Their library may enforce deterministic signatures, but you don't need to follow their library to generate a legitimate Bitcoin address or a legitimate signature. In fact, you could generate a Bitcoin address right on the command line if that's what you wanted to do (will produce the code for that in a second).

This is Why I Pushed For an Industry-Wide Standard

Peter Wiulle claiming, "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...", is actually bullshit.

If you check out this issue here in BitPay's GitHub, you can see how the failure to provide any level of standardization has resulted in a distinct variation in what private keys are produced via mnemonics (i.e., your 'recovery seed' may produce an entirely different address - not fucking good)

Read here: https://github.com/bitpay/bitcore-lib/issues/47

One of these issues is still fucking open right now - https://github.com/bitpay/bitcore-lib/issues/94 Open / Comment

2021-06-15 23:36:35 Read the Comment That I Left

You can read the comment (removed), here - https://github.com/bitcoin/bips/wiki/Comments:BIP-0340/930bacddcd1c1494eefed084d2755e33366232a2#major-request-urgent-this-bip-should-be-canned [not sure where this link was moved to, but here it is]

—-

Cutting Through the Fat

I state in this comment, "This is troublesome for a countless # of reasons, but adding Schnorr in the manner this BIP proposes, will only incur greater technical debt on the protocol by addressing one of the symptoms (malleability), but not the root cause (non-deterministic nonces + a failure to provide a cohesive, ecosystem-wide standard for the instantiation of address signing)."

Peter Wiulle AGREED WITH ME IN HIS RESPONSE! (but also disagreed on things he was wrong about)

1. "Nearly all EDCSA implementations today, including all the ones used in Bitcoin software that I know about, already use derandomized RFC6979..." —- no* they fucking don't and that's the issue I was bringing up. I backed up this claim with a peer-reviewed academic paper published within the past year that made this very statement - this is quoted in my comment.

2. Peter Wiulle agrees with my characterization of Schnorr's addressing this nonce generation (to some extent) to ensure that the TX IDs are uniformly produced (if this were occurring now then we wouldn't have transaction malleability) - specifically, he states, "BIP340 too specifies such a nonce generation algorithm - one that is inspired by ED25519's in fact" —- if its inspired by ed25519, why not fucking use ed25519? that's the WHOLE POINT of what I wrote. It doesn't make fucking sense to keep "fixing" something to make sure it works correctly if there are SOLUTIONS THAT WORK OUT-OF-THE-BOX

3. "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." —— this is is EXACTLY why I said in my comment that one of the issues here is a, "failure to provide a cohesive, ecosystem-wide standard for the instantiation of address signing". If you're admitting that 'it can be done well, or badly...', then don't you think you should provide an industry-wide standard to ensure its done well so that people don't LOSE their MONEY via BAD software implementations? This has resulted in the loss of TENS of millions of dollars for Bitcoin users over the years... Open / Comment

2021-06-15 23:28:48 Message above is a forward from May 22nd in this Chat.

This was published in here over a week before Gregory Maxwell censored my comment.

As you can see, I informed everyone of Peter Wiulle's response. I provided a link to it and a screenshot.

So how the fuck is the comment being ignored?

And why am I obligated to even mention Peter Wiulle's response? What makes his feedback so much more important than mine? If Bitcoin is really as "decentralized" and "open" as everyone says, then his feedback should be considered on equal standing with mine.

Also - how did I publish a "wall of misinformation"? I published an opinion, not a statement of fact. My belief that there are better alternatives than Schnorr's or that further consideration for the usage of ecdsa vs. better alternatives (eddsa or perhaps laying groundwork for post-quantum primitive) is "misinformation"?

Get the fuck out of here. You all can see in front of your eyes in live time that Blockstream does not believe in community participation. Open / Comment

2021-06-15 23:25:39 The author of this channel wrote the only comment on BIP340 to date, clearly articulating grievances with Core's failure to standardize key generation by all major wallet providers before pressing forward with any new initiatives prematurely.

These grievances were stated because there is substantial academic research that suggests that most wallet providers (or tools people are using to craft transactions) are leaking nonce data

(edit: this means that the private key is recoverable to the address ; researchers recently were able to recover a significant # of keys this way)

Here is the URL to my published grievance concerning BIP340 (for some reason the main BIP has not been updated to reflect that there are comments on it) : https://github.com/bitcoin/bips/wiki/Comments:BIP-0340 Open / Comment

2021-06-15 23:25:25 Bitcoin Core Censors Community Contribution and Feedback Again, this channel doesn't believe in just bitching about things. Everyone says that Bitcoin is open for development and contribution - well I attempted to do just that. For BIP340 (which is included… Open / Comment

2021-06-15 23:24:00 Bitcoin Core Censors Community Contribution and Feedback

Again, this channel doesn't believe in just bitching about things.

Everyone says that Bitcoin is open for development and contribution - well I attempted to do just that.

For BIP340 (which is included in this Taproot upgrade), I submitted a comment that voiced my opinion about the upgrade. Perhaps I am misguided in my thoughts - that's fair. But I believe that my feedback should be considered a valid part of "community consensus" if this is really 'open' development as they claim.

But that's not the case.

As we can see here at this link, Gregory Maxwell censored me directly - https://github.com/bitcoin/bips/wiki/Comments:BIP-0340 Open / Comment