Skip to content

Technical and editorial errors #57

@ViniciusCestarii

Description

@ViniciusCestarii

Really enjoyed the book! Before reading it, I never really paid attention to or understood the importance of deterministic builds, so it was great to learn the details behind that. The chapters on eclipse attacks and how internet infrastructure like AS routing can be a point of vulnerability for Bitcoin were also eye-opening. Great job bringing attention to these topics that often go unnoticed.

That said, I found a few errors while reading:

1. Utreexo: "demonstrated ownership" should be "demonstrated existence"

"You’ve now demonstrated ownership of Coin 3 without the need for the verifier to know the entire UTXO set."

Utreexo proves existence of transaction in the UTXO set, not ownership. Every other occurrence in the book correctly states that it proves existence in the UTXO set.

2. Garbled sentence about keys

"Let’s say you’re a company and you offer a semi-custodial wallet solution, where you have one of the keys of the user and the user has the other has two keys."

This sentence seems like a merge of two edits and isn't coherent. I think it was meant to be: "where you have one of the keys of the user and the user has the other two keys."

3. ECDSA referred to as a "curve"

"And so, when Satoshi had to pick a cryptographic curve for Bitcoin, he chose ECDSA namely because it wasn't patented and it's already in OpenSSL"

ECDSA is a signing algorithm, not a curve. Suggested: "And so, when Satoshi had to pick a signing algorithm for Bitcoin, he chose ECDSA namely because it wasn't patented and it's already in OpenSSL."

4. Incorrect coinbase maturity value: "101" instead of "100"

"it can't be spent until it has 101 confirmations, i.e. until there are 101 blocks built on top of it. This is called coinbase maturity."

101 confirmations is correct, but "101 blocks built on top of it" is off by one. The block containing the coinbase itself counts as the first confirmation, so 101 confirmations means 100 blocks on top of it. The referenced Stack Exchange answer by Pieter also confirms this: the rule requires a difference of 100 between the creating block and the spending block.

5. Incorrect description of HASH160

"which takes the SHA-256 hash twice, and then the RIPEMD-160 hash"

"The value for pubKeyHash is generated by the recipient wallet by performing a double SHA-256 hash followed by RIPEMD-160,"

HASH160 computes SHA-256 once, then RIPEMD-160 on the result. It does not apply SHA-256 twice.

6. Wrong retarget period number: "2,106" instead of "2,016"

"then in the very last 2,106-block retargeting period, we go to MUST_SIGNAL"

It should be 2,016 blocks. Every other occurrence in the book correctly uses 2,016.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions