Merge pull request #624 from victorabarros/patch-1

fix typo

02_1_Setting_Up_a_Bitcoin-Core_VPS_with_StackScript.md

@@ -36,7 +36,7 @@ Your server security won't be complete if people can break into your Linode acco
 
 ### Load the StackScript
 
-Download the [Linode Standup Script](https://github.com/BlockchainCommons/Bitcoin-Standup-Scripts/blob/master/Scripts/LinodeStandUp.sh) from the [Bitcoin Standup Scripts repo](https://github.com/BlockchainCommons/Bitcoin-Standup-Scripts). This script basically automates all Bitcoin VPS setup instructions. If you want to be particulary prudent, read it over carefully. If you are satisfied, you can copy that StackScript into your own account by going to the [Stackscripts page](https://cloud.linode.com/stackscripts?type=account) on your Linode account and selecting to [Create New Stackscript](https://cloud.linode.com/stackscripts/create). Give it a good name (we use `Bitcoin Standup`), then copy and paste the script. Choose Debian 11 for your target image and "Save" it.
+Download the [Linode Standup Script](https://github.com/BlockchainCommons/Bitcoin-Standup-Scripts/blob/master/Scripts/LinodeStandUp.sh) from the [Bitcoin Standup Scripts repo](https://github.com/BlockchainCommons/Bitcoin-Standup-Scripts). This script basically automates all Bitcoin VPS setup instructions. If you want to be particulary prudent, read it over carefully. If you are satisfied, you can copy that StackScript into your own account by going to the [Stackscripts page](https://cloud.linode.com/stackscripts?type=account) on your Linode account and selecting to [Create New Stackscript](https://cloud.linode.com/stackscripts/create). Give it a good name (we use `Bitcoin Standup`), then copy and paste the script. Choose Debian 12 for your target image and "Save" it.
 
 ### Do the Initial Setup
 
@@ -53,7 +53,7 @@ You're now ready to create a node based on the Stackscript.
    * **SSH Key.** Copy your local computer's SSH key here; this allows you be able to automatically login in via SSH to the standup account. If you haven't setup an SSH key on your local computer yet, there are good instructions for it on [Github](https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/).  You may also want to add your SSH key into your Linode LISH (Linode Interactive Shell) by going to your "Linode Home Page / My Preferences / LISH Settings /  LISH Keys". Using an SSH key will give you a simpler and safer way to log in to your server.
    * **SSH-Allowed IPs.** This is a comma-separated list of IPs that will be allowed to SSH into the VPS. For example "192.168.1.15,192.168.1.16". If you do not enter any IPs, _your VPS will not be very secure_. It will constantly be bombarded by attackers trying to find their way in, and they may very well succeed.
 5. Select an Image
-   * **Target Image.** If you followed the instructions, this will only allow you to select "Debian 11" (though previous versions of this Stackscript worked with Debian 9 or 10and might still).
+   * **Target Image.** If you followed the instructions, this will only allow you to select "Debian 12" (though previous versions of this Stackscript worked with Debian 9 or 10 or 12 and might still).
 6. Choose a region for where the Linode will be located.
 
 *The remaining questions all have to do with the mechanics of the VPS deployment and should be left as they are with one exception: bump the Swap Disk from 256MB to 512MB, to ensure that you have enough memory to download the blockchain.*
@@ -72,7 +72,7 @@ If you want to instead have a non-Pruned Mainnet in a VPS, you'll need to instal
 
 The following chart shows minimum requirements
 
-| Setup | Memory | Storage | Linnode |
+| Setup | Memory | Storage | Linode  |
 |-------|--------|---------|---------|
 | Mainnet | 2G | 280G | Linode 16GB |
 | Pruned Mainnet | 2G | ~5G | Linode 4GB |
@@ -196,7 +196,7 @@ If all look good, congratulations, you have a functioning Bitcoin node using Lin
 
 ## What We Have Wrought
 
-Although the default Debian 11 image that we are using for your VPS has been modified by Linode to be relatively secure, your Bitcoin node as installed through the Linode StackScript is set up with an even higher level of security. You may find this limiting, or be unable to do things that you expect. Here are a few notes on that:
+Although the default Debian 12 image that we are using for your VPS has been modified by Linode to be relatively secure, your Bitcoin node as installed through the Linode StackScript is set up with an even higher level of security. You may find this limiting, or be unable to do things that you expect. Here are a few notes on that:
 
 ### Protected Services
 
@@ -258,7 +258,7 @@ You have a few options for what's next:
 
 ## Synopsis: Bitcoin Installation Types
 
-**Mainnet.** This will download the entirety of the Bitnet blockchain. That's 280G of data (and getting more every day). 
+**Mainnet.** This will download the entirety of the Bitcoin blockchain. That's 280G of data (and getting more every day). 
 
 **Pruned Mainnet.** This will cut the blockchain you're storing down to just the last 550 blocks. If you're not mining or running some other Bitcoin service, this should be plenty for validation.
 

02_2_Setting_Up_Bitcoin_Core_Other.md

@@ -5,11 +5,13 @@ The previous section, [§2.1: Setting Up a Bitcoin-Core VPS with Bitcoin Standup
 Following are other setup methodologies that we are aware of:
 
 * *[Compiling from Source](A2_0_Compiling_Bitcoin_from_Source.md).* If you prefer to compile Bitcoin Core by hand, that's covered in Appendix 2.
-* *[Using GordianNode-macOS](https://github.com/BlockchainCommons/GordianNode-macOS).* If you have a modern Mac, you can use Blockchain Commons' *GordianNode* app, powered by *BitcoinStandup*, to install a full node on your Mac.
+* *[Using GordianServer-macOS](https://github.com/BlockchainCommons/GordianServer-macOS).* If you have a modern Mac, you can use Blockchain Commons' *GordianNode* app, powered by *BitcoinStandup*, to install a full node on your Mac.
 * *[Using Other Bitcoin Standup Scripts](https://github.com/BlockchainCommons/Bitcoin-Standup-Scripts).* Blockchain Commons also offers a version of the Linode script that you used that can be run from the command line on any Debian or Ubuntu machine. This tends to be the leading-edge script, which means that it's more likely to feature new functions, like Lightning installation.
 * *[Setting Up a Bitcoin Node on AWS](https://wolfmcnally.com/115/developer-notes-setting-up-a-bitcoin-node-on-aws/).* @wolfmcnally has written a step-by-step tutorial for setting up Bitcoin-Core with Amazon Web Services (AWS).
 * *[Setting Up a Bitcoin Node on a Raspberry Pi 3](https://medium.com/@meeDamian/bitcoin-full-node-on-rbp3-revised-88bb7c8ef1d1).* Damian Mee explains how to set up a headless full node on a Raspberry Pi 3.
 
+Be sure that you are installing on a current version of your OS, to avoid problems down the line. As of this writing, this course is tested on Debian 11.
+
 ## What's Next?
 
 Unless you want to return to one of the other methodologies for creating a Bitcoin-Core node, you should:

03_1_Verifying_Your_Bitcoin_Setup.md

@@ -45,15 +45,13 @@ You can do this by looking at a blocknet explorer, such as [the Blockcypher Test
 
 If you'd like an alias to look at everything at once, the following currently works for Testnet, but may disappear at some time in the future:
 ```
-$ cat >> ~/.bash_profile << EOF
-alias btcblock="echo \\\`bitcoin-cli getblockcount 2>&1\\\`/\\\`wget -O - https://blockstream.info/testnet/api/blocks/tip/height 2> /dev/null | cut -d : -f2 | rev | cut -c 1- | rev\\\`"
-EOF
+$ echo "alias btcblock='echo \$(bitcoin-cli -testnet getblockcount)/\$(curl -s https://blockstream.info/testnet/api/blocks/tip/height)'" >> .bash_profile
 $ source .bash_profile 
 $ btcblock
 1804372/1804372
 ```
 
-> :link: **TESTNET vs MAINNET:** Remember that this tutorial generally assumes that you are using testnet. If you're using the mainnet instead, you can retrieve the current block height with: `wget -O - http://blockchain.info/q/getblockcount 2>/dev/null`. You can replace the latter half of the `btblock` alias (after `/`) with that.
+> :link: **TESTNET vs MAINNET:** Remember that this tutorial generally assumes that you are using testnet. If you're using the mainnet instead, you can retrieve the current block height with: `curl -s https://blockchain.info/q/getblockcount`. You can replace the latter half of the `btcblock` alias (after `/\$(`) with that.
 
 If you're not up-to-date, but your `getblockcount` is increasing, no problem. Total download time can take from an hour to several hours, depending on your setup.
 

03_2_Knowing_Your_Bitcoin_Setup.md

@@ -16,7 +16,7 @@ The setup guides in [Chapter Two: Creating a Bitcoin-Core VPS](02_0_Setting_Up_a
 Moving back to your ~/.bitcoin directory, you'll find that the testnet3 directory contains all of the guts:
 ```
 $ ls ~/.bitcoin/testnet3
-banlist.dat   blocks	  debug.log	     mempool.dat	peers.dat
+banlist.json   blocks	  debug.log	     mempool.dat	peers.dat
 bitcoind.pid  chainstate  fee_estimates.dat  onion_private_key	wallets
 ```
 You shouldn't mess with most of these files and directories — particularly not the `blocks` and `chainstate` directories, which contain all of the blockchain data, and the information in your `wallets` directory, which contains your personal wallet. However, do take careful note of the `debug.log` file, which you should refer to if you ever have problems with your setup.

03_3_Setting_Up_Your_Wallet.md

@@ -16,7 +16,8 @@ $
 
 Although Bitcoin Core won't create a new wallet for you, it will still load a top-level unnamed ("") wallet on startup by default. You can take advantage of this by creating a new unnamed wallet.
 ```
-$ bitcoin-cli createwallet ""
+$ bitcoin-cli -named createwallet wallet_name="" descriptors=false
+
 {
   "name": "",
   "warning": ""
@@ -33,6 +34,8 @@ database  db.log  wallet.dat
 
 Sweet, now you have a Bitcoin wallet. But a wallet will be of little use for receiving bitcoins if you don't create an address first.
 
+> :warning: **VERSION WARNING:** Starting in Bitcoin Core v 23.0, descriptor wallets became the default. That's great, because descriptor wallets are very powerful, except they don't currently work with multisigs! So, we turn them off with the "descriptors=false" argument. See [§3.5](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/03_5_Understanding_the_Descriptor.md) for more on descriptors.
+
 ## Create an Address
 
 The next thing you need to do is create an address for receiving payments. This is done with the `bitcoin-cli getnewaddress` command. Remember that if you want more information on this command, you should type `bitcoin-cli help getnewaddress`. Currently, there are three types of addresses: `legacy` and the two types of SegWit address, `p2sh-segwit` and `bech32`. If you do not otherwise specify, you'll get the default, which is currently `bech32`.

03_4_Receiving_a_Transaction.md

@@ -285,7 +285,7 @@ $ bitcoin-cli gettransaction "8e2ab10cabe9ec04ed438086a80b1ac72558cc05bb206e48fc
 ```
 Now you can see the full information on the transaction, including all of the inputs ("vin") and all the outputs ("vout). One of the interesting things to note is that although we received .01 BTC in the transaction, another .01010143 was sent to another address. That was probably a change address, a concept that is explored in the next section. It is quite typical for a transaction to have multiple inputs and/or multiple outputs.
 
-There is another command, `getrawtransaction`, which allows you to look at transactions that are not in your wallet. However, it requires you to have unpruned node and `txindex=1` in your `bitcoin.conf` file. Unless you have a serious need for information not in your wallet, it's probably just better to use a Bitcoin explorer for this sort of thing ...
+There is another command, `getrawtransaction`, which allows you to look at transactions that are not in your wallet. However, it requires you to have an unpruned node and `txindex=1` in your `bitcoin.conf` file. Unless you have a serious need for information not in your wallet, it's probably just better to use a Bitcoin explorer for this sort of thing ...
 
 ## Optional: Use a Block Explorer
 

04_2__Interlude_Using_JQ.md

@@ -4,15 +4,21 @@ Creating a raw transaction revealed how more complex bitcoin-cli results can't e
 
 ## Install JQ
 
-JQ is available from a [Github repository](https://stedolan.github.io/jq/). Just download for Linux, OS X, or Windows, as appropriate.
+For modern versions of Debian, you should be able to install JQ using `apt-get`:
+```
+# apt-get install jq
+```
+> :book: ***What is JQ?*** The repository explains it best, saying "jq is like sed for JSON data - you can use it to slice and filter and map and transform structured data with the same ease that sed, awk, grep and friends let you play with text."
+
+If that works, you're done!
+
+Otherwise, you can download JQ from a [Github repository](https://stedolan.github.io/jq/). Just download a binary for Linux, OS X, or Windows, as appropriate.
 
 Once you've downloaded the binary, you can install it on your system. If you're working on a Debian VPS as we suggest, your installation will look like this:
 ```
 $ mv jq-linux64 jq
 $ sudo /usr/bin/install -m 0755 -o root -g root -t /usr/local/bin jq
 ```
-> :book: ***What is JQ?*** The repository explains it best, saying "jq is like sed for JSON data - you can use it to slice and filter and map and transform structured data with the same ease that sed, awk, grep and friends let you play with text."
-
 ## Use JQ to Access a JSON Object Value by Key
 
 **Usage Example:** _Capture the hex from a signed raw transaction._

04_4__Interlude_Using_Curl.md

@@ -220,7 +220,7 @@ This is almost exactly the same output that you receive when you type `bitcoin-c
 
 After you know where your funds are, the next step in crafting a transaction is to get a change address. By now you've probably got the hang of this, and you know that for simple RPC commands, all you need to do is adjust the `method` is the `curl` command:
 ```
-$ curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getrawchangeaddress", "params": ["", "legacy"] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/ | jq -r '.'
+$ curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getrawchangeaddress", "params": ["legacy"] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/ | jq -r '.'
 {
   "result": "mrSqN37TPs89GcidSZTvXmMzjxoJZ6RKoz",
   "error": null,
@@ -228,12 +228,12 @@ $ curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc"
 }
 ```
 
-> **WARNING:** The parameters order is important when you are sending RPC commands using curl. For example here, if we had sent `"params": ["legacy"]` instead of `"params": ["", "legacy"]`, we would get a `bech32` address with a label of `"legacy"` instead of a `legacy` address, so pay attention to the order.
+> **WARNING:** The parameters order is important when you are sending RPC commands using curl. There's only one argument for `getrawchangeaddress`, but consider its close cousin `getnewaddress`. That takes two arguments: first label, then type. If we sent that same `"params": ["legacy"]` instead of `"params": ["", "legacy"]`, we would get a `bech32` address with a label of `"legacy"` instead of a `legacy` address, so pay attention to the order!
 
 At this point, we can even revert to our standard practice of saving results to variables with additional help from `jq`:
 ```
-$ changeaddress=$(curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getrawchangeaddress", "params": ["", "legacy"] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/ | jq -r '.result')
-$ echo $changeaddress
+$ newaddress=$(curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getrawchangeaddress", "params": ["legacy"] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/ | jq -r '.result')
+$ echo $newaddress
 mqdfnjgWr2r3sCCeuTDfe8fJ1CnycF2e6R
 ```
 No need to worry about the downloading info. It'll go to `STDERR` and be displayed on your screen, while the results go to `STDOUT` and are saved in your variable.

04_6_Creating_a_Segwit_Transaction.md

@@ -279,7 +279,7 @@ The big thing to note is that function has changed. It was previously `pkh`, whi
 
 There's really no complexity to creating SegWit transactions. Internally, they're structured differently from legacy transactions, but from the command line there's no difference: you just use an address with a different prefix. The only thing to watch for is that some people may not be able to send to a Bech32 address if they're using obsolete software.
 
-> :fire: ***What the power of sending coins with SegWit?***
+> :fire: ***What's the power of sending coins with SegWit?***
 
 > _The Advantages._ SegWit transactions are smaller, and so will be cheaper to send than legacy transactions due to lower fees. Bech32 doubles down on this advantage, and also creates addresses that are harder to foul up when transcribing — and that's pretty important, given that user error is one of the most likely ways to lose your bitcoins.
 

06_1_Sending_a_Transaction_to_a_Multisig.md

@@ -199,7 +199,7 @@ As you can see, there was nothing unusual in the creation of the transaction, an
 
 Multisig addresses lock funds to multiple private keys — possibly requiring all of those private keys for redemption, and possibly requiring just some from the set. They're easy enough to create with `bitcoin-cli` and they're entirely normal to send to. This ease is due in large part to the invisible use of P2SH (pay-to-script-hash) addresses, a large topic that we've touched upon twice now, with P2SH-SegWit and multisig addresses, and one that will get more coverage in the future.
 
-> :fire: ***What is the power of multisignatures?*** Multisignatures allow the modeling of a variety of financial arrangements such as corporations, partnerships, committees, and other groups. A 1-of-2 multisig might be a married couple's joint bank account, while a 2-of-2 multisig might be used for large expenditures by a Limited Liability Partnership. Multisignatures also form one of the bases of Smart Contracts. For example, a real estate deal could be closed with a 2-of-3 multisig, where the signatures are submitted by the buyer, the seller, and an escrow agent. Once the escrow agent agrees that all of the conditions have been met, he frees up the funds for the seller; or alternatively, the buyer and seller can jointly free the funds.
+> :fire: ***What is the power of multisignatures?*** Multisignatures allow the modeling of a variety of financial arrangements such as corporations, partnerships, committees, and other groups. A 1-of-2 multisig might be a married couple's joint bank account, while a 2-of-2 multisig might be used for large expenditures by a Limited Liability Partnership. Multisignatures also form one of the bases of Smart Contracts. For example, a real estate deal could be closed with a 2-of-3 multisig, where the signatures are submitted by the buyer, the seller, and a licensed escrow agent. Once the escrow agent agrees that all of the conditions have been met, he frees up the funds for the seller; or alternatively, the buyer and seller can jointly free the funds.
 
 ## What's Next?
 

06_2_Spending_a_Transaction_to_a_Multisig.md

@@ -8,7 +8,7 @@ To start with, you need to find your funds; your computer doesn't know to look f
 ```
 $ bitcoin-cli -named importaddress address=2NAGfA4nW6nrZkD5je8tSiAcYB9xL2xYMCz
 ```
-If you've got a pruned node (and you probably do), you'll instead need to tell it no to rescan:
+If you've got a pruned node (and you probably do), you'll instead need to tell it not to rescan:
 ```
 $ bitcoin-cli -named importaddress address=2NAGfA4nW6nrZkD5je8tSiAcYB9xL2xYMCz rescan="false"
 ```

06_3_Sending_an_Automated_Multisig.md

@@ -49,9 +49,9 @@ As noted in the previous section, it currently doesn't matter whether you use ad
 
 Afterward, the members of the multisig will still need to run `importaddress` to watch for funds received on the multisig address:
 ```
-machine1$ bitcoin-cli -named importaddress address=2Mzw7WBvh9RAQ4ssKqxyNyP7L9NAojLqSW8 rescan="false"
+machine1$ bitcoin-cli -named importaddress address=tb1q9as46kupwcxancdx82gw65365svlzdwmjal4uxs23t3zz3rgg3wqpqlhex rescan="false"
 
-machine2$ bitcoin-cli -named importaddress address=2Mzw7WBvh9RAQ4ssKqxyNyP7L9NAojLqSW8 rescan="false"
+machine2$ bitcoin-cli -named importaddress address=tb1q9as46kupwcxancdx82gw65365svlzdwmjal4uxs23t3zz3rgg3wqpqlhex rescan="false"
 ```
 
 ## Respend with an Automated Transaction

07_2_Using_a_Partially_Signed_Bitcoin_Transaction.md

@@ -588,6 +588,8 @@ Each user puts in their own UTXO, and each one receives a corresponding output.
 
 The best way to manage a CoinJoin is to send out the base PSBT to all the parties (who could be numerous), and then have them each sign the PSBT and send back to a single party who will combine, finalize, and send.
 
+> :book: ***What is CoinJoin?*** CoinJoin is a methodology whereby a group of people can mix together their cryptocurrency, helping to reduce fungibility for all the coins. Each person puts in and takes out the same amount of coins (minus transaction fees) in a multi-person transaction that is simultaneously conducted by a _large_ number of people.  It's designed to be "trustless" so that the parties don't need to know or trust each other. A CoinJoin ultimately increases anonymity by making the coins hard to trace. The Wasabi Wallet and a number of "mixer" services support CoinJoin at the large-scale necessary for improved anonymity.
+
 ## Summary: Using a Partially Signed Bitcoin Transaction
 
 You've now seen the PSBT process that you learned in [§7.1](07_1_Creating_a_Partially_Signed_Bitcoin_Transaction.md) in use in three real-life examples: creating a multi-sig, pooling funds, and CoinJoining. These were all theoretically possible in classic Bitcoin by having multiple people sign carefully constructed transactions, but PSBTs make it standardized and simple.
@@ -598,4 +600,4 @@ That last point, on creating a transaction on one machine and signing on another
 
 ## What's Next?
 
-Continue "Expanding Bitcoin Transactions with PSBTs" with [§7.3: Inegrating with Hardware Wallets](07_3_Integrating_with_Hardware_Wallets.md).
+Continue "Expanding Bitcoin Transactions with PSBTs" with [§7.3: Integrating with Hardware Wallets](07_3_Integrating_with_Hardware_Wallets.md).

07_3_Integrating_with_Hardware_Wallets.md

@@ -130,7 +130,7 @@ You can watch for funds by importing addresses from your hardware wallet to your
 
 To use your hardware wallet with `bitcoin-cli`, you'll want to create a specific named wallet in Bitcoin Core, using the `createwallet` RPC, which is a command we haven't previously discussed.
 ```
-$ bitcoin-cli --named createwallet wallet_name="ledger" disable_private_keys="true"
+$ bitcoin-cli --named createwallet wallet_name="ledger" disable_private_keys="true" descriptors="false"
 {
   "name": "ledger",
   "warning": ""

08_1_Sending_a_Transaction_with_a_Locktime.md

@@ -6,13 +6,13 @@ The previous chapters showed two different ways to send funds from multiple mach
 
 When you create a locktime transaction, you lock it with a number that represents either a block height (if it's a small number) or a UNIX timestamp (if it's a big number). This tells the Bitcoin network that the transaction may not be put into a block until either the specified time has arrived or the blockchain has reached the specified height. 
 
-> :book: _What is block height?_ It's the total count of blocks in the chain, going back to the genesis block for Bitcoin. 
+> :book: **_What is block height?_** It's the total count of blocks in the chain, going back to the genesis block for Bitcoin. 
 
 When a locktime transaction is waiting to go into a block, it can be cancelled. This means that it is far, far from finalized. In fact, the ability to cancel is the whole purpose of a locktime transaction.
 
-> :book: _What is nLockTime?_ It's the same thing as locktime. More specifically, it's what locktime is called internal to the Bitcoin Core source code.
+> :book: **_What is nLockTime?_** It's the same thing as locktime. More specifically, it's what locktime is called internal to the Bitcoin Core source code.
 
-> :book: _What is Timelock?_ Locktime is just one way to lock Bitcoin transactions until some point in the future; collectively these methods are called timelocks. Locktime is the most basic timelock method. It locks an entire transaction with an absolute time, and it's available through `bitcoin-cli` (which is why it's the only timelock covered in this section). A parallel method, which locks a transaction with a relative time, is defined in [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) and covered in [§11.3: Using CSV in Scripts](11_3_Using_CSV_in_Scripts.md). 
+> :book: **_What is Timelock?_** Locktime is just one way to lock Bitcoin transactions until some point in the future; collectively these methods are called timelocks. Locktime is the most basic timelock method. It locks an entire transaction with an absolute time, and it's available through `bitcoin-cli` (which is why it's the only timelock covered in this section). A parallel method, which locks a transaction with a relative time, is defined in [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) and covered in [§11.3: Using CSV in Scripts](11_3_Using_CSV_in_Scripts.md). 
 
 > Bitcoin Script further empowers both sorts of timelocks, allowing for the locking of individual outputs instead of entire transactions. Absolute timelocks (such as Locktime) are linked to the Script opcode OP_CHECKLOCKTIMEVERIFY, which is defined in [BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) and covered in [§11.2: Using CLTV in Scripts](11_2_Using_CLTV_in_Scripts.md), while relative timelocks (such as Timelock) are linked to the Script opcode OP_CHECKSEQUENCEVERIFY, which is defined in [BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) and also covered in [§11.3](11_3_Using_CSV_in_Scripts.md).
 
@@ -24,7 +24,7 @@ In order to create a locktime transaction, you need to first determine what you
 
 Most frequently you will set the locktime to a UNIX timestamp representing a specific date and time. You can calculate a UNIX timestamp at a web site like [UNIX Time Stamp](http://www.unixtimestamp.com/) or [Epoch Convertor](https://www.epochconverter.com/). However, it would be better to [write your own script](https://www.epochconverter.com/#code) on your local machine, so that you know the UNIX timestamp you receive is accurate. If you don't do that, at least double check on two different sites.
 
-> :book: _Why Would I Use a UNIX Timestamp?_ Using a UNIX timestamp makes it easy to definitively link a transaction to a specific time, without worrying about whether the speed of block creation might change at some point. Particularly if you're creating a locktime that's far in the future, it's the safer thing to do. But, beyond that, it's just more intuitive, creating a direct correlation between some calendar date and the time when the transaction can be mined.
+> :book: **_Why Would I Use a UNIX Timestamp?_** Using a UNIX timestamp makes it easy to definitively link a transaction to a specific time, without worrying about whether the speed of block creation might change at some point. Particularly if you're creating a locktime that's far in the future, it's the safer thing to do. But, beyond that, it's just more intuitive, creating a direct correlation between some calendar date and the time when the transaction can be mined.
 
 > :warning: **WARNING:** Locktime with UNIX timestamps has a bit of wriggle room: the release of blocks isn't regular and block times can be two hours ahead of real time, so a locktime actually means "within a few hours of this time, plus or minus".
 
@@ -34,7 +34,7 @@ Alternatively, you can set the locktime to a smaller number representing a block
 
 Once you've figured out the current height, you can decide how far in the future to set your locktime to. Remember that on average a new block will be created every 10 minutes. So, for example, if you wanted to set the locktime to a week in the future, you'd choose a block height that is 6 x 24 x 7 = 1,008 blocks in advance of the current one.
 
-> :book: _Why Would I Use a Blockheight?_ Unlike with timestamps, there's no fuzziness for blockheights. If you set a blockheight of 120,000 for your locktime, then there's absolutely no way for it to go into block 119,999. This can make it easier to algorithmically control your locktimed transaction. The downside is that you can't be as sure of when precisely the locktime will be.
+> :book: **_Why Would I Use a Blockheight?_** Unlike with timestamps, there's no fuzziness for blockheights. If you set a blockheight of 120,000 for your locktime, then there's absolutely no way for it to go into block 119,999. This can make it easier to algorithmically control your locktimed transaction. The downside is that you can't be as sure of when precisely the locktime will be.
 
 > :warning: **WARNING:** If you want to set a block-height locktime, you must set the locktime to less than 500 million. If you set it to 500 million or over, your number will instead be interpreted as a timestamp. Since the UNIX timestamp of 500 million was November 5, 1985, that probably means that your transaction will be put into a block at the miners' first opportunity.
 
@@ -128,7 +128,7 @@ Cancelling a locktime transaction is _very_ simple: you send a new transactions
 
 Locktime offers a way to create a transaction that _should_ not be relayable to the network and that _will_ not be accepted into a block until the appropriate time has arrived. In the meantime, it can be cancelled simply by reusing a UTXO.
 
-> :fire: _What is the Power of Locktime?_ The power of locktime may not be immediately obvious because of the ability to cancel it so easily. However, it's another of the bases of Smart Contracts: it has a lot of utility in a variety of custodial or contractual applications. For example, consider a situation where a third party is holding your bitcoins. In order to guarantee the return of your bitcoins if the custodian ever disappeared, they could produce a timelock transaction to return the coins to you, then update that every once in a while with a new one, further in the future. If they ever failed to update, then the coins would return to you when the current timelock expired. Locktime could similarly be applied to a payment network, where the network holds coins while they're being exchanged by network participants. Finally, a will offers an example of a more complex contract, where payments are sent out to a number of people. These payments would be built on locktime transactions, and would be continually updated as long as the owner continues to show signs of life. (The unifying factor of all of these applications is, of course, _trust_. Simple locktime transactions only work if the holder of the coins can be trusted to send them out under the appropriate conditions.)
+> :fire: **_What is the Power of Locktime?_** The power of locktime may not be immediately obvious because of the ability to cancel it so easily. However, it's another of the bases of Smart Contracts: it has a lot of utility in a variety of custodial or contractual applications. For example, consider a situation where a third party is holding your bitcoins. In order to guarantee the return of your bitcoins if the custodian ever disappeared, they could produce a timelock transaction to return the coins to you, then update that every once in a while with a new one, further in the future. If they ever failed to update, then the coins would return to you when the current timelock expired. Locktime could similarly be applied to a payment network, where the network holds coins while they're being exchanged by network participants. Finally, a will offers an example of a more complex contract, where payments are sent out to a number of people. These payments would be built on locktime transactions, and would be continually updated as long as the owner continues to show signs of life. (The unifying factor of all of these applications is, of course, _trust_. Simple locktime transactions only work if the holder of the coins can be trusted to send them out under the appropriate conditions.)
 
 ## What's Next?
 

09_0_Introducing_Bitcoin_Scripts.md

@@ -2,7 +2,7 @@
 
 To date, we've been interacting with Bitcoin at a relatively high level of abstraction. The `bitcoin-cli` program offers access to a variety of RPC commands that support the creation and control of raw Bitcoin transactions that include funds, data, timelocks, and multisigs.
 
-However, Bitcoin offers much more complexity than that. It includes a simple scripting language that can be used to create even more complex redemption conditions. If multisigs and timelocks provided the bases of Smart Contracts, then Bitcoin Script builds high on that foundation. It's the next step in empowering Bitcoin.
+However, Bitcoin offers much more complexity than that. It includes a simple scripting language that can be used to create even more complex redemption conditions. If multisigs and timelocks provided the basis of Smart Contracts, then Bitcoin Script builds high on that foundation. It's the next step in empowering Bitcoin.
 
 ## Objectives for This Chapter
 

09_3_Testing_a_Bitcoin_Script.md

@@ -182,6 +182,8 @@ btcdeb> stack
 ```
 Using these commands can make it easier to see what's going on and where you are.
 
+> :warning: **WARNING:** `btcdeb` is much more complex to use if you are trying to verify signatures. See [Signature Checking with btcdeb](https://github.com/bitcoin-core/btcdeb/blob/master/doc/btcdeb.md#signature-checking). This is true for any script testing, so we don't suggest it if you're trying to verify an `OP_CHECKSIG` or an `OP_CHECKMULTISIG`.
+
 ## Test a Script Online
 
 There are also a few web simulators that you can use to test scripts online. They can be superior to a command-line tool by offering a more graphical output, but we also find that they tend to have shortcomings.

10_4_Scripting_a_Multisig.md

@@ -99,7 +99,7 @@ These were generally problems with any sort of complex Bitcoin script, but they
 
 ## Create a P2SH Multisig
 
-P2SH multisigs are the modern methodology for creating multisigs on the Blockchains. They can be created very simply, using the same process seen in the previous sections.
+P2SH multisigs are the modern methodology for creating multisigs on the Blockchain. They can be created very simply, using the same process seen in the previous sections.
 
 ### Create the Lock for the P2SH Multisig
 

11_2_Using_CLTV_in_Scripts.md

@@ -51,7 +51,7 @@ But we'll usually abtract it like this:
 
 The above explanation is sufficient to use and understand CLTV. However, [BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) lays out all the details.
 
-A locking script will only allow a transaction to respend a UTXO locked with a CLTV if `OP_CHECKLOCKTIMEVALUE` verifies all of the following:
+A locking script will only allow a transaction to respend a UTXO locked with a CLTV if `OP_CHECKLOCKTIMEVERIFY` verifies all of the following:
 
 * The `nSequence` field must be set to less than 0xffffffff, usually 0xffffffff-1 to avoid confilcts with relative timelocks.
 * CLTV must pop an operand off the stack and it must be 0 or greater.

11_3_Using_CSV_in_Scripts.md

@@ -6,7 +6,7 @@
 
 ## Understand nSequence
 
-Every input into in a transaction has an `nSequence` (or if you prefer `sequence`) value. It's been a prime tool for Bitcoin expansions as discussed previously in [§5.2: Resending a Transaction with RBF](05_2_Resending_a_Transaction_with_RBF.md) and [§8.1 Sending a Transaction with a Locktime](08_1_Sending_a_Transaction_with_a_Locktime.md), where it was used to signal RBF and `nLockTime`, respectively. However, there's one more use for `nSequence`, described by [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki): you can use it to create a relative timelock on a transaction.
+Every input into a transaction has an `nSequence` (or if you prefer `sequence`) value. It's been a prime tool for Bitcoin expansions as discussed previously in [§5.2: Resending a Transaction with RBF](05_2_Resending_a_Transaction_with_RBF.md) and [§8.1 Sending a Transaction with a Locktime](08_1_Sending_a_Transaction_with_a_Locktime.md), where it was used to signal RBF and `nLockTime`, respectively. However, there's one more use for `nSequence`, described by [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki): you can use it to create a relative timelock on a transaction.
 
 A relative timelock is a lock that's placed on a specific input of a transaction and that's calculated in relation to the mining date of the UTXO being used in the input. For example, if a UTXO was mined at block #468260 and a transaction was created where the input for that UTXO was given an `nSequence` of 100, then the new transaction could not be mined until at least block #468360.
 

14_2_Changing_Your_Bitcoin_Hidden_Services.md

@@ -59,6 +59,8 @@ addnode=address.onion
 addnode=address.onion
 addnode=address.onion
 ```
+See [Bitcoin Onion Nodes](https://github.com/emmanuelrosa/bitcoin-onion-nodes) for a listing and an example of how to add them.
+
 Afterward, restart `tor` and `bitcoind`.
 
 You should now be communicating exlusively on Tor. But, unless you are in a hostile state, this level of anonymity is probably not required. It also is not particularly recommended: you might greatly decrease your number of potential peers, inviting problems of censorship or even correlation. You may also see lag. And, this setup may give you a false sense of anonymity that really doesn't exist on the Bitcoin network.

16_1_Accessing_Bitcoind_with_C.md

@@ -6,6 +6,8 @@ You've already seen one alternative way to access the Bitcoind's RPC ports: `cur
 
 ## Set Up libbitcoinrpc
 
+> :warning: **WARNING** It appears that `libbitcoinrpc` has been entirely abandoned. We have logged updating this to a new C library as an [issue](https://github.com/BlockchainCommons/Community/issues/140). In the meantime, the `libbitcoinrpc` library does not currently compile without intervention. As a result 16.1 and 16.2 is mainly viewable as pseudo-code that shows the process of integrating Bitcoin-Core with C.
+
 To use `libbitcoinrpc`, you need to install a basic C setup and the dependent packages `libcurl`, `libjansson`, and `libuuid`. The following will do so on your Bitcoin Standup server (or any other Ubuntu server).
 ```
 $ sudo apt-get install make gcc libcurl4-openssl-dev libjansson-dev uuid-dev
@@ -18,13 +20,13 @@ Need to get 358 kB of archives.
 After this operation, 1.696 kB of additional disk space will be used.
 Do you want to continue? [Y/n] y
 ```
-You can then download [libbitcoinrpc from Github](https://github.com/gitmarek/libbitcoinrpc/blob/master/README.md). Clone it or grab a zip file, as you prefer.
+You can then download [libbitcoinrpc from Github](https://github.com/BlockchainCommons/libbitcoinrpc/blob/master/README.md). Clone it or grab a zip file, as you prefer.
 ```
 $ sudo apt-get install git
-$ git clone https://github.com/gitmarek/libbitcoinrpc
+$ git clone https://github.com/BlockchainCommons/libbitcoinrpc.git
 ```
 
-> :warning: **WARNING** A change in the "signrawtransaction" RPC caused signing with `libbitcoinrpc` to segfault for Bitcoin 0.17 or higher. A [PR has been submitted](https://github.com/gitmarek/libbitcoinrpc/pull/1/commits) to resolve the problem, but if it hasn't yet been merged, you can just make the one simple change in the source code to `src/bitcoinrpc_method.c` before compiling.
+> :warning: **WARNING** A change in the "signrawtransaction" RPC caused signing with `libbitcoinrpc` to segfault for Bitcoin 0.17 or higher. A [PR has been submitted](https://github.com/gitmarek/libbitcoinrpc/pull/1) to resolve the problem, but if it hasn't yet been merged, you can just make the one simple change in the source code to `src/bitcoinrpc_method.c` before compiling.
 
 ### Compiling libbitcoinrpc
 
@@ -160,7 +162,7 @@ Successfully connected to server!
 
 ## Make an RPC Call
 
-In order to use an RPC method using `libbitcoinrpc`, you must initialize a variable of type `bitcoinrpc_method_t`. You do so with the appropriate value for the method you want to use, all of which are listed in the [bitcoinrpc Reference](https://github.com/gitmarek/libbitcoinrpc/blob/master/doc/reference.md).
+In order to use an RPC method using `libbitcoinrpc`, you must initialize a variable of type `bitcoinrpc_method_t`. You do so with the appropriate value for the method you want to use, all of which are listed in the [bitcoinrpc Reference](https://github.com/BlockchainCommons/libbitcoinrpc/blob/master/doc/reference.md).
 ```
 bitcoinrpc_method_t *getmininginfo  = NULL;
 getmininginfo = bitcoinrpc_method_init(BITCOINRPC_METHOD_GETMININGINFO);

18_4_Accessing_Bitcoind_with_Python.md

@@ -218,7 +218,7 @@ pprint(utxos)
 print("------------------------------------------\n")
 ```
 
-In order to manipulate an array like the one returned from `listtransactions` or `listunpsent`, you just grab the appropriate item from the appropriate element of the array:
+In order to manipulate an array like the one returned from `listtransactions` or `listunspent`, you just grab the appropriate item from the appropriate element of the array:
 ```
 ## Select a UTXO - first one selected here
 utxo_txid = utxos[0]['txid']
@@ -379,7 +379,7 @@ change_amt = float('%.8f'%((utxo_amt - recipient_amt) - miner_fee))
 
 > :warning: **WARNING:** Obviously a real program would make more sophisticated choices about what UTXO to use, what to do with the funds, and what miner's fee to pay.
 
-### 2. Create Raw Transacion
+### 2. Create Raw Transaction
 
 Now you have all the information to send a transaction, but before you can send one, you have to create a transaction. 
 
@@ -461,7 +461,8 @@ Learn more about "Talking to Bitcoin in Other Languages" in [18.5: Accessing Bit
 
 ## Variant: Build Python from Source
 
-If you need to install Python 3 from source, follow these instructions, then continue with ["Creating a BitcoinRPC Project"](17_4_Accessing_Bitcoind_with_Python.md#creating-a-bitcoinrpc-project).
+If you need to install Python 3 from source, follow these instructions, then continue with ["Create a BitcoinRPC Project"](18_4_Accessing_Bitcoind_with_Python.md#create-a-bitcoinrpc-project).
+
 
 ### 1. Install Dependencies
 ```sh

CLA-signed/CLA.joa-rodrigues.90487FE3801DE403173A2EDBC685E6D937FDC203.asc

@@ -0,0 +1,65 @@
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA512
+
+# Contributor License Agreement
+
+Version 1.0
+
+Name: `$name`
+
+E-Mail: `$email`
+
+Legal Jurisdiction: Wyoming, United States of America
+
+Project: https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line
+
+Date: `$date`
+
+## Purpose
+
+This agreement gives Blockchain Commons, LLC the permission it needs in order to accept my contributions into its open software project and to manage the intellectual property in that project over time.
+
+## License
+
+I hereby license Blockchain Commons, LLC to:
+
+1.  do anything with my contributions that would otherwise infringe my copyright in them
+
+2.  do anything with my contributions that would otherwise infringe patents that I can or become able to license
+
+3.  sublicense these rights to others on any terms they like
+
+## Reliability
+
+I understand that Blockchain Commons will rely on this license.  I may not revoke this license.
+
+## Awareness
+
+I promise that I am familiar with legal rules, like ["work made for hire" rules](http://worksmadeforhire.com), that can give employers and clients ownership of intellectual property in work that I do.  I am also aware that legal agreements I might sign, like confidential information and invention assignment agreements, will usually give ownership of intellectual property in my work to employers, clients, and companies that I found.  If someone else owns intellectual property in my work, I need their permission to license it.
+
+## Copyright Guarantee
+
+I promise not to offer contributions to the project that contain copyrighted work that I do not have legally binding permission to contribute under these terms.  When I offer a contribution with permission, I promise to document in the contribution who owns copyright in what work, and how they gave permission to contribute it.  If I later become aware that one of my contributions may have copyrighted work of others that I did not have permission to contribute, I will notify Blockchain Commons, in confidence, immediately.
+
+## Patent Guarantee
+
+I promise not to offer contributions to the project that I know infringe patents of others that I do not have permission to contribute under these terms.
+
+## Open Source Guarantee
+
+I promise not to offer contributions that contain or depend on the work of others, unless that work is available under a license that [Blue Oak Council rates bronze or better](https://blueoakconcil.org/list), such as the MIT License, two- or three-clause BSD License, the Apache License Version 2.0, or the Blue Oak Model License 1.0.0.  When I offer a contribution containing or depending on others' work, I promise to document in the contribution who licenses that work, along with copies of their license terms.
+
+## Disclaimers
+
+***As far as the law allows, my contributions come as is, without any warranty or condition.  Other than under [Copyright Guarantee](#copyright-guarantee), [Patent Guarantee](#patent-guarantee), or [Open Source Guarantee](#open-source-guarantee), I will not be liable to anyone for any damages related to my contributions or this contributor license agreement, under any kind of legal claim.***
+
+- ---
+
+To sign this Contributor License Agreement, fill in `$name`, `$email`, and `$date` above. Then sign using GPG using the following command `gpg --armor --clearsign --output ./CLA-signed/CLA.YOURGITHUBNAME.YOURGPGFINGERPRINT.asc CLA.md`, then either submit your signed Contributor License Agreement to this repo as a GPG signed Pull Request or email it to [ChristopherA@BlockchainCommons.com](mailto:ChristopherA@BlockchainCommons.com).
+-----BEGIN PGP SIGNATURE-----
+
+iHUEARYKAB0WIQSQSH/jgB3kAxc6LtvGhebZN/3CAwUCYfxLmQAKCRDGhebZN/3C
+AxImAQCBq6rX67QtcvLaUbZWGiGcb6Lwfh5Nfot2W1U0aX9MDgEAilSaykUsHmmb
++dH7vvIb5o3Su5xstebNxx9wqbBL4Ao=
+=N//+
+-----END PGP SIGNATURE-----

README.md

@@ -1,4 +1,4 @@
-# Learning Bitcoin from the Command Line 2.1.0
+# Learning Bitcoin from the Command Line 2.2.0
 ### _by Christopher Allen and Shannon Appelcline_
 
 ![](https://www.blockchaincommons.com/images/projects/lbtc-screen.png)
@@ -160,6 +160,11 @@ v2.1.0 of **Learning Bitcoin from the Command Line** is feature complete and has
 We are also tentatively considering what we could include in a [v3.0](TODO-30.md) of the course. If you'd like to support work of that sort, become a [GitHub Sponsor](https://github.com/sponsors/BlockchainCommons) or support us at our [BTCPay Server](https://btcpay.blockchaincommons.com/), and let us know that **Learning Bitcoin** was the reason why.
 ### Version History
 
+#### 2.2.0 (November 17, 2021)
+
+* [Portuguese translation](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/tree/master/pt)
+* [Spanish translation](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/tree/master/es)
+
 #### 2.1.0 (October 12, 2021)
 
 * New chapter 15  (i2p).
@@ -203,11 +208,12 @@ if you would like to provide a translation of Learning Bitcoin into another lang
 
 The best place to talk about Blockchain Commons and its projects is in our GitHub Discussions areas.
 
-[**Blockchain Commons Discussions**](https://github.com/BlockchainCommons/Community/discussions). For developers, interns, and patrons of Blockchain Commons, please use the discussions area of the [Community repo](https://github.com/BlockchainCommons/Community) to talk about general Blockchain Commons issues, the intern program, or topics other than the [Gordian System](https://github.com/BlockchainCommons/Gordian/discussions) or the [wallet standards](https://github.com/BlockchainCommons/AirgappedSigning/discussions), each of which have their own discussion areas.
+[**Blockchain Commons Discussions**](https://github.com/BlockchainCommons/Community/discussions). For developers, interns, and patrons of Blockchain Commons, please use the discussions area of the [Community repo](https://github.com/BlockchainCommons/Community) to talk about general Blockchain Commons issues, the intern program, or topics other than those covered by the [Gordian Developer Community](https://github.com/BlockchainCommons/Gordian-Developer-Community/discussions) or the 
+[Gordian User Community](https://github.com/BlockchainCommons/Gordian/discussions).'
 
 ### Other Questions & Problems
 
-As an open-source, open-development community, Blockchain Commons does not have the resources to provide direct support of our projects. Please consider the discussions area as a locale where you might get answers to questions. Alternatively, please use this repository's [issues](./issues) feature. Unfortunately, we can not make any promises on response time.
+As an open-source, open-development community, Blockchain Commons does not have the resources to provide direct support of our projects. Please consider the discussions area as a locale where you might get answers to questions. Alternatively, please use this repository's [issues](../../issues) feature. Unfortunately, we can not make any promises on response time.
 
 If your company requires support to use our projects, please feel free to contact us directly about options. We may be able to offer you a contract for support from one of our contributors, or we might be able to point you to another entity who can offer the contractual support that you need.
 

TODO-23.md

@@ -0,0 +1,64 @@
+# Updates for v2.3 of LBTCftCL
+
+V2.2 of LBTCftCL was drafted in the summer of 2021. The last major upgrade to the book came with the release of v0.20, but there is a smattering of content through 22.0. Bitcoin Core is now up to v23.0, and the course needs to be updated to best address these recent changes. What follows is a rough listing of updates that are likely to require changes to the course. They will all require investigation, and in some cases it might be determined that there's nothing to be done. Some of the main questions that will determine whether material should be included in the course are listed, as our ideas for where material might go in the course.
+
+## Legacy Updates
+
+* [ ] **Segwit**
+   * Segwit is now old enough that we should teach it as the default. That means that sections 3.1-4.5 should be rewritten to use Segwit as the default and 4.6 should be removed (with perhaps a bit of the information about the different types of addresses being preserved).
+   * It's _possible_ that the same should occur with 10.5, but it should first be reviewed to see if it's a meaningful building block in the scripting process (or not).
+* [ ] **Fees**
+   * There was some question of if `mintxfee` is still current, or if `paytxfee` should be used. I haven't seen any evidence of obsolence, but it'd be good to check this and make sure we're still on the best practices.
+   * This is discussed in [4.1](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/04_1_Sending_Coins_The_Easy_Way.md)
+  
+## 23.0 Updates
+
+See also [#575](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/issues/575) and of course the [Bitcoin Core 23.0 release notes](https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-23.0.md).
+
+* [ ] **Schnorr & Taproot**
+   * Obviously, the biggest update. We'll need to teach the basics of both and why they're exciting. The main question here is: what commands actually take advantage of Schnorr & Taproot, and how can we show this off.
+   * If there's just a little bit of functionality right now, it can go into chapter 8, probably in two new sections: 8.3 & 8.4, on Schnorr and Taproot. If there's already a lot of functionality, it should go into its own chapter, and 8 (and everything beyond it) should be shifted back.
+* [ ] **Descriptor Wallets**
+   * Descriptor wallets are now the default. There's some unfortunate lack of integration with multisigs, but we should otherwise give them more attention. What can we do new about inputting and outputting descriptor wallets? Are there any other functions of note?
+   * This will likely go in [3.5](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/03_5_Understanding_the_Descriptor.md), though it's possible it go split into two chapters: Understanding the Descriptor and Understanding the Descriptor Wallet. See the [0.21 release notes at the bottom](https://bitcoincore.org/en/releases/0.21.0/) for everything about Descriptor Wallets. But note that we explicitly turn them off in 3.2, so any discussions explicitly about descriptor wallets will require creating a new wallet for that purpose
+* [ ] **Freezing Coins**
+   * This is an interesting new ability that allows you to prevent UTXOs from being automatically selected when transactions are created. 
+   * This would probably fit well into 4.5 as a final header-section.
+* [ ] **CJDNS Network** 
+   * I'm not familiar with CJDNS, but it sounds like a privacy option that would fit in with Tor and i2p
+   * If that's correctly, this would be a good 15.2, with the 15.0 chapter renamed "Using Other Privacy Options" or something like that
+* [ ] **RPC Changes**
+   * The following RPC commands have had changes to their output and any examples should be rerun. If they are part of a sequence of commands (e.g., building out a transaction), then the whole sequence should be rerun.
+   * [ ] `createmultisig`, 
+   * [ ] `addmultisigaddress`, 
+   * [ ] `listunspent`, 
+   * [ ] `getblockchaininfo`
+   * Updated RPCs may or may not exist in the text. The best way to find out is to search.
+
+## 22.0 Updates
+
+See [release notes](https://bitcoincore.org/en/releases/22.0/).
+
+* [ ] **New External Signer Commands**
+  * There are some new external signer commands: `enumeratesigners` and `displayaddress`. Are they relevant to what we're teaching? If so, should we add info on them.
+  * See https://github.com/bitcoin/bitcoin/blob/22.x/doc/external-signer.md
+  * Any updates would go in [7.3](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/07_3_Integrating_with_Hardware_Wallets.md).
+* [ ] **RPC Changes**
+   * Again, these commands should be reoutput.
+   * [ ] `getpeerinfo`, 
+   * [ ] `gettxout`, 
+   * [ ] `getrawtransaction`, 
+   * [ ] `decoderawtransaction`, 
+   * [ ] `decodescript`, 
+   * [ ] `getnodeaddresses`
+
+## 0.21.0 Updates
+
+See [release notes](https://bitcoincore.org/en/releases/0.21.0/).
+
+* [ ] **Signet**
+   * Signet is considered more controlled and reliable than testnet, and so should be used as our test network, along with an explanation of what it is and how it differs from other networks.
+   * The setup and explanation of networks appears in [3.1](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/03_1_Verifying_Your_Bitcoin_Setup.md). That should be changed, and with the change of the alias there, we should mostly be used Signet. Then the rest of the course can be searched for any references to testnet.
+* [ ] **RPC Changes**
+   * As usual, these may or may not be used, but if they are, outputs should be redone.
+   * [ ] `getnetworkinfo`

TODO-30.md

@@ -2,26 +2,111 @@
 
 The following TODO items are intended for a 3.0 version of Learning Bitcoin from the Command Line
 
-1. 0.21 Additions
-   * New Wallet. See: https://bitcoin.stackexchange.com/questions/101767/dumpwallet-output-documentation-explanation
-1. Animated GIFs for key CLI demos (probably https://github.com/faressoft/terminalizer but there are others)
-1. Section on Libwally Shim for Swift
-1. Section on Wolf's Bitcoin Lib for Swift
-1. Full example of creating a PSBT, handing it to Libwally, and signing it
-1. Miniscript
-1. More complex descriptors
-1. Schnorr (2021)
-1. Other BCC Command-Line Utilities?
-   * seedtool
-   * keytool
-   * bytewords-cli
-1. Interlude on QR production
-   * QuickConnect QR
-   * UR/Animated QR
-1. Programming Lightning with C
-   * _Some good docs from one of the developers are here: https://diyhpl.us/wiki/transcripts/blockstream-webinars/2019-07-31-rusty-russell-getting-started-with-c-lightning/._
-   * _Other potential docs: https://twitter.com/roasbeef/status/1389649064753471488_
-1. Consider TIme Lock Discussion Improvements
-   * Especially look at chart in https://prestwi.ch/bitcoin-time-locks/
-1. Taproot (August/November)
-   * First Successful Taproot Transactions (Peter W., Twitter)
+## Medium-Scale Updates
+
+The following updates involve updates or the creation of new chapters, but their additions are generally bounded and known.
+
+1. General Update: Consider replacing testnet with signet
+1. New Interlude: Creating QR Codes (after 3.3)
+   * New Subsection: Creating a QR
+   * New Subsection: Creating a Quick Connect QR
+1. Revise Section: Understanding the Descriptor (3.5)
+   * New Content: Descriptor Wallets
+   * New Content: Complex Descriptors
+   * Consider: Breaking into Two Sections
+1. New Interlude: Creating Animated QR Codes (after 7.1)
+   * New Subsection: Understanding Uniform Resources
+   * New Subsection: Creating an Animated QR
+   * New Subsection: Creating an Animated QR of a PSBT
+1. New Chapter: Using Other Command-Line Tools (between 8+9)
+   * 9.1: Using seedtool
+   * 9.2: Using keytool
+   * 9.3: Using bytewords-cli
+1. Revise Section: Understanding Timelock Options (11.1)
+   * Explanation: Better distinguish differences
+   * Reference: consider chart at in https://prestwi.ch/bitcoin-time-locks/
+1. New Chapter: Using Miniscript Command-Line Tools (between 13+14)
+   * 15.1: Using miniscript
+   * 15.2: Using Bitcoin Dev Kit (BDK)
+   * 15.3: Planning for the Future
+1. New Content: Expand the PSBT Libwally Content (17.4) into Two Sections
+   * 17.4: Signing PSBTs in Libwally
+      * Explanation: Contains the current info on importing a PSBT, and shows how to sign it
+   * 17.5: Creating PSBTs in Libwally
+      * Explanation: Contains the current info on creating a PSBT, and shows how to export it
+1. New Chapter: Talking to Bitcoind with Swift (between 17+18)
+   * 19.1: Accessing Bitcoind with Swift (existing section)
+   * 19.2: Using Swift with Bitcoin Lib [Wolf's library]
+   * 19.3: Using Swift with Libwally [Wolf's shim]
+
+## Large-Scale Updates
+
+The following updates involve the large-scale work done on Schnorr and Taproot in Bitcoin Core 0.21 and 22. This represents a first cut at how to layout the work, but revision and expansion will likely be needed as everyone's understanding of these new technologies matures.
+
+**Chapter X: Expanding Bitcoin Transactions with Schnorr** (probably between chapters 6+7)
+
+* New Section X.1: Understanding Schnorr Signatures
+   * New Subsection: Understanding the Math of Schnorr
+      * Explanation: Add + subtract for one signature
+   * New Subsection: Supporting MuSig
+   * New Subsection: Understanding the Use of Adapter Signatures
+   * New Subsection: Knowing the Advantages of Schnorr
+      * Explanation: size, 64 bytes vs 72, better for multisigs
+      * Explanation: speed, linear, validate a million-sig multisig in 2 minutes
+      * Explanation: privacy, no difference between MuSig and sig, no detection of Lightning
+      * Explanation: also better security, non-malleability
+      * Reference: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
+* New Section X.2: Using Schnorr Signatures
+   * New Subsection: Signing with Schnorr
+   * New Subsection: Adding a Schnorr Signature
+   * New Subsection: Reading a Schnorr Signature 
+   * New Subsection: Using Schnorr with Taproot   
+* Update Chapter 6 (Multisigs) to Integrate with Schnorr
+
+**Chapter Y: Improving Bitcoin Scripts with Taproot** (probably between chapters 13+14, possibly expanding to two chapters)
+
+* New Section Y.1: Understanding MAST
+   * New Subsection: Improving Privacy with MAST
+   * New Subsection: Laying out a Script in MAST
+   * New Subsection: Knowing the Advantages of MAST
+      * Explanation: larger scripts
+      * Explanation: hidden branches of scripts
+      * Explanation: fungibility
+      * https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki
+* New Section Y.2: Understanding Taproot
+   * New Subsection: Integrating MAST with Taproot
+      * Explanation: Expanding Segwit
+      * Explanation: Integrating Schnorr Signatures
+   * New Subsection: KNowing the Advantages of Taproot
+      * Explanation: even more privacy; scripts and other addresses are indistinbuishable
+      * Reference: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
+      * Reference: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki
+* New Subsection Y.3: Creating a Taproot Script
+   * New Subsection: Defining a Taproot Script
+      * Explanation: Segwit v1, 32-byte program, not P2SH wrapped, leaf version is 0xc0
+   * New Codes: OP_CHECKSIGADD and OP_SUCCESS
+   * Cut Codes: OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY
+   * Reference: https://twitter.com/pwuille/status/1459778730369368067
+* New Subsection Y.4: Importing a tr Desciptor
+* New Subsection Y.5: Using Taproot in Practice
+   * New Subsection: Making a Taproot Payment
+   * New Subsection: Validating a Taproot Script
+* Update Chapter 9 to Integrate with Taproot
+   * Mention Taproot in 9.1 or 9.2
+   * Add New Section 9.6: Scripting a P2TR (mostly a pointer to Chapter Y)
+
+## Further Updates
+
+The following updates could be part of v3.0 or could be further future, depending on interest and funding.
+
+1. New Graphics: Animated GIFs for key demos.
+   * Reference: https://github.com/faressoft/terminalizer
+1. New Chapter: Talking to Lightningd with C (after chapter 20)
+   * 22.1: Creating a Lightning Channel with C
+   * 22.2: Creating a Payment Request with C
+   * 22.3: Paying an Invoice with C
+   * 22.4: Closing a Lightning Channel with C
+      * Alternatives: Consider Swift instead of C, depending on Lightning support
+      * Reference: https://diyhpl.us/wiki/transcripts/blockstream-webinars/2019-07-31-rusty-russell-getting-started-with-c-lightning/
+      * Reference: https://twitter.com/roasbeef/status/1389649064753471488_
+

es/16_1_Accediendo_a_Bitcoind_en_C_con_las_Bibliotecas_RPC.md

@@ -18,13 +18,13 @@ Need to get 358 kB of archives.
 After this operation, 1.696 kB of additional disk space will be used.
 Do you want to continue? [Y/n] y
 ```
-Puede descargar [libbitcoinrpc de Github](https://github.com/gitmarek/libbitcoinrpc/blob/master/README.md). Clónelo o tome un archivo zip, como prefiera.
+Puede descargar [libbitcoinrpc de Github](https://github.com/BlockchainCommons/libbitcoinrpc/blob/master/README.md). Clónelo o tome un archivo zip, como prefiera.
 ```
 $ sudo apt-get install git
-$ git clone https://github.com/gitmarek/libbitcoinrpc
+$ git clone https://github.com/BlockchainCommons/libbitcoinrpc
 ```
 
-> :warning: **ADVERTENCIA** Un cambio en el RPC de "signrawtransaction" provocó que la firma con `libbitcoinrpc` provocara un segfault para Bitcoin 0.17 o superior. [Se ha enviado un PR](https://github.com/gitmarek/libbitcoinrpc/pull/1/commits) para resolver el problema, pero si aún no se ha fusionado, puede hacer un simple cambio en el código fuente `src/bitcoinrpc_method.c` antes de compilar.
+> :warning: **ADVERTENCIA** Un cambio en el RPC de "signrawtransaction" provocó que la firma con `libbitcoinrpc` provocara un segfault para Bitcoin 0.17 o superior. [Se ha enviado un PR](https://github.com/gitmarek/libbitcoinrpc/pull/1) para resolver el problema, pero si aún no se ha fusionado, puede hacer un simple cambio en el código fuente `src/bitcoinrpc_method.c` antes de compilar.
 
 
 ### Compilar libbitcoinrpc
@@ -161,7 +161,7 @@ Successfully connected to server!
 
 ## Realizar una llamada RPC
 
-Para utilizar un método RPC con `libbitcoinrpc`, debe inicializar una variable de tipo `bitcoinrpc_method_t`. Lo hace con el valor apropiado para el método que desea utilizar, todos los cuales se enumeran en la [referencia bitcoinrpc](https://github.com/gitmarek/libbitcoinrpc/blob/master/doc/reference.md).
+Para utilizar un método RPC con `libbitcoinrpc`, debe inicializar una variable de tipo `bitcoinrpc_method_t`. Lo hace con el valor apropiado para el método que desea utilizar, todos los cuales se enumeran en la [referencia bitcoinrpc](https://github.com/BlockchainCommons/libbitcoinrpc/blob/master/doc/reference.md).
 ```
 bitcoinrpc_method_t *getmininginfo  = NULL;
 getmininginfo = bitcoinrpc_method_init(BITCOINRPC_METHOD_GETMININGINFO);

pt/16_1_Accessing_Bitcoind_with_C.md

@@ -19,14 +19,14 @@ Need to get 358 kB of archives.
 After this operation, 1.696 kB of additional disk space will be used.
 Do you want to continue? [Y/n] y
 ```
-Agora, podemos baixar o [libbitcoinrpc no github](https://github.com/gitmarek/libbitcoinrpc/blob/master/readme.md). Vamos clonar ou pegar um arquivo zip, do jeito que preferir.
+Agora, podemos baixar o [libbitcoinrpc no github](https://github.com/BlockchainCommons/libbitcoinrpc/blob/master/readme.md). Vamos clonar ou pegar um arquivo zip, do jeito que preferir.
 
 ```
 $ sudo apt-get install git
-$ git clone https://github.com/gitmarek/libbitcoinrpc
+$ git clone https://github.com/BlockchainCommons/libbitcoinrpc
 ```
 
-> :warning: **ATENÇÃO** Uma alteração no RPC "signrawtransaction" causou uma assinatura com ``libbitcoinrpc`` para o segfault no Bitcoin 0.17 ou superior. O [Pull Request foi submetido](https://github.com/gitmarek/libbitcoinrpc/pull/1/commits) para resolver o problema, mas se ainda não tiver sido feito o merge, podemos simplesmente fazer uma simples mudança no código-fonte para ``src/bitcoinrpc_method.c`` antes de compilarmos.
+> :warning: **ATENÇÃO** Uma alteração no RPC "signrawtransaction" causou uma assinatura com ``libbitcoinrpc`` para o segfault no Bitcoin 0.17 ou superior. O [Pull Request foi submetido](https://github.com/gitmarek/libbitcoinrpc/pull/1) para resolver o problema, mas se ainda não tiver sido feito o merge, podemos simplesmente fazer uma simples mudança no código-fonte para ``src/bitcoinrpc_method.c`` antes de compilarmos.
 
 ### Compilando o libbitcoinrpc
 
@@ -168,7 +168,7 @@ Successfully connected to server!
 
 ## Fazendo uma Chamada ao RPC
 
-Para usarmos um método RPC usando ``libbitcoinrpc``, devemos inicializar uma variável do tipo ``bitcoinrpc_method_t``. Podemos fazer com o valor apropriado para o método que desejamos utilizar, que estão todos listados na [Referências do BitcoinRPC](https://github.com/gitmarek/libbitcoinrpc/blob/master/doc/reference.md).
+Para usarmos um método RPC usando ``libbitcoinrpc``, devemos inicializar uma variável do tipo ``bitcoinrpc_method_t``. Podemos fazer com o valor apropriado para o método que desejamos utilizar, que estão todos listados na [Referências do BitcoinRPC](https://github.com/BlockchainCommons/libbitcoinrpc/blob/master/doc/reference.md).
 ``` c
 bitcoinrpc_method_t *getmininginfo  = NULL;
 getmininginfo = bitcoinrpc_method_init(BITCOINRPC_METHOD_GETMININGINFO);