CH11: minor edits

ch09.asciidoc

@@ -1,12 +1,9 @@
 [[blockchain]]
 == The Blockchain
 
-=== Introduction
-
 ((("blockchain (the)", "overview of")))The blockchain data structure is
 an ordered, back-linked list of blocks of transactions. The blockchain
-can be stored as a flat file, or in a simple database. The Bitcoin Core
-client stores the blockchain metadata using Google's LevelDB database.
+can be stored as a flat file, or in a simple database.
 Blocks are linked "back," each referring to the previous block in the
 chain. ((("blocks", "block height")))The blockchain is often visualized
 as a vertical stack, with blocks layered on top of each other and the
@@ -19,20 +16,19 @@ blocks stacked on top of each other results in the use of terms such as
 "parent blocks")))((("genesis block")))((("parent blocks")))Each block
 within the blockchain is identified by a hash, generated using the
 SHA256 cryptographic hash algorithm on the header of the block. Each
-block also references a previous block, known as the _parent_ block,
+block also commits to the previous block, known as the _parent_ block,
 through the "previous block hash" field in the block header. In other
 words, each block contains the hash of its parent inside its own header.
 The sequence of hashes linking each block to its parent creates a chain
 going back all the way to the first block ever created, known as the
 _genesis block_.
 
-Although a block has just one parent, it can temporarily have multiple
-children. Each of the children refers to the same block as its parent
-and contains the same (parent) hash in the "previous block hash" field.
+Although a block has just one parent, it can have multiple
+children. Each of the children commits to the same parent block.
 Multiple children arise during a blockchain "fork," a temporary
-situation that occurs when different blocks are discovered almost
+situation that can occur when different blocks are discovered almost
 simultaneously by different miners (see <<forks>>). Eventually, only one
-child block becomes part of the blockchain and the "fork" is resolved.
+child block becomes part of the blockchain accepted by all full nodes and the "fork" is resolved.
 Even though a block may have more than one child, each block can have
 only one parent. This is because a block has one single "previous block
 hash" field referencing its single parent.
@@ -48,7 +44,7 @@ on. This cascade effect ensures that once a block has many generations
 following it, it cannot be changed without forcing a recalculation of
 all subsequent blocks. Because such a recalculation would require
 enormous computation (and therefore energy consumption), the existence
-of a long chain of blocks makes the blockchain's deep history immutable,
+of a long chain of blocks makes the blockchain's deep history impractical to change,
 which is a key feature of bitcoin's security.
 
 One way to think about the blockchain is like layers in a geological
@@ -58,14 +54,14 @@ once you go a few inches deep, geological layers become more and more
 stable. By the time you look a few hundred feet down, you are looking at
 a snapshot of the past that has remained undisturbed for millions of
 years. In the blockchain, the most recent few blocks might be revised if
-there is a chain recalculation due to a fork. The top six blocks are
+there is a chain reorganization due to a fork. The top six blocks are
 like a few inches of topsoil. But once you go more deeply into the
 blockchain, beyond six blocks, blocks are less and less likely to
 change. ((("transactions", "coinbase transactions")))((("coinbase
 transactions")))After 100 blocks back there is so much stability that
-the coinbase transaction—the transaction containing newly mined
-bitcoin—can be spent. A few thousand blocks back (a month) and the
-blockchain is settled history, for all practical purposes. While the
+the coinbase transaction--the transaction containing the reward in
+bitcoin for creating a new block--can be spent. A few thousand blocks back (a month) and the
+blockchain is settled history for all practical purposes. While the
 protocol always allows a chain to be undone by a longer chain and while
 the possibility of any block being reversed always exists, the
 probability of such an event decreases as time passes until it becomes
@@ -78,10 +74,10 @@ structure")))A block is a container data structure that aggregates
 transactions for inclusion in the public ledger, the blockchain. The
 block is made of a header, containing metadata, followed by a long list
 of transactions that make up the bulk of its size. The block header is
-80 bytes, whereas the average transaction is at least 400 bytes and the
-average block contains more than 1900 transactions. A complete block,
-with all transactions, is therefore 10,000 times larger than the block
-header. <<block_structure1>> describes the structure of a block.
+80 bytes, whereas the total size of all transactions in a block can be
+up to about 4,000,000 bytes.  A complete block,
+with all transactions, can therefore be over 10,000 times larger than the block
+header. <<block_structure1>> describes how Bitcoin Core stores the structure of a block.
 
 [[block_structure1]]
 [role="pagebreak-before"]
@@ -91,7 +87,7 @@ header. <<block_structure1>> describes the structure of a block.
 |Size| Field | Description
 | 4 bytes | Block Size | The size of the block, in bytes, following this field
 | 80 bytes | Block Header | Several fields form the block header
-| 1&#x2013;9 bytes (VarInt) | Transaction Counter | How many transactions follow
+| 1-9 bytes (VarInt) | Transaction Counter | How many transactions follow
 | Variable | Transactions | The transactions recorded in this block
 |=======
 
@@ -115,7 +111,7 @@ header.
 [options="header"]
 |=======
 |Size| Field | Description
-| 4 bytes | Version | A version number to track software/protocol upgrades
+| 4 bytes | Version | A version number to track protocol upgrades
 | 32 bytes | Previous Block Hash | A reference to the hash of the previous (parent) block in the chain
 | 32 bytes | Merkle Root | A hash of the root of the merkle tree of this block's transactions
 | 4 bytes | Timestamp | The approximate creation time of this block (seconds from Unix Epoch)
@@ -137,13 +133,13 @@ hash is called the _block hash_ but is more accurately the _block header
 hash_, pass:[<span role="keep-together">because only the block header is
 used to compute it. For example,</span>]
 +000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f+ is
-the block hash of the first bitcoin block ever created. The block hash
+the block hash of the first Bitcoin block ever created. The block hash
 identifies a block uniquely and unambiguously and can be independently
 derived by any node by simply hashing the block header.
 
 Note that the block hash is not actually included inside the block's
 data structure, neither when the block is transmitted on the network,
-nor when it is stored on a node's persistence storage as part of the
+nor when it is stored on a node's persistant storage as part of the
 blockchain. Instead, the block's hash is computed by each node as the
 block is received from the network. The block hash might be stored in a
 separate database table as part of the block's metadata, to facilitate
@@ -158,9 +154,10 @@ referenced by the following block hash</span>]
 block can thus be identified in two ways: by referencing the block hash
 or by referencing the block height. Each subsequent block added "on top"
 of that first block is one position "higher" in the blockchain, like
-boxes stacked one on top of the other. The block height on January 1,
-2017 was approximately 446,000, meaning there were 446,000 blocks
-stacked on top of the first block created in January 2009.
+boxes stacked one on top of the other. The block height 800,000 was
+reached during the writing of this book in mid-2023, meaning there were
+800,000 blocks stacked on top of the first block created in January
+2009.
 
 Unlike the block hash, the block height is not a unique identifier.
 Although a single block will always have a specific and invariant block
@@ -190,14 +187,14 @@ the blockchain.
 === The Genesis Block
 
 ((("blocks", "genesis block")))((("blockchain (the)", "genesis
-block")))The first block in the blockchain is called the genesis block
+block")))The first block in the blockchain is called the _genesis block_
 and was created in 2009. It is the common ancestor of all the blocks in
 the blockchain, meaning that if you start at any block and follow the
 chain backward in time, you will eventually arrive at the genesis block.
 
 Every node always starts with a blockchain of at least one block because
-the genesis block is statically encoded within the Bitcoin client
-software, such that it cannot be altered. Every node always "knows" the
+the genesis block is statically encoded within Bitcoin Core,
+such that it cannot be altered. Every node always "knows" the
 genesis block's hash and structure, the fixed time it was created, and
 even the single transaction within. Thus, every node has the starting
 point for the blockchain, a secure "root" from which to build a trusted
@@ -216,7 +213,7 @@ You can search for that block hash in any block explorer website, such
 as _blockchain.info_, and you will find a page describing the contents
 of this block, with a URL containing that hash:
 
-https://blockchain.info/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
+https://blockstream.info/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
 
 Using the Bitcoin Core reference client on the command line:
 
@@ -249,21 +246,21 @@ $ bitcoin-cli getblock 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60
 }
 ----
 
-The genesis block contains a hidden message within it. The coinbase
+The genesis block contains a message within it. The coinbase
 transaction input contains the text "The Times 03/Jan/2009 Chancellor on
 brink of second bailout for banks." This message was intended to offer
 proof of the earliest date this block was created, by referencing the
 headline of the British newspaper _The Times_. It also serves as a
 tongue-in-cheek reminder of the importance of an independent monetary
-system, with bitcoin's launch occurring at the same time as an
+system, with Bitcoin's launch occurring at the same time as an
 unprecedented worldwide monetary crisis. The message was embedded in the
-first block by Satoshi Nakamoto, bitcoin's creator.
+first block by Satoshi Nakamoto, Bitcoin's creator.
 
 === Linking Blocks in the Blockchain
 
 ((("blocks", "linking blocks in the blockchain")))((("blockchain (the)",
-"linking blocks in the blockchain")))Bitcoin full nodes maintain a local
-copy of the blockchain, starting at the genesis block. The local copy of
+"linking blocks in the blockchain")))Bitcoin full nodes validate every
+block in the blockchain, starting at the genesis block. Their local view of
 the blockchain is constantly updated as new blocks are found and used to
 extend the chain. As a node receives incoming blocks from the network,
 it will validate these blocks and then link them to the existing
@@ -334,10 +331,10 @@ examples that follow.
 image::images/mbc2_0901.png[]
 
 Merkle trees are used in bitcoin to summarize all the transactions in a
-block, producing an overall digital fingerprint of the entire set of
-transactions, providing a very efficient process to verify whether a
+block, producing an overall commitment to the entire set of
+transactions and permitting a very efficient process to verify whether a
 transaction is included in a block. A merkle tree is constructed by
-recursively hashing pairs of nodes until there is only one hash, called
+recursively hashing pairs of elements until there is only one hash, called
 the _root_, or _merkle root_. The cryptographic hash algorithm used in
 bitcoin's merkle trees is SHA256 applied twice, also known as
 double-SHA256.
@@ -393,13 +390,13 @@ shown in <<merkle_tree_odd>>, where transaction C is duplicated.
 image::images/mbc2_0903.png["merkle_tree_odd"]
 
 The same method for constructing a tree from four transactions can be
-generalized to construct trees of any size. In bitcoin it is common to
-have several hundred to more than a thousand transactions in a single
+generalized to construct trees of any size. In Bitcoin it is common to
+have several thousand transactions in a single
 block, which are summarized in exactly the same way, producing just 32
 bytes of data as the single merkle root. In <<merkle_tree_large>>, you
 will see a tree built from 16 transactions. Note that although the root
 looks bigger than the leaf nodes in the diagram, it is the exact same
-size, just 32 bytes. Whether there is one transaction or a hundred
+size, just 32 bytes. Whether there is one transaction or ten
 thousand transactions in the block, the merkle root always summarizes
 them into 32 bytes.
 
@@ -411,7 +408,7 @@ especially important as the number of transactions increases, because
 the base-2 logarithm of the number of transactions increases much more
 slowly. This allows Bitcoin nodes to efficiently produce paths of 10 or
 12 hashes (320–384 bytes), which can provide proof of a single
-transaction out of more than a thousand transactions in a megabyte-sized
+transaction out of more than a thousand transactions in a multi-megabyte
 block.
 
 [[merkle_tree_large]]
@@ -523,22 +520,22 @@ and block, and between the block and blockchain, proves that the
 transaction is recorded in the blockchain. All in all, the SPV client will
 have received less than a kilobyte of data for the block header and
 merkle path, an amount of data that is more than a thousand times less
-than a full block (about 1 megabyte currently).((("",
+than a full block (about 2 megabytes currently).((("",
 startref="BCTmerkle09")))((("", startref="merkle09")))
 
 === Bitcoin's Test Blockchains
 
 ((("blockchain (the)", "test blockchains",
 id="BCTtest09")))((("mainnet", seealso="blockchain (the)")))You might be
-surprised to learn that there is more than one Bitcoin blockchain. The
+surprised to learn that there is more than one blockchain used with Bitcoin. The
 "main" Bitcoin blockchain, the one created by Satoshi Nakamoto on
 January 3rd, 2009, the one with the genesis block we studied in this
 chapter, is called _mainnet_.  There are other Bitcoin blockchains that
-are used for testing purposes: at this time _testnet_, _segnet_, and
+are used for testing purposes: at this time _testnet_, _signet_, and
 _regtest_. Let's look at each in turn.((("testnet", id="testnet09")))
 
 
-==== Testnet&#x2014;Bitcoin's Testing Playground
+==== Testnet: Bitcoin's Testing Playground
 
 Testnet is the name of the test blockchain, network, and currency that
 is used for testing purposes. The testnet is a fully featured live P2P
@@ -549,7 +546,7 @@ low enough that anyone can mine testnet coins relatively easily (keeping
 them worthless).
 
 Any software development that is intended for production use on
-bitcoin's mainnet should first be tested on testnet with test coins.
+Bitcoin's mainnet can first be tested on testnet with test coins.
 This protects both the developers from monetary losses due to bugs and
 the network from unintended behavior due to bugs.
 
@@ -566,17 +563,15 @@ The current testnet is called _testnet3_, the third iteration of
 testnet, restarted in February 2011 to reset the difficulty from the
 previous testnet.
 
-Keep in mind that testnet3 is a large blockchain, in excess of 20 GB in
-early 2017. It will take a day or so to sync fully and use up resources
+Keep in mind that testnet3 is a large blockchain, in excess of 30 GB in
+2023. It will take a while to sync fully and use up resources
 on your computer. Not as much as mainnet, but not exactly "lightweight"
-either. One good way to run a testnet node is as a virtual machine image
-(e.g., VirtualBox, Docker, Cloud Server, etc.) dedicated for that
-purpose.
+either.
 
 ===== Using testnet
 
-Bitcoin Core, like almost all other bitcoin software, has full support
-for operation on testnet instead of mainnet. All of Bitcoin Core's
+Bitcoin Core, like many other Bitcoin programs, has full support
+for operation on testnet as an alternative mainnet. All of Bitcoin Core's
 functions work on testnet, including the wallet, mining testnet coins,
 and syncing a full testnet node.
 
@@ -618,8 +613,8 @@ You can also run on testnet3 with other full-node implementations, such
 as +btcd+ (written in Go) and +bcoin+ (written in JavaScript), to
 experiment and learn in other programming languages and frameworks.
 
-In early 2017, testnet3 supports all the features of mainnet, including
-Segregated Witness (see <<segwit>>). Therefore, testnet3 can also be
+Testnet3 supports all the features of mainnet, including
+Segregated Witness v0 and v1 (see <<segwit>> and <<taproot>>). Therefore, testnet3 can also be
 used to test Segregated Witness features.((("", startref="testnet09")))
 
 ===== Problems With Testnet
@@ -654,7 +649,7 @@ provide a highly usable blockchain without introducing economic
 incentives, so Bitcoin protocol developers began considering
 alternatives.  The primary goal was to preserve as much of the structure of
 Bitcoin as possible so that software could run on a testnet with minimal
-changes---but to also provide an environment that would remain useful.
+changes--but to also provide an environment that would remain useful.
 A secondary goal was to produce a reusable design that would allow
 developers of new software to easily create their own test networks.
 
@@ -666,7 +661,7 @@ block was sanctioned by a trusted authority.
 Whereas mining in Bitcoin is permissionless--anyone can do it--mining on
 signet is fully permissioned.  Only those with permission can do it.
 This would be a completely unacceptable change to Bitcoin's mainnet--no
-user would accept it--but it's acceptable on a testnet where coins have
+one would use that software--but it's reasonable on a testnet where coins have
 no value and the only purpose is testing software and systems.
 
 BIP325 signets are designed to make it very easy to create your own.  If
@@ -729,10 +724,10 @@ $ bitcoin-cli -signet getblockchaininfo
 
 ((("regtest (Regression Testing)")))Regtest, which stands for
 "Regression Testing," is a Bitcoin Core feature that allows you to
-create a local blockchain for testing purposes. Unlike testnet3, which
-is a public and shared test blockchain, the regtest blockchains are
+create a local blockchain for testing purposes. Unlike signet and testnet3, which
+are a public and shared test blockchain, the regtest blockchains are
 intended to be run as closed systems for local testing. You launch a
-regtest blockchain from scratch, creating a local genesis block. You may
+regtest blockchain from scratch. You may
 add other nodes to the network, or run it with a single node only to
 test the Bitcoin Core software.
 
@@ -800,7 +795,7 @@ $ bitcoin-cli -regtest getbalance
 === Using Test Blockchains for Development
 
 ((("development environment", "test blockchains and")))Bitcoin's various
-blockchains (+regtest+, +segnet+, +testnet3+, +mainnet+) offer a range
+blockchains (+regtest+, +signet+, +testnet3+, +mainnet+) offer a range
 of testing environments for bitcoin development. Use the test
 blockchains whether you are developing for Bitcoin Core, or another
 full-node consensus client; an application such as a wallet, exchange,
@@ -809,10 +804,10 @@ scripts.
 
 You can use the test blockchains to establish a development pipeline.
 Test your code locally on a +regtest+ as you develop it. Once you are
-ready to try it on a public network, switch to +testnet+ to expose your
+ready to try it on a public network, switch to +signet+ or +testnet+ to expose your
 code to a more dynamic environment with more diversity of code and
 applications. Finally, once you are confident your code works as
 expected, switch to +mainnet+ to deploy it in production. As you make
 changes, improvements, bug fixes, etc., start the pipeline again,
-deploying each change first on +regtest+, then on +testnet+, and finally
+deploying each change first on +regtest+, then on +signet+ or +testnet+, and finally
 into production.((("", startref="BCTtest09")))