From 672c3fdc0706c9f1afaa50113173a9c94fc262e0 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Thu, 3 Aug 2023 08:02:49 -1000 Subject: [PATCH] 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 | 2 +- ch03.asciidoc | 2 +- ch05.asciidoc | 13 ++++++++----- ch08.asciidoc | 9 +++++++++ ch12.asciidoc | 12 ++++++++++-- chapters/authorization-authentication.adoc | 4 ++++ chapters/signatures.adoc | 3 +++ chapters/transactions.adoc | 5 ++++- 8 files changed, 40 insertions(+), 10 deletions(-) diff --git a/ch02.asciidoc b/ch02.asciidoc index 588e60b5..e1e28633 100644 --- a/ch02.asciidoc +++ b/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 diff --git a/ch03.asciidoc b/ch03.asciidoc index 922628dc..22a62ad5 100644 --- a/ch03.asciidoc +++ b/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 diff --git a/ch05.asciidoc b/ch05.asciidoc index 9ed04947..cd2c9ec7 100644 --- a/ch05.asciidoc +++ b/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 diff --git a/ch08.asciidoc b/ch08.asciidoc index df6bc13f..eb7c3138 100644 --- a/ch08.asciidoc +++ b/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 diff --git a/ch12.asciidoc b/ch12.asciidoc index 59fb25e5..94a34841 100644 --- a/ch12.asciidoc +++ b/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 diff --git a/chapters/authorization-authentication.adoc b/chapters/authorization-authentication.adoc index 97c1d947..ec421f4a 100644 --- a/chapters/authorization-authentication.adoc +++ b/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 <>. + +//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)." diff --git a/chapters/signatures.adoc b/chapters/signatures.adoc index bd3109da..65533536 100644 --- a/chapters/signatures.adoc +++ b/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 diff --git a/chapters/transactions.adoc b/chapters/transactions.adoc index 816a570e..7b18e77b 100644 --- a/chapters/transactions.adoc +++ b/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