All: edits for Roasbeef feedback

- Drop soon-to-be-outdated mention of current block reward amount

- Aezeed: mention internal and external version sumbers.  Instead of
  saying "global word list", clarify that both the backup and the
  recovery software need to support the same word list.

- Mention that compact block filters are something that blocks might
  commit to in the future in a consensus-enforced way.

- Add links to both RGB and Taproot Assets documentation.

- Mention that taproot assets can also support native forwarding.

- Minor edits and add some FIXMEs for later changes.

ch02.asciidoc

@@ -572,7 +572,7 @@ of competition. He immediately creates a new candidate block, fills it with
 transactions and the fingerprint of the previous block, and starts
 calculating the Proof-of-Work for the candidate block. Each miner includes a
 special transaction in his candidate block, one that pays his own Bitcoin address
-the block reward (currently 12.5 newly created bitcoin) plus the sum of
+the block reward plus the sum of
 transaction fees from all the transactions included in the candidate block. If he
 finds a solution that makes the candidate into a valid block, he "wins" this reward
 because his successful block is added to the global blockchain and the

ch03.asciidoc

@@ -1147,7 +1147,7 @@ toolkits, organized by programming languages.
 ==== C/C++
 https://github.com/bitcoin/bitcoin[Bitcoin Core] :: The reference implementation of bitcoin
 https://github.com/libbitcoin/libbitcoin[libbitcoin]:: Cross-platform C++ development toolkit, node, and consensus library
-https://github.com/libbitcoin/libbitcoin-explorer[bitcoin explorer]:: Libbitcoin's command-line tool
+https://github.com/libbitcoin/libbitcoin-explorer[Libbitcoin explorer]:: Libbitcoin's command-line tool
 
 ==== JavaScript
 http://bcoin.io/[bcoin]:: A modular and scalable full-node implementation with API

ch05.asciidoc

@@ -283,9 +283,12 @@ Electrum v2::
 
 Aezeed::
   Used in the LND wallet, this is another word-based recovery code that
-  offers improvements over BIP39.  Similar to Electrum v2 recovery codes,
-  it includes a version number that eliminates several issues with
-  upgrading wallet applications.  It also includes a _wallet birthday_
+  offers improvements over BIP39.  It includes two version numbers: one
+  is internal to eliminates several issues with upgrading wallet
+  applications (like Electrum v2's version number); the other version
+  number is external, which can be incremented to change the underlying
+  cryptographic properties of the recovery code.  
+  It also includes a _wallet birthday_
   in the recovery code, a reference to the date when the user created
   the wallet database; this allows a restoration process to find all of
   the funds associated with a wallet without scanning the entire
@@ -294,8 +297,8 @@ Aezeed::
   aspects of the recovery code without needing to move funds to a new
   seed--the user need only back up a new recovery code.  One
   disadvantage compared to Electrum v2 is that, like BIP39, it depends
-  on a global word list that all Aezeed-compatible wallet programs must
-  implement.
+  on both the backup and the recovery software supporting the same
+  word list.
 
 Muun::
   Used in the Muun wallet, which defaults to requiring spending

ch08.asciidoc

@@ -1126,6 +1126,15 @@ it's not a major problem.  A false positive rate can also help improve a
 client's privacy, as it does with bloom filters, although anyone wanting
 the best possible privacy should still use their own full node.
 
+In the long term, some developers advocate for having blocks commit to
+the filter for that block, with the most likely scheme having each
+coinbase transaction commit to the filter for that block.  Full nodes
+would calculate the filter for each block themselves and only accept a
+block if it contained an accurate commitment.  That would allow a
+lightweight client to download an 80-byte block header, a (usually)
+small coinbase transaction, and the filter for that block to receive
+strong evidence that the filter was accurate.
+
 === SPV Clients and Privacy
 
 Clients that implement SPV have weaker privacy than a full node. A full

ch12.asciidoc

@@ -319,6 +319,8 @@ The developers of RGB have described other uses for their protocol, such
 as creating identity tokens that can be periodically updated to protect
 against private key compromise.
 
+For more information, see https://rgb.tech/[RGB's documentation].
+
 ==== Taproot Assets
 
 Formerly called Taro, Taproot Assets are a colored coin protocol that is
@@ -365,8 +367,14 @@ siphon money from the hop next to them.  Although there's no known
 perfect solution to the free American call option, there may be
 practical solutions that limit its harm.
 
-Taproot Assets is specifically designed around translated forwarding,
-whereas RGB can technically support both.
+Both Taproot Assets and RGB can technically support both native and
+translated forwarding.  Taproot Assets is specifically designed around
+translated forwarding, whereas RGB has seen proposals to implement both.
+
+For more information, see
+https://docs.lightning.engineering/the-lightning-network/taproot-assets[Taproot
+Asset's documentation].  Additionally, the Taproot Asset developers are
+working on BIPs that may be available after this book goes into print.
 
 [[state_channels]]
 === Payment Channels and State Channels

chapters/authorization-authentication.adoc

@@ -2024,6 +2024,8 @@ in November 2021.
 
 === Tapscript
 
+//FIXME:mention "control block" (maybe in MAST section)
+
 Taproot enables MAST but only with a slightly different version of the
 Bitcoin Script language than previously used, the new version being
 called _tapscript_.  The major differences include:
@@ -2063,3 +2065,5 @@ Although we've looked at authorization and authentication in depth in
 this chapter, we've skipped over one very important part of how Bitcoin
 authenticates spenders: its signatures.  We'll look at that next in
 <<c_signatures>>.
+
+//FIXME: "I think more information should be added concerning: tapscript in general. I think the MAST section would better serve to be condensed and integrated in the section on taproot. It should also mention how the taproot merle tree is unique (sorting the leaves, tagged hashes, etc, etc)."

chapters/signatures.adoc

@@ -987,3 +987,6 @@ learned how to create transactions, how to secure them with
 authorization and authentication, and how to sign them.  We will next
 learn how to encourage miners to confirm them by adding fees to the
 transactions we create.
+
+//FIXME:mention segwit v0 and v1 coverage of values to aid hardware
+//wallets

chapters/transactions.adoc

@@ -53,7 +53,8 @@ e739df2f899c49dc267c0ad280aca6dab0d2fa2b42a45182fc83e81713010000
 
 
 Bitcoin Core's serialization format is special because it's the format
-used to make commitments to transaction, but otherwise programs can use
+used to make commitments to transaction and to relay them across
+Bitcoin's Peer-to-Peer (P2P) network, but otherwise programs can use
 a different format as long as they transmit all of the
 same data.  However, Bitcoin Core's format is reasonably compact for the
 data it transmits and simple to parse, so many other Bitcoin programs
@@ -1175,3 +1176,5 @@ satisfying conditions which restrict who can spend what bitcoins.
 Understanding how to construct and use these conditions is essential to
 ensuring that only Alice can spend her bitcoins, so they will be the
 subject of the next chapter.
+
+//FIXME: long section or full chapter about psbts