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
Before earlier edits, the second edition text for this chapter was about
buying a cup of coffee. The edits changed it to a laptop. The risk
profile of a cup of coffee and a laptop are different, making some parts
of the text problematic, e.g. Bob accepting payment without waiting for
confirmation.
This update replaces the example with Alice buying a premium podcast
episode, which has a very low risk profile.
Existing text claimed that Alice's unconfirmed transaction completed the
payment to Bob, but Bob would be wise to wait for a $750 transaction to
confirm.
I think this is a problem resulting from a previous edit to the
second-edition text where the example was changed from a cup of coffee
at a cafe to a laptop. A cup of coffee is cheap and has no resale
value, so the chance of fraud is small; a laptop is expensive and has
significant resale value, making fraud a greater risk.
The payment request language is confusing because BIP70 payment requests
look a lot like the URI used here but this is not a BIP70 payment
request (and BIP70 is dead, so we need not describe it).
Instead, update the text to use the more generic word "invoice", which
has the advantage of also being simpler English.
Existing text used "bitcoin" as both the singular and plural unit, which
was not an uncommon practice when the first edition was written.
However, my edits to the first chapter and this update adopt the
practice of using the same pluralization rules used for other
currencies, like the dollar, plus most numbered things in general.
This produces more natural text.
Reference: https://www.chicagomanualofstyle.org/qanda/data/faq/topics/Numbers/faq0058.html
Replace older block explorers with modern alternatives and warn readers
that looking up info on explorers may disclose their interest to third
parties.
Users operating a full node don't need to trust anyone else for certain
guarantees about the system, although they do need at least one honest
peer to obtain some other guarantees. Clarify this in the text by
revising text about text and emergent properties.
Original text claimed that there is no association between a user's
identity and their addresses prior to using that address in most
wallets, but many lightweight wallets send even their not-yet-used
addresses to remote servers to scan for incoming payments. This is
often done over IPv4 or IPv6, which creates a link between the user's
connection and their addresses. Update text by simply dropping this
claim.
SPV verification doesn't require connecting to a full node over the P2P
network. Many clients connect to specially designed tranasctions
servers (e.g. an Electrum server) which provides them with transactions,
SPV proofs, and headers--and provide relay for outgoing transactions.
Update text to remove claims about direct P2P connection.
- The previous text only refers to onchain addresses, but BIP22 URIs,
QR-encoded BIP22 URIs, and offchain invoices (like BOLT11) are the way
many users will now exchange payment information, so the tipbox is
generalized to refer to both addresses and invoices.
- A few words are added to clarify why sharing an address or invoice
doesn't create security risks: Bitcoin is push-only.
- We mention the privacy downsides of sharing addresses or invoices and
encourage generating new addresses for each payment.
- Use "recovery code" instead of "mnemonic phrase" or "seed phrase". A
new tipbox describes that mnemonic implies memorization but that's bad
practice. The phrase recovery code is generic enough to apply to a
variety of schemes, including Electrum seed words, BIP38 seed words,
aezeed, and non-phrase schemes like that used in Muun.
- Be clearer about the difference between "wallet" and "wallet
software".
- Mention that restoring from a code doesn't restore labels or
offchain transaction info.
- Warn about re-entering your code into malware / phishing attacks.
- Full nodes don't need to store transactions long-term or serve data to
other software, so mention those as option
- Stop calling full nodes "clients". Add a tipbox describing that full
nodes are the peers on Bitcoin's P2P network.
- Mention that mobile wallets and web wallets almost universally use
remote servers for scanning, reducing privacy.
- Rename "hardware wallets" to "hardware signing devices". In general,
all these devices do is display info about an unsigned transaction to
a user and then sign it if the user approves. They need to be paired
with other software that implements all of the other wallet behavior.
We rename them accordingly and mention that the security and privacy
of the wallet they pair with plays a role in the user's security and
privacy.
- A key element of the problem is *leaderless* selection; mention this.
- Drop the list of other things PoW helps with. Some of them are very
wrong, e.g. "proving the fairness of elections".
- Bitcoin was invented in 2007 (not 2008) per Nakamoto saying he'd
worked on it for about a year and a half prior to publication. Update
text to just say "first described in 2008"
- Of the inventions Bitcoin combined, b-money wasn't one of them. We
know that Nakamoto sent his original paper to Adam Back, Back told
Nakamoto about Wei Dai's b-mony, and Nakamoto contacted Dai in order
to add the b-money reference to his paper as an example of a previous
related idea. Nakamoto was aparently unaware of b-money before then
and so couldn't have combined it with other ideas in the creation of
bitcoin. Updated text from "b-money" to say "digital signatures",
which is a critical technology that was obviously part of Bitcoin's
original combination.
- The text describes "the" critical invention of Bitcoin as using PoW to
conduct an global election. Although that was critical, other factors
may also have been critical (e.g. difficulty adjustments to keep the
rate of issuance relatively constant). Updated text to say "a"
critical invention.
- Changed Bitcoin from exceeding the combined processing power of top
super computers to exceeding the number of computing operations.
It's not really fair to compare ASICs to general purpose CPU chips;
it's like comparing a wrench to your hand.
- Updated the dollar value of the largest transaction to "over a billion
dollars"; dropped the amount of the transaction fee. I think this
will better future-proof the text.
Previous text mentioned all bitcoins would be mined by 2140, which is
correct but easily confuses people who don't understand exponential
decay into thinking a substantial number of bitcoins will continue to be
mined for a century.
Previous text said they "verify" transactions, but that's not always the
case (e.g. validationless mining) and it may give readers the impression
that the entities primarily responsible for verifying transactions are
miners---when it's actually users who are ultimately responsible for
verifying the transactions they care about.
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.
