1
0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2024-11-27 02:18:25 +00:00
Commit Graph

4413 Commits

Author SHA1 Message Date
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
David A. Harding
ab30a5f0a2 CH05::Intro: re-title and re-introduce
- Retitle from "wallets" to "wallet recovery".  The existing chapter is
  entirely about generating keys in a way that can be recovered after a
  data loss.  I worry that calling this chapter "wallets" results in ignoring
  many other aspects of wallet design, such as how they scan for
  transactions (important for privacy) and how they sign (important for
  security and wallet interoperation).

- Re-introduce the chapter, given the changed name.
2023-02-17 22:32:19 -10:00
David A. Harding
24b31b369e CH05::style: s/BIP-/BIP/ for compatibility with many modern docs 2023-02-17 22:18:34 -10:00
David A. Harding
22c7060518 CH05: reflow text so that future diffs will be more readable 2023-02-17 22:18:34 -10:00
kristen@oreilly.com
caa32f2309 Edited cover.html with Atlas code editor 2023-02-16 09:30:25 -08:00
kristen@oreilly.com
8e7ba28073 Created images/coverER.png 2023-02-16 09:29:43 -08:00
kristen@oreilly.com
5949bf441a Edited author_bio.html with Atlas code editor 2023-02-14 05:35:19 -08:00
kristen@oreilly.com
2a3065a5f0 Edited copyright.html with Atlas code editor 2023-02-14 05:31:30 -08:00
kristen@oreilly.com
d6b1519c3e Updated atlas.json 2023-02-13 13:02:34 -08:00
kristen@oreilly.com
91ea805f94 Edited author_bio.html with Atlas code editor 2023-02-13 13:02:28 -08:00
kristen@oreilly.com
bc087b3a37 Edited copyright.html with Atlas code editor 2023-02-13 13:01:14 -08:00
kristen@oreilly.com
e469016b7c Edited titlepage.html with Atlas code editor 2023-02-13 12:57:13 -08:00
harding
e8de62f48e Updated atlas.json 2023-02-09 23:00:28 -08:00
David A. Harding
fd0aed78e9 CH01-03: edits for feedback from arufino (thanks!) 2023-02-09 20:58:47 -10:00
David A. Harding
23340d43bf CH04: minor edits for consistency, voice, and correctness 2023-02-09 20:58:47 -10:00
David A. Harding
3a3d2181d4 CH04::headings, make various changes to improve logical hierarchy 2023-02-09 20:58:47 -10:00
David A. Harding
03259f9e60 CH04::privkeys: remove address function from here
We'll describe the commitment in the P2PKH section and base58check in
its section.
2023-02-09 20:58:47 -10:00
David A. Harding
1b4e3b7b2b CH04::pubkeys: remove repetitive text 2023-02-09 20:58:47 -10:00
David A. Harding
ceaa898888 CH04::pubkeys: move-only 2023-02-09 20:58:47 -10:00
David A. Harding
f11b3971d2 CH04::terminology: keys prove "control" of BTC, not "ownership" 2023-02-09 20:58:47 -10:00
David A. Harding
5fd0f159ca CH04::base58check: update info for later usage 2023-02-09 20:58:47 -10:00
David A. Harding
eeef3cdd34 CH04::dumpprivkey: remove
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
2023-02-09 20:58:47 -10:00
David A. Harding
ca26228f58 CH04::privkeys: Hash digests aren't numbers
We just choose to interpet them that way
2023-02-09 20:58:47 -10:00
David A. Harding
bf46fef5bf CH04::privkeys: Add warning about generating from coinflips 2023-02-09 20:58:47 -10:00
David A. Harding
9de657b887 CH04::P2SH: describe collision attacks
This will be important for describing why RIPEMD160 isn't used for
segwit.
2023-02-09 20:58:47 -10:00
David A. Harding
206ee88a26 CH04::vanity addresses: update, drop code, clarify security/privacy
- 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.
2023-02-09 20:58:47 -10:00
David A. Harding
132094b670 CH04::legacy addresses: remove code examples
We instead provide an example for bech32 addresses, which are now the
preferred format.
2023-02-09 20:58:47 -10:00
David A. Harding
74c144bbf4 CH04::bech32 and bech32m: add new sections
- 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.
2023-02-09 20:58:47 -10:00