- 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.
Bitcoin Core works fine as a wallet (and I personally use it). Although
it doesn't implement BIP39, it does implement BIP32 and many other
standards, including some significant improvements over other wallets
(such as descriptors and HWI support ). It's also the easiest way to
take advantage of the additional verification and privacy advantages of
running a full node.
- Move "don't need to rely on third parties" to the top of the list
- Add the privacy benefit of a full node
- Clarify that running a full node only makes the network more robust if
you use it to verify your own wallet transactions
- Update resource requirements to their 2023 figures (and mention that
they may increase in the future).
- Be more precise about the minimal data a node needs, e.g. disk space
requirements with pruning enabled and bandwidth in blocks-only mode.
- Mention bandwidth alternatives, like Blockstream Satellite
- Drop text about running on a VPS, since that's not useful to the
network and not sure for anyone using a wallet.
- Add just a few words so users know what the "d" in bitcoind and the
"Unix" in build-unix.md stand for.
- Since the last update to this text, there are instructions for many
more platforms available, so rewrite final sentence to alert users to
them.
- Previous text said Bitcoin (Core) was "completed" before the Nakamoto
paper was written, but Nakamoto sent unfinished code to Hal Finney and
others after the paper was published but prior to the public software
release, suggesting Bitcoin wasn't completed at that time. This also
ignores the two updates (at least) which Nakamoto made to the Bitcoin
paper after the network was started. It also seems much more likely
to me that parts of the code and the paper were written in tandem.
Update text to say "mostly completed" and "published".
- Drop word "authoritative" from the description of Bitcoin Core as a
reference implementation. There's no authority here.
- Change problematic "full network node" language; see edits to previous
chapters.
Previous text didn't explain how including a transaction in a block
gave it security. We add a short explanation here, knowing that we'll
go into more detail in the mining chapter.
This takes up the same amount of space and is (I think) just as easy to
understand, but avoids the indirection of a metaphorical example and
some of the confusions it can create, e.g. that mining is a race to
complete a puzzle rather than a memoryless lottery.
We also remove a later desciption of PoW which is now redundant.
This advice may have been somewhat accurate when the first edition of
this book was published and opt-in replace-by-fee wasn't available, but
that's no longer the case. And now, especially, with default
replace-by-fee on the probable horizon, there's even less safety in
accepting unconfirmed transactions as final without some type of
secondary protection.
- Alice can send her transaction to software that will forward it to a
node for her. This is very common today.
- Previous text used the term "flooding" but the more common phrase for
this particular propagation technique is "gossiping".
Per the updated infobox in CH01, we stop using the name "clients" for
full nodes; they're peers. We also clarify that miners commit effort to
blocks rather than necessary prove them valid.
Introduce the UTXO term as it is one of the most essential concepts to
understanding how Bitcoin works and is widely used in other Bitcoin
technical documentation.
Previous text said that wallets can construct tranactions offline. Add
clarification that this requires the wallet to already know what inputs
it controls.
- Update text to refer to new illustration
- Introduce the term "change output" in addition to existing term
"change address"
- Add information about the privacy advantages of unique change
addresses
- Previous illustration was cut-off, both in the source and the print
edition. We update the illustration to not only correct that but also
provide more accuracy:
- Instead of showing input values, the illustration now shows input
references to prevouts.
- Instead of using BTC denomination, it use satoshis
- Instead of putting tx fees in the output category, it shows them
outside the transaction since they're an implicit value
- The source for the new illustration is provided as a comment to
make future editing easier
- The text is updated to refer to the new illustration appropriately.
- Text now mentions the implicit input value
- We describe that we use satoshi values because that's what's in the
protocol
