diff --git a/book.asciidoc b/book.asciidoc
index 4ee73e54..a7466455 100644
--- a/book.asciidoc
+++ b/book.asciidoc
@@ -14,6 +14,14 @@ include::ch04.asciidoc[]
 
 include::ch05.asciidoc[]
 
+include::chapters/transactions.adoc[]
+
+include::chapters/authorization-authentication.adoc[]
+
+include::chapters/signatures.adoc[]
+
+include::chapters/fees.adoc[]
+
 include::ch06.asciidoc[]
 
 include::ch07.asciidoc[]
diff --git a/ch03.asciidoc b/ch03.asciidoc
index bdd47aa8..9e86eb5f 100644
--- a/ch03.asciidoc
+++ b/ch03.asciidoc
@@ -526,7 +526,7 @@ options")))((("txindex option")))((("full indexing option")))By default,
 Bitcoin Core builds a database containing _only_ the transactions
 related to the user's wallet. If you want to be able to access _any_
 transaction with commands like +getrawtransaction+ (see
-<<exploring_and_decoding_transanctions>>), you need to configure Bitcoin
+<<exploring_and_decoding_transactions>>), you need to configure Bitcoin
 Core to build a complete transaction index, which can be achieved with
 the +txindex+ option. Set +txindex=1+ in the Bitcoin Core configuration
 file. If you don't set this option at first and later set it to full
@@ -771,7 +771,7 @@ blocks from other Bitcoin nodes. You can check its progress using
 +getblockchaininfo+ to see the number of known blocks.
 ====
 
-[[exploring_and_decoding_transanctions]]
+[[exploring_and_decoding_transactions]]
 ==== Exploring and Decoding Transactions
 
 In <<spending_bitcoin>>, ((("use cases", "buying coffee",
diff --git a/ch04.asciidoc b/ch04.asciidoc
index 1ae101e4..60e2044d 100644
--- a/ch04.asciidoc
+++ b/ch04.asciidoc
@@ -478,13 +478,13 @@ full nodes will consider the transaction to be valid.
 In short, the script above uses the same public key and signature
 described in the original paper but adds in the complexity of two script
 fields and an opcode.  That seems like extra work here, but we'll begin
-to see the benefits when we look at <<p2pkh>>.
+to see the benefits when we look at <<addresses_for_p2pkh>>.
 
 This type of output is known today as _Pay-to-Public-Key_, or _P2PK_ for
 short.  It was never widely used for payments, and no widely-used
 program has supported IP address payments for almost a decade.
 
-[[p2pkh]]
+[[addresses_for_p2pkh]]
 === Legacy Addresses for P2PKH
 
 Entering the IP address of the person you want to pay has a number of
@@ -861,7 +861,7 @@ represent them is implemented slightly differently in newer Bitcoin
 wallets, to indicate that these private keys have been used to produce
 compressed public keys.
 
-[[p2sh]]
+[[addresses_for_p2sh]]
 === Legacy Pay-to-Script-Hash (P2SH)
 
 As we've seen in preceding sections, someone receiving Bitcoins (like
@@ -869,7 +869,7 @@ Bob) can require payments to him contain certain constraints in their
 scriptPubKeys.  Bob will need to fulfill those constraints using a
 scriptSig when he spends those bitcoins.  In <<p2pk>>, the constraint
 was simply that the scriptSig needed to provide an appropriate
-signature.  In <<p2pkh>>, an appropriate public key also needed to be
+signature.  In <<addresses_for_p2pkh>>, an appropriate public key also needed to be
 provided.
 
 In order for a spender (like Alice) to place the constraints Bob wants
@@ -1295,7 +1295,7 @@ scripts are listed in <<scripts_for_diff_segwit_outputs>>.
 |===
 
 For the P2WPKH output, the witness program contains a commitment constructed in exactly the same
-way as the commitment for a P2PKH output seen in <<p2pkh>>.  A public key is passed into a SHA256 hash
+way as the commitment for a P2PKH output seen in <<addresses_for_p2pkh>>.  A public key is passed into a SHA256 hash
 function.  The resultant 32 byte digest is then passed into a RIPEMD-160
 hash function.  The digest of that function (the commitment) is placed
 in the witness program.
diff --git a/ch05.asciidoc b/ch05.asciidoc
index 22bc8cfa..e88d4041 100644
--- a/ch05.asciidoc
+++ b/ch05.asciidoc
@@ -924,7 +924,7 @@ code_ (c).
 
 The master private key (m) then generates a corresponding master public
 key (M) using the normal elliptic curve multiplication process +m * G+
-that we saw in <<pubkey>>.
+that we saw in <<public_key_derivation>>.
 
 The chain code (c) is used to introduce entropy in the function that
 creates child keys from parent keys, as we will see in the next section.
diff --git a/ch06.asciidoc b/ch06.asciidoc
index 0c8a2697..9013f446 100644
--- a/ch06.asciidoc
+++ b/ch06.asciidoc
@@ -734,7 +734,7 @@ different subsets of the data in the transaction. By including the
 [NOTE]
 ====
 All +SIGHASH+ types sign the transaction +nLocktime+ field (see
-<<transaction_locktime_nlocktime>>). In addition, the +SIGHASH+ type
+<<nlocktime>>). In addition, the +SIGHASH+ type
 itself is appended to the transaction before it is signed, so that it
 can't be modified once signed.
 ====
@@ -808,7 +808,7 @@ the transaction hash.
 The temporary key pair is based on a random number _k_, which is used as
 the temporary private key. From _k_, we generate the corresponding
 temporary public key _P_ (calculated as _P = k*G_, in the same way
-bitcoin public keys are derived; see <<pubkey>>). The _R_ value of the
+bitcoin public keys are derived; see <<public_key_derivation>>). The _R_ value of the
 digital signature is then the x coordinate of the ephemeral public key
 _P_.
 
diff --git a/ch10.asciidoc b/ch10.asciidoc
index 4bbd4769..955cd221 100644
--- a/ch10.asciidoc
+++ b/ch10.asciidoc
@@ -1,6 +1,15 @@
 [[mining]]
 == Mining and Consensus
 
+[[mtp]]
+=== Median Time Past (MTP)
+
+FIXME
+
+[[duplicate_transactions]]
+=== Preventing Duplicate Transactions
+
+FIXME:BIP30 and 34
 
 === Introduction
 
@@ -296,7 +305,7 @@ If Jing's mining node writes the coinbase transaction, what stops Jing from "rew
 
 ((("coinbase transactions", "structure of")))With these calculations, Jing's node then constructs the coinbase transaction to pay himself 25.09094928 bitcoin.
 
-As you can see in <<generation_tx_example>>, the coinbase transaction has a special format. Instead of a transaction input specifying a previous UTXO to spend, it has a "coinbase" input. We examined transaction inputs in <<tx_in_structure>>. Let's compare a regular transaction input with a coinbase transaction input. <<table_8-1>> shows the structure of a regular transaction, while <<table_8-2>> shows the structure of the coinbase transaction's input.
+As you can see in <<generation_tx_example>>, the coinbase transaction has a special format. Instead of a transaction input specifying a previous UTXO to spend, it has a "coinbase" input. We examined transaction inputs in <<inputs>>. Let's compare a regular transaction input with a coinbase transaction input. <<table_8-1>> shows the structure of a regular transaction, while <<table_8-2>> shows the structure of the coinbase transaction's input.
 
 [[table_8-1]]
 .The structure of a "normal" transaction input
diff --git a/chapters/authorization-authentication.adoc b/chapters/authorization-authentication.adoc
new file mode 100644
index 00000000..59d0eda4
--- /dev/null
+++ b/chapters/authorization-authentication.adoc
@@ -0,0 +1,4 @@
+[[c_authorization_authentication]]
+=== Authorization and Authentication with Scripts and Witnesses
+
+FIXME
diff --git a/chapters/fees.adoc b/chapters/fees.adoc
new file mode 100644
index 00000000..02f58337
--- /dev/null
+++ b/chapters/fees.adoc
@@ -0,0 +1,9 @@
+[[transaction-pinning]]
+=== Transaction Pinning
+
+FIXME
+
+[[rbf]]
+=== Replace by Fee (RBF)
+
+FIXME
diff --git a/chapters/signatures.adoc b/chapters/signatures.adoc
new file mode 100644
index 00000000..81ae3dc4
--- /dev/null
+++ b/chapters/signatures.adoc
@@ -0,0 +1,9 @@
+[[signatures]]
+=== Signatures
+
+FIXME
+
+[[sighashes]]
+=== Signature Hashes (Sighashes)
+
+FIXME