diff --git a/appb_errata.adoc b/appb_errata.adoc index 373affe6..c65c8a21 100644 --- a/appb_errata.adoc +++ b/appb_errata.adoc @@ -36,12 +36,12 @@ occurred in July 2010, long after Bitcoin’s initial release: - if (pindexNew->nHeight > nBestHeight) + if (pindexNew->bnChainWork > bnBestChainWork) ---- -* *Terminology change:* General CPUs were used to generate the POW for -the earliest Bitcoin blocks, but POW generation today is mostly performed +* *Terminology change:* General CPUs were used to generate the PoW for +the earliest Bitcoin blocks, but PoW generation today is mostly performed by specialist Application Specific Integrated Circuits (ASICs), so instead of saying "CPU power" it is perhaps more correct to say "computational power" or, simply, "hash rate" for the hashing used -in generating the POW. +in generating the PoW. ____ "As long as a majority of CPU power is controlled by nodes that are not diff --git a/ch01_intro.adoc b/ch01_intro.adoc index 34526736..9bf8eaf8 100644 --- a/ch01_intro.adoc +++ b/ch01_intro.adoc @@ -133,7 +133,7 @@ computing, known as the "Byzantine Generals' Problem." Briefly, the problem consists of trying to get multiple participants without a leader to agree on a course of action by exchanging information over an unreliable and potentially compromised network. Satoshi Nakamoto's solution, which uses the concept of -Proof-of-Work to achieve consensus _without a central trusted +proof of work to achieve consensus _without a central trusted authority_, represents a breakthrough in distributed computing. **** diff --git a/ch02_overview.adoc b/ch02_overview.adoc index 2a482002..5a266091 100644 --- a/ch02_overview.adoc +++ b/ch02_overview.adoc @@ -14,8 +14,7 @@ transactions, the network, and mining. === Bitcoin Overview -In the ((("Bitcoin", "operational overview", id="bitcoin-operational-overview-ch2")))((("blockchain explorers", id="blockchain-explorers")))overview diagram shown in <>, we see that the -Bitcoin system consists of users with wallets containing keys, +The ((("Bitcoin", "operational overview", id="bitcoin-operational-overview-ch2")))((("blockchain explorers", id="blockchain-explorers")))Bitcoin system consists of users with wallets containing keys, transactions that are propagated across the network, and miners who produce (through competitive computation) the consensus blockchain, which is the authoritative journal of all transactions. @@ -30,10 +29,6 @@ application that operates as a Bitcoin search engine, in that it allows you to search for addresses, transactions, and blocks and see the relationships and flows between them. -[[bitcoin-overview]] -.Bitcoin overview -image::images/mbc3_0201.png["Bitcoin Overview"] - Popular blockchain explorers include: * https://blockstream.info[Blockstream Explorer] diff --git a/ch04_keys.adoc b/ch04_keys.adoc index 02229c08..e17ebb76 100644 --- a/ch04_keys.adoc +++ b/ch04_keys.adoc @@ -63,10 +63,10 @@ from the private key, so storing only the private key is also possible. A Bitcoin wallet contains a collection of key pairs, each consisting of a private key and a public key. The private -key (k) is a number, usually derived from a number picked at random. +key (_k_) is a number, usually derived from a number picked at random. From the private key, we use elliptic curve multiplication, a one-way cryptographic function, to -generate a public((("public key cryptography", startref="pub-key")))((("key pairs", startref="key-pair"))) key (K). +generate a public((("public key cryptography", startref="pub-key")))((("key pairs", startref="key-pair"))) key (_K_). .Why Use Asymmetric Cryptography (Public/Private Keys)? **** @@ -118,15 +118,15 @@ or repeatable. Bitcoin software uses cryptographically secure random number generators to produce 256 bits of entropy. More precisely, the private key can be any number between 0 and n - -1 inclusive, where n is a constant (n = 1.1578 × 10^77^, slightly less +1 inclusive, where _n_ is a constant (_n_ = 1.1578 × 10^77^, slightly less than 2^256^) defined as the order of the elliptic curve used in Bitcoin (see <>). To create such a key, we randomly pick a -256-bit number and check that it is less than +n+. In programming terms, +256-bit number and check that it is less than _n_. In programming terms, this is usually achieved by feeding a larger string of random bits, collected from a cryptographically secure source of randomness, into the SHA256 hash algorithm, which will conveniently produce a 256-bit value that can be interpreted as a number. -If the result is less than +n+, we have a suitable private key. +If the result is less than _n_, we have a suitable private key. Otherwise, we simply try again with another random number. [WARNING] @@ -140,7 +140,7 @@ choose to make sure it is cryptographically secure. Correct implementation of the CSPRNG is critical to the security of the keys. ==== -The following is a randomly generated private key (k) shown in +The following is a randomly generated private key (_k_) shown in hexadecimal format (256 bits shown as 64 hexadecimal digits, each 4 bits): @@ -167,7 +167,7 @@ curve. by Bitcoin. [[ecc-curve]] -[role="width-80"] +[role="width-50"] .An elliptic curve image::images/mbc3_0402.png["ecc-curve"] @@ -341,12 +341,10 @@ Implementing the elliptic curve multiplication, we take the private key _k_ generated previously and multiply it with the generator point _G_ to find the public key _K_: -[latexmath] -++++ -\begin{equation} -{K = 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD \times G} -\end{equation} -++++ +[source, python] +---- +K = 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD * G +---- Public key _K_ is defined as a point K = (x, y): @@ -1087,7 +1085,7 @@ The "32" stands for the number of characters in the bech32 alphabet .Bech32 typo detection ==== Address: - bc1p9nh05ha8wrljf7ru236aw**n**4t2x0d5ctkkywm**v**9sclnm4t0av2vgs4k3au7 + bc1p9nh05ha8wrljf7ru236awpass:[n]4t2x0d5ctkkywm**v**9sclnm4t0av2vgs4k3au7 Detected errors shown in bold. Generated using the https://oreil.ly/paWIx[bech32 address decoder demo]. @@ -1633,7 +1631,7 @@ Once a vanity address matching the desired pattern is found, the private key from which it was derived can be used by the owner to spend bitcoins in exactly the same way as any other address. Vanity addresses are no less or more secure than any other address. They depend on the same -elliptic curve cryptography (ECC) and SHA as any other address. You can +elliptic curve cryptography (ECC) and secure hash algorithm (SHA) as any other address. You can no more easily find the private key of an address starting with a vanity pattern than you can any other address. diff --git a/ch05_wallets.adoc b/ch05_wallets.adoc index 05b66944..687e13b7 100644 --- a/ch05_wallets.adoc +++ b/ch05_wallets.adoc @@ -141,7 +141,7 @@ simply adding the same value to both sides of the equation: [latexmath] ++++ \begin{equation} -K + (123 \times G) == (k + 123) \times G +K + (123 \times G) =\!= (k + 123) \times G \end{equation} ++++ @@ -149,13 +149,13 @@ K + (123 \times G) == (k + 123) \times G [TIP] ==== In equations throughout this book, we use a single equals sign for -operations such as K = k × G where the value of a variable is +operations such as _K_ = _k_ × _G_ where the value of a variable is calculated. We use a double equals sign to show both sides of an equation are equivalent, or that an operation should return false (not true) if the two sides aren't equivalent. ==== -An interesting consequence of this is that adding `123` to the public +An interesting consequence of this is that adding 123 to the public key can be done using entirely public information. For example, Alice generates public key _K_ and gives it to Bob. Bob doesn't know the private key, but he does know the global constant _G_, so he can add any @@ -1053,7 +1053,7 @@ hash is used to create a _master private key_ (m) and a _master chain code_ (c). The master private key (m) then generates a corresponding master public -key (M) using the normal elliptic curve multiplication process __m × G__ +key (M) using the normal elliptic curve multiplication process m × _G_ that we saw in <>. The chain code (c) is used to introduce entropy in the function that @@ -1318,11 +1318,6 @@ To export the xpub from his Trezor hardware signing device, Gabriel uses the web-based Trezor wallet application. The Trezor device must be plugged in for the public keys to be exported. Note that most hardware signing devices will never export private keys--those always remain on the device. -<> shows the web interface Gabriel uses to export the xpub. - -[[export_xpub]] -.Exporting an xpub from a Trezor hardware signing device -image::images/mbc3_0509.png["Exporting the xpub from the Trezor"] Gabriel copies the xpub to his web store's Bitcoin payment processing software, such as the widely used open source BTCPay Server. diff --git a/ch06_transactions.adoc b/ch06_transactions.adoc index b2564d0c..330f6961 100644 --- a/ch06_transactions.adoc +++ b/ch06_transactions.adoc @@ -228,22 +228,22 @@ unsigned integers: -

>= 0 && <= 252 (0xfc)

+

≥ 0 && ≤ 252 (0xfc)

1

uint8_t

-

>= 253 && <= 0xffff

+

≥ 253 && ≤ 0xffff

3

0xfd followed by the number as uint16_t

-

>= 0x10000 && <= 0xffffffff

+

≥ 0x10000 && ≤ 0xffffffff

5

0xfe followed by the number as uint32_t

-

>= 0x100000000 && <= 0xffffffffffffffff

+

≥ 0x100000000 && ≤ 0xffffffffffffffff

9

0xff followed by the number as uint64_t

@@ -276,7 +276,7 @@ control over bitcoins is assigned in transaction outputs, Alice _points_ to the previous _output_ using an _outpoint_ field. Each input must contain a single outpoint. -The outpoint contains a 32-byte transaction identifier (_txid_) for the +The outpoint contains a 32-byte txid for the transaction where Alice received the bitcoins she now wants to spend. This txid is in Bitcoin's internal byte order for hashes; see <>. @@ -325,7 +325,7 @@ Different approaches to tracking previous outputs have been tried by different full node implementations at various times. Bitcoin Core currently uses the solution believed to be most effective at retaining all necessary information while minimizing disk space: it keeps a -database that stores every unspent transaction output (UTXO) and +database that stores every UTXO and essential metadata about it (like its confirmation block height). Each time a new block of transactions arrives, all of the outputs they spend are removed from the UTXO database and all of the outputs they create @@ -986,23 +986,23 @@ be received to witness programs and spent with the witness structure. The terms

Authorization

-

Authentication

+

Authentication

Whitepaper

Public key

-

Signature

+

Signature

Original (Legacy)

Output script

-

Input script

+

Input script

Segwit

Witness program

-

Witness structure

+

Witness structure

diff --git a/ch07_authorization-authentication.adoc b/ch07_authorization-authentication.adoc index c32c319d..246efb8f 100644 --- a/ch07_authorization-authentication.adoc +++ b/ch07_authorization-authentication.adoc @@ -1383,8 +1383,7 @@ satisfy that redeem script, all inside the transaction input: Now, let's look at how this entire example would be upgraded to segwit v0. If Mohammed's customers were using a segwit-compatible wallet, they -would make a payment, creating a pay to witness script hash (P2WSH) -output that would look like this: +would make a payment, creating a P2WSH output that would look like this: .Example P2WSH output script ---- diff --git a/ch08_signatures.adoc b/ch08_signatures.adoc index 4e81b552..90638695 100644 --- a/ch08_signatures.adoc +++ b/ch08_signatures.adoc @@ -409,7 +409,7 @@ brute force is easy; the numbers used in Bitcoin are much larger. Let's discuss some of the features of the interactive schnorr identity protocol that make it secure: -The nonce ([.plain]#k#):: +The nonce (k):: In step 1, ((("digital signatures", "schnorr signature algorithm", "security features")))((("schnorr signature algorithm", "security features")))Alice chooses a number that Bob doesn't know and can't guess and gives him the scaled form of that number, _kG_. At that point, Bob also already has her public key (_xG_), @@ -424,7 +424,7 @@ In step 1, ((("digital signatures", "schnorr signature algorithm", "security fea be able to leverage that into figuring out Alice's private key. See <> for more details. -The challenge scalar ([.plain]#e#):: +The challenge scalar (e):: Bob waits to receive Alice's public nonce and then proceeds in step 2 to give her a number (the challenge scalar) that Alice didn't previously know and couldn't have guessed. @@ -674,8 +674,7 @@ MuSig2:: This only ((("MuSig2 protocol")))requires two rounds of communication and can sometimes allow one of the rounds to be combined with key exchange. This can significantly speed up signing for certain protocols, such as how - scriptless multisignatures are planned to be used in the Lightning - Network. MuSig2 is specified in BIP327 (the only scriptless + scriptless multisignatures are planned to be used in the LN. MuSig2 is specified in BIP327 (the only scriptless multisignature protocol that has a BIP as of this writing). MuSig-DN:: @@ -903,7 +902,7 @@ the following DER-encoded signature: b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e381301 ---- -That signature is a serialized byte stream of the +R+ and _s_ values +That signature is a serialized byte stream of the _R_ and _s_ values produced by the signer to prove control of the private key authorized to spend an output. The serialization format consists of nine elements as follows: diff --git a/ch09_fees.adoc b/ch09_fees.adoc index 23d4cb7f..06bf005e 100644 --- a/ch09_fees.adoc +++ b/ch09_fees.adoc @@ -590,7 +590,7 @@ miners: [latexmath] ++++ \begin{equation} -{Fees = Sum(Inputs) – Sum(Outputs)} +{Fees = Sum(Inputs) - Sum(Outputs)} \end{equation} ++++ diff --git a/ch12_mining.adoc b/ch12_mining.adoc index 7e622d30..a4ab7b5f 100644 --- a/ch12_mining.adoc +++ b/ch12_mining.adoc @@ -385,7 +385,7 @@ transaction fees: [latexmath] ++++ \begin{equation} -Total Fees = Sum(Inputs) - Sum(Outputs) +Total\:Fees = Sum(Inputs) - Sum(Outputs) \end{equation} ++++ @@ -858,7 +858,7 @@ is: ++++
    -
  • target = coefficient * 2(8*(exponent–3))
    • +
  • target = coefficient * 2(8*(exponent – 3))
++++ @@ -866,9 +866,7 @@ Using that formula, and the difficulty bits value 0x1903a30c, we get: ++++
    -
  • target = 0x03a30c * 20x08*(0x19-0x03)
    • -
  • => target = 0x03a30c * 2(0x08*0x16)
    • -
  • => target = 0x03a30c * 20xB0
    • +
  • target = 0x03a30c × 20x08 × (0x19 - 0x03)
++++ @@ -876,16 +874,15 @@ which in decimal is: ++++
    -
  • => target = 238,348 * 2176
    • -
  • => target =
    22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,575,715,328
    • +
  • 22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,575,715,328
++++ -switching back to hexadecimal: +Or, in hexadecimal: ++++
    -
  • => target =
    0x0000000000000003A30C00000000000000000000000000000000000000000000
    • +
  • 0x0000000000000003A30C00000000000000000000000000000000000000000000
++++ @@ -944,7 +941,7 @@ resulting in a retargeting bias toward higher difficulty by 0.05%. <> shows the code used in the Bitcoin Core client. [[retarget_code]] -.Retargeting the proof of work—[.plain]#++CalculateNextWorkRequired()++# in pow.cpp +.Retargeting the proof of work—[.plain]#++CalculateNextWorkRequired()++# in pow.cpp ==== [source,cpp] ---- diff --git a/ch14_applications.adoc b/ch14_applications.adoc index aa14a730..31168ba9 100644 --- a/ch14_applications.adoc +++ b/ch14_applications.adoc @@ -339,9 +339,8 @@ Translated forwarding:: support forwarding bitcoin payments. Native forwarding is conceptually simpler but essentially requires a -separate Lightning Network for every asset. Translated forwarding -allows building on the economies of scale of the Bitcoin Lightning -Network, but it may be vulnerable to a problem called((("free American call option"))) the _free American +separate LN for every asset. Translated forwarding +allows building on the economies of scale of the Bitcoin LN, but it may be vulnerable to a problem called((("free American call option"))) the _free American call option_, where a receiver may selectively accept or reject certain payments depending on recent changes to the exchange rate in order to siphon money from the hop next to them. Although there's no known @@ -712,8 +711,7 @@ Even though a transaction cannot be canceled, it can be constructed in such a way as to make it undesirable to use. The way we do that is by giving each party a _revocation key_ that can be used to punish the other party if they try to cheat. This mechanism for revoking prior -commitment transactions was first proposed as part of the Lightning -Network. +commitment transactions was first proposed as part of the LN. To explain revocation keys, we will construct a more complex payment channel between two exchanges run by Hitesh and Irene. Hitesh and Irene @@ -909,8 +907,7 @@ Asymmetric revocable commitments with relative time locks (+CSV+) are a much better way to implement payment channels and a very significant innovation in this technology. With this construct, the channel can remain open indefinitely and can have billions of intermediate -commitment transactions. In implementations of Lightning -Network, the commitment state is identified by a 48-bit index, allowing +commitment transactions. In implementations of LN, the commitment state is identified by a 48-bit index, allowing more than 281 trillion (2.8 × 10^14^) state transitions in ((("payment channels", "asymmetric revocable commitments", startref="payment-channel-revoke")))((("asymmetric revocable commitments", startref="asymmetric-revoke-commit")))((("commitment transactions", "asymmetric revocable commitments", startref="commit-revoke")))((("revocable commitments", startref="revoke-commit")))any single channel. @@ -996,12 +993,11 @@ to Carol, Carol to Diana, and Diana to Eric. For simplicity let's assume each channel is funded with 2 bitcoins by each participant, for a total capacity of 4 bitcoins in each channel. -<> shows five participants in a Lightning -Network, connected by bidirectional payment channels that can be linked +<> shows five participants in an LN, connected by bidirectional payment channels that can be linked to make a payment from Alice to Eric (see <>). [[lightning_network_fig]] -.A series of bidirectional payment channels linked to form a Lightning Network that can route a payment from Alice to Eric +.A series of bidirectional payment channels linked to form an LN that can route a payment from Alice to Eric image::images/mbc3_1406.png["A series of bi-directional payment channels linked to form a Lightning Network"] Alice wants to pay Eric 1 bitcoin. However, Alice is not connected to @@ -1015,10 +1011,10 @@ payment from Alice to Eric, through a series of HTLC commitments on the payment channels connecting the participants. [[ln_payment_process]] -.Step-by-step payment routing through a Lightning Network +.Step-by-step payment routing through an LN image::images/mbc3_1407.png["Step-by-step payment routing through a Lightning Network"] -Alice is running a Lightning Network (LN) node that is keeping track of +Alice is running an LN node that is keeping track of her payment channel to Bob and has the ability to discover routes between payment channels. Alice's LN node also has the ability to connect over the internet to Eric's LN node. Eric's LN node creates a @@ -1114,7 +1110,7 @@ with sufficient capacity. Nodes advertise routing information, including what channels they have open, how much capacity each channel has, and what fees they charge to route payments. The routing information can be shared in a variety of ways, and different pathfinding protocols have -emerged as Lightning Network technology has advanced. +emerged as LN technology has advanced. Current implementations of route discovery use a P2P model where nodes propagate channel announcements to their peers in a "flooding" model, similar to how @@ -1132,15 +1128,15 @@ Carol's perspective, this looks like a payment from Bob to Diana. Carol does not know that Bob is actually relaying a payment from Alice. She also doesn't know that Diana will be relaying a payment to Eric. -This is a critical feature of the Lightning Network because it ensures +This is a critical feature of the LN because it ensures privacy of payments and makes it difficult to apply surveillance, censorship, or blacklists. But how does Alice establish this payment path without revealing anything to the intermediary nodes? -The Lightning Network implements an onion-routed protocol based on a +The LN implements an onion-routed protocol based on a scheme called https://oreil.ly/fuCiK[Sphinx]. This routing protocol ensures that a payment sender can construct and communicate a path -through the Lightning Network such that: +through the LN such that: - Intermediate nodes can verify and decrypt their portion of route information and find the next hop. @@ -1192,40 +1188,39 @@ hops to go. ==== Lightning Network Benefits -A((("payment channels", "Lightning Network", "benefits of", id="payment-channel-ln-benefits")))((("Lightning Network", "benefits of", id="lightning-benefits"))) Lightning Network is a +An((("payment channels", "Lightning Network", "benefits of", id="payment-channel-ln-benefits")))((("Lightning Network", "benefits of", id="lightning-benefits"))) LN is a second-layer routing technology. It can be applied to any blockchain that supports some basic capabilities, such as multisignature transactions, timelocks, and basic smart contracts. -Lightning Network is layered on top of the Bitcoin network, giving +LN is layered on top of the Bitcoin network, giving Bitcoin a significant increase in capacity, privacy, granularity, and speed, without sacrificing the principles of trustless operation without intermediaries: -Privacy:: Lightning Network payments are much more private than payments +Privacy:: LN payments are much more private than payments on the Bitcoin blockchain, as they are not public. While participants in a route can see payments propagated across their channels, they do not know the sender or recipient. -Fungibility:: A Lightning Network makes it much more difficult to apply +Fungibility:: An LN makes it much more difficult to apply surveillance and blacklists on Bitcoin, increasing the fungibility of the currency. -Speed:: Bitcoin transactions using Lightning Network are settled in +Speed:: Bitcoin transactions using LN are settled in milliseconds, rather than minutes or hours, as HTLCs are cleared without committing transactions to a block. -Granularity:: A Lightning Network can enable payments at least as small +Granularity:: An LN can enable payments at least as small as the Bitcoin "dust" limit, perhaps even smaller. -Capacity:: A Lightning Network increases the capacity of the Bitcoin +Capacity:: An LN increases the capacity of the Bitcoin system by several orders of magnitude. The upper bound to the number of payments per second that can be routed over a Lightning Network depends only on the capacity and speed of each node. -Trustless Operation:: A Lightning Network uses Bitcoin transactions -between nodes that operate as peers without trusting each other. Thus, a -Lightning Network preserves the principles of the Bitcoin system, while +Trustless Operation:: An LN uses Bitcoin transactions +between nodes that operate as peers without trusting each other. Thus, an LN preserves the principles of the Bitcoin system, while expanding its operating parameters ((("Bitcoin", "as application platform", "routed payment channels (Lightning Network)", secondary-sortas="application platform", startref="bitcoin-app-platform-ln")))((("application platform, Bitcoin as", "routed payment channels (Lightning Network)", startref="app-platform-ln")))((("payment channels", "Lightning Network", startref="payment-channel-ln")))((("Lightning Network", startref="lightning")))((("payment channels", "Lightning Network", "benefits of", startref="payment-channel-ln-benefits")))((("Lightning Network", "benefits of", startref="lightning-benefits")))significantly. We have examined just a few of the emerging applications that can be diff --git a/preface.asciidoc b/preface.asciidoc index 3f53d8aa..dbb151ae 100644 --- a/preface.asciidoc +++ b/preface.asciidoc @@ -125,7 +125,7 @@ Watch us on YouTube: link:$$https://youtube.com/oreillymedia$$[]. === Contacting the Authors -[.align] +[role="align"] You can contact Andreas M. Antonopoulos on his personal site: [.keep-together]#link:$$https://antonopoulos.com$$[].# diff --git a/theme/epub/epub.css b/theme/epub/epub.css index ebda9599..9fa75e74 100644 --- a/theme/epub/epub.css +++ b/theme/epub/epub.css @@ -4,4 +4,7 @@ td.fakeheader { color: White !important; background-color: Black !important; border: 0pt solid cmyk(0%,0%,0%,100%); - } \ No newline at end of file + } + + /*--Table lines--*/ +table td.right, th.right { border-right: 0.25pt solid cmyk(0%,0%,0%,100%); } diff --git a/theme/pdf/pdf.css b/theme/pdf/pdf.css index 4b87e8fa..f5aeb222 100644 --- a/theme/pdf/pdf.css +++ b/theme/pdf/pdf.css @@ -18,6 +18,10 @@ pre[data-type="programlisting"] { font-style: normal; } +/*--Table lines--*/ +table td.right, th.right { border-right: 0.25pt solid cmyk(0%,0%,0%,100%); } + + td.fakeheader { font-family: "MyriadPro-SemiboldCond" !important; font-weight: 600 !important;