diff --git a/bech32m.asciidoc b/bech32m.asciidoc new file mode 100644 index 00000000..126889cc --- /dev/null +++ b/bech32m.asciidoc @@ -0,0 +1,5 @@ + +[[bech32m]] +=== SegWit v1 Addresses (bech32m) + +https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki diff --git a/ch03.asciidoc b/ch03.asciidoc index 8865b7df..1f41cdf7 100644 --- a/ch03.asciidoc +++ b/ch03.asciidoc @@ -474,6 +474,7 @@ $ bitcoin-cli getnetworkinfo ---- [source,json] ---- +{ "version": 150000, "subversion": "/Satoshi:0.15.0/", "protocolversion": 70015, diff --git a/ch05.asciidoc b/ch05.asciidoc index eda566f5..ddfaa029 100644 --- a/ch05.asciidoc +++ b/ch05.asciidoc @@ -261,7 +261,7 @@ luggage oxygen faint major edit measure invite love trap field dilemma oblige+ [TIP] ==== -Many wallets do not allow for the creation of wallets with more than a 12 word mnemonic phrase. You will notice from the tables above that despite the unique lengths of entropy input, the seed size remains the same (512 bits). From a security perspective, the amount of entropy actually used for the production of HD wallets is roughly 128 bits, which equals 12 words. Providing more than 12 words produces additional entropy which is unnecessary, and this _unused_ entropy is not used for the derivation of the seed in the way that one might intially suspect. From a usability perspective, 12 words is also easier to write down, back up, and store. +Many wallets do not allow for the creation of wallets with more than a 12 word mnemonic phrase. You will notice from the tables above that despite the unique lengths of entropy input, the seed size remains the same (512 bits). From a security perspective, the amount of entropy actually used for the production of HD wallets is roughly 128 bits, which equals 12 words. Providing more than 12 words produces additional entropy which is unnecessary, and this _unused_ entropy is not used for the derivation of the seed in the way that one might initially suspect. From a usability perspective, 12 words is also easier to write down, back up, and store. ==== [[mnemonic_passphrase]] @@ -478,7 +478,7 @@ However, the little web store became quite successful and attracted many orders Gabriel's HD wallet offers a much better solution through the ability to derive public child keys without knowing the private keys. Gabriel can load an extended public key (xpub) on his website, which can be used to derive a unique address for every customer order. Gabriel can spend the funds from his Trezor, but the xpub loaded on the website can only generate addresses and receive funds. This feature of HD wallets is a great security feature. Gabriel's website does not contain any private keys and therefore does not need high levels of security. -To export the xpub, Gabriel uses the web-based software in conjunction with the Trezor hardware wallet. The Trezor device must be plugged in for the public keys to be exported. Note that hardware wallets will never export private keys—those always remain on the device. <> shows the web interface Gabriel uses to export the xpub. +To export the xpub, Gabriel uses the Trezor Suite desktop app in conjunction with the Trezor hardware wallet. The Trezor device must be plugged in for the public keys to be exported. Note that hardware wallets will never export private keys—those always remain on the device. <> shows what Gabriel sees in Trezor Suite when exporting the xpub. [[export_xpub]] .Exporting an xpub from a Trezor hardware wallet diff --git a/copyright.html b/copyright.html index 75aff723..d182436f 100644 --- a/copyright.html +++ b/copyright.html @@ -3,7 +3,7 @@

by Andreas M. Antonopoulos

-

Copyright © 2017 Andreas M. Antonopoulos, LLC. All rights reserved.

+

Copyright © 2022 aantonop Books, LLC. All rights reserved.

Printed in the United States of America.

@@ -25,12 +25,12 @@
-

Revision History for the Second Edition

+

Revision History for the Third Edition

  • 2017-06-01: First Release
    • @@ -44,12 +44,14 @@

    The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Mastering Bitcoin, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc.

    -

    While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.

    +////change isbn if necessary +

    978-1-491-95438-6

    diff --git a/github_contrib.asciidoc b/github_contrib.asciidoc index a920d15f..feb6fdfd 100644 --- a/github_contrib.asciidoc +++ b/github_contrib.asciidoc @@ -99,6 +99,7 @@ * Liu Yue (lyhistory) * Lobbelt * Lucas Betschart (lclc) +* Matt Wesley (MatthewWesley) * Magomed Aliev (30mb1) * Mai-Hsuan Chia (mhchia) * Marco Falke (MarcoFalke) diff --git a/images/ECDSA.png b/images/ECDSA.png new file mode 100644 index 00000000..32a58782 Binary files /dev/null and b/images/ECDSA.png differ diff --git a/images/Group 4.png b/images/Group 4.png new file mode 100644 index 00000000..dbe38a31 Binary files /dev/null and b/images/Group 4.png differ diff --git a/images/Group.png b/images/Group.png new file mode 100644 index 00000000..b67a9f17 Binary files /dev/null and b/images/Group.png differ diff --git a/images/mbc2_0512.png b/images/mbc2_0512.png index a0d524d0..48c5ec8e 100755 Binary files a/images/mbc2_0512.png and b/images/mbc2_0512.png differ diff --git a/images/schnorr_signatures.png b/images/schnorr_signatures.png new file mode 100644 index 00000000..a5ecd83b Binary files /dev/null and b/images/schnorr_signatures.png differ diff --git a/mast.asciidoc b/mast.asciidoc new file mode 100644 index 00000000..1cc1797f --- /dev/null +++ b/mast.asciidoc @@ -0,0 +1,6 @@ + +[[mast]] +=== Merkleized Abstract Syntax Trees + +[[merkle_branches]] +==== Merkle branches in SegWit v1 diff --git a/schnorr.asciidoc b/schnorr.asciidoc new file mode 100644 index 00000000..a47c5f80 --- /dev/null +++ b/schnorr.asciidoc @@ -0,0 +1,83 @@ +[[schnorr]] +=== Schnorr Signatures + +https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki + +A _Schnorr signature_ is a digital signature scheme for elliptic curves named after the inventor of the algorithm Claus Schnorr. Schnorr signatures were proposed in 1989 and subsequently held under patent by Claus Schnorr until 2008, which coincided with the year of Bitcoin's invention. + +Bitcoin was originally designed to use the Elliptic Curve Digital Signature Algorithm (ECDSA) algorithm. Schnorr signatures are an _alternative_ signature scheme to ECDSA. Schnorr signatures were introduced in Bitcoin in 2021, as part of a _soft fork_ upgrade package called "Taproot". The Bitcoin implementation of Schnorr signatures is specified in BIP-340 found at https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki (see <>). + +Schnorr signatures offer several advantages compared to ECDSA signatures, including _provable security_, _key aggregation_, _batch verification_, and _space efficiency_. These advantages lead to increased privacy and capacity for Bitcoin, when Schnorr signatures are used instead of ECDSA signatures. + +[[why_ecdsa_over_schnorr]] +.Why did Satoshi use ECDSA instead of Schnorr? +**** +If Schnorr signatures are superior to ECDSA signatures, why did Satoshi use ECDSA? + +In 2008, the patent on Schnorr signatures expired, meaning that Satoshi could have used Schnorr signatures in Bitcoin instead of ECDSA. Given the many advantages, we must wonder why Satoshi didn't use Schnorr signatures. + +While we don't have a definitive answer, the commonly accepted reasoning is that in 2008 ECDSA signatures were standardized, well tested and implemented in several broadly used cryptographic libraries (e.g. OpenSSL). In contrast, Schnorr signatures were not standardized or as well studied, probably because the patent prevented them from being broadly used without paying for a license. + +BIP-340 is the culmination of a multi-year research, standardization, and development effort to bring Schnorr signatures to Bitcoin. +**** + +==== Bitcoin's implementation of Schnorr signatures + +Schnorr signatures in Bitcoin are implemented according to BIP-340, which outlines the specific design choices and adaptations made to the Schnorr signature algorithm. Remember that a signature scheme, such as ECDSA or Schnorr, is simply a pair of equations that we can use to respectively produce and verify a signature. For both ECDSA and Schnorr signatures, the corresponding equations can be applied to any elliptic curve, relying on the discrete logarithm problem for their security properties. + +In Bitcoin, Schnorr signatures are applied to the secp256k1 elliptic curve. This is the same elliptic curve chosen by Satoshi that is used for ECDSA signatures. The difference is in the equations used to calculate and verify the signatures. When adapting Schnorr signatures for use in Bitcoin, the developers had to make several design choices that are specific to the security requirements of a decentralized cryptocurrency. In doing so, the Bitcoin developers have _adapted_ and _standardized_ the Schnorr signature algorithm and the encoding of the signatures. When we describe Schnorr signatures in this book, we are therefore describing the specific implentation of Schnorr signatures for Bitcoin, rather than the Schnorr signature scheme in general. + +The BIP-340 document contains more than simply the final implementation of Bitcoin's Schnorr signatures: it describes the various design decisions and the rationale for the choices that were made. While we won't repeat those explanations here, we urge you to read BIP-340 for yourself, so that you may better understand the process and reasoning behind the specification. + +Illustration footnote:[The Schnorr signature illustration is sourced from Stepan Snigirev's article "How Schnorr Signatures May Improve Bitcoin" (https://medium.com/cryptoadvance/how-schnorr-signatures-may-improve-bitcoin-91655bcb4744)] + +[[schnorr_sigs_illustrated]] +.Schnorr signatures illustrated +image::images/schnorr_signatures.png["Schnorr signatures illustrated"] + + +==== Creting a Schnorr signature + +The first part of a signature scheme is the formula used to create the digital signature, which is shown in <>: + +[[schnorr_signing_formula]] +.Bitcoin's Schnorr signing formula +latexmath:[\(s⋅G = R + hash(R || P || m)⋅P\)] + +Let's work through this formula step-by-step, explaining the various components as they are build from the perspective of the software that is signing a specific Bitcoin transaction. + +===== The wallet owner's private key (pk) +First of all, the purpose of Bitcoin digital signatures is to prove ownership and allow spending of bitcoin in a transaction. The owner of the bitcoin is identified by a private key +pk+, which they have kept secret. The owner has derived a corresponding public key +P+, such that latexmath:[\(P = pk⋅G\)]. As a reminder, +G+ is a known and fixed point on the elliptic curve called the _generator point_, used as the starting point for elliptic curve multiplication and public key derivation (see <>). + +===== The ephemeral random value +r+ + +The signing software will randomly generate one more integer (also known as the _emphemeral_ or _nonce_ value) +r+ and corresponding point +R+ such that: + +latexmath:[\(R = r⋅G\)] + +As in ECDSA signatures, it is *essential* to the security of the Schnorr signature scheme that +r+ is indeed random and used only once. Repeating values of +r+ with different messages or signing keys may allow an attacker to guess the signer's private key, defeating the security of the scheme. + +===== The Bitcoin transaction (message) +m+ + +In cryptography, the thing we are signing is called the "message". In Bitcoin, the message is the serialized Bitcoin transaction. Therefore, in the formula the Bitcoin transaction is denoted by the letter +m+, for "message". + +===== The prefixed hash of the message +m+ +The signing software will now calculate a SHA256 hash of the message +m+, prefixed by +R+ and +P+, as follows: + +latexmath:[\(hash( R || P || m )\)] + +In Bitcoin's implementation of Schnorr signatures, the message is prefixed by +R+ and +P+ in the hash formula so as to _bind_ the signed message to those public keys, preventing a class of attacks called "related key attacks". + +===== Calculating the signature value +s+ + +Finally, the signing software calculates a value +s+, using the equation in <>: + +latexmath:[\(s⋅G = R + hash(R || P || m)⋅P\)] + +===== Encoding the signature + +The signature is encoded in the witness of the Bitcoin transaction as a serialized encoding of the pair of values (R, s), which allows anyone to verify the authenticity of the signature. + +===== Verifying the signature + +Given the signature +(R, s)+, the message (Bitcoin transaction) +m+, and the owner's public key +P+ a verifier can evaluate the same formula as in <> and see that the two parts are equal. Since the verifier does not have the private key +pk+ or the nonce value +r+, that were used to produce the points +P+ and +R+ respectively, they cannot themselves calculate a value +s+ that satisfies the formula. They can however, given the value +s+, verify that it works in the equation and thereby verify that the signature is authentic. diff --git a/segwit_v1.asciidoc b/segwit_v1.asciidoc new file mode 100644 index 00000000..cdd5c421 --- /dev/null +++ b/segwit_v1.asciidoc @@ -0,0 +1,5 @@ +[[segwitv1]] +[[taproot]] +=== SegWit v1 + +https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki diff --git a/tapscript.asciidoc b/tapscript.asciidoc new file mode 100644 index 00000000..2450e0b0 --- /dev/null +++ b/tapscript.asciidoc @@ -0,0 +1,6 @@ + +[[taproot_scripts]] +[[tapscript]] +=== Taproot Scripts (Tapscript) + +https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki diff --git a/third_edition_changes.asciidoc b/third_edition_changes.asciidoc new file mode 100644 index 00000000..5556439f --- /dev/null +++ b/third_edition_changes.asciidoc @@ -0,0 +1,249 @@ +== Third Edition Changes + +=== 1. Introduction + +* Bitcoin Uses, Users, and Their Stories + + Minor changes to the stories, updating to reflect current common uses and current price + +=== 2. How Bitcoin Works + +* Buying a [line-through]#Cup of Coffee# Laptop + + Updated Alice and Bob's story. Buying a cup of coffee is no longer sensible "on-chain", due to the value of Bitcoin and on-chain fees. Instead, small retail purchases are now a use-case for the Lightning Network. In the updated story, Alice is buying a laptop from an e-commerce store run by Bob. + +* Bitcoin Transactions + + Updated all the transactions to use native-Segwit addresses that start with "bc1", instead of legacy bitcoin addresses that start with "1". + +* Transaction Inputs and Outputs +* Transaction Chains +* Making Change +* Common Transaction Forms +* Constructing a Transaction +* Getting the Right Inputs +* Creating the Outputs +* Adding the Transaction to the Ledger +* Bitcoin Mining +* Mining Transactions in Blocks +* Spending the Transaction + +=== 3. Bitcoin Core: The Reference Implementation +* Bitcoin Development Environment +* Compiling Bitcoin Core from the Source Code +* Selecting a Bitcoin Core Release +* Configuring the Bitcoin Core Build +* Building the Bitcoin Core Executables +* Running a Bitcoin Core Node +* Configuring the Bitcoin Core Node +* Bitcoin Core Application Programming Interface (API) +* Getting Information on the Bitcoin Core Client Status +* Exploring and Decoding Transactions +* Exploring Blocks +* Using Bitcoin Core’s Programmatic Interface +* Alternative Clients, Libraries, and Toolkits +* C/C++ +* JavaScript +* Java +* PHP +* Python +* Ruby +* Go +* Rust +* C# +* Objective-C +=== 4. Keys, Addresses +* Introduction +* Public Key Cryptography and Cryptocurrency +* Private and Public Keys +* Private Keys +* Public Keys +* Elliptic Curve Cryptography Explained +* Generating a Public Key +* Bitcoin Addresses +* Base58 and Base58Check Encoding +* Key Formats +* Implementing Keys and Addresses in C++ +* Implementing Keys and Addresses in Python +* Advanced Keys and Addresses +* Encrypted Private Keys (BIP-38) +* Pay-to-Script Hash (P2SH) and Multisig Addresses +* Vanity Addresses +* Paper Wallets +=== 5. Wallets +* Wallet Technology Overview +* Nondeterministic (Random) Wallets +* Deterministic (Seeded) Wallets +* HD Wallets (BIP-32/BIP-44) +* Seeds and Mnemonic Codes (BIP-39) +* Wallet Best Practices +* Using a Bitcoin Wallet +* Wallet Technology Details +* Mnemonic Code Words (BIP-39) +* Creating an HD Wallet from the Seed +* Using an Extended Public Key on a Web Store +=== 6. Transactions +* Introduction +* Transactions in Detail +* Transactions—Behind the Scenes +* Transaction Outputs and Inputs +* Transaction Outputs +* Transaction Inputs +* Transaction Fees +* Adding Fees to Transactions +* Transaction Scripts and Script Language +* Turing Incompleteness +* Stateless Verification +* Script Construction (Lock + Unlock) +* Pay-to-Public-Key-Hash (P2PKH) +* Digital Signatures (ECDSA) +* How Digital Signatures Work +* Verifying the Signature +* Signature Hash Types (SIGHASH) +* ECDSA Math +* The Importance of Randomness in Signatures +* *NEW: Schnorr Signatures* +* +Bitcoin Addresses, Balances, and Other Abstractions +=== 7. Advanced Transactions And Scripting +* Introduction +* Multisignature +* Pay-to-Script-Hash (P2SH) +* P2SH Addresses +* Benefits of P2SH +* Redeem Script and Validation +* Data Recording Output (RETURN) +* Timelocks +* Transaction Locktime (nLocktime) +* Check Lock Time Verify (CLTV) +* Relative Timelocks +* Relative Timelocks with nSequence +* Relative Timelocks with CSV +* Median-Time-Past +* Timelock Defense Against Fee Sniping +* Scripts with Flow Control (Conditional Clauses) +* Conditional Clauses with VERIFY Opcodes +* Using Flow Control in Scripts +* Complex Script Example +* Segregated Witness +* Why Segregated Witness? +* How Segregated Witness Works +* Soft Fork (Backward Compatibility) +* Segregated Witness Output and Transaction Examples +* Upgrading to Segregated Witness +* Segregated Witness’ New Signing Algorithm +* Economic Incentives for Segregated Witness +* *NEW: Segwit v1: Taproot* +* *NEW: MAST * +* *NEW: Tapscript* +* *NEW: Taproot * +=== 8. The Bitcoin Network +* Peer-to-Peer Network Architecture +* Node Types and Roles +* The Extended Bitcoin Network +* Bitcoin Relay Networks +* Network Discovery +* Full Nodes +* Exchanging “Inventory” +* Simplified Payment Verification (SPV) Nodes +* Bloom Filters +* How Bloom Filters Work +* How SPV Nodes Use Bloom Filters +* SPV Nodes and Privacy +* NEW Neutrino +* NEW Compact Blocks +* Encrypted and Authenticated Connections +* Tor Transport +* Peer-to-Peer Authentication and Encryption +* Transaction Pools +=== 9. The Blockchain +* Introduction +* Structure of a Block +* Block Header +* Block Identifiers: Block Header Hash and Block Height +* The Genesis Block +* Linking Blocks in the Blockchain +* Merkle Trees +* Merkle Trees and Simplified Payment Verification (SPV) +* Bitcoin’s Test Blockchains +* Testnet—Bitcoin’s Testing Playground +* Segnet—The Segregated Witness Testnet +* Regtest—The Local Blockchain +* *NEW: Signet - The POA Test Blockchain* +* Using Test Blockchains for Development +=== 10. Mining And Consensus +* Introduction +* Bitcoin Economics and Currency Creation +* Decentralized Consensus +* Independent Verification of Transactions +* Mining Nodes +* Aggregating Transactions into Blocks +* The Coinbase Transaction +* Coinbase Reward and Fees +* Structure of the Coinbase Transaction +* Coinbase Data +* Constructing the Block Header +* Mining the Block +* Proof-of-Work Algorithm +* Target Representation +* Retargeting to Adjust Difficulty +* Successfully Mining the Block +* Validating a New Block +* Assembling and Selecting Chains of Blocks +* Blockchain Forks +* Mining and the Hashing Race +* The Extra Nonce Solution +* Mining Pools +* Consensus Attacks +* Changing the Consensus Rules +* Hard Forks +* Hard Forks: Software, Network, Mining, and Chain +* Diverging Miners and Difficulty +* Contentious Hard Forks +* Soft Forks +* Criticisms of Soft Forks +* Soft Fork Signaling with Block Version +* BIP-34 Signaling and Activation +* BIP-9 Signaling and Activation +* NEW BIP-8 Activation +* *NEW: Speedy Trial Activation* +* Consensus Software Development +=== 11. Bitcoin Security +* Security Principles +* Developing Bitcoin Systems Securely +* The Root of Trust +* User Security Best Practices +* Physical Bitcoin Storage +* Hardware Wallets +* Balancing Risk +* Diversifying Risk +* Multisig and Governance +* Survivability +* Conclusion +=== 12. Blockchain Applications +* Introduction +* Building Blocks (Primitives) +* Applications from Building Blocks +* Colored Coins +* Using Colored Coins +* Issuing Colored Coins +* Colored Coins Transactions +* Counterparty +* Payment Channels and State Channels +* State Channels—Basic Concepts and Terminology +* Simple Payment Channel Example +* Making Trustless Channels +* Asymmetric Revocable Commitments +* Hash Time Lock Contracts (HTLC) +* Routed Payment Channels (Lightning Network) +* Basic Lightning Network Example +* Lightning Network Transport and Routing +* Lightning Network Benefits +* Conclusion +=== A. The Bitcoin Whitepaper By Satoshi Nakamoto +=== B. Transaction Script Language Operators, Constants, And Symbols +=== C. Bitcoin Improvement Proposals +=== D. Bitcore +=== E. Pycoin, Ku, And Tx +=== F. Bitcoin Explorer (Bx) Commands +=== *NEW: BTCD* diff --git a/titlepage.html b/titlepage.html index 13fb89b8..4b24e536 100644 --- a/titlepage.html +++ b/titlepage.html @@ -1,6 +1,6 @@

    Mastering Bitcoin

    -

    Second Edition

    +

    Third Edition

    Programming the Open Blockchain

    Andreas M. Antonopoulos