Explanation of Bitcoin’s Elliptic Curve Digital Signature Algorithm | Hacker News Reader

Explanation of Bitcoin’s Elliptic Curve Digital Signature Algorithm

suhailsaqan.medium.com

105 pointseminem_stan13 comments

Reading this post, this is actually an explanation of Schnorr signatures, not ECDSA signatures. Bitcoin uses the latter, except for new transactions after the Taproot update, which the author doesn't reference here. In fact, the author isn't even describing a signature scheme, but rather an identification scheme, since the only step that involves the message is the vague: "5. Alice customizes a hash function with a message that she is signing". I believe what the author is referencing is to turn the Schnorr identification scheme into a signature scheme, you include the message along with the nonce commitment, hashing H(R, m) instead of H(R). In fact, you should also include the public key, hashing H(X, R, m).

I remain somewhat confused as to how this article was written.

I’m pretty sure this is an explanation of ECDSA. However, I do agree with you on the last part, I should’ve been a little clearer about the identification scheme.

https://cointelegraph.com/news/satoshi-nakamoto-had-outside-...

Some interesting background. For people that don’t know, the Laszlo in the story is Bitcoin pizza guy that spent 10k Bitcoin on two pizzas and initiated the thought in the public’s mind that Bitcoin could actually pay for things.

I found that article because it occurred to me that Satoshi knowing cryptography that deeply and coding and all his other attributes would be quite hard to believe all in one person.

Satoshi was maybe an above-average coder nor cryptographer, but not genius. Reminder: bitcoin v0.1 was made to run only on Windows, the code was fairly ugly and had a bunch of common crypto mistakes/weirdness [0].

Don't get me wrong, Satoshi was/is a genius, but not for his coding/cryptography skills.

[0] A good summary of vulns in bitcoind: https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposu...

Most of those vulnerabilities were added later, the original bitcoin software had an extraordinarily low defect rate. While some of the bugs in the original were very severe indeed (particularly in Bitcoin script), there were very few in total.

The original code was essentially perfectly portable and extremely clean. It's true that it was was highly integrated, and lacked significant modularity-- but this also made it small and simple. Its use of modern techniques and conscious style made it completely free of broad classes of bugs.

The more modern code is highly abstracted and modular, but much more difficult to read, understand, and review. But its level of functionality wouldn't be realistic or maintainable (particularly by such a large number of participants) otherwise. That level of functionality didn't exist in the original code.

The ugly comment is the sort of remark made by junior developers who can't distinguish style different from what they learned from poor quality. Poor quality code also differs from their preferred style, but not everything that does is poor quality. By any objective metric, -- save modularity/abstraction-- the original code base was extremely high quality including the metrics that matter most: the defect rate. The level of abstraction wasn't optimum for the work that came latter, but it wasn't later and prematurely abstracting would have made the code far less clear (and probably less reliable).

The "the code was ugly" thing is an often repeated statement but doesn't really reflect the reality of what was released.

The source code is very tightly integrated, but it avoids many of the common issues you would see in software of its type (ie, the wire protocol had no variable length strings whatsoever), and it implements a crazy amount of different features in a concise, readable code base. You can look over the original Bitcoin source code and immediately get an answer for how something functions, which is entirely the goal for what was effectively a prototype that introduced new key concepts to anybody who picked it up. wxBitcoin compiled happy on linux with only minor modifications, and OSX not a whole lot of time afterwards.

If the author had gone for absolute perfection or many levels of abstraction it never would have been released; what was created was nothing short of astounding, and being functional while creating something so absolutely novel is great code.

> the wire protocol had no variable length strings whatsoever

Script is serialized as a variable-length string.

It is variable length but not a string.

Reply on news.ycombinator.com