- Mention the reason for the long validation time is the verification of
transactions. We previously implied it was download time, but some
people have really fast internet.
- Better describe bitcoind cookie authentication and provide an example
to make it even more clear.
- Add a link to bitcoin-s
- Make the long sidebar on collision attacks even longer by descripting
a pre-image attack in addition to the previous descriptions of second
pre-image and collision. That way we don't conflate pre-image and
second pre-image.
- Remove redundant tip box about an oddity in language about compressed
and uncompressed private keys.
- Link to information about vanity address "mining" (brute forcing)
Remove text about dumping a private key:
- Example using Bitcoin Core is no longer supported for descriptor
wallets.
- Dumping private keys is very bad practice with HD wallets due to risk
of compromising the whole wallet.
- Because of safety risks, and lack of need, most modern wallets don't
support private key export or import
- Explain why almost nobody uses vanity addresses any more---HD wallets
killed them, plus they suck for privacy.
- Remove example code. It's only useful for base58check addresses, but
those are no longer recommended and (as mentioned above) almost nobody
uses vanity addresses any more, so there's not much point in updating
it for bech32(m).
- Remove vanity address security section with unvetted security claims.
- Replace outdated claim about miners using GPUs.
- Remove specific amount for cost of vanity address pooling and URL for
a pool. That pool doesn't work, I don't know of any others, and I
have no idea what the pricing would be even if there were existing
pools.
- Briefly mention segwit and the need for new addresses. Mention that
getting wallets to a new base58check version would probably be only a
little less work than upgrading to an entirely new address format.
Describe the problems with base58check and the solutions provide by
bech32. Illustrate some of the problems and solutions.
- Describe the bech32 length extension issue and provide an example.
- Introduce bech32m as the solution to the lengith extension issue.
- Provide examples using the bech32m reference library for Python for
encoding and decoding a bech32m address (mentioning the backwards
compatibility with bech32 addresses).
- Ask wallet authors to ensure they support forward compatibility with
future segwit versions.
- Start with a description of the problem that P2SH helps solve, the
ability for the receiver to specify a script without having to
communicate all the details of that script to the spender (and having
the spender pay the tx fees for it).
- Mention that P2SH uses base58check. Provide the prefix and continue
using an existing example, but don't go into too much detail since
bech32m addresses are now the preferred format
This is extraneous information. Any programmer who understands how to
create a base58check address can convert to it, or from it, using any
byte encoding supported by their programming language or one of its
libraries.
- A section for scriptPubKey and scriptSig allow us to explain how the
hashes for P2PKH work.
- A section for P2PK allows us to connect P2PKH payments to the original
Bitcoin paper and help us understand the underlying use of pubkeys and
signatures
- A section on P2PKH explains why we use a hash commitment (to save
space) and allows us to separate base58check (and addresses in
general) from scripts. It also helps set up a later section for P2SH.
This was probaby the case on some JS-based private key websites, or when
using something like GPG, but it's unlikely to be the case on any modern
production software.
The commit ab5ae32bae is the last commit
for the second edition, so all changes since then are dropped except for
several commits for the third edition authored by Andreas Antonopoulos.
No attempt is made to remove CC-BY-SA or other licensed content present
in the already-published first or second editions.
This revert may itself be reverted for versions of the book published
under CC-BY-SA.
On the elliptic curve, a line that goes through two different points
with the same `x` coordinates, but different `y` coordinates (they must
be `y` and `-y`) is not "tangent".
David A. Harding