1
0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2024-12-24 15:38:08 +00:00
Commit Graph

4090 Commits

Author SHA1 Message Date
David A. Harding
61b18af41b CH07: Update warning about mixing locktimes
We go into more detail about the problems of mixining locktimes, both
CLTV and CSV.
2023-03-30 14:01:06 -10:00
David A. Harding
7b6bc29171 CH07: drop confusing claims about segwit wallet requirements 2023-03-30 14:01:06 -10:00
David A. Harding
90eafb5df8 CH07: Minor: wallets don't need to know what type of wit prog they spend to 2023-03-30 14:01:06 -10:00
David A. Harding
d84c3be909 CH07: clarify P2PKH to P2WPKH conversion 2023-03-30 14:01:06 -10:00
David A. Harding
50795e578f CH07: Remove claim about VERIFY opcodes that doesn't apply to CLTV/CSV
Previous text claimed VERIFY opcodes consumed their inputs, but that's
not the case for upgraded OP_NOP opcodes.
2023-03-30 14:01:06 -10:00
David A. Harding
5ea4e4ef03 CH07: OP_CMS "bug" -> "oddity", with explanation for why it might not be a bug
Details in the diff but there's a case for this not being a bug.
2023-03-30 14:01:06 -10:00
David A. Harding
15d9399521 CH07: tone down beyond-bitcoin applications
Bitcoin can do things beyond money, but (as other text in the chapter
notes) this can be controversial.  Let's not oversell those other uses
here only to throw shade on them later.
2023-03-30 14:01:06 -10:00
David A. Harding
ec534165ba CH07: Switch from M-of-N to K-of-N
Explanation for change is in changed text, but briefly: k-of-n is
clearer when pronounced.
2023-03-30 14:01:06 -10:00
David A. Harding
7417842837 CH07: prefix opcodes with OP_
I think this helps distinguish between opcodes and data
variables/constants.
2023-03-30 14:01:06 -10:00
David A. Harding
8cdac91f1a CH07: drop description of op_return limits
I think this is an overabundance of detail (and I'm not sure it's
correct about a 40-byte release; I think that may have been changed in
the RC phase).

There has also been recent (March 2023) discussion about making this
limit arbitrarily high, so this is something that might become outdated
quickly.
2023-03-30 14:01:06 -10:00
David A. Harding
9acf053805 CH07: drop cafe tx since we're not using that tx 2023-03-30 14:01:06 -10:00
David A. Harding
66c0861b62 CH07: Use term "nested" for P2SH-P2WPKH/P2WSH
This is the phrasing used in BIP141.
2023-03-30 14:01:06 -10:00
David A. Harding
bef3a4e5ae CH07: s/fingerprint/commitment/
This is consistent with phrasing we've used in previous chapters.
2023-03-30 14:01:06 -10:00
David A. Harding
a1d7bd1ecf CH07: drop ref to "programmable money"
I think this could be confusing.  It's not so much that the money is
programmable---in Bitcoin, your money won't go out and take actions on
its own based on programming.  Instead, Bitcoin allows contracts to be
enforced by deterministic full nodes rather than a more arbitrary justice
system.
2023-03-30 14:01:06 -10:00
David A. Harding
107e331b2f CH07: Statlessnes is per-tx not per-script
Some of the information necessary to validate a transaction is contained
within the transaction executing the script, such as the data the
signature commits to plus its locktimes for OP_CLTV & OP_CSV.
2023-03-30 14:01:06 -10:00
David A. Harding
38dd2398ae CH07: correction: the utxo set is not stored in ram 2023-03-30 14:01:06 -10:00
David A. Harding
245adc151d CH07: s/nLocktime/nLockTime/
Matches the style used in Bitcoin Core, which matches the style we use
for other terms in this book.
2023-03-30 14:01:06 -10:00
David A. Harding
6c0368c5c6 CH07: s/BIP-xx/BIPxx/
This is my personal preference.  I think it's maximally concise and
reasonably clear.  It's also popular, which aids in searching.
2023-03-30 14:01:06 -10:00
David A. Harding
22ddf6a202 CH07: replace terms locking/unlocking with sPK/sS/rS/wP/w
Although I understand the desire to use more human-friendly terms than
scriptPubKey, scriptSig, redeemScript, witness program, and witness, I
think it makes things less clear, particularly when we switch from
legacy to legacy P2SH to segwit v0 to segwit v1.

An additional problem is that, with scriptSig no longer being executed
(and witnesses never being executed), it's not quite accurate to use the
phrase "unlocking script".

This commit replaces "locking script" and "unlocking script" with either
the specific data type or with non-specific phrasing.
2023-03-30 14:01:06 -10:00
David A. Harding
d304235d59 CH6/7/8: update link anchors for consistency 2023-03-30 14:01:06 -10:00
David A. Harding
34723bf97a CH07: fix image links now that we're using a file in chapters/ 2023-03-30 14:01:06 -10:00
David A. Harding
b2df51488b [Move only] Move content from CH06 & CH07 to new A&A chapter
A&A = Authorization & Authentication
2023-03-30 14:01:06 -10:00
harding
de5367d5ab Updated atlas.json 2023-03-05 13:48:47 -08:00
harding
7c147c02d0 Updated atlas.json 2023-03-05 13:44:57 -08:00
David A. Harding
fc1de7cf2d CH05: edits suggested by arufino (thanks!) 2023-03-05 11:40:16 -10:00
David A. Harding
f3689a028a Update cross-references 2023-03-05 11:05:36 -10:00
David A. Harding
56c701a6ad C_Txes: edits (nearly complete rewrite)
This chapter, containing parts of previous chapters 6 and 7, is almost
entirely rewritten.

- Instead of introducing concepts in a somewhat arbitrary order, almost
  every section except the last three (coinbase txes, weight, and legacy
  serializitaion) follows the order of transaction fields as seen in
  a P2P serialized transaction.

- We leave details of scripts for the next chapter (authorization &
  authentication), signatures for the chapter after that, and fees and
  fee bumping for the chapter after that (reflecting the increased
  importance of fees).
2023-03-05 11:05:36 -10:00
David A. Harding
4c1a702a48 Move getrawtx example to snippet for reuse 2023-03-05 11:05:36 -10:00
David A. Harding
0a24448da5 [Move only] Move content from CH06 & CH07 to new Transactions chapter 2023-03-05 10:58:12 -10:00
David A. Harding
da42564e86 CH06-7: reflow text so that future diffs will be more readable 2023-03-05 10:54:23 -10:00
David A. Harding
e230df579d CH04: edits suggested by arufino (thanks!) 2023-03-05 10:54:23 -10:00
kristen@oreilly.com
a45b66697f Updated atlas.json 2023-02-22 10:48:15 -08:00
kristen@oreilly.com
1c626ddcca Edited copyright.html with Atlas code editor 2023-02-22 10:35:06 -08:00
kristen@oreilly.com
d12c28d774 Edited theme/epub/layout.html with Atlas code editor 2023-02-22 10:34:29 -08:00
harding
f621e37732 Updated atlas.json 2023-02-18 00:33:49 -08:00
David A. Harding
99a41afdb1 CH05::Implementation details: edits
Edits to the implementation details section to conform to updated
language (wallet->wallet application/database, hardware wallet->hardware
signing device, mnemonic->recovery code) and also to update some
descriptions.
2023-02-17 22:32:19 -10:00
David A. Harding
5ded97927a CH05::Tech details: new section name & intro
Previously this section described all the "best practices" technologies
in detail.  We dropped the best practices section, since there are
multiple valid alternatives, so we need to describe now why we're only
focusing on a subset of the available technologies.
2023-02-17 22:32:19 -10:00
David A. Harding
1f55e04eb0 CH05::xpubs: warn about the gap limit 2023-02-17 22:32:19 -10:00
David A. Harding
331cb5a14a CH05::seeds: explain why entroy is 128/256/512 bits
I think it's probably confusing to people learning about this to see
that BIP32 takes up to 512 bits of entropy, BIP39 accepts up to 256
bits, and Aezeed uses 128 bits, not to mention all the other possible
combinations.  This commit adds a sidebar explaining why you can't get
any better than 256 and that 128 is probably appropriate.
2023-02-17 22:32:19 -10:00
David A. Harding
305a205437 CH05::key stretching: clarify that BIP39 key stretching adds little security 2023-02-17 22:32:19 -10:00
David A. Harding
0605638d38 CH05::remove web-based BIP39 generator/editor
Even in the hands of an expert, the security of these things is dubious.
When used by a novice, there's a pretty high chance of them leaking or
breaking their keys.
2023-02-17 22:32:19 -10:00
David A. Harding
eb7164212e CH05::best practices/using wallet: remove these sections
The previous version of this chapter focused on a single set of
technologies: BIP32 HD wallets, BIP39 seeds, and BIP43/44 paths.  The
previous Best Practices section described these as a de facto standard.

In the rewrite of this chapter, we've introduced several alternatives
for BIP39 seeds and BIP43/44 paths, all of which are good practices.  I
have my opinions about what might best, but I think it's entirely
possible for a reasonable person to conclude one of the other choices is
best, so we remove that section.

The Using A Wallet section was redundant; we've already introduce all of
those concepts.
2023-02-17 22:32:19 -10:00
David A. Harding
c82128839a CH05::HD derivation: extended keys
Previous text said that extended keys were 512 bit concatenations, but
BIP32 includes extra data, including the depth, fingerprint, child
number, and a null byte for private keys.  Update to be less precise but
more accurate.
2023-02-17 22:32:19 -10:00
David A. Harding
960f16645f CH05: add section about backing up path information
- Previously this chapter recommended using the BIP43/44 family of
  implicit paths.  New text starts with an introduction to why path
  information is necessary (thsi was previously at teh end of the
  chapter) and then uses that to describe the two modern ways of dealing
  with paths:

    - Implicit paths, e.g. BIP43/44

    - Expilict paths, e.g. output script descriptors
2023-02-17 22:32:19 -10:00
David A. Harding
a69a1246f1 CH05: add section about backing up non-key data
An often-overlooked backup concern among both wallet developers and
users is labels, which can't be restored from an HD seed.  Also,
wallets for LN and other contract protocols may have additional data
they need to recover all funds.  Mention these concerns and describe the
method used by several wallets (including LND) of encrypting wallet data
to one of the wallet's BIP32-derived keys.
2023-02-17 22:32:19 -10:00
David A. Harding
184ff4d73b CH05::mnemonics: rename and expand
- Rename from Seeds and Mnemonic Codes (BIP39) to Seeds and Recovery Codes

- Describe several notable alternatives to BIP39 and how they improve
  upon it, such as Electrum v2, Aezeed, Muun, and SLIP39.

- Provide a sidebar that goes into detail about recovery code
  passphrases, discussing the tradeoffs related to plausible
  deniability.
2023-02-17 22:32:19 -10:00
David A. Harding
ab15f629a1 CH05::hd wallets: rename and moderately edit
- Rename to HD Key Generation to avoid confusing use of the term
  "wallet"

- Remove detail that's now redundant thanks to the introduction of the
  newly added previous sections.

- Lightly edit the rest.
2023-02-17 22:32:19 -10:00
David A. Harding
40fd08c4b4 CH05::HD wallets: add section for public child key derivation
As we rewrite the opening of the chapter to introduce HD wallets in
stages, this introduces the penultimate part: the ability to create
derived public keys without access to the corresponding private keys.
2023-02-17 22:32:19 -10:00
David A. Harding
d6e05eeaae CH05::determistic key generation:revise
- Use updated terminology introduced in previous commits.

- Provide a very simple example of deterministic key generation.

- Tease the next section.
2023-02-17 22:32:19 -10:00
David A. Harding
0213feb9ce CH05::overview: reduce material about JBOK wallets
There are no modern wallets applications which use
independently-generated keys, except when providing backwards
compatibility, so we reduce the amount of text devoted to this
concept.

We also begin trying to be consistent about using the terms "wallet
application" and "wallet database" it disambiguate the term "wallet".
2023-02-17 22:32:19 -10:00