1
0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2024-12-04 22:08:23 +00:00
Commit Graph

5022 Commits

Author SHA1 Message Date
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
David A. Harding
91eae20099 CH04::P2SH: remove multisig, describe p2sh rationale, give examples
- 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
2023-02-09 20:58:47 -10:00
David A. Harding
708545a446 CH04::P2SH: move only
Put it after base58check in the history of addresses, rather than in the
advanced addresses section at the end.
2023-02-09 20:58:47 -10:00
David A. Harding
8c5b2fd291 CH04::privkey formats: add sidebar about format relevancy
Most software today doesn't export or import private keys, so add a
sidebar noting that this section is mainly for historical reasons.
2023-02-09 20:58:47 -10:00
David A. Harding
bdf31e90af CH04::private key formats: move-only 2023-02-09 20:58:47 -10:00
David A. Harding
1ddec1538e CH04::encrypted private keys: drop
These were always a bad idea and they've been superceded both in
theory and in practice by HD wallets.
2023-02-09 20:58:47 -10:00
David A. Harding
915b961d41 CH04::compressed pubkeys: merge with "pubkey formats"
This reduces repitive text, provides a better introducion to compressed
pubkeys, and updates adoption claims.
2023-02-09 20:58:47 -10:00
David A. Harding
e4c8d67956 CH04: Drop section about hex to base58check
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.
2023-02-09 20:58:47 -10:00
David A. Harding
97ba0810c1 CH04: added sectios for spk/ss, P2PK, and P2PKH
- 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.
2023-02-09 20:58:47 -10:00
David A. Harding
e5e465c4b0 CH04::paper wallets: update terminology
s/mnemonic/recovery code/
s/hardware wallet/hardware signing device/
2023-02-09 20:58:47 -10:00
David A. Harding
8e879b658a CH04::ecc: Replace OpenSSL callout with libsecp256k1 2023-02-09 20:58:47 -10:00
David A. Harding
64e9c3d7a7 CH04::privkeys: drop note about human-generated randomness
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.
2023-02-09 20:58:47 -10:00
David A. Harding
a906f0735f CH04::privkeys: update for HD wallets
- Previously said privkeys were numbers picked at random.  Updated to
  say "derived from numbers picked at random".
2023-02-09 20:58:47 -10:00
David A. Harding
94f864cda4 CH04::intro: retitle and replace intro
- Introduce the problem keys solve (pseudonymonous encumbrance and
  satisfaction) and tell the user that we'll build up to addresses
2023-02-09 20:58:47 -10:00
David A. Harding
c604a1650a CH04: reflow text so that future diffs will be more readable 2023-02-09 20:58:47 -10:00
harding
c186d15390 Updated atlas.json 2023-02-05 15:43:25 -08:00
David A. Harding
809e4e025a CH03: minor edits for consistency, voice, and correctness 2023-02-05 13:33:02 -10:00
David A. Harding
5d21bc3726 CH03::API: Bitcoin Core no longer provides native SSL (HTTPS) support 2023-02-05 13:33:02 -10:00
David A. Harding
204cc7572e CH03::intro: clarify what open source means
Having an open community is not required.
2023-02-05 13:33:02 -10:00
David A. Harding
33402f685d Anchors: rename "cup_of_coffee" to "spending_bitcoin" 2023-02-05 13:33:02 -10:00
David A. Harding
6056b0438b CH03::Bitcoin Core wallet warning: drop
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.
2023-02-05 13:33:02 -10:00
David A. Harding
4131102e9c CH03::malleability: correct statement about malleability after confirmation
Txids can be mutated after confirmation, it's just rare.  Update text to
state this.
2023-02-05 13:33:02 -10:00
David A. Harding
aa316f415b CH03::config: update/clarify configuration option descriptions 2023-02-05 13:33:02 -10:00
David A. Harding
b8a1ef31ad CH03::running a node: clarify benefits
- 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
2023-02-05 13:33:02 -10:00
David A. Harding
8e9fc4485c CH03::running a node: update resource requirements
- 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.
2023-02-05 13:33:02 -10:00
David A. Harding
ff1d3fb92e CH03::building: mention daemon & Unix; link to other instructions
- 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.
2023-02-05 13:33:02 -10:00
David A. Harding
5f2c61e71b CH03::shell & code examples: update for 2023 2023-02-05 13:33:02 -10:00
David A. Harding
922ef94b6d CH03::intro: correct Nakamoto facts; clarify Bitcoin Core details
- 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.
2023-02-05 13:33:02 -10:00
David A. Harding
69caac4b17 CH03: reflow text so that future diffs will be more readable 2023-02-05 13:33:02 -10:00
David A. Harding
05c956e6a9 CH02: minor edits for consistency, voice, and correctness 2023-02-05 13:33:02 -10:00
David A. Harding
e472d344af CH02::mining: explain how confirmations add security
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.
2023-02-05 13:33:02 -10:00
David A. Harding
cb3420c572 CH02::mining: replace sudoku example with accurate description
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.
2023-02-05 13:33:02 -10:00
David A. Harding
2612342b9e CH02::mining: clarify what security miners provide re: valid txes 2023-02-05 13:33:02 -10:00
David A. Harding
08c1b635a1 CH02::mining: clarify that putting txes in blocks isn't hard
It's just forming the header correctly that's hard.

Also remove the word trust, since Bitcoin doesn't depend on "trust in
computation".
2023-02-05 13:33:02 -10:00
David A. Harding
a543abe388 CH02::Bobs view: remove tipbox about unconfirmed safety
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.
2023-02-05 13:33:02 -10:00
David A. Harding
e338f0ddc7 CH02::Bobs view: clarify what Bob's wallet sees (peer vs client)
Clarify what Bob's wallet can see if it's a lightweight client versus a
full node peer.
2023-02-05 13:33:02 -10:00
David A. Harding
fddaace478 CH02::propagation: mention non-node relay and s/flooding/gossiping/
- 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".
2023-02-05 13:33:02 -10:00
David A. Harding
8aa01e03aa CH02::propagation: define full node / peer 2023-02-05 13:33:02 -10:00
David A. Harding
3af9bb8e93 CH02::tx propagation: use "full node" and "lightweight client"
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.
2023-02-05 13:33:02 -10:00
David A. Harding
a40d5456f3 CH02: remove some more unnecessary specific values
Will make updating the text in the future easier.
2023-02-05 13:33:02 -10:00
David A. Harding
ab4935b2a8 CH02::creating outputs: remove block explorer image
Don't have enough space for readable text at a good resolution.
There's still a link for anyone who wants to see the tx.
2023-02-05 13:33:02 -10:00
David A. Harding
1601de2634 CH02::getting inputs: update example for new input for Alice
This uses the same address used in the updated CH01 screenshots.

We also mention that the output index number and script are needed for
spending.
2023-02-05 13:33:02 -10:00