diff --git a/ch08.asciidoc b/ch08.asciidoc index 24075318..3889411e 100644 --- a/ch08.asciidoc +++ b/ch08.asciidoc @@ -568,7 +568,7 @@ when the transaction does not in fact exist. The lightweight client establishes the existence of a transaction in a block by requesting a merkle path proof and by validating the Proof-of-Work in the chain of blocks. However, a transaction's existence can be "hidden" from a lightweight client. A -lightweight client can definitely prove that a transaction exists but cannot +lightweight client can definitely verify that a transaction exists but cannot verify that a transaction, such as a double-spend of the same UTXO, doesn't exist because it doesn't have a record of all transactions. This vulnerability can be used in a denial-of-service attack or for a @@ -1140,7 +1140,7 @@ node downloads all transactions and therefore reveals no information about whether it is using some address in its wallet. A lightweight client only downloads transactions that are related to its wallet in some way. -Bloom filters and compact block filters are a way to reduce the loss of privacy. Without them, a +Bloom filters and compact block filters are ways to reduce the loss of privacy. Without them, a lightweight client would have to explicitly list the addresses it was interested in, creating a serious breach of privacy. However, even with filters, an adversary monitoring the traffic of a lightweight client or diff --git a/ch09.asciidoc b/ch09.asciidoc index 48a4a792..014d9fb1 100644 --- a/ch09.asciidoc +++ b/ch09.asciidoc @@ -490,7 +490,7 @@ bloom filter, it will send that block using a +merkleblock+ message. The +merkleblock+ message contains the block header as well as a merkle path that links the transaction of interest to the merkle root in the block. The lightweight client can use this merkle path to connect the transaction to the -block and verify that the transaction is included in the block. The lightweight +block header and verify that the transaction is included in the block. The lightweight client also uses the block header to link the block to the rest of the blockchain. The combination of these two links, between the transaction and block, and between the block and blockchain, proves that the diff --git a/ch10.asciidoc b/ch10.asciidoc index a94ea439..87f8487c 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -609,7 +609,7 @@ step is to commit to all the transactions using merkle trees. Each transaction is listed using its witness transaction identifier (_wtxid_) in topographical order, with 32 0x00 bytes standing in for the wtxid of the first transaction (the coinbase). As we saw in the <> -the last wtxid is duplicated if there are an odd number of wtxids, +the last wtxid is hashed with itslef if there are an odd number of wtxids, creating nodes that each containing the hash of one transaction. The transaction hashes are then combined, in pairs, creating each level of the tree, until all the transactions are summarized into one node at the @@ -643,7 +643,7 @@ The final field is the nonce, which is initialized to zero. With all the other fields filled, the header of the candidate block is now complete and the process of mining can begin. The goal is now to find a header -that results in its hash that is less than the target. +that results in a hash that is less than the target. The mining node will need to test billions or trillions of variations of the header before a version is found that satisfies the requirement. @@ -1454,7 +1454,7 @@ consensus mechanism so as to disrupt the security and availability of the Bitcoin network. It is important to note that consensus attacks have the greatest effect on future -consensus. Confirmed transactions ont he best blockchain +consensus. Confirmed transactions on the best blockchain become more and more immutable as time passes. While in theory, a fork can be achieved at any depth, in practice, the computing power needed to force a very deep fork is immense, making old blocks diff --git a/ch11.asciidoc b/ch11.asciidoc index d244d542..7306dc29 100644 --- a/ch11.asciidoc +++ b/ch11.asciidoc @@ -216,7 +216,7 @@ stick. ((("hardware signing devices")))In the long term, Bitcoin security may increasingly take the form of tamper-proof hardware signing devices. Unlike a smartphone or desktop -computer, a Bitcoin hardware signing device only needs hold keys and +computer, a Bitcoin hardware signing device only needs to hold keys and use them to generate signatures. Without general-purpose software to compromise and with limited interfaces, hardware signing devices can deliver an almost diff --git a/ch12.asciidoc b/ch12.asciidoc index e9a348ef..e8c31a30 100644 --- a/ch12.asciidoc +++ b/ch12.asciidoc @@ -63,7 +63,7 @@ Nonexpiration:: A valid transaction does not expire. If it is valid today, it will be valid in the near future, as long as the inputs remain unspent and the consensus rules do not change. -Integrity:: A Bitcoin transaction signed with +SIGHASH_ALL+ or parts of +Integrity:: The outputs of Bitcoin transaction signed with +SIGHASH_ALL+ or parts of a transaction signed by another +SIGHASH+ type cannot be modified without invalidating the signature, thus invalidating the transaction itself. @@ -710,7 +710,7 @@ id="PSCaymetric12")))Another way to handle the prior commitment states is to explicitly revoke them. However, this is not easy to achieve. A key characteristic of Bitcoin is that once a transaction is valid, it remains valid and does not expire. The only way to cancel a transaction -is to get a conflicting transactionn confirmed. +is to get a conflicting transaction confirmed. That's why we used timelocks in the simple payment channel example above to ensure that more recent commitments could be spent before older commitments were valid. However, sequencing commitments in diff --git a/chapters/authorization-authentication.adoc b/chapters/authorization-authentication.adoc index 42fe691e..97a4a5e6 100644 --- a/chapters/authorization-authentication.adoc +++ b/chapters/authorization-authentication.adoc @@ -324,9 +324,8 @@ scripts")))((("transactions", "advanced", id="Tadv07")))((("scripting", "multisignature scripts", id="Smulti07")))((("multisignature scripts")))Multisignature scripts set a condition where _k_ public keys are recorded in the script and at least _t_ of those must provide -signatures to spend the funds. This is also known as a "M-of-N" scheme, -where M is the total number of keys and N is the threshold of signatures -required for validation. For example, a 2-of-3 multisignature is one +signatures to spend the funds, called t-of-k. +For example, a 2-of-3 multisignature is one where three public keys are listed as potential signers and at least two of those must be used to create signatures for a valid transaction to spend the funds. @@ -1233,7 +1232,7 @@ number prefixed as XX): 03 2 04 OP_ELSE 05 <30 days> OP_CHECKSEQUENCEVERIFY OP_DROP -06 OP_CHECKSIG +06 OP_CHECKSIGVERIFY 07 1 08 OP_ENDIF 09 3 OP_CHECKMULTISIG diff --git a/chapters/errata.adoc b/chapters/errata.adoc index 96ba0f17..cffc4bc4 100644 --- a/chapters/errata.adoc +++ b/chapters/errata.adoc @@ -1,3 +1,4 @@ +[appendix] == Errata to the Bitcoin Whitepaper A description of known problems in Satoshi Nakamoto’s paper, "Bitcoin: @@ -6,8 +7,8 @@ changes and how Bitcoin's implementation differs from that described in the paper. This document was originally published by a co-author of this book in -2016; it is reproduced here with updates. The numbers and names of -sections in this errata correspond to the numbers and names of the +2016; it is reproduced here with updates. The names of +sections in this errata correspond to the names of the sections in Nakamoto's original paper. === Abstract @@ -23,7 +24,7 @@ longest chain would be the one backed by the largest pool of computational power. However, Bitcoin was implemented in such a way that the amount of POW can vary between blocks, so it became important not to check for the "the longest chain" but rather "the chain demonstrating -the most POW"; this is often shortened to "strongest chain". +the most POW"; this is often shortened to "most-work chain". + The https://github.com/bitcoin/bitcoin/commit/40cd0369419323f8d7385950e20342e998c994e1#diff-623e3fd6da1a45222eeec71496747b31R420[change] @@ -68,7 +69,8 @@ paper which refer to "network nodes" is mainly about what nodes can do even if they aren’t mining. * *Post-publication discovery:* When a new block is produced, the miner who produces that block can begin working on its sequel immediately but -all other miners must wait for that new block to propagate across the +all other miners are unaware of the new block and cannot begin working +on it until it has propagated across the network to them. This gives miners who produce many blocks an edge over miners who produce fewer blocks, and this can be exploited in what’s known as the _selfish mining attack_ to allow an attacker with around @@ -186,8 +188,9 @@ Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner ____ -* *Post-publication invention:* the revelation of a common owner for -different inputs isn’t necessary if owners often mix their inputs with +* *Post-publication invention:* it isn't clear that different inputs +in the same transaction have the same owner if if owners often mix their +inputs with inputs belonging to other owners. For example, there’s no public difference between Alice and Bob each contributing one of their inputs towards paying Charlie and Dan than there is between just Alice diff --git a/chapters/fees.adoc b/chapters/fees.adoc index 3c8f22c2..7f6bc568 100644 --- a/chapters/fees.adoc +++ b/chapters/fees.adoc @@ -113,10 +113,10 @@ different units: - BTC/Bytes (a legacy unit rarely used anymore) - BTC/Kilobytes (a legacy unit rarely used anymore) -- BTC/vbytes (rarely used) +- BTC/Vbytes (rarely used) - BTC/Kilo-vbyte (used mainly in Bitcoin Core) -- Satoshi/vbyte (most commonly used today) -- Satoshi/weight (also commonly used today) +- Satoshi/Vbyte (most commonly used today) +- Satoshi/Weight (also commonly used today) We recommend either the sat/vbyte or sat/weight units for displaying fee rates. @@ -560,7 +560,7 @@ uses her output to attach either 25 child transactions or any smaller number of child transactions equaling 100,000 vbytes in size. Without carve-out, Bob would be unable to attach another child transaction to his output for CPFP fee bumping. With carve-out, he can spend one of -the two outputs in the transaction, the one that belongs to me, as long +the two outputs in the transaction, the one that belongs to him, as long as his child transaction is less than 1,000 vbytes in size (which should be more than enough space). diff --git a/chapters/signatures.adoc b/chapters/signatures.adoc index 58068b4b..eac43c5e 100644 --- a/chapters/signatures.adoc +++ b/chapters/signatures.adoc @@ -664,7 +664,7 @@ Everyone with a partial public key that becomes part of the aggregated public key must contribute a partial signature and partial nonce to the final signature. Sometimes, though, the participants want to allow a subset of them to sign, such as t-of-k where a threshold (t) number of participants can sign for -a key constructed by n participants. That type of signature is called a +a key constructed by k participants. That type of signature is called a _threshold signature_. We saw script-based threshold signatures in