Merge pull request #624 from victorabarros/patch-1

fix typo

01_0_Introduction.md

@@ -40,10 +40,10 @@ If you have different levels of skill or want to learn different things, you mig
 
 * If you've already got a Bitcoin environment ready to be used, jump to [Chapter Three: Understanding Your Bitcoin Setup](03_0_Understanding_Your_Bitcoin_Setup.md).
 * If you only care about Bitcoin scripting, jump to [Chapter Nine: Introducing Bitcoin Scripts](09_0_Introducing_Bitcoin_Scripts.md).
-* If you just want to read about using programming languages, jump to [Chapter Fifteen: Talking to Bitcoin](15_0_Talking_to_Bitcoind.md).
+* If you just want to read about using programming languages, jump to [Chapter Sixteen: Talking to Bitcoin](16_0_Talking_to_Bitcoind.md).
 * If you conversely don't want to do any programming, definitely skip chapters 15-17 while you're reading, and perhaps skip chapters 9-13. The rest of the course should still make sense without them.
-* If you are only interested in Lightning, zap over to [Chapter Eighteen: Understanding Your Lightning Setup](18_0_Understanding_Your_Lightning_Setup.md).
-* If you want to read the major new content added for v2 of the course (2020), following on v1 (2017), read [§3.5: Understanding the Descriptor](03_5_Understanding_the_Descriptor.md), [§4.6: Creating a SegWit Transaction](04_6_Creating_a_Segwit_Transaction.md), [Chapter 7: Expanding Bitcoin with PSBTs](07_0_Expanding_Bitcoin_Transactions_PSBTs.md), [§9.5: Scripting a P2WPKH](09_5_Scripting_a_P2WPKH.md), [§10.5: Scripting a SegWit Script](10_5_Scripting_a_Segwit_Script.md), [Chapter 14: Using Tor](14_0_Using_Tor.md), [Chapter 15: Talking to Bitcoind with C](15_0_Talking_to_Bitcoind.md), [Chapter 16: Programming with Libwally](16_0_Programming_with_Libwally.md), [Chapter Seventeen: Talking to Bitcoind with Other Languages](17_0_Talking_to_Bitcoind_Other.md), [Chapter Eighteen: Understanding ](18_0_Understanding_Your_Lightning_Setup.md), and [Chapter Nineteen: Using Lightning](19_0_Using_Lightning.md).
+* If you are only interested in Lightning, zap over to [Chapter Nineteen: Understanding Your Lightning Setup](19_0_Understanding_Your_Lightning_Setup.md).
+* If you want to read the major new content added for v2 of the course (2020), following on v1 (2017), read [§3.5: Understanding the Descriptor](03_5_Understanding_the_Descriptor.md), [§4.6: Creating a SegWit Transaction](04_6_Creating_a_Segwit_Transaction.md), [Chapter 7: Expanding Bitcoin with PSBTs](07_0_Expanding_Bitcoin_Transactions_PSBTs.md), [§9.5: Scripting a P2WPKH](09_5_Scripting_a_P2WPKH.md), [§10.5: Scripting a SegWit Script](10_5_Scripting_a_Segwit_Script.md), [Chapter 14: Using Tor](14_0_Using_Tor.md), [Chapter 15: Using i2p](15_0_Using_i2p.md), [Chapter 16: Talking to Bitcoind with C](16_0_Talking_to_Bitcoind.md), [Chapter 17: Programming with Libwally](17_0_Programming_with_Libwally.md), [Chapter 18: Talking to Bitcoind with Other Languages](18_0_Talking_to_Bitcoind_Other.md), [Chapter 19: Understanding Your Lighting Setup](19_0_Understanding_Your_Lightning_Setup.md), and [Chapter 20: Using Lightning](20_0_Using_Lightning.md).
 
 ## Why to Use this Course
 

02_1_Setting_Up_a_Bitcoin-Core_VPS_with_StackScript.md

@@ -20,11 +20,9 @@ You can create a Linode account by going here:
 https://www.linode.com
 ```
 
-If you prefer, the following referral code will give you about a months worth of free usage, great for learning Bitcoin:
+If you prefer, the following referral code will give you two months worth of free usage (up to $100), great for learning Bitcoin:
 
-```
-https://www.linode.com/?r=23211828bc517e2cb36e0ca81b91cc8c0e1b2d96
-```
+[https://www.linode.com/?r=3c7fa15a78407c9a3d4aefb027539db2557b3765](https://www.linode.com/?r=3c7fa15a78407c9a3d4aefb027539db2557b3765)
 
 You'll need to provide an email address and later preload money from a credit card or PayPal for future costs.
 
@@ -38,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 10 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
 
@@ -49,19 +47,16 @@ You're now ready to create a node based on the Stackscript.
    * **Short Hostname.** Pick a name for your VPS. For example, "mybtctest".
    * **Fully Qualified Hostname.** If you're going to include this VPS as part of a network with full DNS records, type in the hostname with its domain. For example, "mybtctest.mydomain.com". Otherwise, just repeat the short hostname and add ".local", for example "mybtctest.local".
 3. Enter the password for the "standup" user.
-4. Choose an Installation Type in the advanced options. 
-   * **Installation Type.** This is likely "Mainnet" or "Pruned Mainnet" if you are setting up a node for usage and "Testnet" or "Pruned Testnet" if you're just playing around. The bulk of this tutorial will assume you chose "Pruned Testnet", but you should still be able to follow along with other types. See the [Synopsis](#synopsis-bitcoin-installation-types) for more information on these options. (Note that if you plan to try out the Lightning chapters, you'll probably want to use an Unpruned node, as working with Pruned nodes on Lightning is iffy. See [§18.1](18_1_Verifying_Your_Lightning_Setup.md#compiling-the-source-code) for the specifics.)
-5. Fill in any other appropriate advanced options.
+4. Fill in the appropriate advanced options. 
    * **X25519 Public Key.** This is a public key to add to Tor's list of authorized clients. If you don't use it, anyone who gets the QR code for your node can access it. You'll get this public key from whichever client you're using to connect to your node. For example, if you use [FullyNoded 2](https://github.com/BlockchainCommons/FullyNoded-2), you can go to its settings and "Export Tor V3 Authentication Public Key" for use here.
-  * **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.
-4. Select an Image
-   * **Target Image.** If you followed the instructions, this will only allow you to select "Debian 10" (though "Debian 9" did also work with previous versions of this Stackscript and might still).
-5. Choose a region for where the Linode will be located.
+   * **Installation Type.** This is likely "Mainnet" or "Pruned Mainnet" if you are setting up a node for usage and "Testnet" or "Pruned Testnet" if you're just playing around. The bulk of this tutorial will assume you chose "Pruned Testnet", but you should still be able to follow along with other types. See the [Synopsis](#synopsis-bitcoin-installation-types) for more information on these options. (Note that if you plan to try out the Lightning chapters, you'll probably want to use an Unpruned node, as working with Pruned nodes on Lightning is iffy. See [§18.1](18_1_Verifying_Your_Lightning_Setup.md#compiling-the-source-code) for the specifics.)
+   * **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 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._
-
-Finally, you'll need to fill in a root password, which will be the password used for the root account.
+*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.*
 
 ### Choose Other Standup Options
 
@@ -71,13 +66,13 @@ Blockchain Commons is currently in the process of expanding its Bitcoin Standup
 
 You'll next to choose a Linode plan.
 
-A Linode 4GB will suffice for most setups, including: Pruned Mainnet, Pruned Testnet, and even non-Pruned Testnet. They all use less than 50G of storage and 4GB is a comfortable amount of memory. This is the setup we suggest. It runs $20 per month.
+Linode will default to Dedicated-CPU plans, but you can select the more cost-efficient Shared-CPU instead. A Shared-CPU Linode 4GB will suffice for most setups, including: Pruned Mainnet, Pruned Testnet, and even non-Pruned Testnet. They all use less than 50G of storage and 4GB is a comfortable amount of memory. This is the setup we suggest. It runs $20 per month.
 
 If you want to instead have a non-Pruned Mainnet in a VPS, you'll need to install a Linode with a disk in excess of 280G(!), which is currently the Linode 16GB, which has 320G of storage and 16G of memory and costs approximately $80 per month. We do _not_ suggest this.
 
 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 |
@@ -90,6 +85,8 @@ Note, there may be ways to reduce both costs.
 * For the machines we suggest as **Linode 4GB**, you may be able to reduce that to a Linode 2GB. Some versions of Bitcoin Core have worked well at that size, some have occasionally run out of memory and then recovered, and some have continuously run out of memory. Remember to up that swap space to maximize the odds of this working. Use at your own risk.
 * For the Unpruned Mainnet, which we suggest as a **Linode 16GB**, you can probably get by with a Linode 4GB, but add [Block Storage](https://cloud.linode.com/volumes) sufficient to store the blockchain. This is certainly a better long-term solution since the Bitcoin blockchain's storage requirements continuously increase if you don't prune, while the CPU requirements don't (or don't to the same degree). A 320 GibiByte storage would be $32 a month, which combined with a Linode 4GB is $52 a month, instead of $80, and more importantly you can keep growing it. We don't fully document this setup for two reasons (1) we don't suggest the unpruned mainnet setup, and so we suspect it's a much less common setup; and (2) we haven't tested how Linodes volumes compare to their intrinic SSDs for performance and usage. But there's full documentation on the Block Storage page. You'd need to set up the Linode, run its stackscript, but then interrupt it to move the blockchain storage overly to a newly commissioned volume before continuing.
 
+If you are running a deployment that will be transacting real Bitcoins, you may want to alternatively consider a Dedicated-CPU Linode, which tends to run 50% more expensive than the Shared-CPU Linode. We've generally found the Shared CPUs to be entirely sufficient, but for a wide deployment, you may wish to consider higher levels of reliability.
+
 ### Do the Final Setup
 
 The last thing you need to do is enter a root password. (If you missed anything, you'll be told so now!)
@@ -124,7 +121,7 @@ Here's a little catch: _your StackScript is running right now_. The BASH script
 
 The total run time is about 10 minutes. So, go take a break, get an espresso, or otherwise relax for a few minutes. There are two parts of the script that take a while: the updating of all the Debian packages; and the downloading of the Bitcoin code. They shouldn't take more than 5 minutes each, which means if you come back in 10 minutes, you'll probably be ready to go.
 
-If you're impatient you can jump ahead and `sudo tail -f ~root/standup.log` which will display the current progress of installation, as described in the next section.
+If you're impatient you can jump ahead and `sudo tail -f /standup.log` which will display the current progress of installation, as described in the next section.
 
 ## Verify Your Installation
 
@@ -138,7 +135,7 @@ At that point, your home directory should look like this:
 
 ```
 $ ls
-bitcoin-0.20.0-x86_64-linux-gnu.tar.gz  laanwj-releases.asc  SHA256SUMS.asc
+bitcoin-22.0-x86_64-linux-gnu.tar.gz  keys.txt  SHA256SUMS  SHA256SUMS.asc
 ```
 
 These are the various files that were used to install Bitcoin on your VPS. _None_ of them are necessary. We've just left them in case you want to do any additional verification. Otherwise, you can delete them:
@@ -152,16 +149,32 @@ $ rm *
 In order to ensure that the downloaded Bitcoin release is valid, the StackScript checks both the signature and the SHA checksum. You should verify that both of those tests came back right:
 
 ```
-$ sudo grep VERIFICATION ~root/standup.log
+$ sudo grep VERIFICATION /standup.log
 ```
 
 If you see something like the following, all should be well:
 
 ```
-/root/StackScript - VERIFICATION SUCCESS / SIG: gpg: Good signature from "Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>" [unknown]
-/root/StackScript - VERIFICATION SUCCESS / SHA: 35ec10f87b6bc1e44fd9cd1157e5dfa4```
+./standup.sh - SIG VERIFICATION SUCCESS: 9 GOOD SIGNATURES FOUND.
+./standup.sh - SHA VERIFICATION SUCCESS / SHA: bitcoin-22.0-x86_64-linux-gnu.tar.gz: OK
 ```
-However, if either of those two checks instead reads "VERIFICATION ERROR", then there's a problem. Since this is all scripted, it's possible that there's just been a minor change that has caused the script's checks not to work right. (This has happened a few times over the existence of the script that became Standup.) But, it's also possible that someone is trying to encourage you to run a fake copy of the Bitcoin daemon. So, _be very sure you know what happened before you make use of Bitcoin!_
+If either of those two checks instead reads "VERIFICATION ERROR", then there's a problem.
+
+The log also contains more information on the Signatures, if you want to make sure you know _who_ signed the Bitcoin release:
+```
+$ sudo grep -i good /standup.log
+./standup.sh - SIG VERIFICATION SUCCESS: 9 GOOD SIGNATURES FOUND.
+gpg: Good signature from "Andrew Chow (Official New Key) <achow101@gmail.com>" [unknown]
+gpg: Good signature from "Ben Carman <benthecarman@live.com>" [unknown]
+gpg: Good signature from "Antoine Poinsot <darosior@protonmail.com>" [unknown]
+gpg: Good signature from "Stephan Oeste (it) <it@oeste.de>" [unknown]
+gpg: Good signature from "Michael Ford (bitcoin-otc) <fanquake@gmail.com>" [unknown]
+gpg: Good signature from "Oliver Gugger <gugger@gmail.com>" [unknown]
+gpg: Good signature from "Hennadii Stepanov (hebasto) <hebasto@gmail.com>" [unknown]
+gpg: Good signature from "Jon Atack <jon@atack.com>" [unknown]
+gpg: Good signature from "Wladimir J. van der Laan <laanwj@visucore.com>" [unknown]
+```
+Since this is all scripted, it's possible that there's just been a minor change that has caused the script's checks not to work right. (This has happened a few times over the existence of the script that became Standup.) But, it's also possible that someone is trying to encourage you to run a fake copy of the Bitcoin daemon. So, _be very sure you know what happened before you make use of Bitcoin!_
 
 ### Read the Logs
 
@@ -169,13 +182,13 @@ You may also want to read through all of the setup log files, to make sure that
 
 It's best to look through the standard StackScript log file, which has all of the output, including errors:
 
-`$ sudo more ~root/standup.log`
+`$ sudo more /standup.log`
 
 Note that it is totally normal to see _some_ errors, particularly when running the very noisy gpg software and when various things try to access the non-existant `/dev/tty` device.
 
 If you want instead to look at a smaller set of info, all of the errors should be in:
 
-`$ sudo more ~root/standup.err`
+`$ sudo more /standup.err`
 
 It still has a fair amount of information that isn't errors, but it's a quicker read.
 
@@ -183,15 +196,15 @@ If all look good, congratulations, you have a functioning Bitcoin node using Lin
 
 ## What We Have Wrought
 
-Although the default Debian 10 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
 
 Your Bitcoin VPS installation is minimal and allows almost no communication. This is done through the uncomplicated firewall (`ufw`), which blocks everything except SSH connections. There's also some additional security possible for your RFC ports, thanks to the hidden services installed by Tor.
 
-**Adjusting UFW.** You should probably leave UFW in its super-protected stage! You don't want to use a Bitcoin machine for other services, because everyone increases your vulnerability! If you decide otherwise, there are several [guides to UFW](https://www.digitalocean.com/community/tutorials/ufw-essentials-common-firewall-rules-and-commands) that will allow you to add services. As advertised, it's ncomplicated. For example adding mail services would just require opening the mail port: `sudo ufw allow 25`. But don't do that.
+**Adjusting UFW.** You should probably leave UFW in its super-protected stage! You don't want to use a Bitcoin machine for other services, because everyone increases your vulnerability! If you decide otherwise, there are several [guides to UFW](https://www.digitalocean.com/community/tutorials/ufw-essentials-common-firewall-rules-and-commands) that will allow you to add services. As advertised, it's uncomplicated. For example adding mail services would just require opening the mail port: `sudo ufw allow 25`. But don't do that.
 
-**Adjusting Tor.** You might want to better protect services like SSH. See [Chapter 12: Using Tor](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/12_0_Using_Tor.md) for more on Tor.
+**Adjusting Tor.** You might want to better protect services like SSH. See [Chapter 14: Using Tor](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/14_0_Using_Tor.md) for more on Tor.
 
 ### Protected Shells
 
@@ -245,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 *BitocinStandup*, 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

@@ -19,7 +19,7 @@ After you enter these aliases you can either `source .bash_profile` to input the
 
 Note that these aliases includes shortcuts for running `bitcoin-cli`, for running `bitcoind`, and for going to the Bitcoin directory. These aliases are mainly meant to make your life easier. We suggest you create other aliases to ease your use of frequent commands (and arguments) and to minimize errors. Aliases of this sort can be even more useful if you have a complex setup where you regularly run commands associated with Mainnet, with Testnet, _and_ with Regtest, as explained further below.
 
-With that said, use of these aliases in _this_ document might accidentally obscure the core lessons being taught about Bitcoin, so the only alias directly used here is `btcinfo` because it encapsulatea  much longer and more complex command. Otherwise, we show the full commands; adjust for your own use as appropriate.
+With that said, use of these aliases in _this_ document might accidentally obscure the core lessons being taught about Bitcoin, so the only alias directly used here is `btcinfo` because it encapsulates  much longer and more complex command. Otherwise, we show the full commands; adjust for your own use as appropriate.
 
 ## Run Bitcoind
 
@@ -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

@@ -1,28 +1,67 @@
 # 3.3: Setting Up Your Wallet
 
-You're now ready to start working with Bitcoin. To begin with, you'll need to create an address for receiving funds.
+You're now ready to start working with Bitcoin. To begin with, you'll need to create a wallet for sending and receiving funds.
+
+## Create a Wallet
+
+> :warning: **VERSION WARNING:** Newer versions of Bitcoin Core, starting with v0.21.0, will no longer automatically create a default wallet on startup. So, you will need to manually create one. But if you're running an older version of Bitcoin Core, a new wallet has already been created for you, in which case you can skip ahead to [Create an Address](#create-an-address).
+
+The first thing you need to do is create a new wallet, which can be done with the `bitcoin-cli createwallet` command. By creating a new wallet, you'll be creating your public-private key pair. Your public key is the source from which your addresses will be created, and your private key is what will allow you to spend any funds you receive into your addresses. Bitcoin Core will automatically save that information into a `wallet.dat` file in your `~/.bitcoin/testnet3/wallets` directory.
+
+If you check your `wallets` directory, you'll see that it's currently empty.
+```
+$ ls ~/.bitcoin/testnet3/wallets
+$
+```
+
+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 -named createwallet wallet_name="" descriptors=false
+
+{
+  "name": "",
+  "warning": ""
+}
+```
+
+Now, your `wallets` directory should be populated.
+```
+$ ls ~/.bitcoin/testnet3/wallets
+database  db.log  wallet.dat
+```
+
+> :book: ***What is a Bitcoin wallet?*** A Bitcoin wallet is the digital equivalent of a physical wallet on the Bitcoin network. It stores information on the amount of bitcoins you have and where it's located (addresses), as well as the ways you can use to spend it. Spending physical money is intuitive, but to spend bitcoins users need to provide the correct _private key_. We will explain this in more detail throughout the course, but what you should know for now is that this public-private key dynamic is part of what makes Bitcoin secure and trustless. Your key pair information is saved in the `wallet.dat` file, in addition to data about preferences and transactions. For the most part, you won't have to worry about that private key: `bitcoind` will use it when it's needed. However, this makes the `wallet.dat` file extremely important: if you lose it, you lose your private keys, and if you lose your private keys, you lose your funds!
+
+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 first 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`.
+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`.
 
 However, for the next few sections we're instead going to be using `legacy` addresses, both because `bitcoin-cli` had some teething problems with its early versions of SegWit addresses, and because other people might not be able to send to `bech32` addresses. This is all unlikely to be a problem for you now, but for the moment we want to get your started with transaction examples that are (mostly) guaranteed to work.
 
-You can require `legacy` address either with the second argument to `getnewaddress` or with the named `addresstype` argument.
+First, restart `bitcoind` so your new unnamed wallet is set as default and automatically loaded.
+```
+$ bitcoin-cli stop
+Bitcoin Core stopping # wait a minute so it stops completely
+$ bitcoind -daemon
+Bitcoin Core starting # wait a minute so it starts completely
+```
+
+You can now create an address. You can require `legacy` address either with the second argument to `getnewaddress` or with the named `addresstype` argument.
 ```
 $ bitcoin-cli getnewaddress -addresstype legacy
 moKVV6XEhfrBCE3QCYq6ppT7AaMF8KsZ1B
 ```
 Note that this address begins with an "m" (or sometimes an "n") to signify a testnet Legacy address. It would be a "2" for a P2SH address or a "tb1" for a Bech32 address.
 
-> :link: **TESTNET vs MAINNET:** The equivalent mainnet address would start with a "1" (for Legacy), "3" (for P2SH), or "bc1" (for Bech320.
-
+> :link: **TESTNET vs MAINNET:** The equivalent mainnet address would start with a "1" (for Legacy), "3" (for P2SH), or "bc1" (for Bech32).
 
 Take careful note of the address. You'll need to give it to whomever will be sending you funds.
 
-> :book: ***What is a Bitcoin address?*** A Bitcoin address is literally where you receive money. It's like an email address, but for funds. Technically, it's a public key, though different address schemes adjust that in different ways. However unlike an email address, a Bitcoin address should be considered single use: use it to receive funds just _once_. When you want to receive funds from someone else or at some other time, generate a new address. This is suggested in large part to improve your privacy. The whole blockchain is immutable, which means that explorers can look at long chains of transactions over time, making it possible to statistically determine who you and your contacts are, no matter how careful you are. However, if you keep reusing the same address, then this becomes even easier.
-
-> :book: ***What is a Bitcoin wallet?*** By creating your first Bitcoin address, you've also begun to fill in your Bitcoin wallet. More precisely, you've begun to fill the `wallet.dat` file in your `~/.bitcoin/testnet3 /wallets` directory. The `wallet.dat` file contains data about preferences and transactions, but more importantly it contains all of the key pairs that you create: both the public key (which is the source of the address where you receive funds) and the private key (which is how you spend those funds). For the most part, you won't have to worry about that private key: `bitcoind` will use it when it's needed. However, this makes the `wallet.dat` file extremely important: if you lose it, you lose your private keys, and if you lose your private keys, you lose your funds!
+> :book: ***What is a Bitcoin address?*** A Bitcoin address is literally where you receive money. It's like an email address, but for funds. Technically, it's a public key, though different address schemes adjust that in different ways. However unlike an email address, a Bitcoin address should be considered single use: use it to receive funds just _once_. When you want to receive funds from someone else or at some other time, generate a new address. This is suggested in large part to improve your privacy. The whole blockchain is immutable, which means that explorers can look at long chains of transactions over time, making it possible to statistically determine who you and your contacts are, no matter how careful you are. However, if you keep reusing the same address, then this becomes even easier. By creating your first Bitcoin address, you've also begun to fill in your Bitcoin wallet. More precisely, you've begun to fill the `wallet.dat` file in your `~/.bitcoin/testnet3 /wallets` directory.
 
 With a single address in hand, you could jump straight to the next section and begin receiving funds. However, before we get there, we're going to briefly discuss the other sorts of addresses that you'll meet in the future and talk about a few other wallet commands that you might want to use in the future.
 

03_4_Receiving_a_Transaction.md

@@ -14,7 +14,7 @@ To use a faucet, you'll usually need to go to a URL and copy and paste in your a
 
 ## Verify Your Money
 
-After you've requested your money, you should be able to verify it with the 'bitcoin-cli getbalance' command:
+After you've requested your money, you should be able to verify it with the `bitcoin-cli getbalance` command:
 ```
 $ bitcoin-cli getbalance
 0.00000000
@@ -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_0_Sending_Bitcoin_Transactions.md

@@ -25,5 +25,6 @@ Supporting objectives include the ability to:
      * [Interlude: Using JQ](04_2__Interlude_Using_JQ.md)
   * [Section Three: Creating a Raw Transaction with Named Arguments](04_3_Creating_a_Raw_Transaction_with_Named_Arguments.md)
   * [Section Four: Sending Coins with Raw Transactions](04_4_Sending_Coins_with_a_Raw_Transaction.md)
+     * [Interlude: Using Curl](04_4__Interlude_Using_Curl.md)
   * [Section Five: Sending Coins with Automated Raw Transactions](04_5_Sending_Coins_with_Automated_Raw_Transactions.md)
   * [Section Six: Creating a SegWit Transaction](04_6_Creating_a_Segwit_Transaction.md)

04_1_Sending_Coins_The_Easy_Way.md

@@ -22,7 +22,7 @@ txconfirmtarget=1
 ```
 You should enter these into `~/.bitcoin/bitcoin.conf`, in the main section, toward the top of the file or if you want to be sure you never use it elsewhere, under the `[test]` section.
 
-In order to get through this tutorial, we're willing to spend 100,00 satoshis per kB on every transaction (about $10!), and we want to get each transaction into the next block! (To put that in perspective, a typical transaction runs between .25 kB and 1 kB, so you'll actually be paying more like $2.50 than $10 ... if this were real money.)
+In order to get through this tutorial, we're willing to spend 100,000 satoshis per kB on every transaction (about $10!), and we want to get each transaction into the next block! (To put that in perspective, a typical transaction runs between .25 kB and 1 kB, so you'll actually be paying more like $2.50 than $10 ... if this were real money.)
 
 After you've edited your bitcoin.conf file, you'll want to kill and restart bitcoind.
 ```

04_2_Creating_a_Raw_Transaction.md

@@ -105,7 +105,7 @@ Each transaction has a fee associated with. It's _implicit_ when you send a raw
 
 > :book: ***How much should you spend on transaction fees?*** [Bitcoin Fees](https://bitcoinfees.21.co/) has a nice live assessment. It says that the "fastest and cheapest transaction fee is currently 42 satoshis/byte" and that "For the median transaction size of 224 bytes, this results in a fee of 9,408 satoshis".
 
-Currently Bitcoin Fees suggests a transaction fee of about 10,000 satoshis, which is the same as .0001 BC. Yes, that's for the mainnet, not the testnet, but we want to test out things realistically, so that's what we're going to use.
+Currently Bitcoin Fees suggests a transaction fee of about 10,000 satoshis, which is the same as .0001 BTC. Yes, that's for the mainnet, not the testnet, but we want to test out things realistically, so that's what we're going to use.
 
 In this case, that means taking the .0005 BTC in the UTXO we're selected, reducing it by .0001 BTC for the transaction fee, and sending the remaining .0004 BTC. (And this is an example of why micropayments don't work on the Bitcoin network, because a $1 or so transaction fee is pretty expensive when you're sending $4, let alone if you were trying to make a micropayment of $0.50. But that's always why we have Lightning.)
 

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._
@@ -51,7 +57,7 @@ $ bitcoin-cli sendrawtransaction $signedtx
 
 Grabbing data out of a JSON object is easy, but what if that JSON object is in a JSON array? The `listunspent` command offers a great example, because it'll usually contain a number of different transactions. What if you want to capture specific information from _one_ of them?
 
-When working with a JSON array, the first thing you need to do is tell JQ which index to access. For example, you might have looked through your transactions in `listunspent` and decided that you wanted to work with the second of them. You use `'.[1]'` to access that first element. The `[]` says that we're referencing a JSON array and the `0` says we want the 0th index.
+When working with a JSON array, the first thing you need to do is tell JQ which index to access. For example, you might have looked through your transactions in `listunspent` and decided that you wanted to work with the second of them. You use `'.[1]'` to access that second element. The `[]` says that we're referencing a JSON array and the `1` says we want the 1st index.
 ```
 $ bitcoin-cli listunspent | jq -r '.[1]'
 {
@@ -68,7 +74,7 @@ $ bitcoin-cli listunspent | jq -r '.[1]'
   "safe": true
 }
 ```
-You can then capture an individual value from that selected array by (1) using a pipe _within_ the JQ arguments; and then (2) requesting the specific value afterward, as in the previous example. The following would capture the `txid` from the 0th JSON object in the JSON array produced by `listunspent`:
+You can then capture an individual value from that selected array by (1) using a pipe _within_ the JQ arguments; and then (2) requesting the specific value afterward, as in the previous example. The following would capture the `txid` from the 1st JSON object in the JSON array produced by `listunspent`:
 ```
 $ bitcoin-cli listunspent | jq -r '.[1] | .txid'
 91261eafae15ea53dedbea7c1db748c52bbc04a85859ffd0d839bda1421fda4c
@@ -357,7 +363,7 @@ To complete the transaction fee calculation, you subtract the .vout .amount (1.0
 
 To do this, you'll need to install `bc`:
 ```
-$ sudo apt-get intall bc
+$ sudo apt-get install bc
 ```
 
 Putting it all together creates a complete calculator in just five lines of script:

04_4__Interlude_Using_Curl.md

@@ -111,9 +111,11 @@ Here's what some parameter arrays will look like:
 You can now send your first `curl` command by accessing the `getmininginfo` RPC:
 ```
 $ curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getmininginfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/
-{"result":{"blocks":1772428,"difficulty":10178811.40698772,"networkhashps":91963587385939.06,"pooledtx":61,"chain":"test","warnings":"Warning: unknown new rules activated (versionbit 28)"},"error":null,"id":"curltest"}```
-Note that we provided the method, `getmininginfo`, and the parameter, `[]`, but that everything else was the standard `curl` command line.
+{"result":{"blocks":1772428,"difficulty":10178811.40698772,"networkhashps":91963587385939.06,"pooledtx":61,"chain":"test","warnings":"Warning: unknown new rules activated (versionbit 28)"},"error":null,"id":"curltest"}
 ```
+
+Note that we provided the method, `getmininginfo`, and the parameter, `[]`, but that everything else was the standard `curl` command line.
+
 > **WARNING:** If you get a result like "Failed to connect to 127.0.0.1 port 8332: Connection refused", be sure that a line like `rpcallowip=127.0.0.1` is in your ~/.bitcoin/bitcoin.conf. If things still don't work, be sure that you're allowing access to port 18332 (or 8332) from localhost. Our standard setup from [Chapter Two: Creating a Bitcoin-Core VPS](02_0_Setting_Up_a_Bitcoin-Core_VPS.md) should do all of this.
 
 The result is another JSON array, which is unfortunately ugly to read if you're using `curl` by hand. Fortunately, you can clean it up  simply by piping it through `jq`:
@@ -224,12 +226,14 @@ $ curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc"
   "error": null,
   "id": "curltest"
 }
-
 ```
+
+> **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

@@ -12,7 +12,7 @@ The catch? SegWit uses different addresses, some of which are compatible with ol
 
 ## Understand a SegWit Transaction
 
-In classic transactions, signature (witness) information was stored toward the middle of the transaction, while in SegWit transactions, it's at the bottom. This goes hand-in-hand with the blocksize increases that were introduced in the SegWit upgrade. The blocksize was increased from 1M to a variable amount based on how many SegWit transactions are in a block, starting as low as 1M (no SegWit transactions) and going as high as 4M (all SegWit transactions). This variable sized was created to accomodate classic nodes, so that everything remains backward compatible. If a classic node sees a SegWit transaction, it throws out the witness information (resulting in a smaller sized block, under the old 1M limit), while if a new node sees a SegWit transaction, it keeps the witness information (resulting in a larger sized block, up to the new 4M limit).
+In classic transactions, signature (witness) information was stored toward the middle of the transaction, while in SegWit transactions, it's at the bottom. This goes hand-in-hand with the blocksize increases that were introduced in the SegWit upgrade. The blocksize was increased from 1M to a variable amount based on how many SegWit transactions are in a block, starting as low as 1M (no SegWit transactions) and going as high as 4M (all SegWit transactions). This variable size was created to accomodate classic nodes, so that everything remains backward compatible. If a classic node sees a SegWit transaction, it throws out the witness information (resulting in a smaller sized block, under the old 1M limit), while if a new node sees a SegWit transaction, it keeps the witness information (resulting in a larger sized block, up to the new 4M limit).
 
 So that's the what and how of SegWit transactions. Not that you need to know any of it to use them. Most transactions on the Bitcoin network are now SegWit. They're what you're going to natively use for more transactions and receipts of money. The details are no more relevant at this point than the details of how most of Bitcoin works.
 
@@ -120,7 +120,7 @@ $ bitcoin-cli sendtoaddress tb1qw508d6qejxtdg4y5r3zarvary0c5xw7kxpjzsx 0.005
 ```
 If you look at your transaction, you can see the use of the Bech32 address:
 ```
-$ bitcoin-cli gettransaction txid="854a833b667049ac811b4cf1cad40fa7f8dce8b0f4c1018a58b84559b6e05f42" verbose=true
+$ bitcoin-cli -named gettransaction txid="854a833b667049ac811b4cf1cad40fa7f8dce8b0f4c1018a58b84559b6e05f42" verbose=true
 {
   "amount": -0.00500000,
   "fee": -0.00036600,
@@ -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.
 

05_2_Resending_a_Transaction_with_RBF.md

@@ -2,7 +2,7 @@
 
 If your Bitcoin transaction is stuck, and you're the sender, you can resend it using RBF (replace-by-fee). However, that's not all that RBF can do: it's generally a powerful and multipurpose feature that allows Bitcoin senders to recreate transactions for a variety of reasons.
 
-> :warning: **VERSION WARNING:** This is an innovation from Bitcoin Core v 0.12.0,that reached full maturity in the Bitcoin Core wallet with Bitcoin Core v 0.14.0. Obviously, most people should be using it by now.
+> :warning: **VERSION WARNING:** This is an innovation from Bitcoin Core v 0.12.0, that reached full maturity in the Bitcoin Core wallet with Bitcoin Core v 0.14.0. Obviously, most people should be using it by now.
 
 ## Opt-In for RBF
 

06_1_Sending_a_Transaction_to_a_Multisig.md

@@ -97,7 +97,7 @@ The _address_ is what you'll give out to people who want to send funds. You'll n
 
 > :link: **TESTNET vs MAINNET:** On testnet, the prefix for P2SH addresses is `2`, while on mainnet, it's `3`.
 
-The _redeemScript_ is what you need to redeem the funds (along with the private keys for "m" of the "n" addresses). This script is another special feature of P2SH addresses and will be fully explained in [§8.1: Building a Bitcoin Script with P2SH](08_1_Building_a_Bitcoin_Script_with_P2SH.md). For now, just be aware that it's a bit of data that's required to get your money.
+The _redeemScript_ is what you need to redeem the funds (along with the private keys for "m" of the "n" addresses). This script is another special feature of P2SH addresses and will be fully explained in [§10.3: Running a Bitcoin Script with P2SH](10_3_Running_a_Bitcoin_Script_with_P2SH.md). For now, just be aware that it's a bit of data that's required to get your money.
 
 The _descriptor_ is the standardized description for an address that we met in [§3.5: Understanding the Descriptor](03_5_Understanding_the_Descriptor.md). It provides one way that you could import this address back to the other machine, using the `importmulti` RPC.
 
@@ -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"
 ```
@@ -177,7 +177,7 @@ That produces scary errors and says that it's `failing`. This is all fine. You c
 
 ### Repeat for Other Signers
 
-You can now pass the transaction on, to be signed again by anyone else required for the multisig. They do this by running the same signing command that you did but: (1) with the longer `hex` that you output from (`bitcoin-cli -named signrawtransactionwithkey hexstring=$rawtxhex prevtxs='''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout', "scriptPubKey": "'$utxo_spk'", "redeemScript": "'$redeem_script'" } ]''' privkeys='["cMgb3KM8hPATCtgMKarKMiFesLft6eEw3DY6BB8d97fkeXeqQagw"]' | jq -r '. | .hex'`); and (2) with their own private key.
+You can now pass the transaction on, to be signed again by anyone else required for the multisig. They do this by running the same signing command that you did but: (1) with the longer `hex` that you output from (`bitcoin-cli -named signrawtransactionwithkey hexstring=$rawtxhex prevtxs='''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout', "scriptPubKey": "'$utxo_spk'", "redeemScript": "'$redeem_script'" } ]''' privkeys='["cMgb3KM8hPATCtgMKarKMiFesLft6eEw3DY6BB8d97fkeXeqQagw"]' | jq -r '.hex'`); and (2) with their own private key.
 
 > :information_source: **NOTE — M-OF-N VS N-OF-N:** Obviously, if you have an n-of-n signature (like the 2-of-2 multisignature in this example), then everyone has to sign, but if you hae a m-of-n multisignature where "m < n", then the signature will be complete when only some ("m") of the signers have signed.
 

06_3_Sending_an_Automated_Multisig.md

@@ -15,13 +15,13 @@ You start off creating P2PKH addresses and retrieving public keys, as usual, for
 machine1$ address3=$(bitcoin-cli getnewaddress)
 machine1$ echo $address3
 tb1q4ep2vmakpkkj6mflu94x5f94q662m0u5ad0t4w
-machine1$ bitcoin-cli -named getaddressinfo address=$address3 | jq -r '. | .pubkey'
+machine1$ bitcoin-cli -named getaddressinfo address=$address3 | jq -r '.pubkey'
 0297e681bff16cd4600138449e2527db4b2f83955c691a1b84254ecffddb9bfbfc
 
 machine2$ address4=$(bitcoin-cli getnewaddress)
 machine2$ echo $address4
 tb1qa9v5h6zkhq8wh0etnv3ae9cdurkh085xufl3de
-machine2$ bitcoin-cli -named getaddressinfo address=$address4 | jq -r '. | .pubkey'
+machine2$ bitcoin-cli -named getaddressinfo address=$address4 | jq -r '.pubkey'
 02a0d96e16458ff0c90db4826f86408f2cfa0e960514c0db547ff152d3e567738f
 ```
 
@@ -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_1_Creating_a_Partially_Signed_Bitcoin_Transaction.md

@@ -467,7 +467,7 @@ $ bitcoin-cli analyzepsbt $psbt_new_f
   "next": "extractor"
 }
 ```
-Now would you realy want to use `walletcreatefundedpsbt` if you were creating a `bitcoin-cli` program? Probably not. But it's the same analysis as whether to use `fundrawtransaction`. Do you let Bitcoin Core do the analysis and calculation and decisions, or do you take that on yourself?
+Now would you really want to use `walletcreatefundedpsbt` if you were creating a `bitcoin-cli` program? Probably not. But it's the same analysis as whether to use `fundrawtransaction`. Do you let Bitcoin Core do the analysis and calculation and decisions, or do you take that on yourself?
 
 ## Send a PSBT
 #### PSBT Role: Extractor

07_2_Using_a_Partially_Signed_Bitcoin_Transaction.md

@@ -584,10 +584,12 @@ The methodology for managing it with PSBTs is exactly the same as you've seen in
 ```
 $ psbt=$(bitcoin-cli -named createpsbt inputs='''[ { "txid": "'$utxo_txid_1'", "vout": '$utxo_vout_1' }, { "txid": "'$utxo_txid_2'", "vout": '$utxo_vout_2' }, { "txid": "'$utxo_txid_3'", "vout": '$utxo_vout_3' } ]''' outputs='''{ "'$split1'": 1.7,"'$split2'": 0.93,"'$split3'": 1.4 }''')
 ```
-Each user puts in their own UTXO, and each one receives a corresponding output.
+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

@@ -2,7 +2,7 @@
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
-One of the greatest powers of PSBTs is the ability to hand transactions off to hardware wallets. This will be a great development tool for you if you continue to program with Bitcoin. However, you can't test it out now if you're using one of the configurations we suggest for this course — a VM on Linode per [§2.1](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/02_1_Setting_Up_a_Bitcoin-Core_VPS_with_StackScript.md) or an even more farflung option such an AWS per [§2.2](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/02_2_Setting_Up_Bitcoin_Core_Other.md) — because obviously you won't have any way to hook a hardware wallet up to your remote, virtual machine.
+One of the greatest powers of PSBTs is the ability to hand transactions off to hardware wallets. This will be a great development tool for you if you continue to program with Bitcoin. However, you can't test it out now if you're using one of the configurations we suggest for this course — a VM on Linode per [§2.1](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/02_1_Setting_Up_a_Bitcoin-Core_VPS_with_StackScript.md) or an even more farflung option such as AWS per [§2.2](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/02_2_Setting_Up_Bitcoin_Core_Other.md) — because obviously you won't have any way to hook a hardware wallet up to your remote, virtual machine.
 
 > :book: ***What is a Hardware Wallet?*** A hardware wallet is an electronic device that improves the security of a cryptocurrency by maintaining all the private keys on the device, rather than ever putting them on a computer directly connected to the internet. Hardware wallets have specific protocols for providing online interactions, usually managed by a program talking to the device through a USB port. In this chapter, we'll be managing a hardware wallet with `bitcoin-cli` and the `hwy.py` program.
 
@@ -22,7 +22,7 @@ There are alternate versions of the Bitcoin Standup script that you used to crea
 
 If you have MacOS, you can install [Bitcoin Standup MacOS](https://github.com/BlockchainCommons/Bitcoin-Standup-MacOS/blob/master/README.md).
 
-If you have a local Linux machine, you can install [Bitcoin Standup Linux Scripts](https://github.com/BlockchainCommons/Bitcoin-Standup-MacOS/blob/master/README.md).
+If you have a local Linux machine, you can install [Bitcoin Standup Linux Scripts](https://github.com/BlockchainCommons/Bitcoin-Standup-Scripts/blob/master/README.md).
 
 Once you've gotten Bitcoin Standup running on your local machine, you'll want to sync the "Testnet" blockchain, assuming that you're continuing to follow the standard methodlogy of this course.
 
@@ -91,7 +91,7 @@ HWI$ python3 setup.py install
 
 You'll want to create an alias here too, varied by your actual install location:
 ```
-$ alias hwi="~/Standup/HWI/hwi.py --testnet"
+$ alias hwi="~/Standup/HWI/hwi.py --chain test"
 ```
 Again, we've included a reference to testnet in this alias.
 
@@ -104,7 +104,7 @@ If you are working with Bitcoins on your Ledger, you probably won't need to do a
 To work with Testnet coins, as suggested by this course, you'll need to make a few updates:
 
 1. Go to Settings on your Ledger Live app (it's the gear), go to the "Experimental Features" tab, and turn on "Developer Mode".
-2. Go to the "Manager" and install "Bitcoin Test". The current version requires that you have "Bitcoin" and "Etereum" installed first.
+2. Go to the "Manager" and install "Bitcoin Test". The current version requires that you have "Bitcoin" installed first.
 3. Go to the "Manager", scroll to your new "Bitcoin Test", and "Add Account"
 
 ## Link to a Ledger
@@ -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": ""
@@ -154,10 +154,10 @@ Because you've created a second wallet, some commands will now require a `-rpcwa
 
 You now have to import a watch-list of addresses from the hardware wallet. This is done with HWI's `getkeypool` command:
 ```
-$ hwi -f 9a1d520b getkeypool --wpkh 0 1000
+$ hwi -f 9a1d520b getkeypool 0 1000
 [{"desc": "wpkh([9a1d520b/84h/1h/0h]tpubDD7KTtoGzK9GuWUQcr1uTJazsAkqoXhdrwGXWVix6nPpNZmSbagZWD4QSaMsyK8YohAirGDPrWdRiEpKzTFB7DrTrqfzHCn7yi5EsqeR93S/0/*)#qttxy592", "range": [0, 1000], "timestamp": "now", "internal": false, "keypool": true, "active": true, "watchonly": true}, {"desc": "wpkh([9a1d520b/84h/1h/0h]tpubDD7KTtoGzK9GuWUQcr1uTJazsAkqoXhdrwGXWVix6nPpNZmSbagZWD4QSaMsyK8YohAirGDPrWdRiEpKzTFB7DrTrqfzHCn7yi5EsqeR93S/1/*)#3lw8ep4j", "range": [0, 1000], "timestamp": "now", "internal": true, "keypool": true, "active": true, "watchonly": true}]
 ```
-We address HWI with the `fingerprint` and ask for the first 1000 WPKH (native Segwit) addresses. In return, we receive two descriptors for the key pool: one for receiving addresses and one for change addresses.
+We address HWI with the `fingerprint` and ask for the first 1000 addresses. The WPKH (native Segwit) address type is used as a default. In return, we receive two descriptors for the key pool: one for receiving addresses and one for change addresses.
 
 > :book: ***What is a key pool?*** A key pool is a group of pregenerated keys. Modern HD wallets create key pools by continuing to determine new hierarchical addresses based on the original seed. The idea of key pools was originally implemented to ease the backup requirements of wallets. This allowed a user to generate a keypool and then backup the wallet immediately, rather than requiring backups after every new address was created. The concept has also proven very useful in the modern day since it allows the importing of a whole set of future addresses from one device to another.
 

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
 
@@ -22,6 +22,6 @@ Supporting objectives include the ability to:
 
 * [Section One: Understanding the Foundation of Transactions](09_1_Understanding_the_Foundation_of_Transactions.md)
 * [Section Two: Running a Bitcoin Script](09_2_Running_a_Bitcoin_Script.md)
-* [Section Three: Scripting a P2PKH](09_3_Scripting_a_P2PKH.md)
-* [Section Four: Testing a Bitcoin Script](09_4_Testing_a_Bitcoin_Script.md)
+* [Section Three: Testing a Bitcoin Script](09_3_Testing_a_Bitcoin_Script.md)
+* [Section Four: Scripting a P2PKH](09_4_Scripting_a_P2PKH.md)
 * [Section Five: Scripting a P2WPKH](09_5_Scripting_a_P2WPKH.md)

09_1_Understanding_the_Foundation_of_Transactions.md

@@ -4,20 +4,20 @@ The foundation of Bitcoin is the ability to protect transactions, something that
 
 ## Know the Parts of the Cryptographic Puzzle
 
-As described in [Chapter 1](01_0_Introducing_Bitcoin.md), the funds in each Bitcoin transaction are locked with a cryptographic puzzle. To be precise, we said that Bitcoin is made up of "a sequence of atomic transactions". We noted that: "Each transaction is authenticated by a sender with the solution to a previous cryptographic puzzle that was stored as a script. The new transaction is locked for the recipient with a new cryptographic puzzle that is also stored as a script." Those scripts, which lock and unlock transactions, are written in Bitcoin Script.
+As described in [Chapter 1](01_0_Introduction.md), the funds in each Bitcoin transaction are locked with a cryptographic puzzle. To be precise, we said that Bitcoin is made up of "a sequence of atomic transactions". We noted that: "Each transaction is authenticated by a sender with the solution to a previous cryptographic puzzle that was stored as a script. The new transaction is locked for the recipient with a new cryptographic puzzle that is also stored as a script." Those scripts, which lock and unlock transactions, are written in Bitcoin Script.
 
 > :book: ***What is Bitcoin Script?*** Bitcoin Script is a stack-based Forth-like language that purposefully avoids loops and so is not Turing-complete. It's made up of individual opcodes. Every single transaction in Bitcoin is locked with a Bitcoin Script; when the locking transaction for a UTXO is run with the correct inputs, that UTXO can then be spent.
 
 The fact that transactions are locked with scripts means that they can be locked in a variety of different ways, requiring a variety of different keys. In fact, we've met a number of different locking mechanisms to date, each of which used different opcodes:
 
-   * OP_CHECKSIG, which checks a public key against a signature, is the basis of the classic P2PKH address, as will be fully detailed in [§9.3: Scripting a P2PKH](09_3_Scripting_a_P2PKH.md).
+   * OP_CHECKSIG, which checks a public key against a signature, is the basis of the classic P2PKH address, as will be fully detailed in [§9.3: Scripting a P2PKH](09_4_Scripting_a_P2PKH.md).
    * OP_CHECKMULTISIG similarly checks multisigs, as will be fully detailed in [§10.4: Scripting a Multisig](10_4_Scripting_a_Multisig.md).
-   * OP_CHECKLOCKTIMEVERIFY and OP_SEQUENCEVERIFY form the basis of more complex Timelocks, as will be fully detailed in [§11.2: Using CLTV in Scripts](11_2_Using_CLTV_in_Scripts) and [§11.3: Using CSV in Scripts](11_3_Using_CSV_in_Scripts.md).
+   * OP_CHECKLOCKTIMEVERIFY and OP_SEQUENCEVERIFY form the basis of more complex Timelocks, as will be fully detailed in [§11.2: Using CLTV in Scripts](11_2_Using_CLTV_in_Scripts.md) and [§11.3: Using CSV in Scripts](11_3_Using_CSV_in_Scripts.md).
    * OP_RETURN is the mark of an unspendable transaction, which is why it's used to carry data, as was alluded to in [§8.2: Sending a Transaction with Data](08_2_Sending_a_Transaction_with_Data.md).
 
 ## Access Scripts In Your Transactions
 
-You may not realize it, but you've already seen these locking and unlocking scripts as part of the raw transactins you've been working with. The best way to look into these scripts in more depth is thus to create a raw transaction, then examine it.
+You may not realize it, but you've already seen these locking and unlocking scripts as part of the raw transactions you've been working with. The best way to look into these scripts in more depth is thus to create a raw transaction, then examine it.
 
 ### Create a Test Transaction
 

09_2_Running_a_Bitcoin_Script.md

@@ -12,7 +12,7 @@ Bitcoin Scripts are run from left to right. That sounds easy enough, because it'
 
 For example, if you were adding together "1" and "2", your Bitcoin Script for that would be `1 2 OP_ADD`, _not_ "1 + 2". Since we know that OP_ADD operator takes two inputs, we know that the two inputs before it are its operands.
 
-> :warning: **WARNING:** Technically, everything in Bitcoin Script is an opcode, thus it would be most appropriate to record the above example as `OP_1 OP_2 OP_ADD`. In our examples, we don't worry about how the constants will be evaluated, as that's a topic of translation, as is explained in [§8.2: Building the Structure of P2SH](08_2_Building_the_Structure_of_P2SH.md). Some writers prefer to also leave the "OP" prefix off all operators, but we have opted not to.
+> :warning: **WARNING:** Technically, everything in Bitcoin Script is an opcode, thus it would be most appropriate to record the above example as `OP_1 OP_2 OP_ADD`. In our examples, we don't worry about how the constants will be evaluated, as that's a topic of translation, as is explained in [§10.2: Building the Structure of P2SH](10_2_Building_the_Structure_of_P2SH.md). Some writers prefer to also leave the "OP" prefix off all operators, but we have opted not to.
 
 ### Understand the Stack
 

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.

09_5_Scripting_a_P2WPKH.md

@@ -63,7 +63,7 @@ Here's a comparison of our two examples:
 | Type | PubKeyHash | PubKey | Signature |
 |----------------|----------|-------------|---------|
 | SegWit | 92a0db923b3a13eb576a40c4b35515aa30206cba | 03839e6035b33e37597908c83a2f992ec835b093d65790f43218cb49ffe5538903 | 3044022064f633ccfc4e937ef9e3edcaa9835ea9a98d31fbea1622c1d8a38d4e7f8f6cb602204bffef45a094de1306f99da055bd5a603a15c277a59a48f40a615aa4f7e5038001 |
-| SegWit | 06b5c6ba5330cdf738a2ce91152bfd0e71f9ec39 | 0315a0aeb37634a71ede72d903acae4c6efa77f3423dcbcd6de3e13d9fd989438b | 04402201cc39005b076cb06534cd084fcc522e7bf937c4c9654c1c9dfba68b92cbab7d1022066f273178febc7a37568e2e9f4dec980a2e9a95441abe838c7ef64c39d85849c |
+| non-SegWit | 06b5c6ba5330cdf738a2ce91152bfd0e71f9ec39 | 0315a0aeb37634a71ede72d903acae4c6efa77f3423dcbcd6de3e13d9fd989438b | 04402201cc39005b076cb06534cd084fcc522e7bf937c4c9654c1c9dfba68b92cbab7d1022066f273178febc7a37568e2e9f4dec980a2e9a95441abe838c7ef64c39d85849c |
 
 So how does this work? It depends on old code interpreting this as a valid transaction and new code knowing to check the new "witness" information
 
@@ -96,7 +96,7 @@ script                                   |                                   sta
 ```
 Bitcoin Scripts are considered successful if there's something in the Stack, and it's non-zero, so SegWit scripts automatically succeed on old nodes as long as the `scriptPubKey` is correctly created with a non-zero pub-key hash. This is called an "anyone-can-spend" transaction, because old nodes verified them as correct without any need for signatures.
 
-> :book: ***What can't old nodes steal SegWit UTXOs?*** SegWit was enabled on the Bitcoin network when 95% of miners signalled that they were ready to start using it. That means that only 5% of nodes at that point might have registered anyone-can-spend SegWit transactions as valid without going through the proper work of checking the `txinwitness`. If they incorrectly incorporated an invalid anyone-can-spend UTXO into a block, the other 95% of nodes would refuse to validate that block, and so it would quickly be orphaned rather than being added to the "main" blockchain. (Certainly, 51% of nodes could choose to stop interpreting SegWit transactions correctly, but 51% of nodes can do anything on a consensus network like a blockchain.)
+> :book: ***Why can't old nodes steal SegWit UTXOs?*** SegWit was enabled on the Bitcoin network when 95% of miners signalled that they were ready to start using it. That means that only 5% of nodes at that point might have registered anyone-can-spend SegWit transactions as valid without going through the proper work of checking the `txinwitness`. If they incorrectly incorporated an invalid anyone-can-spend UTXO into a block, the other 95% of nodes would refuse to validate that block, and so it would quickly be orphaned rather than being added to the "main" blockchain. (Certainly, 51% of nodes could choose to stop interpreting SegWit transactions correctly, but 51% of nodes can do anything on a consensus network like a blockchain.)
 
 Because old nodes always see SegWit scripts as correct, they will always verify them, even without understanding their content.
 

10_1_Understanding_the_Foundation_of_P2SH.md

@@ -8,8 +8,8 @@ Here's the gotcha for using Bitcoin Scripts: for security reasons, most Bitcoin
 
 * __Pay to Public Key (P2PK)__ — An older, deprecated transaction (`<pubKey> OP_CHECKSIG`) that has been replaced by the better security of P2PKH.
 * __Pay to Public Key Hash (P2PKH)__ — A standard transaction (`OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG`) that pays to the hash of a public key.
-* __Pay to Witness Public Key hash (P2WPKH)__ — The newest sort of public-key transaction. It's just (`OP_0 <pubKeyHash`) because it depends on miner consensus to work, as described in [§9.5](09_5_Scripting_a_P2WPKH.md).
-* __Multisig__ — A transaction for a group of keys, as explained more fully in [§8.4](08_4_Scripting_a_Multisig.md).
+* __Pay to Witness Public Key hash (P2WPKH)__ — The newest sort of public-key transaction. It's just (`OP_0 <pubKeyHash>`) because it depends on miner consensus to work, as described in [§9.5](09_5_Scripting_a_P2WPKH.md).
+* __Multisig__ — A transaction for a group of keys, as explained more fully in [§10.4](10_4_Scripting_a_Multisig.md).
 * __Null Data__ — An unspendable transaction (`OP_RETURN Data`).
 * __Pay to Script Hash (P2SH)__ — A transaction that pays out to a specific script, as explained more fully here.
 
@@ -19,7 +19,7 @@ So how do you write a more complex Bitcoin Script? The answer is in that last so
 
 ## Understand the P2SH Script
 
-You already saw a P2SH transaction when you created a multisig in [§6.1: Sending a Transaction to a Multisig](06_1_Sending_a_Transaction_to_a_Multisig.md). Though multisig is one of the standard transaction types, `bitcoin-cli` simplifies the usage of its multisigs by embedding them into P2SH transactions, as described more fully in [§8.4: Scripting a Multisig](08_4_Scripting_a_Multisig.md).
+You already saw a P2SH transaction when you created a multisig in [§6.1: Sending a Transaction to a Multisig](06_1_Sending_a_Transaction_to_a_Multisig.md). Though multisig is one of the standard transaction types, `bitcoin-cli` simplifies the usage of its multisigs by embedding them into P2SH transactions, as described more fully in [§10.4: Scripting a Multisig](10_4_Scripting_a_Multisig.md).
 
 So, let's look one more time at the `scriptPubKey` of that P2SH multisig:
 ```

10_2_Building_the_Structure_of_P2SH.md

@@ -6,7 +6,7 @@ In the previous section we overviewed the theory of how to create P2SH transacti
 
 Any P2SH transaction starts with a locking script. This is the subject of chapters 9 and 11-12. You can use any of the Bitcoin Script methods described therein to create any sort of locking script, as long as the resulting serialized `redeemScript` is 520 bytes or less. 
 
-> :book: ***Why are P2SH scripts limited to 520 bytes?*** As with many things in Bitcoin, the answer is backward compatibility: new functionality has to constantly be built within the old constraints of the system. Is this case, 520 bytes is the maximum that can be pushed onto the stack at once. Since the whole redeemScript is pushed onto the stack as part of the redemption process, it hits that limit.
+> :book: ***Why are P2SH scripts limited to 520 bytes?*** As with many things in Bitcoin, the answer is backward compatibility: new functionality has to constantly be built within the old constraints of the system. In this case, 520 bytes is the maximum that can be pushed onto the stack at once. Since the whole redeemScript is pushed onto the stack as part of the redemption process, it hits that limit.
 
 ## Serialize a Locking Script the Hard Way
 
@@ -67,7 +67,7 @@ To complete your serialization, you translate the hexcode into binary. On the co
 
 ## Run The Integer Conversion Script
 
-A complete script for changing an integer between -2147483647 and 2147483647 to a little-endian signed-magnitude representation in hex can be found in th e[src code directory](src/10_2_integer2lehex.sh). You can download it as `integeer2lehex.sh`.
+A complete script for changing an integer between -2147483647 and 2147483647 to a little-endian signed-magnitude representation in hex can be found in the [src code directory](src/10_2_integer2lehex.sh). You can download it as `integer2lehex.sh`.
 
 > :warning: **WARNING:** This script has not been robustly checked. If you are going to use it to create real locking scripts you should make sure to double-check and test your results.
 
@@ -171,7 +171,7 @@ Depending on your API, you might be able to enter this as an `asm`-style `script
 
 Note that the `hex scriptPubKey` for P2SH Script transaction will _always_ start with an `a914`, which is the `OP_HASH160` followed by an `OP_PUSHDATA` of 20 bytes (hex: `0x14`); and it will _always_ end with a `87`, which is an `OP_EQUAL`. So all you have to do is put your hashed redeem script in between those numbers.
 
-## Summary: Understanding the Foundation of P2SH
+## Summary: Building the Structure of P2SH
 
 Actually creating the P2SH locking script dives further into the guts of Bitcoin than you've ever gone before. Though it's helpful to know how all of this works at a very low level, it's most likely that you'll have an API taking care of all of the heavy-lifting for you. Your task will simply be to create the Bitcoin Script to do the locking ... which is the main topic of chapters 9 and 11-12.
 

10_4_Scripting_a_Multisig.md

@@ -10,7 +10,7 @@ Multisig transactions are created in Bitcoin using the `OP_CHECKMULTISIG` code.
 2. Pop "n" values from the stack as Bitcoin addresses (hashed public keys).
 3. Pop the next value from the stack (`<m>`).
 4. Pop "m" values from the stack as potential signatures.
-5. Pop an `0` from the stack due to a mistake in the original coding.
+5. Pop a `0` from the stack due to a mistake in the original coding.
 6. Compare the signatures to the Bitcoin adddresses.
 7. Push a `True` or `False` depending on the result.
 
@@ -22,15 +22,15 @@ The requirement for that `0` as the first operand for `OP_CHECKMULTISIG` is a co
 
 ## Create a Raw Multisig 
 
-As discussed in [§10.1: Building a Bitcoin Script with P2SH](10_1_Building_a_Bitcoin_Script_with_P2SH.md), multisigs are one of the standard Bitcoin transaction types. A transaction can be created with a locking script that uses the raw `OP_CHECKMULTISIG` command, and it will be accepted into a block. This is the classic methodology for using multisigs in Bitcoin.
+As discussed in [§10.1: Understanding the Foundation of P2SH](10_1_Understanding_the_Foundation_of_P2SH.md), multisigs are one of the standard Bitcoin transaction types. A transaction can be created with a locking script that uses the raw `OP_CHECKMULTISIG` command, and it will be accepted into a block. This is the classic methodology for using multisigs in Bitcoin.
 
-As an example, we will revisit the multisig created in [§8.1](08_1_Sending_a_Transaction_to_a_Multisig.md) one final time and build a new locking script for it using this methodology. As you may recall, that was a 2-of-2 multisig built from `$address1` and `$address2`. 
+As an example, we will revisit the multisig created in [§6.1](06_1_Sending_a_Transaction_to_a_Multisig.md) one final time and build a new locking script for it using this methodology. As you may recall, that was a 2-of-2 multisig built from `$address1` and `$address2`. 
 
-As as `OP_CHECKMULTISIG` locking script requires the "m" (`2`), the addresses, and the "n" (`2`), you could write the following `scriptPubKey`:
+As `OP_CHECKMULTISIG` locking script requires the "m" (`2`), the addresses, and the "n" (`2`), you could write the following `scriptPubKey`:
 ```
 2 $address1 $address2 2 OP_CHECKMULTISIG
 ```
-If this looks familiar, that's because it's the multisig that you deserialized in [§8.2: Building the Structure of P2SH](08_2_Building_the_Structure_of_P2SH.md).
+If this looks familiar, that's because it's the multisig that you deserialized in [§10.2: Building the Structure of P2SH](10_2_Building_the_Structure_of_P2SH.md).
 ```
 2 02da2f10746e9778dd57bd0276a4f84101c4e0a711f9cfd9f09cde55acbdd2d191 02bfde48be4aa8f4bf76c570e98a8d287f9be5638412ab38dede8e78df82f33fa3 2 OP_CHECKMULTISIG
 ```
@@ -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
 

10_5_Scripting_a_Segwit_Script.md

@@ -36,66 +36,70 @@ $ bitcoin-cli listunspent
     "safe": true
   }
 ```
-More importantly, there's a `redeemScript`, which decodes to `OP_0 OP_PUSHDATA (20 bytes) 3ab2a09a1a5f2feb6c799b5ab345069a96e1a0a`. The should look familiar, because it's an `OP_0` followed by 20-byte hexcode of a public key hash. In other words, a P2SH-SegWit is just a SegWit `scriptPubKey` jammed into a script. That's all there is to it. It precisely matches how modern multisigs are a multsig jammed into a P2SH, as discussed in [§10.4: Scripting a Multisig](10_4_Scripting_a_Multisig.md).
+More importantly, there's a `redeemScript`, which decodes to `OP_0 OP_PUSHDATA (20 bytes) 3ab2a09a1a5f2feb6c799b5ab345069a96e1a0a`. This should look familiar, because it's an `OP_0` followed by 20-byte hexcode of a public key hash. In other words, a P2SH-SegWit is just a SegWit `scriptPubKey` jammed into a script. That's all there is to it. It precisely matches how modern multisigs are a multsig placed inside a P2SH, as discussed in [§10.4: Scripting a Multisig](10_4_Scripting_a_Multisig.md).
 
-The raw transaction reveals a bit more when you look at the `vout` `1`:
+Conversely, when we spend this transaction, it looks exactly like a P2SH:
 ```
-$ hex=$(bitcoin-cli gettransaction "bb4362dec15e67d366088f5493c789f22fb4a604e767dae1f6a631687e2784aa" | jq -r '.hex')
-$ bitcoin-cli decoderawtransaction $hex
+$ bitcoin-cli getrawtransaction ed752673bfd4338ccf0995983086da846ad652ae0f28280baf87f9fd44b3c45f 1
 {
-  "txid": "bb4362dec15e67d366088f5493c789f22fb4a604e767dae1f6a631687e2784aa",
-  "hash": "6866490b16a92d68179e1cf04380fd08f16ec80bf66469af8d5e78ae624ff202",
+  "txid": "ed752673bfd4338ccf0995983086da846ad652ae0f28280baf87f9fd44b3c45f",
+  "hash": "aa4b1c2bde86ea446c9a9db2f77e27421316f26a8d88869f5b195f03b1ac4f23",
   "version": 2,
-  "size": 249,
-  "vsize": 168,
-  "weight": 669,
-  "locktime": 1780788,
+  "size": 247,
+  "vsize": 166,
+  "weight": 661,
+  "locktime": 1781316,
   "vin": [
     {
-      "txid": "4779bb137ddbcaf796f905e264554b1ec28c0f3ab4538ca02eac5099bfc3fc1e",
-      "vout": 0,
+      "txid": "59178b02cfcbdee51742a4b2658df35b63b51115a53cf802bc6674fd94fa593a",
+      "vout": 1,
       "scriptSig": {
-        "asm": "0014c4ea10874ae77d957e170bd43f2ee828a8e3bc71",
-        "hex": "160014c4ea10874ae77d957e170bd43f2ee828a8e3bc71"
+        "asm": "00149ef51fb1f5adb44e20eff758d34ae64fa781fa4f",
+        "hex": "1600149ef51fb1f5adb44e20eff758d34ae64fa781fa4f"
       },
       "txinwitness": [
-        "3044022025ee4fd38e6865125f7c315406c0b3a8139d482e3be333727d38868baa656d3d02204b35d9b5812cb85894541da611d5cec14c374ae7a7b8ba14bb44495747b5715301",
-        "033cae26cb3fa063c95e2c55a94bd04ab9cf173104555efe448b1bfc3a68c8f873"
+        "3044022069a23fcfc421b44c622d93b7639a2152f941dbfd031970b8cef69e6f8e97bd46022026cb801f38a1313cf32a8685749546a5825b1c332ee4409db82f9dc85d99086401",
+        "030aec1384ae0ef264718b8efc1ef4318c513403d849ea8466ef2e4acb3c5ccce6"
       ],
       "sequence": 4294967294
     }
   ],
   "vout": [
     {
-      "value": 0.00095000,
+      "value": 8.49029534,
       "n": 0,
       "scriptPubKey": {
-        "asm": "OP_DUP OP_HASH160 41d83eaffbf80f82dee4c152de59a38ffd0b6021 OP_EQUALVERIFY OP_CHECKSIG",
-        "hex": "76a91441d83eaffbf80f82dee4c152de59a38ffd0b602188ac",
+        "asm": "OP_HASH160 b4b656f4c4b14ee0d098299d1d6eb42d2e22adcd OP_EQUAL",
+        "hex": "a914b4b656f4c4b14ee0d098299d1d6eb42d2e22adcd87",
         "reqSigs": 1,
-        "type": "pubkeyhash",
+        "type": "scripthash",
         "addresses": [
-          "mmX7GUoXq2wVcbnrnFJrGKsGR14fXiGbD9"
+          "2N9ik3zihJ91VGNF55sZFe9GiCAXh2cVKKW"
         ]
       }
     },
     {
-      "value": 0.01063793,
+      "value": 0.00095000,
       "n": 1,
       "scriptPubKey": {
-        "asm": "OP_HASH160 b780fc2e945bea71b9ee2d8d2901f00914a25fbd OP_EQUAL",
-        "hex": "a914b780fc2e945bea71b9ee2d8d2901f00914a25fbd87",
+        "asm": "OP_HASH160 ee7aceea0865a05a29a28d379cf438ac5b6cd9c6 OP_EQUAL",
+        "hex": "a914ee7aceea0865a05a29a28d379cf438ac5b6cd9c687",
         "reqSigs": 1,
         "type": "scripthash",
         "addresses": [
-          "2N9yWARt5E3TQsX2RjsauxSZaEZVhinAS4h"
+          "2NEzBvokxh4ME4ahdT18NuSSoYvvhS7EnMU"
         ]
       }
     }
-  ]
+  ],
+  "hex": "020000000001013a59fa94fd7466bc02f83ca51511b5635bf38d65b2a44217e5decbcf028b175901000000171600149ef51fb1f5adb44e20eff758d34ae64fa781fa4ffeffffff029e299b320000000017a914b4b656f4c4b14ee0d098299d1d6eb42d2e22adcd87187301000000000017a914ee7aceea0865a05a29a28d379cf438ac5b6cd9c68702473044022069a23fcfc421b44c622d93b7639a2152f941dbfd031970b8cef69e6f8e97bd46022026cb801f38a1313cf32a8685749546a5825b1c332ee4409db82f9dc85d9908640121030aec1384ae0ef264718b8efc1ef4318c513403d849ea8466ef2e4acb3c5ccce6442e1b00",
+  "blockhash": "0000000069cbe44925fab2d472870608c7e1e241a1590fd78be10c63388ed6ee",
+  "confirmations": 282952,
+  "time": 1595360859,
+  "blocktime": 1595360859
 }
 ```
-This confirms that this is just a normal P2SH, locked by `"OP_DUP OP_HASH160 41d83eaffbf80f82dee4c152de59a38ffd0b6021 OP_EQUALVERIFY OP_CHECKSIG"`. It's when the redeem script is run that the magic occurs. Just as with a P2WPKH, an old node wil see `OP_0 OP_PUSHDATA (20 bytes) 3ab2a09a1a5f2feb6c799b5ab345069a96e1a0a` and verify it automatically, while a new node will see that, know it's a P2WPKH, and so go out to the `witnesses`. See [§9.5: Scripting a P2WPKH](09_5_Scripting_a_P2WPKH.md).
+Each `vout` is of the form `OP_HASH160 <HASH> OP_EQUAL`. That's a normal P2SH per [§10.2](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/82ca897286aac612804ae849b260750229fa3a52/10_2_Building_the_Structure_of_P2SH.md), which means that it's only when the redeem script is run that the magic occurs. Just as with a P2WPKH, an old node wil see `OP_0 OP_PUSHDATA (20 bytes) 3ab2a09a1a5f2feb6c799b5ab345069a96e1a0a` in the redeem script and verify it automatically, while a new node will see that, know it's a P2WPKH, and so go out to the `witnesses`. See [§9.5: Scripting a P2WPKH](09_5_Scripting_a_P2WPKH.md).
 
 > :book: ***What are the disadvantages of nested Segwit transactions?*** They're bigger than native Segwit transactions, so you get some of advantages of Segwit, but not all of them.
 
@@ -114,7 +118,7 @@ This works just like a P2WPKH address, the only difference being that instead of
 
 There is also one more variant, a P2WSH script embedded in a P2SH script, which works much like the P2SH-Segwit described above, but for nested P2WSH scripts. (Whew!)
 
-## Summary: Scripting a Pay to Witness Public Key Hash
+## Summary: Scripting a Segwit Script
 
 There are two sorts of P2SH scripts that relate to Segwit. 
 

10_6_Spending_a_P2SH_Transaction.md

@@ -4,11 +4,11 @@ Before we close out this overview of P2SH transactions, we're going to touch upo
 
 ## Use the Redeem Script
 
-As we saw in [§6.2: Spending a Transaction to a Multisig](06_2_Spending_a_Transaction_to_a_Multisig.md), spending a P2SH transaction is all about having that serialized version of the locking script, the so-called _redeemScript_. So, the first step in being able to spend a P2SH transaction is making sure that you save the _redeemScript_ before you give out the P2SH address to everyone. 
+As we saw in [§6.2: Spending a Transaction with a Multisig](06_2_Spending_a_Transaction_to_a_Multisig.md), spending a P2SH transaction is all about having that serialized version of the locking script, the so-called _redeemScript_. So, the first step in being able to spend a P2SH transaction is making sure that you save the _redeemScript_ before you give out the P2SH address to everyone. 
 
 ### Collect Your Variables
 
-Because P2SH addresses other than the special multisig and nested Segwit addresses aren't integrated into `bitcoin-cli` there will be no short-cuts for P2SH spending like you saw in [§6.3: Sending an Automated Multisig](6_3_Sending_an_Automated_Multisig.md). You're going to need to collect all the more complex variables on your own!
+Because P2SH addresses other than the special multisig and nested Segwit addresses aren't integrated into `bitcoin-cli` there will be no short-cuts for P2SH spending like you saw in [§6.3: Sending an Automated Multisig](06_3_Sending_an_Automated_Multisig.md). You're going to need to collect all the more complex variables on your own!
 
 This means that you need to collect:
 
@@ -33,7 +33,7 @@ $ bitcoin-cli -named signrawtransactionwithkey hexstring=$rawtxhex prevtxs='''[
 ```
 With any other sort of P2SH you're going to be including a different `redeemscript`, but otherwise the practice is exactly the same. The only difference is that after two chapters of work on Scripts you now understand what the `scriptPubKey` is and what the `redeemScript` is, so hopefully what were mysterious elements four chapters ago are now old hat.
 
-## Summary: Spending a Transaction with a Bitcoin Script
+## Summary: Spending a P2SH Transaction
 
 You already spent a P2SH back in Chapter 6, when you resent a multsig transaction the hard way, which required lining up the `scriptPubKey` and `redeemScript` information. Now you know that the `scriptPubKey` is a standardized P2SH locking script, while the `redeemScript` matches a hash in that locking script and that you need to be able to run it with the proper variables to receive a `True` result. But other than knowing more, there's nothing new in spending a P2SH transaction, because you already did it!
 

11_2_Using_CLTV_in_Scripts.md

@@ -38,7 +38,7 @@ Or this:
 
 ### Understand a CLTV Absolute Block Height
 
-This is how `OPCHECKLOCKTIMEVERIFY` would check against a blockheight that was reached on May 24, 2017:
+This is how `OP_CHECKLOCKTIMEVERIFY` would check against a blockheight that was reached on May 24, 2017:
 ```
 467951 OP_CHECKLOCKTIMEVERIFY
 ```
@@ -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.
@@ -146,7 +146,7 @@ Finally, the remainder of the script runs, which is a normal check of a signatur
 
 ## Summary: Using CLTV in Scripts
 
-`OP-CHECKLOCKTIMEVERIFY` is a simple opcode that looks at a single argument, interprets it as a blockheight or UNIX timestamp, and only allows its UTXO to be unlocked if that blockheight or UNIX timestamp is in the past. Setting `nLockTime` on the spending transaction is what allows Bitcoin to make this calculation.
+`OP_CHECKLOCKTIMEVERIFY` is a simple opcode that looks at a single argument, interprets it as a blockheight or UNIX timestamp, and only allows its UTXO to be unlocked if that blockheight or UNIX timestamp is in the past. Setting `nLockTime` on the spending transaction is what allows Bitcoin to make this calculation.
 
 > :fire: ***What is the Power of CLTV?*** You've already seem that simple locktimes were one of the bases of Smart Contracts. CLTV takes the next step. Now you can both guarantee that a UTXO can't be spent before a certain time _and_ guarantee that it won't be spent either. In its simplest form, this could be used to create a trust that someone could only access when they reached 18 or a retirement fund that they could only access when they turned 50. However its true power comes when combined with conditionals, where the CLTV only activates in certain situations.
 

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.
 

12_2_Using_Other_Script_Commands.md

@@ -18,7 +18,7 @@ Manipulate one number:
 
 Also see: `OP_0NOTEQUAL` (0x92)
 
-Manipulate two number mathematically:
+Manipulate two numbers mathematically:
 
 * OP_ADD (0x93) — Add two numbers
 * OP_SUB (0x94) — Subtract two numbers

13_1_Writing_Puzzle_Scripts.md

@@ -177,7 +177,7 @@ script   |  stack
 
 What if you wanted to instead write an equation system, such as `x + y = 3`, `y + z = 5`, and `x + z = 4`? A bit of algebra tells you that the answers come out to `x = 1`, `y = 2`, and `z = 3`. But, how do you script it?
 
-Most obviously, after the redeemer inputs the three numbers, you're going to need two copies of each numbers, since each number goes into two different equations. `OP_3DUP` takes care of that and results in `x y z x y z` being on the stack. Popping off two items at a time will give you `y z`, `z x`, and `x y`. Voila! That's the three equations, so you just need to add them up and test them in the right order! Here's the full script: `OP_3DUP OP_ADD 5 OP_EQUALVERIFY OP_ADD 4 OP_EQUALVERIFY OP_ADD 3 OP_EQUAL`.
+Most obviously, after the redeemer inputs the three numbers, you're going to need two copies of each number, since each number goes into two different equations. `OP_3DUP` takes care of that and results in `x y z x y z` being on the stack. Popping off two items at a time will give you `y z`, `z x`, and `x y`. Voila! That's the three equations, so you just need to add them up and test them in the right order! Here's the full script: `OP_3DUP OP_ADD 5 OP_EQUALVERIFY OP_ADD 4 OP_EQUALVERIFY OP_ADD 3 OP_EQUAL`.
 
 Here's how it runs with the correct unlocking script of `1 2 3`:
 ```
@@ -481,7 +481,7 @@ This is a nice script because it shows careful use of logic (with the `OP_NOT` a
 
 `btcdeb` can be run to prove the collision (and the script):
 ```
-btcdeb $ btcdeb '[255044462d312e330a25e2e3cfd30a0a0a312030206f626a0a3c3c2f57696474682032203020522f4865696768742033203020522f547970652034203020522f537562747970652035203020522f46696c7465722036203020522f436f6c6f7253706163652037203020522f4c656e6774682038203020522f42697473506572436f6d706f6e656e7420383e3e0a73747265616d0affd8fffe00245348412d3120697320646561642121212121852fec092339759c39b1a1c63c4c97e1fffe017f46dc93a6b67e013b029aaa1db2560b45ca67d688c7f84b8c4c791fe02b3df614f86db1690901c56b45c1530afedfb76038e972722fe7ad728f0e4904e046c230570fe9d41398abe12ef5bc942be33542a4802d98b5d70f2a332ec37fac3514e74ddc0f2cc1a874cd0c78305a21566461309789606bd0bf3f98cda8044629a1 255044462d312e330a25e2e3cfd30a0a0a312030206f626a0a3c3c2f57696474682032203020522f4865696768742033203020522f547970652034203020522f537562747970652035203020522f46696c7465722036203020522f436f6c6f7253706163652037203020522f4c656e6774682038203020522f42697473506572436f6d706f6e656e7420383e3e0a73747265616d0affd8fffe00245348412d3120697320646561642121212121852fec092339759c39b1a1c63c4c97e1fffe017346dc9166b67e118f029ab621b2560ff9ca67cca8c7f85ba84c79030c2b3de218f86db3a90901d5df45c14f26fedfb3dc38e96ac22fe7bd728f0e45bce046d23c570feb141398bb552ef5a0a82be331fea48037b8b5d71f0e332edf93ac3500eb4ddc0decc1a864790c782c76215660dd309791d06bd0af3f98cda4bc4629b1 OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL']
+$ btcdeb '[255044462d312e330a25e2e3cfd30a0a0a312030206f626a0a3c3c2f57696474682032203020522f4865696768742033203020522f547970652034203020522f537562747970652035203020522f46696c7465722036203020522f436f6c6f7253706163652037203020522f4c656e6774682038203020522f42697473506572436f6d706f6e656e7420383e3e0a73747265616d0affd8fffe00245348412d3120697320646561642121212121852fec092339759c39b1a1c63c4c97e1fffe017f46dc93a6b67e013b029aaa1db2560b45ca67d688c7f84b8c4c791fe02b3df614f86db1690901c56b45c1530afedfb76038e972722fe7ad728f0e4904e046c230570fe9d41398abe12ef5bc942be33542a4802d98b5d70f2a332ec37fac3514e74ddc0f2cc1a874cd0c78305a21566461309789606bd0bf3f98cda8044629a1 255044462d312e330a25e2e3cfd30a0a0a312030206f626a0a3c3c2f57696474682032203020522f4865696768742033203020522f547970652034203020522f537562747970652035203020522f46696c7465722036203020522f436f6c6f7253706163652037203020522f4c656e6774682038203020522f42697473506572436f6d706f6e656e7420383e3e0a73747265616d0affd8fffe00245348412d3120697320646561642121212121852fec092339759c39b1a1c63c4c97e1fffe017346dc9166b67e118f029ab621b2560ff9ca67cca8c7f85ba84c79030c2b3de218f86db3a90901d5df45c14f26fedfb3dc38e96ac22fe7bd728f0e45bce046d23c570feb141398bb552ef5a0a82be331fea48037b8b5d71f0e332edf93ac3500eb4ddc0decc1a864790c782c76215660dd309791d06bd0af3f98cda4bc4629b1 OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL]'
 ```
 
 Peter Todd's other [bounties](https://bitcointalk.org/index.php?topic=293382.0) remain unclaimed at the time of this writing. They're all written in the same manner as the SHA-1 example above.
@@ -494,7 +494,7 @@ Here's where the security falls down:
 
 First, anyone can redeem them without knowing much of a secret. They do have to have the `redeemScript`, which offers some protection, but once they do, that's probably the only secret that's necessary — unless your puzzle is _really_ tough, such as a computational puzzle.
 
-Second, the actual redemption isn't secure. Normally, a Bitcoin transction is protected by the signature. Because the signature covers the transaction, no one on the network can rewrite that transaction to instead send to their address without invalidating the signature (and thus the transaction). That isn't true with a transactions whose inputs are just numbers. Anyone could grab the transaction and rewrite it to allow them to steal the funds. If they can get their transaction into a block before yours, they win, and you don't get the puzzle money. There are solutions for this, but they involve mining the block yourself or having a trusted pool mine it, and neither of those options is rational for an average Bitcoin user. 
+Second, the actual redemption isn't secure. Normally, a Bitcoin transaction is protected by the signature. Because the signature covers the transaction, no one on the network can rewrite that transaction to instead send to their address without invalidating the signature (and thus the transaction). That isn't true with a transactions whose inputs are just numbers. Anyone could grab the transaction and rewrite it to allow them to steal the funds. If they can get their transaction into a block before yours, they win, and you don't get the puzzle money. There are solutions for this, but they involve mining the block yourself or having a trusted pool mine it, and neither of those options is rational for an average Bitcoin user. 
 
 Yet, Peter Todd's cryptographic bounties prove that puzzle scripts do have some real-world application.
 

13_2_Writing_Complex_Multisig_Scripts.md

@@ -78,7 +78,7 @@ Script:
 Running: 0 <sigVPA> <sigVPB> 2 <pubKeyVPA> <pubKeyVPB> <pubKeyVPC> 3 OP_CHECKMULTISIG
 Stack: [ ]
 ```
-You might notice that the President's signature just uses a simple `OP_CHECKSIGNATURE` rather than the more complex code ususally required for a P2PKH. We can get away with including the public key in the locking script, obviating the usual rigamarole, because it's hashed and won't be revealed (through the `redeemScript`) until the transaction is unlocked. This also allows for all of the possible signers to sign using the same methodology.
+You might notice that the President's signature just uses a simple `OP_CHECKSIGNATURE` rather than the more complex code usually required for a P2PKH. We can get away with including the public key in the locking script, obviating the usual rigamarole, because it's hashed and won't be revealed (through the `redeemScript`) until the transaction is unlocked. This also allows for all of the possible signers to sign using the same methodology.
 
 The only possible problem is if the President is absent-minded and accidentally signs a transaction with one of his VPs, because he remembers this being a 2-of-3 multisig. One option is to decide that's an acceptable failure condition, because the President is using the multsig incorrectly. Another option is to turn the 2-of-3 multisig into a 2-of-4 multisig, just in case the President doesn't tolerate failure: `OP_DEPTH 1 OP_EQUAL IF <pubKeyPres> OP_CHECKSIGNATURE ELSE 2 <pubKeyVPA> <pubKeyVPB> <pubKeyVPC> <pubKeyPres> 4 OP_CHECKMULTISIG ENDIF`. This would allow the President to mistakenly sign with any Vice President, but wouldn't impact things if two Vice Presidents wanted to (correctly) sign.
 
@@ -106,7 +106,7 @@ The result of the final `OP_CHECKMULTISIG` that was run will be left on the top
 
 We've talked a lot about escrows. Complex multisigs combined with timelocks offer an automated way to create them in a robust manner.
 
-Imagine home buyer Alice and home seller Bob who are working with an escrow agent The easy way to script this would be as a multisig where any two of the three parties could release the money: either the seller and buyer agree or the escrow agent takes over and agrees with one of the parties: `2 <pubKeyA> <pubKeyB> <pubKeyEscrow> 3 OP_CHECKMULTISG`.
+Imagine home buyer Alice and home seller Bob who are working with an escrow agent. The easy way to script this would be as a multisig where any two of the three parties could release the money: either the seller and buyer agree or the escrow agent takes over and agrees with one of the parties: `2 <pubKeyA> <pubKeyB> <pubKeyEscrow> 3 OP_CHECKMULTISG`.
 
 However, this weakens the power of the escrow agent and allows the seller and buyer to accidentally make a bad decision between themselves — which is one of the things an escrow system is designed to avoid. So it could be that what we really want is the system that we just laid out, where the escrow agent is a required party in the 2-of-3 multisig: `OP_3DUP 2 <pubKeyEscrow> <pubKeyA> 2  OP_CHECKMULTISIG NOTIF 2 <pubKeyEscrow> <pubKeyB> 2  OP_CHECKMULTISIG ENDIF`.
 
@@ -130,7 +130,7 @@ First, you test a signature for the buyer and the escrow agent, then a signature
 
 ### Write a Buyer-Centric Escrow Multisig
 
-[BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#Escrow_with_Timeout) offers an different example of this sort of escrow that doesn't have the extra protections to prevent going around the escrow agent, but which does give Alice total control if the escrow fails.
+[BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#Escrow_with_Timeout) offers a different example of this sort of escrow that doesn't have the extra protections to prevent going around the escrow agent, but which does give Alice total control if the escrow fails.
 ```
 IF
 

13_3_Empowering_Bitcoin_with_Scripts.md

@@ -4,7 +4,7 @@ Bitcoin Scripts can go far beyond the relatively simple financial instruments de
 
 ## Lock for the Lightning Network
 
-The [Lightning Network](https://rusty.ozlabs.org/?p=450) is a payment channel that allows users to take funds off-chain and engage in numerous microtransactions before finalizing the payment channel and bringing the funds back into Bitcoin. Benefits include lower fees and faster transaction speeds. It's discussed in more detail, with examples of how to use it from the command line, starting [Chapter 18](18_0_Understanding_Your_Lightning_Setup.md).
+The [Lightning Network](https://rusty.ozlabs.org/?p=450) is a payment channel that allows users to take funds off-chain and engage in numerous microtransactions before finalizing the payment channel and bringing the funds back into Bitcoin. Benefits include lower fees and faster transaction speeds. It's discussed in more detail, with examples of how to use it from the command line, starting [Chapter 19](19_0_Understanding_Your_Lightning_Setup.md).
 
 [BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) contains a few examples of how these off-chain transactions could be generated, using Bitcoin locking scripts.
 
@@ -270,7 +270,7 @@ Running through the script reveals that the initial checks, above the `IF`/`ELSE
 
 #### Understand HTLCs
 
-HTLCs are quite complex, and this overview doesn't try to explain all of their intricacies. Rusty Russell's [overview](https://rusty.ozlabs.org/?p=462) explains more. and there's even more detail in his [Deployable Lightning](https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf) paper. But don't worry if some of the intricacies still escape you, particularly the interrelations of the two scripts.
+HTLCs are quite complex, and this overview doesn't try to explain all of their intricacies. Rusty Russell's [overview](https://rusty.ozlabs.org/?p=462) explains more, and there's even more detail in his [Deployable Lightning](https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf) paper. But don't worry if some of the intricacies still escape you, particularly the interrelations of the two scripts.
 
 For the purposes of this tutorial, there are two important lessons for HTLCs:
 
@@ -291,6 +291,6 @@ Move on to "Using Tor" with [Chapter Fourteen: Using Tor](14_0_Using_Tor.md).
 
 Or, if you prefer, there are two alternate paths:
 
-If you want to stay focused on Bitcoin, move on to "Programming with RPC" with [Chapter Fifteen: Talking to Bitcoind with C](15_0_Talking_to_Bitcoind.md).
+If you want to stay focused on Bitcoin, move on to "Programming with RPC" with [Chapter Sixteen: Talking to Bitcoind with C](16_0_Talking_to_Bitcoind.md).
 
-Or, if you want to stay focused on the command-line because you're not a programmer, you can skip to [Chapter Eighteen: Understanding Your Lightning Seutp](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/18_0_Understanding_Your_Lightning_Setup.md) to continue your command-line education with the Lightning Network.
+Or, if you want to stay focused on the command-line because you're not a programmer, you can skip to [Chapter Nineteen: Understanding Your Lightning Setup](19_0_Understanding_Your_Lightning_Setup.md) to continue your command-line education with the Lightning Network.

14_1_Verifying_Your_Tor_Setup.md

@@ -6,13 +6,13 @@ If you did a standard installation with [Bitcoin Standup](https://github.com/Blo
 
 > :book: ***What is Tor?*** Tor is a low-latency anonymity and overlay network based on onion routing and path-building design for enabling anonymous communication. It's free and open-source software with the name derived from the acronym for the original software project name: "The Onion Router".
 
-> :book: ***Why Use Tor for Bitcoin?*** The Bitcoin network is a peer-to-peer network that listens for transactions and propagates them using a public IP address.  When connecting to the network not using Tor, you would share your IP address, which could expose your location, your uptime, and others details to third parties — which is an undesirable privacy practice. To protect yourself online you should use tools like Tor to hide your connection details. Tor allows improve your privacy online as your data is cryptographically encoded and goes through different nodes, each one decoding a single layer (hence the onion metaphor).
+> :book: ***Why Use Tor for Bitcoin?*** The Bitcoin network is a peer-to-peer network that listens for transactions and propagates them using a public IP address.  When connecting to the network not using Tor, you would share your IP address, which could expose your location, your uptime, and others details to third parties — which is an undesirable privacy practice. To protect yourself online you should use tools like Tor to hide your connection details. Tor allows you to improve your privacy online as your data is cryptographically encoded and goes through different nodes, each one decoding a single layer (hence the onion metaphor).
 
 ## Understand Tor
 
 So how does Tor work?
 
-When a user wants to connect to an Internet server, Tor tries to build a path formed by at least three Tor nodes relays, called Guard, Middle, and Exit. While building this path, symmetric encryption keys are negotiated; when a message moves along the path, each relay then strips off its layer of encryption. In this way, the message arrives at the final destination in its original form, and each party only knows the previous and the next hop and cannot determine origin or destination.
+When a user wants to connect to an Internet server, Tor tries to build a path formed by at least three Tor relay nodes, called Guard, Middle, and Exit. While building this path, symmetric encryption keys are negotiated; when a message moves along the path, each relay then strips off its layer of encryption. In this way, the message arrives at the final destination in its original form, and each party only knows the previous and the next hop and cannot determine origin or destination.
 
 Here's what a connection looks like without Tor:
 ```

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.

14_3_Adding_SSH_Hidden_Services.md

@@ -54,6 +54,6 @@ Now that you've got Tor installed and know how to use it, you can add other serv
 
 > :fire: ***What's the power of Other Hidden Services?*** Every time you access a service on your server remotely, you leave footprints on the network. Even if the data is encrypted by something like SSH (or TLS), lurkers on the network can see where you're connecting from, where you're connecting to, and what service you're using. Does this matter? This is the question you have to ask. But if the answer is "Yes", you can protect the connection with a hidden service.
 
-Move on to "Programming with RPC" with [Chapter Fifteen: Talking to Bitcoind with C](15_0_Talking_to_Bitcoind.md).
+## What's Next?
 
-Or, if you're not a programmer, you can skip to [Chapter Eighteen: Understanding Your Lightning Seutp](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/18_0_Understanding_Your_Lightning_Setup.md) to continue your command-line education with the Lightning Network.
+For a different sort of privacy, move on to "Using i2p" with [Chapter Fifteen: Using i2p](15_0_Using_i2p.md).

15_0_Using_i2p.md

@@ -0,0 +1,20 @@
+# Chapter 15: Using I2P
+
+There are alternatives to Tor. One is the Invisible Internet Project (I2P), a fully encrypted private network layer. It uses a distributed [network database](https://geti2p.net/en/docs/how/network-database) and encrypted unidirectional tunnels between peers. The biggest difference between Tor and I2P is that Tor is fundamentally a proxy network that offers internet services in a private form, while I2P is fundamentally a sequestered network that offers I2P services only to the I2P network, creating a "network within a network". However, you might just want it as an alternative, so that you're not dependent solely on Tor.
+
+I2P is not currently installed by [Bitcoin Standup](https://github.com/BlockchainCommons/Bitcoin-Standup-Scripts), as I2P support was recently added in Bitcoin Core. However, this chapter explains how to manually install it.
+
+## Objectives for This Chapter
+
+After working through this chapter, a developer will be able to:
+
+  * Run Bitcoin Core as an I2P (Invisible Internet Project) service
+
+Supporting objectives include the ability to:
+
+  * Understand the I2P Network
+  * Learn the difference between Tor and I2P
+
+## Table of Contents
+
+* [Section One: Bitcoin Core as an I2P (Invisible Internet Project) service](15_1_i2p_service.md)

15_1_i2p_service.md

@@ -0,0 +1,121 @@
+# 15.1: Bitcoin Core as an I2P (Invisible Internet Project) service
+
+> :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
+
+Rather than using the proxy-based Tor service to ensure the privacy of your Bitcoin communications, you may instead wish to use I2P, which is designed to act as a private network within the internet, rather than simply offering private access to internet services.
+
+## Understand the Differences
+
+Tor and I2P both offer private access to online services, but with different routing and databases, and with different architectures for relays. Since hidden services (such as Bitcoin access) are core to the design of I2P, they have also been better optimized:
+
+|  | Tor | I2P |
+| :---         |     :---:      |          ---: |
+| Routing   | [Onion](https://www.onion-router.net/)     | [Garlic](https://geti2p.net/en/docs/how/garlic-routing)    |
+| Network Database     | Trusted [Directory Servers](https://blog.torproject.org/possible-upcoming-attempts-disable-tor-network)       | [Distributed network database](https://geti2p.net/en/docs/how/network-database)      |
+| Relay     | **Two-way** encrypted connections between each Relay       | **One-way** connections between every server in its tunnels      |
+| Hidden services     | Slow       | Fast      |
+
+A more detailed comparison may be found at [geti2p.net](https://geti2p.net/en/comparison/tor).
+
+### Understand Tradeoffs for Limiting Outgoing Connections
+
+There are [tradeoffs](https://bitcoin.stackexchange.com/questions/107060/tor-and-i2p-tradeoffs-in-bitcoin-core) if you choose to support only I2P, only Tor, or both. These configurations, which limit outgoing clearnet connections, are made in Bitcoin Core using the `onlynet` argument in your `bitcoin.conf`.
+
+* `onlynet=onion`, which limits outgoing connections to Tor, can expose a node to Sybil attacks and can create network partitioning, because of limited connections between Tornet and the clearnet.
+* `onlynet=onion` and `onlynet=i2p` in conjunction, which runs Onion service with I2P service is experimental for now.
+
+## Install I2P
+
+To install I2P, you should make sure your ports are correctly set up and then you can continue with your setup process.
+
+### Prepare Ports
+
+To use I2P, you will need to open the following ports, which are required by I2P:
+
+1. **Outbound (Internet facing):** a random port between 9000 and 31000 is selected. It is best if all these ports are open for outbound connections, which doesn't affect your security. 
+- You can check firewall status using `sudo ufw status verbose`, which shouldn't deny outgoing connections by default.
+2. Inbound (Internet facing): optional. A variety of inbound ports are listed in the [I2P docs](https://geti2p.net/en/faq#ports).
+- For maximum privacy, it is preferable to disable accepting incoming connections.
+
+### Run I2P
+
+The following will run Bitcoin Core I2P services:
+
+1. Install `i2pd` on Ubuntu:
+
+   ```
+   sudo add-apt-repository ppa:purplei2p/i2pd
+   sudo apt-get update
+   sudo apt-get install i2pd
+   ```
+
+   For installing on other OSes, see [these docs](https://i2pd.readthedocs.io/en/latest/user-guide/install/)
+
+2. [Run](https://i2pd.readthedocs.io/en/latest/user-guide/run/) the I2P service:
+
+   ```
+   $ sudo systemctl start i2pd.service
+   ```
+
+3. Check that I2P is running. You should see it on port 7656:
+
+   ```
+   $ ss -nlt
+
+   State   Recv-Q   Send-Q     Local Address:Port      Peer Address:Port  Process
+
+   LISTEN  0        4096           127.0.0.1:7656           0.0.0.0:*
+   ```
+
+4. Add the following lines in `bitcoin.conf`: 
+
+   ```
+   i2psam=127.0.0.1:7656
+   debug=i2p
+   ```
+   The logging option, `debug=i2p`, is used to record additional information in the debug log about your I2P configuration and connections. The default location for this debugging file on Linux is: `~/.bitcoin/debug.log`:
+
+5. Restart `bitcoind`
+
+   ```
+   $ bitcoind
+   ```
+
+6. Check `debug.log` to see if I2P was setup correctly, or if any errors appeared in the logs.  
+   ```
+   2021-06-15T20:36:16Z i2paccept thread start
+   2021-06-15T20:36:16Z I2P: Creating SAM session with 127.0.0.1:7656
+
+   2021-06-15T20:36:56Z I2P: SAM session created: session id=3e0f35228b, my address=bmwyyuzyqdc5dcx27s4baltbu6zw7rbqfl2nmclt45i7ng3ul4pa.b32.i2p:18333
+   2021-06-15T20:36:56Z AddLocal(bmwyyuzyqdc5dcx27s4baltbu6zw7rbqfl2nmclt45i7ng3ul4pa.b32.i2p:18333,4)
+   ```
+   
+   The I2P address is mentioned in the logs, ending with _b32.i2p_. For example `bmwyyuzyqdc5dcx27s4baltbu6zw7rbqfl2nmclt45i7ng3ul4pa.b32.i2p:18333`.
+
+7. Confirm `i2p_private_key` was created in the Bitcoin Core data directory. The first time Bitcoin Core connects to the I2P router, its I2P address (and corresponding private key) will be automatically generated and saved in a file named *i2p_private_key*:
+   ```
+   ~/.bitcoin/testnet3$ ls
+
+   anchors.dat  chainstate         i2p_private_key  settings.json
+   banlist.dat  debug.log          mempool.dat      wallets
+   blocks       fee_estimates.dat  peers.dat
+   ```
+
+8. Check that `bitcoin-cli -netinfo` or `bitcoin-cli getnetworkinfo`returns the I2P address:
+
+   ```
+   Local addresses
+   bmwyyuzyqdc5dcx27s4baltbu6zw7rbqfl2nmclt45i7ng3ul4pa.b32.i2p     port  18333    score      4
+   ```
+  
+You now have your Bitcoin server accessible through the I2P network at your new local address.
+
+## Summary: Bitcoin Core as an I2P (Invisible Internet Project) service
+
+It is always good to have alternatives for privacy and not depend solely on Tor for running Bitcoin Core as a hidden service. Since I2P was recently added in Bitcoin Core, not many people use it. Experiment with it and report bugs if you find any issues.
+
+> :information_source: **NOTE:** For the official i2prouter implementation in Java, visit the [I2P download page](https://geti2p.net/en/download) and follow the instructions for your Operating System. Once installed, open a terminal window and type `i2prouter start`. Then visit `127.0.0.1:7657` in your browser to enable SAM. To do so, select: "Configure Homepage", then "Clients", and finally select the "Play Button" next to SAM application Bridge. On the left side of the page, there should be a green light next to "Shared Clients".
+
+Move on to "Programming with RPC" with [Chapter Sixteen: Talking to Bitcoind with C](16_0_Talking_to_Bitcoind.md).
+
+Or, if you're not a programmer, you can skip to [Chapter Nineteen: Understanding Your Lightning Setup](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/19_0_Understanding_Your_Lightning_Setup.md) to continue your command-line education with the Lightning Network.

16_0_Talking_to_Bitcoind.md

@@ -1,4 +1,4 @@
-# Chapter 15: Talking to Bitcoind with C
+# Chapter 16: Talking to Bitcoind with C
 
 While working with Bitcoin Scripts, we hit the boundaries of what's possible with `bitcoin-cli`: it can't currently be used to generate transactions containing unusual scripts. Shell scripts also aren't great for some things, such as creating listener programs that are constantly polling. Fortunately, there are other ways to access the Bitcoin network: programming APIs.
 
@@ -20,6 +20,6 @@ Supporting objectives include the ability to:
    
 ## Table of Contents
 
-  * [Section One: Accessing Bitcoind in C with RPC Libraries](15_1_Accessing_Bitcoind_with_C.md)
-  * [Section Two: Programming Bitcoind in C with RPC Libraries](15_2_Programming_Bitcoind_with_C.md)
-  * [Section Three: Receiving Notifications in C with ZMQ Libraries](15_3_Receiving_Bitcoind_Notifications_with_C.md)
+  * [Section One: Accessing Bitcoind in C with RPC Libraries](16_1_Accessing_Bitcoind_with_C.md)
+  * [Section Two: Programming Bitcoind in C with RPC Libraries](16_2_Programming_Bitcoind_with_C.md)
+  * [Section Three: Receiving Notifications in C with ZMQ Libraries](16_3_Receiving_Bitcoind_Notifications_with_C.md)

16_1_Accessing_Bitcoind_with_C.md

@@ -1,11 +1,13 @@
-# 15.1: Accessing Bitcoind in C with RPC Libraries
+# 16.1: Accessing Bitcoind in C with RPC Libraries
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
-You've already seen one alternative way to access the Bitcoind's RPC ports: `curl`, which was covered in a [Chapter 4 Interlude](04_4__Interlude_Using_Curl.md). Interacting with `bitcoind` through a RPC library in C is no different than that, you just need some good libraries to help you out. This section introduces a package called `libbitcoinrpc`, which allows you to access JSON-RPC `bitcoind` port.  It uses a `curl` library for accessing the data and it uses the `jansson` library for encoding and decoding the JSON.
+You've already seen one alternative way to access the Bitcoind's RPC ports: `curl`, which was covered in a [Chapter 4 Interlude](04_4__Interlude_Using_Curl.md). Interacting with `bitcoind` through an RPC library in C is no different than that, you just need some good libraries to help you out. This section introduces a package called `libbitcoinrpc`, which allows you to access JSON-RPC `bitcoind` port.  It uses a `curl` library for accessing the data and it uses the `jansson` library for encoding and decoding the JSON.
 
 ## 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
 
@@ -34,7 +36,7 @@ $ PATH="/sbin:$PATH"
 ```
 For an Ubuntu system, you'll also want to adjust the `INSTALL_LIBPATH` in the `libbitcoinrpc` `Makefile` to install to `/usr/lib` instead of `/usr/local/lib`:
 ```
-$ emacs ~/libbitcoinrpc/Makefile 
+$ emacs ~/libbitcoinrpc/Makefile
 ...
 INSTALL_LIBPATH    := $(INSTALL_PREFIX)/usr/lib
 ```
@@ -69,7 +71,7 @@ ln -fs libbitcoinrpc.so.0 .lib/libbitcoinrpc.so
 If that works, you can install the package:
 ```
 $ sudo make install
-Installing to 
+Installing to
 install .lib/libbitcoinrpc.so.0.2 /usr/local/lib
 ldconfig  -n /usr/local/lib
 ln -fs libbitcoinrpc.so.0 /usr/local/lib/libbitcoinrpc.so
@@ -106,9 +108,9 @@ First, initialize the library:
 ```
 bitcoinrpc_global_init();
 ```
-Then connect to your `bitcoind` with `bitcoinrpc_cl_init_params`. The four arguments for `bitcoinrpc_cl_init_params` are username, password, IP address, and port. You should already know all of this information from your work with [Curl](04_4__Interlude_Using_Curl.md). As you'll recall, the IP address 127.0.0.1 and port 18332 should be correct for the standard testnet setup described in this documents, while you can extract the user and password from `~/.bitcoin/bitcoin.conf`.
+Then connect to your `bitcoind` with `bitcoinrpc_cl_init_params`. The four arguments for `bitcoinrpc_cl_init_params` are username, password, IP address, and port. You should already know all of this information from your work with [Curl](04_4__Interlude_Using_Curl.md). As you'll recall, the IP address 127.0.0.1 and port 18332 should be correct for the standard testnet setup described in these documents, while you can extract the user and password from `~/.bitcoin/bitcoin.conf`.
 ```
-$ cat bitcoin.conf 
+$ cat bitcoin.conf
 server=1
 dbcache=1536
 par=1
@@ -147,12 +149,12 @@ bitcoinrpc_global_cleanup();
 
 ### Test the Test Code
 
-Test code can be found at [15_1_testbitcoin.c in the src directory](src/15_1_testbitcoin.c). Download it to your testnet machine, then insert the correct RPC password (and change the RPC user if you didn't create your server with StandUp).
+Test code can be found at [16_1_testbitcoin.c in the src directory](src/16_1_testbitcoin.c). Download it to your testnet machine, then insert the correct RPC password (and change the RPC user if you didn't create your server with StandUp).
 
 You can compile and run this as follows:
 ```
 $ cc testbitcoin.c -lbitcoinrpc -ljansson -o testbitcoin
-$ ./testbitcoin 
+$ ./testbitcoin
 Successfully connected to server!
 ```
 
@@ -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);
@@ -191,7 +193,7 @@ printf ("%s\n", json_dumps(j, JSON_INDENT(2)));
 ```
 However, since you're now writing complete programs, you probably want to do more subtle work, such as pulling out individual JSON values for specific usage. The [jansson Reference](https://jansson.readthedocs.io/en/2.10/apiref.html) details how to do so.
 
-Just as when you were using [Curl](04_4__Interlude_Using_Curl.md), you'll find that RPC returns a JSON object containing an `id`, an `error`, and most importantly a JSON object of the `result`. 
+Just as when you were using [Curl](04_4__Interlude_Using_Curl.md), you'll find that RPC returns a JSON object containing an `id`, an `error`, and most importantly a JSON object of the `result`.
 
 The `json_object_get` function will let you retrieve a value (such as the `result`) from a JSON object by key:
 ```
@@ -213,10 +215,10 @@ printf("Block Count: %d\n",blocks);
 
 ### Test the Info Code
 
-Retrieve the test code from [the src directory](15_1_getmininginfo.c).
+Retrieve the test code from [the src directory](src/16_1_getmininginfo.c).
 ```
 $ cc getmininginfo.c -lbitcoinrpc -ljansson -o getmininginfo
-$ ./getmininginfo 
+$ ./getmininginfo
 Full Response: {
   "result": {
     "blocks": 1804406,
@@ -243,11 +245,11 @@ Block Count: 1804406
 ```
 ## Make an RPC Call with Arguments
 
-But what if your RPC call _did_ have arguments? 
+But what if your RPC call _did_ have arguments?
 
 ### Create a JSON Array
 
-To send parameters to your RPC call using `libbitcoinrpc` you have to wrap them in a JSON array. Since an array is just a simple listing of values, all you have to do is encode the parameters as ordered elements in the array. 
+To send parameters to your RPC call using `libbitcoinrpc` you have to wrap them in a JSON array. Since an array is just a simple listing of values, all you have to do is encode the parameters as ordered elements in the array.
 
 Create the JSON array using the `json_array` function from `jansson`:
 ```
@@ -260,7 +262,7 @@ json_array_append_new(params,json_string(tx_rawhex));
 ```
 Note that there are two variants to the append command: `json_array_append_new`, which appends a newly created variable, and `json_array_append`, which appends an existing variable.
 
-This simple `json_array_append_new` methodology will serve for the majority of RPC commands with parameters, but some RPC commands require more complex inputs. In these cases you may need to create subsidiary JSON objects or JSON arrays, which you will then append to the parameters array as usual. The next section contains an example of doing so using `createrawtransaction`, which contains a JSON array of JSON objects for the inputs, a JSON object for the outputs, and the `locktime` parameter. 
+This simple `json_array_append_new` methodology will serve for the majority of RPC commands with parameters, but some RPC commands require more complex inputs. In these cases you may need to create subsidiary JSON objects or JSON arrays, which you will then append to the parameters array as usual. The next section contains an example of doing so using `createrawtransaction`, which contains a JSON array of JSON objects for the inputs, a JSON object for the outputs, and the `locktime` parameter.
 
 ### Assign the Parameters
 
@@ -278,4 +280,4 @@ By linking to the `bitcoinrpc` RPC and `jansson` JSON libraries, you can easily
 
 ## What's Next?
 
-Learn more about "Talking to Bitcoind with C" in [15.2: Programming Bitcoind in C with RPC Libraries](15_2_Programming_Bitcoind_with_C.md).
+Learn more about "Talking to Bitcoind with C" in [16.2: Programming Bitcoind in C with RPC Libraries](16_2_Programming_Bitcoind_with_C.md).

16_2_Programming_Bitcoind_with_C.md

@@ -1,8 +1,8 @@
-# 15.2: Programming Bitcoind in C with RPC Libraries
+# 16.2: Programming Bitcoind in C with RPC Libraries
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
-[§15.1](15_1_Accessing_Bitcoind_with_C.md) laid out the methodology for creating C programs using RPC and JSON libraries. We're now going to show the potential of those C libraries by laying out a simplistic, first cut of an actual Bitcoin program.
+[§16.1](16_1_Accessing_Bitcoind_with_C.md) laid out the methodology for creating C programs using RPC and JSON libraries. We're now going to show the potential of those C libraries by laying out a simplistic, first cut of an actual Bitcoin program.
 
 ## Plan for Your Code
 
@@ -55,7 +55,7 @@ printf("Sending %4.8f BTC to %s\n",tx_amount,tx_recipient);
 
 ### Step 2: Set an Arbitrary Fee
 
-This example just an arbitrary0.0005 BTC fee to ensure that the test transactions goes through quickly:
+This example just an arbitrary 0.0005 BTC fee to ensure that the test transactions goes through quickly:
 ```
 float tx_fee = 0.0005;
 float tx_total = tx_amount + tx_fee;
@@ -65,7 +65,7 @@ float tx_total = tx_amount + tx_fee;
 
 ### Step 3: Prepare Your RPC 
 
-Obviously, you're going to need to get all of your variables ready again, as discussed in [§15.1: Accessing Bitcoind with C](15_1_Accessing_Bitcoind_with_C.md). You also need to initialize your library, connect your RPC client, and prepare your response object:
+Obviously, you're going to need to get all of your variables ready again, as discussed in [§16.1: Accessing Bitcoind with C](16_1_Accessing_Bitcoind_with_C.md). You also need to initialize your library, connect your RPC client, and prepare your response object:
 ```
 bitcoinrpc_global_init();
 rpc_client = bitcoinrpc_cl_init_params ("bitcoinrpc", "YOUR-RPC-PASSWD", "127.0.0.1", 18332);
@@ -324,7 +324,7 @@ The entire code, with a _little_ more error-checking appears in the Appendix.
 
 ## Test Your Code
 
-The complete code can be found in the [src directory](src/15_2_sendtoaddress.c).
+The complete code can be found in the [src directory](src/16_2_sendtoaddress.c).
 
 Compile this as usual:
 ```
@@ -344,4 +344,4 @@ With access to a C library, you can create much more fully featured programs tha
 
 ## What's Next?
 
-Learn more about "Talking to Bitcoind with C" in [15.3: Receiving Notifications in C with ZMQ Libraries](15_3_Receiving_Bitcoind_Notifications_with_C.md).
+Learn more about "Talking to Bitcoind with C" in [16.3: Receiving Notifications in C with ZMQ Libraries](16_3_Receiving_Bitcoind_Notifications_with_C.md).

16_3_Receiving_Bitcoind_Notifications_with_C.md

@@ -1,8 +1,8 @@
-# 15.3 Receiving Notifications in C with ZMQ  Libraries
+# 16.3 Receiving Notifications in C with ZMQ  Libraries
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
-[§15.1](15_1_Accessing_Bitcoind_with_C.md) and [§15.2](15_2_Programming_Bitcoind_with_C.md) introduced RPC and JSON libraries for C, and in doing so showed one of the advantages of accessing Bitcoin's RPC commands through a programming language: the ability to reasonably create much more complex programs. This chapter introduces a third library, for [ZMQ](http://zeromq.org/), and in doing so reveals another advantage: the ability to monitor for notifications. It will use that for coding a blockchain listener.
+[§16.1](16_1_Accessing_Bitcoind_with_C.md) and [§16.2](16_2_Programming_Bitcoind_with_C.md) introduced RPC and JSON libraries for C, and in doing so showed one of the advantages of accessing Bitcoin's RPC commands through a programming language: the ability to reasonably create much more complex programs. This chapter introduces a third library, for [ZMQ](http://zeromq.org/), and in doing so reveals another advantage: the ability to monitor for notifications. It will use that for coding a blockchain listener.
 
 > :book: ***What is ZMQ?*** ZeroMQ (ZMQ)is a high-performance asynchronous messaging library that provides a message queue.  ZeroMQ supports common messaging patterns (pub/sub, request/reply, client/server, and others) over a variety of transports (TCP, in-process, inter-process, multicast, WebSocket, and more), making inter-process messaging as simple as inter-thread messaging. You can find more details about ZMQ notifications and others kind of messages in [this repo](https://github.com/Actinium-project/ChainTools/blob/master/docs/chainlistener.md).
 
@@ -121,7 +121,7 @@ Of course when you're done, you should clean up:
 
 ### Test the Notification Code
 
-The source code is in the [src directory](src/15_3_chainlistener.c) as usual. You should compile it:
+The source code is in the [src directory](src/16_3_chainlistener.c) as usual. You should compile it:
 ```
 $ cc -o chainlistener chainlistener.c -I/usr/local/include -L/usr/local/lib -lzmq -lczmq
 ```
@@ -151,7 +151,7 @@ By using the ZMQ framework, you can easily receive notifications by subscribing
 
 ## What's Next?
 
-Learn more about "Programming with RPC" in [Chapter 16: Programming Bitcoin with Libwally](16_0_Programming_with_Libwally.md).
+Learn more about "Programming with RPC" in [Chapter 17: Programming Bitcoin with Libwally](17_0_Programming_with_Libwally.md).
 
 
 

17_0_Programming_with_Libwally.md

@@ -1,8 +1,8 @@
-# Chapter 16: Programming with Libwally
+# Chapter 17: Programming with Libwally
 
 The previous chapter presented three C Libraries, for RPC, JSON, and ZMQ, all of which are intended to interact directly with `bitcoind`, just like you've been doing since the start. But, sometimes you might want to code without direct access to a `bitcoind`. This might be due to an offline client, or just because you want to keep some functionality internal to your C program. You also might want to get into deeper wallet functionality, like mnemonic word creation or address derivation. That's where Libwally comes in: it's a wallet library for C, C++, Java, NodeJS, or Python, with wrappers also available for other languages, such as Swift.
 
-This chapter touches upon the functionality possible within Libwally, most of which complements the work you've done through RPC access to `bitcoind`, but some of which replicates it. It also shows how to integrate that work with the RPC clients that you're more familiar with. However, note that this is just the barest introduction to Libwally. Several of its more improtant function sets are highlighted, but we never do more than stick our toes in. If you find its functions useful or intriguing, then you'll need to dig in much more deeply than this course can cover.
+This chapter touches upon the functionality possible within Libwally, most of which complements the work you've done through RPC access to `bitcoind`, but some of which replicates it. It also shows how to integrate that work with the RPC clients that you're more familiar with. However, note that this is just the barest introduction to Libwally. Several of its more important function sets are highlighted, but we never do more than stick our toes in. If you find its functions useful or intriguing, then you'll need to dig in much more deeply than this course can cover.
 
 ## Objectives for This Chapter
 
@@ -20,10 +20,10 @@ Supporting objectives include the ability to:
    
 ## Table of Contents
 
-  * [Section One: Setting Up Libwally](16_1_Setting_Up_Libwally.md)
-  * [Section Two: Using BIP39 in Libwally](16_2_Using_BIP39_in_Libwally.md)
-  * [Section Three: Using BIP32 in Libwally](16_3_Using_BIP32_in_Libwally.md)
-  * [Section Four: Using PSBTs in Libwally](16_4_Using_PSBTs_in_Libwally.md) 
-  * [Section Five: Using Scripts in Libwally](16_5_Using_Scripts_in_Libwally.md)
-  * [Section Six: Using Other Functions in Libwally](16_6_Using_Other_Functions_in_Libwally.md)
-  * [Section Seven: Integrating Libwally and Bitcoin-CLI](16_7_Integrating_Libwally_and_Bitcoin-CLI.md)
+  * [Section One: Setting Up Libwally](17_1_Setting_Up_Libwally.md)
+  * [Section Two: Using BIP39 in Libwally](17_2_Using_BIP39_in_Libwally.md)
+  * [Section Three: Using BIP32 in Libwally](17_3_Using_BIP32_in_Libwally.md)
+  * [Section Four: Using PSBTs in Libwally](17_4_Using_PSBTs_in_Libwally.md) 
+  * [Section Five: Using Scripts in Libwally](17_5_Using_Scripts_in_Libwally.md)
+  * [Section Six: Using Other Functions in Libwally](17_6_Using_Other_Functions_in_Libwally.md)
+  * [Section Seven: Integrating Libwally and Bitcoin-CLI](17_7_Integrating_Libwally_and_Bitcoin-CLI.md)

17_1_Setting_Up_Libwally.md

@@ -1,4 +1,4 @@
-# 16.1: Setting Up Libwally
+# 17.1: Setting Up Libwally
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
@@ -129,7 +129,7 @@ In both cases, the argument is for flags, but is currently set to `0`.
 
 ## Test a Test Libwally Program
 
-The src directory contains [testwally.c](src/16_1_testwally.c), which just shows how the initialize and cleanup functions work.
+The src directory contains [testwally.c](src/17_1_testwally.c), which just shows how the initialize and cleanup functions work.
 
 You can compile it as follows:
 ```
@@ -186,12 +186,12 @@ This course will only use `libsodium` for one small (but crucial!) bit of entrop
 
 ## Summary: Setting Up Libwally
 
-By installing the Libwally (and Libsodium) includes and libraries, you gain access to a number of cryptographic and wallet functions, which can complement your RPC and ZMG libraries (or your command-line `bitcoin-cli`).
+By installing the Libwally (and Libsodium) includes and libraries, you gain access to a number of cryptographic and wallet functions, which can complement your RPC and ZMQ libraries (or your command-line `bitcoin-cli`).
 
 So what precisely can you do now? That's what the rest of this chapter is about.
 
 ## What's Next?
 
-Learn more about "Programming Bitcoin with Libwally" in [16.2: Using BIP39 in Libwally](16_2_Using_BIP39_in_Libwally.md).
+Learn more about "Programming Bitcoin with Libwally" in [17.2: Using BIP39 in Libwally](17_2_Using_BIP39_in_Libwally.md).
 
 

17_2_Using_BIP39_in_Libwally.md

@@ -1,4 +1,4 @@
-# 16.2: Using BIP39 in Libwally
+# 17.2: Using BIP39 in Libwally
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
@@ -14,7 +14,7 @@ All Bitcoin keys start with entropy. This first use of Libwally, and its BIP39 m
 
 > :book: ***What is Entropy?*** Entropy is a fancy way of saying randomness, but it's a carefully measured randomness that's used as the foundation of a true-random-number generated (TRG). Its measured in "bits", with more bits of entropy resulting in more randomness (and thus more protection for what's being generated). For Bitcoin, entropy is the foundation of your seed, which in an HD wallet generates all of your addresses.
 
-You'll always start work with Libwally by initializing the library and testing the results, as first demonstrated in [§16.1](16_1_Setting_Up_Libwally.md):
+You'll always start work with Libwally by initializing the library and testing the results, as first demonstrated in [§17.1](17_1_Setting_Up_Libwally.md):
 ```
   int lw_response;
 
@@ -57,7 +57,7 @@ That's it! You've created a mnemonic phrase!
 
 ### Translate into a Seed
 
-There are some functions, such as `bip32_key_from_seed` (which we'll meet in the next section) that require you to have theseeddeed rather than the Mnemonic. The two things are functionally identical: if you have the seed, you can generate the mnemonic, and vice-versa.
+There are some functions, such as `bip32_key_from_seed` (which we'll meet in the next section) that require you to have the seed rather than the Mnemonic. The two things are functionally identical: if you have the seed, you can generate the mnemonic, and vice-versa.
 
 If you need to generate the seed from your mnemonic, you just use the `bip39_mnemonic_to_seed` command:
 ```
@@ -82,7 +82,7 @@ If you've done everything right, you should get back a 64-byte seed. (That's the
 
 ## Test Mnemonic Code
 
-The full code for generating entropy, generating a BIP39 mnemonic, validating the mnemonic, and generating a seed can be found in the [src directory](src/16_2_genmnemonic.c). Download it and compile:
+The full code for generating entropy, generating a BIP39 mnemonic, validating the mnemonic, and generating a seed can be found in the [src directory](src/17_2_genmnemonic.c). Download it and compile:
 ```
 $ cc genmnemonic.c -lwallycore -lsodium -o genmnemonic
 ```
@@ -99,8 +99,8 @@ BIP39 allows you generate a set of 12-24 Mnemonic words from a seed (and the Lib
 
 > :fire: ***What is the power of BIP39?*** Bitcoin seeds and private keys are prone to all sorts of lossage. You mistype a single digit, and your money is gone forever. Mnemonic Words are a much more user-friendly way of representing the same data, but because they're words in the language of the user's choice, they're less prone to mistakes. The power of BIP39 is thus to improve the accessibility, usability, and safety of Bitcoin.
 
-> :fire: ***What is the power of BIP39 in Libwally?*** Bitcoind doesn't currently support mnemonic words, so using Libwally can allow you to generate mnemonic words in conjunction with addresses held by `bitcoind` (though as we'll see in §16.7, it requires a bit of a work-around at present to import your keys into Bitcoin Core).
+> :fire: ***What is the power of BIP39 in Libwally?*** Bitcoind doesn't currently support mnemonic words, so using Libwally can allow you to generate mnemonic words in conjunction with addresses held by `bitcoind` (though as we'll see in §17.7, it requires a bit of a work-around at present to import your keys into Bitcoin Core).
 
 ## What's Next?
 
-Learn more about "Programming Bitcoin with Libwally" in [16.3: Using BIP32 in Libwally](16_3_Using_BIP32_in_Libwally.md).
+Learn more about "Programming Bitcoin with Libwally" in [17.3: Using BIP32 in Libwally](17_3_Using_BIP32_in_Libwally.md).

17_3_Using_BIP32_in_Libwally.md

@@ -1,15 +1,15 @@
-# 16.3: Using BIP32 in Libwally
+# 17.3: Using BIP32 in Libwally
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
-In [§16.2](16_2_Using_BIP39_in_Libwally.md), you were able to use entropy to generate a seed and its related mnemonic. As you may recall from [§3.5: Understanding the Descriptor](03_5_Understanding_the_Descriptor.md), a seed is the basis of a Hierchical Deterministic (HD) Wallet, where that single seed can be used to generate many addresses. So how do you get from the seed to actual addresses? That's where [BIP32](https://en.bitcoin.it/wiki/BIP_0032) comes in.
+In [§17.2](17_2_Using_BIP39_in_Libwally.md), you were able to use entropy to generate a seed and its related mnemonic. As you may recall from [§3.5: Understanding the Descriptor](03_5_Understanding_the_Descriptor.md), a seed is the basis of a Hierchical Deterministic (HD) Wallet, where that single seed can be used to generate many addresses. So how do you get from the seed to actual addresses? That's where [BIP32](https://en.bitcoin.it/wiki/BIP_0032) comes in.
 
 ## Create an HD Root
 
 To create a HD address requires starting with a seed, and then walking down the hierarchy until the point that you create addresses.
 
 That starts off easily enough, you just generate a seed, which you already did in the previous section:
-```
+```c
   unsigned char entropy[16];  
   randombytes_buf(entropy, 16);
 
@@ -23,7 +23,7 @@ That starts off easily enough, you just generate a seed, which you already did i
 ### Generate a Root Key
 
 With a seed in hand, you can then generate a master extended key with the `bip32_key_from_seed_alloc` function (or alternatively the `bip32_key_from_seed`, which doesn't do the `alloc`):
-```
+```c
   struct ext_key *key_root;  
   lw_response = bip32_key_from_seed_alloc(seed,sizeof(seed),BIP32_VER_TEST_PRIVATE,0,&key_root);
 ```
@@ -34,7 +34,7 @@ As you can see, you'll need to tell it what version of the key to return, in thi
 ### Generate xpub & xprv
 
 Whenever you have a key in hand, you can turn it into xpub or xprv keys for distribution with the `bip32_key_to_base58` command. You just tell it whether you want a `PRIVATE` (xprv) or `PUBLIC` (xpub) key:
-```
+```c
   char *xprv;
   lw_response = bip32_key_to_base58(key_root, BIP32_FLAG_KEY_PRIVATE, &xprv);
 
@@ -44,7 +44,7 @@ Whenever you have a key in hand, you can turn it into xpub or xprv keys for dist
 
 ## Understand the Hierarchy
 
-Before going further, you need to understand how the hierarchy of an HD wallet works. As discussed in [§3.5](03_5_Understanding_the_Descriptor.md), a derivation path describes the tree that you follow to get to a hierarchical key, so `[0/1/0]` is the 0th child of the 1st child of the 0th child of a root key. Sometimes part of that derivation are marked with `'`s or `h`s to show "hardened derivations, which increase security: `[0'/1'/0']`.
+Before going further, you need to understand how the hierarchy of an HD wallet works. As discussed in [§3.5](03_5_Understanding_the_Descriptor.md), a derivation path describes the tree that you follow to get to a hierarchical key, so `[0/1/0]` is the 0th child of the 1st child of the 0th child of a root key. Sometimes part of that derivation are marked with `'`s or `h`s to show hardened derivations, which increase security: `[0'/1'/0']`.
 
 However, for HD wallets, each of those levels of the hierachy is used in a very specific way. This was originally defined in [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) and was later updated for Segwit in [BIP84].
 
@@ -71,18 +71,18 @@ To generate an address, you thus have to dig down through the whole hierarchy.
 ### Generate an Account Key
 
 One way to do this is to use the `bip32_key_from_parent_path_alloc` function to drop down several levels of a hierarchy. You embed the levels in an array:
-```
+```c
   uint32_t path_account[] = {BIP32_INITIAL_HARDENED_CHILD+84, BIP32_INITIAL_HARDENED_CHILD+1, BIP32_INITIAL_HARDENED_CHILD};
 ```
 Here we'll be looking at the zeroth hardened child (that's the account) or the first hardened child (that's testnet coins) of the 84th hardened child (that's the BIP84 standard): `[m/84'/1'/0']`.
 
 You can then use that path to generate a new key from your old key:
-```
+```c
   struct ext_key *key_account;
   lw_response = bip32_key_from_parent_path_alloc(key_root,path_account,sizeof(path_account),BIP32_FLAG_KEY_PRIVATE,&key_account);
 ```
 Every time you have a new key, you can use that to generate new xprv and xpub keys, if you desire:
-```
+```c
   lw_response = bip32_key_to_base58(key_account, BIP32_FLAG_KEY_PRIVATE, &a_xprv);
   lw_response = bip32_key_to_base58(key_account, BIP32_FLAG_KEY_PUBLIC, &a_xpub);
 ```
@@ -90,19 +90,19 @@ Every time you have a new key, you can use that to generate new xprv and xpub ke
 ### Generate an Address Key
 
 Alternatively, you can use the `bip32_key_from_parent_alloc` function, which just drops down one level of the hierarchy at a time. The following example drops down to the 0th child of the account key (which is the external address) and then the 0th child of that. This would be useful because then you could continue generating the 1st address, the 2nd address, and so on from that external key:
-```
+```c
   struct ext_key *key_external;  
   lw_response = bip32_key_from_parent_alloc(key_account,0,BIP32_FLAG_KEY_PRIVATE,&key_external);
 
   struct ext_key *key_address;  
   lw_response = bip32_key_from_parent_alloc(key_external,0,BIP32_FLAG_KEY_PRIVATE,&key_address);
 ```
-> :warning: **WARNING::** At some point in this hierarchy, you might decide to generate `BIP32_FLAG_KEY_PUBLIC` instead of `BIP32_FLAG_KEY_PRIVATE`. Obviously this decision will be based on your security and your needs, but remember that you only need a public key to generate the actual address.
+> :warning: **WARNING:** At some point in this hierarchy, you might decide to generate `BIP32_FLAG_KEY_PUBLIC` instead of `BIP32_FLAG_KEY_PRIVATE`. Obviously this decision will be based on your security and your needs, but remember that you only need a public key to generate the actual address.
 
 ### Generate an Address
 
 Finally, you're ready to generate an address from your final key. All you do is run `wally_bip32_to_addr_segwit` using your final key and a description of what sort of address this is.
-```
+```c
   char *segwit;
   lw_response = wally_bip32_key_to_addr_segwit(key_address,"tb",0,&segwit);
 
@@ -115,7 +115,7 @@ There is also a `wally_bip32_key_to_address` function, which can be used to gene
 
 ## Test HD Code
 
-The code for these HD example can, as usual, be found in the [src directory](src/16_3_genhd.c).
+The code for these HD example can, as usual, be found in the [src directory](src/17_3_genhd.c).
 
 You can compile and test it:
 ```
@@ -139,4 +139,4 @@ An HD wallet allows you to generate a vast number of keys from a single seed. Yo
 
 ## What's Next?
 
-Learn more about "Programming Bitcoin with Libwally" in [16.4: Using PSBTs in Libwally](16_4_Using_PSBTs_in_Libwally.md).
+Learn more about "Programming Bitcoin with Libwally" in [17.4: Using PSBTs in Libwally](17_4_Using_PSBTs_in_Libwally.md).

17_4_Using_PSBTs_in_Libwally.md

@@ -1,4 +1,4 @@
-# 16.4: Using PSBTs in Libwally
+# 17.4: Using PSBTs in Libwally
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
@@ -116,7 +116,7 @@ Obviously, there's a lot more you could look at in the PSBTs. In fact, looking i
 
 ### Test Your PSBT Reader
 
-Again, the code for this (extremely rudimentary and specific) PSBT reader is in the [src directory](src/16_4_examinepsbt.c). 
+Again, the code for this (extremely rudimentary and specific) PSBT reader is in the [src directory](src/17_4_examinepsbt.c). 
 
 You can compile it as normal:
 ```
@@ -289,7 +289,7 @@ But what you have is not yet a legal PSBT, because of the lack of inputs. You ca
 ```
 ### Test Your PSBT Creation
 
-At this point, you should have an empty, but working PSBT, which you can see by compiling and running [the program](src/16_4_createemptypsbt.c).
+At this point, you should have an empty, but working PSBT, which you can see by compiling and running [the program](src/17_4_createemptypsbt.c).
 ```
 $ cc createemptypsbt.c -lwallycore -o createemptypsbt
 $ ./createemptypsbt 
@@ -373,4 +373,4 @@ This section could be an entire chapter, as working with PSBTs at a low level is
 
 ## What's Next?
 
-Learn more about "Programming Bitcoin with Libwally" in [16.5: Using Scripts in Libwally](16_5_Using_Scripts_in_Libwally.md).
+Learn more about "Programming Bitcoin with Libwally" in [17.5: Using Scripts in Libwally](17_5_Using_Scripts_in_Libwally.md).

17_5_Using_Scripts_in_Libwally.md

@@ -1,4 +1,4 @@
-# 16.5: Using Scripts in Libwally
+# 17.5: Using Scripts in Libwally
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
@@ -82,7 +82,7 @@ One more command adds it to your transaction:
 
 Creating the input is much harder because you have to pile information into the creation routines, not all of which is intuitively accessible when you're using Libwally. So, rather than going that deep into the weeds, here's where we take our shortcut. We write our code so that it's passed the hex code for a transaction that's already been created, and then we just reuse the input.
 
-The conversion from the hex code is done with `wally_tx_from_hex:
+The conversion from the hex code is done with `wally_tx_from_hex`:
 ```
   struct wally_tx *utxo;
   lw_response = wally_tx_from_hex(utxo_hex,0,&utxo);
@@ -98,7 +98,7 @@ As you might expect, you then add that input to your transaction:
   lw_response = wally_tx_add_input(tx,tx_input);
 ```
 
-> **NOTE** Obviously, you'll want to be able to create your own inputs if you're using Libwally for real applications, but this is intended as a first step. And, it can actually be useful for integrating with `bitcoin-cli`, as we'll see in [§16.7](16_7_Integrating_Libwally_and_Bitcoin-CLI.md).
+> **NOTE** Obviously, you'll want to be able to create your own inputs if you're using Libwally for real applications, but this is intended as a first step. And, it can actually be useful for integrating with `bitcoin-cli`, as we'll see in [§16.7](17_7_Integrating_Libwally_and_Bitcoin-CLI.md).
 
 ### Print a Transaction
 
@@ -113,7 +113,7 @@ We'll show how to make use of that in §16.7.
 
 ## Test Your Replacement Script
 
-You can grab the test code from the [src directory](src/16_5_replacewithscript.c) and compile it:
+You can grab the test code from the [src directory](src/17_5_replacewithscript.c) and compile it:
 ```
 $  cc replacewithscript.c -lwallycore -o replacewithscript
 ```
@@ -177,4 +177,4 @@ Creating transactions in Libwally is another topic that could take up a whole ch
 
 ## What's Next?
 
-Learn more about "Programming Bitcoin with Libwally" in [§16.6: Using Other Functions in Libwally](16_6_Using_Other_Functions_in_Libwally.md).  
+Learn more about "Programming Bitcoin with Libwally" in [§17.6: Using Other Functions in Libwally](17_6_Using_Other_Functions_in_Libwally.md).

17_6_Using_Other_Functions_in_Libwally.md

@@ -1,4 +1,4 @@
-# 16.6: Using Other Functions in Libwally
+# 17.6: Using Other Functions in Libwally
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
@@ -45,7 +45,7 @@ Some relate to the wallet import format (WIF):
    
 ## Use BIP32 Functions
 
-There are additional BIP32 HD-wallet functions, beyond what was covered in [§16.3: Using BIP32 in Libwally](16_3_Using_BIP32_in_Libwally.md).
+There are additional BIP32 HD-wallet functions, beyond what was covered in [§17.3: Using BIP32 in Libwally](17_3_Using_BIP32_in_Libwally.md).
 
    * `bip32_key_get_fingerprint` — Generate a BIP32 fingerprint for an extended key
    * `bip32_key_serialize` — Transform an extended key into serialized bytes
@@ -65,7 +65,7 @@ The main functions are:
    
 ## Use BIP39 Functions
 
-A few BIP39 mnemonic-word functions were just overviewed in [§16.2: Using BIP39 in Libwally](16_2_Using_BIP39_in_Libwally.md):
+A few BIP39 mnemonic-word functions were just overviewed in [§17.2: Using BIP39 in Libwally](17_2_Using_BIP39_in_Libwally.md):
 
    * `bip39_get_languages` — See a list of supported languages
    * `bit39_get_word` — Retrieve a specific word from a language's word list
@@ -73,11 +73,11 @@ A few BIP39 mnemonic-word functions were just overviewed in [§16.2: Using BIP39
    
 ## Use PSBT Functions
 
-Listings of most PSBT functions can be found in [16.4: Using PSBTs in Libwally](16_4_Using_PSBTs_in_Libwally.md).
+Listings of most PSBT functions can be found in [17.4: Using PSBTs in Libwally](17_4_Using_PSBTs_in_Libwally.md).
 
 ## Use Script Functions
 
-[§16.5: Using Scripts in Libwally](16_5_Using_Scripts_in_Libwally.md) just barely touched upon Libwally's Scripts functions.
+[§17.5: Using Scripts in Libwally](17_5_Using_Scripts_in_Libwally.md) just barely touched upon Libwally's Scripts functions.
 
 There's another function that lets you determine the sort of script found in a transaction:
 
@@ -102,7 +102,7 @@ Then there are a slew of functions that create `scriptPubKey` from bytes, `scrip
 
 ## Use Transaction Functions
 
-We also just barely touched upon the functions that can be used to create and convert functions in [§16.5](16_5_Using_Scripts_in_Libwally.md).
+We also just barely touched upon the functions that can be used to create and convert functions in [§17.5](17_5_Using_Scripts_in_Libwally.md).
 
 There are numerous informational functions, some of the more interesting of which are:
 
@@ -122,6 +122,6 @@ There is much more that you can do with Libwally, more than can be covered in th
 
 ## What's Next?
 
-Finish learning about "Programming Bitcoin with Libwally" in [§16.7: Integrating Libwally and Bitcoin-CLI](16_7_Integrating_Libwally_and_Bitcoin-CLI.md).  
+Finish learning about "Programming Bitcoin with Libwally" in [§17.7: Integrating Libwally and Bitcoin-CLI](17_7_Integrating_Libwally_and_Bitcoin-CLI.md).  
 
 

17_7_Integrating_Libwally_and_Bitcoin-CLI.md

@@ -1,4 +1,4 @@
-# 16.7: Integrating Libwally and Bitcoin-CLI
+# 17.7: Integrating Libwally and Bitcoin-CLI
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
@@ -8,7 +8,7 @@ This final section will offer some examples of using Libwally programs to comple
 
 ## Share a Transaction
 
-[§16.5: Using Scripts in Libwally](16_5_Using_Scripts_in_Libwally.md) detailed how Libwally could be used to rewrite an existing transaction, to do something that `bitcoin-cli` can't: produce a transaction that contains a unique P2SH. Obviously, this is a building block; if you decide to dig further into Libwally you'll create entire transactions on your own. But, this abbreviated methodology also has its own usage: it shows how transactions can be passed back and forth between `bitcoin-cli` and Libwally, demonstrating a first example of using them in a complementary fashion.
+[§17.5: Using Scripts in Libwally](17_5_Using_Scripts_in_Libwally.md) detailed how Libwally could be used to rewrite an existing transaction, to do something that `bitcoin-cli` can't: produce a transaction that contains a unique P2SH. Obviously, this is a building block; if you decide to dig further into Libwally you'll create entire transactions on your own. But, this abbreviated methodology also has its own usage: it shows how transactions can be passed back and forth between `bitcoin-cli` and Libwally, demonstrating a first example of using them in a complementary fashion.
 
 To fully demonstrate this methodology, you'll create a transaction with `bitcoin-cli`, using this UTXO:
 ```
@@ -33,7 +33,7 @@ $ utxo_vout=$(bitcoin-cli listunspent | jq -r '.[0] | .vout')
 $ recipient=tb1qycsmq3jas5wkhf8xrfn8k7438cm5pc8h9ae2k0
 $ rawtxhex=$(bitcoin-cli -named createrawtransaction inputs='''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout' } ]''' outputs='''{ "'$recipient'": 0.0009 }''')
 ```
-Though you placed a recipient and an amount in the output, it's irrelevent, because you'll be rewriting those. A fancier bit of code could read the existing `vout` info before rewriting, but we're keeping things very close to our [original code](src/16_5_replacewithscript.c).
+Though you placed a recipient and an amount in the output, it's irrelevent, because you'll be rewriting those. A fancier bit of code could read the existing `vout` info before rewriting, but we're keeping things very close to our [original code](src/17_5_replacewithscript.c).
 
 Here's the one change necessary, to allow you to specify the satoshi `vout`, without having to hardcode it, as in the original:
 ```
@@ -170,7 +170,7 @@ $ bitcoin-cli decoderawtransaction $signedtx
 ```
 Voila! That's the power of Libwally with `bitcoin-cli`.
 
-Obviously, you can also pass around a PSBT using the functions described in [§16.4](16_4_Using_PSBTs_in_Libwally.md) and that's a more up-to-date methodology for the modern-day usage of Bitcoin, but in either example, the concept of passing transactions from `bitcoin-cli` to Libwally code and back should be similar.
+Obviously, you can also pass around a PSBT using the functions described in [§17.4](17_4_Using_PSBTs_in_Libwally.md) and that's a more up-to-date methodology for the modern-day usage of Bitcoin, but in either example, the concept of passing transactions from `bitcoin-cli` to Libwally code and back should be similar.
 
 ## Import & Export BIP39 Seeds
 
@@ -178,11 +178,11 @@ Unfortunately, not all interactions between Libwally and `bitcoin-cli` go as smo
 
 > :book: ***What's the Difference Between Entropy & a Seed?*** Libwally says that it creates its mnemonic phrases from entropy. That's essentially the same thing as a seed: they're both large, randomized numbers. So, if `bitcoin-cli` was compatible with 512-bit mnemonic-phrase seeds, you could use one to generate the mneomnic phrases, and get the results that you'd expect.
 
-> :book: ***What's the difference between Entropy & Raw Entropy?*** Not all entropy is the same. When you input entropy into a command that creates a mnemonic seed, it has to a specific, well-understand length. Changing raw entropy into entropy requires massaging the raw entropy until it's the right length and format, and at that point you could reuse that (non-raw) entropy to always recreate the same mnemonics (which is why entropy is effectively the same thing as a seed at that point, but raw entropy isn't).
+> :book: ***What's the difference between Entropy & Raw Entropy?*** Not all entropy is the same. When you input entropy into a command that creates a mnemonic seed, it has to a specific, well-understood length. Changing raw entropy into entropy requires massaging the raw entropy until it's the right length and format, and at that point you could reuse that (non-raw) entropy to always recreate the same mnemonics (which is why entropy is effectively the same thing as a seed at that point, but raw entropy isn't).
 
 ## Import Private Keys
 
-Fortunately, you can do much the same thing by importing a private key generated in Libwally. Take a look at [genhd-for-import.c](src/16_7_genhd_for_import.c), a simplified version of the `genhd` program from [§16.3](16_3_Using_BIP32_in_Libwally.md) that also uses the `jansson` library from [§15.1](15_1_Accessing_Bitcoind_with_C.md) for regularized output.
+Fortunately, you can do much the same thing by importing a private key generated in Libwally. Take a look at [genhd-for-import.c](src/17_7_genhd_for_import.c), a simplified version of the `genhd` program from [§17.3](17_3_Using_BIP32_in_Libwally.md) that also uses the `jansson` library from [§16.1](15_1_Accessing_Bitcoind_with_C.md) for regularized output.
 
 The updated code also contains one change of note: it requests a fingerprint from Libwally so that it can properly create a derivation path:
 ```
@@ -195,7 +195,7 @@ The updated code also contains one change of note: it requests a fingerprint fro
 
 > :warning: **WARNING:** Remember that the fingerprint in derivation paths is arbitrary. Because Libwally provides one, we're using it, but if you didn't have one, you could add an arbitrary 4-byte hexcode as a fingerprint to your derivation path.
 
-Be sure to compile the new code with the `jansson` library, after installing it (if necessary) per [§15.1](15_1_Accessing_Bitcoind_with_C.md).
+Be sure to compile the new code with the `jansson` library, after installing it (if necessary) per [§16.1](15_1_Accessing_Bitcoind_with_C.md).
 ```
 $ cc genhd-for-import.c -lwallycore -lsodium -ljansson -o genhd-for-import
 ```
@@ -327,4 +327,4 @@ With a foundational knowledge of Libwally, you can now complement all of the wor
 
 ## What's Next?
 
-Learn about other sorts of programming in [Chapter 17: Talking to Bitcoind with Other Languages](17_0_Talking_to_Bitcoind_Other.md).
+Learn about other sorts of programming in [Chapter 18: Talking to Bitcoind with Other Languages](18_0_Talking_to_Bitcoind_Other.md).

18_0_Talking_to_Bitcoind_Other.md

@@ -1,4 +1,4 @@
-# Chapter 17: Talking to Bitcoind with Other Languages
+# Chapter 18: Talking to Bitcoind with Other Languages
 
 You should now have a solid foundation for working with Bitcoin in C, not only using RPC, JSON, and ZMQ libraries to directly interact with `bitcoind`, but also utilizing the Libwally libraries to complement that work. And C is a great language for prototyping and abstraction — but it's probably not what you're programming in. This chapter thus takes a whirlwind tour of six other programming languages, demonstrating the barest Bitcoin functionality in each and allowing you to expand the lessons of the command line and C to the programming language of your choice.
 
@@ -18,9 +18,9 @@ Supporting objectives include the ability to:
    
 ## Table of Contents
 
-  * [Section One: Accessing Bitcoind with Go](17_1_Accessing_Bitcoind_with_Go.md)
-  * [Section Two: Accessing Bitcoind with Java](17_2_Accessing_Bitcoind_with_Java.md)
-  * [Section Three: Accessing Bitcoind with NodeJS](17_3_Accessing_Bitcoind_with_NodeJS.md)
-  * [Section Four: Accessing Bitcoind with Python](17_4_Accessing_Bitcoind_with_Python.md)
-  * [Section Five: Accessing Bitcoind with Rust](17_5_Accessing_Bitcoind_with_Rust.md)
-  * [Section Six: Accessing Bitcoind with Swift](17_6_Accessing_Bitcoind_with_Swift.md)
+  * [Section One: Accessing Bitcoind with Go](18_1_Accessing_Bitcoind_with_Go.md)
+  * [Section Two: Accessing Bitcoind with Java](18_2_Accessing_Bitcoind_with_Java.md)
+  * [Section Three: Accessing Bitcoind with NodeJS](18_3_Accessing_Bitcoind_with_NodeJS.md)
+  * [Section Four: Accessing Bitcoind with Python](18_4_Accessing_Bitcoind_with_Python.md)
+  * [Section Five: Accessing Bitcoind with Rust](18_5_Accessing_Bitcoind_with_Rust.md)
+  * [Section Six: Accessing Bitcoind with Swift](18_6_Accessing_Bitcoind_with_Swift.md)

18_1_Accessing_Bitcoind_with_Go.md

@@ -1,4 +1,4 @@
-# 17.1: Accessing Bitcoind with Go
+# 18.1: Accessing Bitcoind with Go
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
@@ -160,7 +160,7 @@ However, a quirk with hashes in `rpcclient` is that they will typically print in
 
 ### Run Your Code
 
-You can download the complete code from the [src directory](src/17_1_blockinfo.go).
+You can download the complete code from the [src directory](src/18_1_blockinfo.go).
 
 You can then run:
 ```
@@ -185,7 +185,7 @@ Due to limitations of the `btcd` `rpcclient`, you can't make a use of the ```get
 ```
 ```client.GetBalance("*")``` requires the ```"*"``` input, due to a quirk with `btcd`. The asterisk signifies that you want to get the balance of all of your wallets.
 
-If you run [the src code](src/17_1_getbalance.go), you should get an output similar to this:
+If you run [the src code](src/18_1_getbalance.go), you should get an output similar to this:
 ```
 $ go run getbalance.go 
 0.000689 BTC
@@ -279,7 +279,7 @@ Only afterward do you use the `getreceivedbyaddress` RPC, on your decoded addres
 
 	fmt.Println(wallet)
 ```
-When you run [the code](src/17_1_getamountreceived.go), you should get output similar to:
+When you run [the code](src/18_1_getamountreceived.go), you should get output similar to:
 ```
 $ go run getamountreceived.go 
 0.0085 BTC
@@ -331,7 +331,7 @@ func main() {
 	fmt.Println(sent)
 }
 ```
-When you run [the code](src/17_1_sendtransaction.go), the txid of the transaction is outputted: 
+When you run [the code](src/18_1_sendtransaction.go), the txid of the transaction is outputted: 
 
 ```
 $ go run sendtransaction.go
@@ -415,4 +415,4 @@ Although the `btcd` `rpcclient` has some limits, you can still perform the main
 
 ## What's Next?
 
-Learn more about "Talking to Bitcoin in Other Languages" in [17.2: Accessing Bitcoin with Java](17_2_Accessing_Bitcoind_with_Java.md).
+Learn more about "Talking to Bitcoin in Other Languages" in [18.2: Accessing Bitcoin with Java](18_2_Accessing_Bitcoind_with_Java.md).

18_2_Accessing_Bitcoind_with_Java.md

@@ -1,12 +1,12 @@
-# 17.2: Accessing Bitcoind with Java
+# 18.2: Accessing Bitcoind with Java
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
-This section explains how to interact with `bitcoind` using the Java programming language and the [JavaBitcoindRpcClient](https://github.com/Polve/JavaBitcoindRpcClient). 
+This section explains how to interact with `bitcoind` using the Java programming language and the [JavaBitcoindRpcClient](https://github.com/Polve/JavaBitcoindRpcClient).
 
 ## Set Up Java
 
-You can install Java on your server, using the `apt-get` command. You will also install [Apache Maven](http://maven.apache.org/) to manage the dependencies. 
+You can install Java on your server, using the `apt-get` command. You will also install [Apache Maven](http://maven.apache.org/) to manage the dependencies.
 ```
 $ sudo apt-get install openjdk-11-jre-headless maven
 ```
@@ -57,15 +57,15 @@ In order to include `JavaBitcoindRpcClient`, you must add its dependency to `<de
         <version>1.2.1</version>
       </dependency>
 ```
-You also need to add compiler properties to indicate what JDK version will compile the source code.    
+You also need to add compiler properties to indicate what JDK version will compile the source code.
 
 ```
-  <properties>                                                                  
+  <properties>
     <!-- https://maven.apache.org/general.html#encoding-warning -->
     <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
     <maven.compiler.source>11</maven.compiler.source>
     <maven.compiler.target>11</maven.compiler.target>
-  </properties>                                                                 
+  </properties>
 ```
 
 Whenever you add source code to your classes, you'll be able to test it with:
@@ -110,7 +110,7 @@ rpcClient.stop();
 
 ### Make an RPC Call
 
-You'll find that the `BitcoindRpcClient` provides most of the functionality that can be accessed through `bitcoin-cli` or other RPC methods, using the same method names, but in camelCase. 
+You'll find that the `BitcoindRpcClient` provides most of the functionality that can be accessed through `bitcoin-cli` or other RPC methods, using the same method names, but in camelCase.
 
 For example, to execute the `getmininginfo` command to get the block information and the difficulty on the network, you should use the `getMiningInfo()` method:
 ```java
@@ -137,7 +137,7 @@ You can look up addresses on your wallet by passing the address as an argument t
 
 ```java
 	String addr1 = "mvLyH7Rs45c16FG2dfV7uuTKV6pL92kWxo";
-	
+
 	AddressInfo addr1Info = rpcClient.getAddressInfo(addr1);
 	System.out.println("Address: " + addr1Info.address());
 	System.out.println("MasterFingerPrint: " + addr1Info.hdMasterFingerprint());
@@ -154,7 +154,7 @@ PubKey: 0368d0fffa651783524f8b934d24d03b32bf8ff2c0808943a556b3d74b2e5c7d65
 
 ### Run Your Code
 
-The code for these examples can be found in [the src directory](src/17_2_App-getinfo.java) and should be installed into the standard directory structure created here as `~/java-project/src/main/java/com/blockchaincommons/lbtc/App.java`. It can then be compiled and run. 
+The code for these examples can be found in [the src directory](src/18_2_App-getinfo.java) and should be installed into the standard directory structure created here as `~/java-project/src/main/java/com/blockchaincommons/lbtc/App.java`. It can then be compiled and run.
 
 ```
 $ mvn compile
@@ -200,7 +200,7 @@ The JavaBitcoindRpcClient library has some good tools that make it easy to creat
 
 ### Create a Transaction
 
-You can create a raw transaction using the `createRawTransaction` method, passing as arguments two ArrayList objects containing inputs and outputs to be used.  
+You can create a raw transaction using the `createRawTransaction` method, passing as arguments two ArrayList objects containing inputs and outputs to be used.
 
 First you set up your new addresses, here an existing address on your system and a new address on your system.
 ```
@@ -243,7 +243,7 @@ Second, you fill the ouputs each with an amount and an address:
 	BigDecimal estimatedFee = BigDecimal.valueOf(0.00000200);
       	BigDecimal txToAddr2Amount = utxos.get(0).amount().subtract(estimatedFee);
 	txb.out(addr2, txToAddr2Amount);
-	
+
 	System.out.println("unsignedRawTx in amount: " + utxos.get(0).amount());
         System.out.println("unsignedRawTx out amount: " + txToAddr2Amount);
 ```
@@ -261,7 +261,7 @@ You now can sign transaction with the method `signRawTransactionWithKey`. This m
 ```java
 	SignedRawTransaction srTx = rpcClient.signRawTransactionWithKey(
 					unsignedRawTxHex,
-					Arrays.asList(rpcClient.dumpPrivKey(addr1)), // 
+					Arrays.asList(rpcClient.dumpPrivKey(addr1)), //
 					Arrays.asList(in),
 					null);
 	System.out.println("signedRawTx hex: " + srTx.hex());
@@ -273,12 +273,12 @@ You now can sign transaction with the method `signRawTransactionWithKey`. This m
 Finally, sending requires the `sendRawTransaction` command:
 ```java
 String sentRawTransactionID = rpcClient.sendRawTransaction(srTx.hex());
-System.out.println("Sent signedRawTx (txID): " + sentRawTransactionID);```
+System.out.println("Sent signedRawTx (txID): " + sentRawTransactionID);
 ```
 
 ### Run Your Code
 
-You can now run [the transaction code](src/17_2_App-sendtx.java) as `~/java-project/src/main/java/com/blockchaincommons/lbtc/App.java`.
+You can now run [the transaction code](src/18_2_App-sendtx.java) as `~/java-project/src/main/java/com/blockchaincommons/lbtc/App.java`.
 
 ```
 $ mvn compile
@@ -317,7 +317,7 @@ To do this, use `JavaBitcoindRpcClient`'s `BitcoinAcceptor` class, which allows
   acceptor.run();
 ```
 
-See [the src directory](src/17_2_App-listen.java) for the complete code. Every time a transaction is sent or a new block is generated, you should see output on your console:
+See [the src directory](src/18_2_App-listen.java) for the complete code. Every time a transaction is sent or a new block is generated, you should see output on your console:
 ```
 Transaction: {account=Tests, address=mhopuJzgmTwhGfpNLCJ9CRknugY691oXp1, category=receive, amount=5.0E-4, label=Tests, vout=1, confirmations=0, trusted=false, txid=361e8fcff243b74ebf396e595a007636654f67c3c7b55fd2860a3d37772155eb, walletconflicts=[], time=1513132887, timereceived=1513132887, bip125-replaceable=unknown}
 
@@ -330,5 +330,5 @@ By using the javabitcoinrpc library, you can easily access bitcoind via RPC call
 
 ## What's Next?
 
-Learn more about "Talking to Bitcoin in Other Languages" in [17.3: Accessing Bitcoin with NodeJS](17_3_Accessing_Bitcoind_with_NodeJS.md).
+Learn more about "Talking to Bitcoin in Other Languages" in [18.3: Accessing Bitcoin with NodeJS](18_3_Accessing_Bitcoind_with_NodeJS.md).
 

18_3_Accessing_Bitcoind_with_NodeJS.md

@@ -1,4 +1,4 @@
-# 17.3: Accessing Bitcoind with NodeJS
+# 18.3: Accessing Bitcoind with NodeJS
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
@@ -34,7 +34,7 @@ $ export BITCOIND_PASS=d8340efbcd34e312044c8431c59c792c
 $ export BITCOIND_PORT=18332
 ```
 
-> :warning: **WARNING:** Obviously, you'd never put set your password in an environmental variable in a production environment.
+> :warning: **WARNING:** Obviously, you'd never put your password in an environmental variable in a production environment.
 
 > :link: **MAINNET VS TESTNET:** The port would be 8332 for a mainnet setup.
 
@@ -111,7 +111,7 @@ The result of the BCRPC functions is a JSON object containing information about
 
 ### Run Your Code
 
-You can find the `getinfo` code in [the src directory](src/17_3_getinfo.js).
+You can find the `getinfo` code in [the src directory](src/18_3_getinfo.js).
 ```
 $ node getinfo.js
 1831094
@@ -163,7 +163,7 @@ agent.getWalletInfo(function (err, walletInfo) {
 });
 ```
 
-The source is available as [walletinfo.js](src/17_3_walletinfo.js).
+The source is available as [walletinfo.js](src/18_3_walletinfo.js).
 ```
 $ node walletinfo.js
 0.008498
@@ -261,7 +261,7 @@ You should get an output similar to this:
 }
 ```
 
-The full code is available as [sendtx.js](src/17_3_sendtx.js).
+The full code is available as [sendtx.js](src/18_3_sendtx.js).
 
 ## Summary: Accessing Bitcoind with Node
 
@@ -271,4 +271,4 @@ Based on these examples you should be able to incorporate Bitcoin in a Node.js p
 
 ## What's Next?
 
-Learn more about "Talking to Bitcoin in Other Languages" in [17.4: Accessing Bitcoin with Python](17_4_Accessing_Bitcoind_with_Python.md).
+Learn more about "Talking to Bitcoin in Other Languages" in [18.4: Accessing Bitcoin with Python](18_4_Accessing_Bitcoind_with_Python.md).

18_4_Accessing_Bitcoind_with_Python.md

@@ -1,4 +1,4 @@
-# 17.4: Accessing Bitcoind with Python
+# 18.4: Accessing Bitcoind with Python
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
@@ -125,7 +125,7 @@ print("---------------------------------------------------------------\n")
 
 ### Run Your Code
 
-You can retrieve [the src code](src/17_4_getinfo.py) and run it with `python3`:
+You can retrieve [the src code](src/18_4_getinfo.py) and run it with `python3`:
 ```
 $ python3 getinfo.py
 ---------------------------------------------------------------
@@ -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']
@@ -239,7 +239,7 @@ pprint(utxo_tx_details)
 print("---------------------------------------------------------------\n")
 ```
 
-This code is available at [walletinfo.py](src/17_4_walletinfo.py).
+This code is available at [walletinfo.py](src/18_4_walletinfo.py).
 
 ```
 $ python3 walletinfo.py 
@@ -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. 
 
@@ -418,7 +418,7 @@ send_tx = rpc_client.sendrawtransaction(signed_tx['hex'])
 ```
 ### Run Your Code
 
-The [sample code](src/17_4_sendtx.py) is full of `print` statements to demonstrate all of the data available at every point:
+The [sample code](src/18_4_sendtx.py) is full of `print` statements to demonstrate all of the data available at every point:
 ```
 $ python3 sendtx.py 
 Creating a Transaction
@@ -453,15 +453,16 @@ TXID of sent transaction:  187f8baa222f9f37841d966b6bad59b8131cfacca861cbe9bfc86
 
 ## Summary: Accessing  Bitcoind with Python
 
-Accessing Bitcoind with Python is very easy while using the `python-bitcoinrpc` library. The first thing to always do is to establish a connection with your `bitcoind` instance, then you can call all of the bitcoin API calls as described in the bitcoin-core documentation. This makes it easy to create small or large prorgrams to manage your own node, check balances, or create cool applications on top, as you access the full power of `bitcoin-cli`.
+Accessing Bitcoind with Python is very easy while using the `python-bitcoinrpc` library. The first thing to always do is to establish a connection with your `bitcoind` instance, then you can call all of the bitcoin API calls as described in the bitcoin-core documentation. This makes it easy to create small or large programs to manage your own node, check balances, or create cool applications on top, as you access the full power of `bitcoin-cli`.
 
 ## What's Next?
 
-Learn more about "Talking to Bitcoin in Other Languages" in [17.5: Accessing Bitcoin with Rust](17_5_Accessing_Bitcoind_with_Rust.md).
+Learn more about "Talking to Bitcoin in Other Languages" in [18.5: Accessing Bitcoin with Rust](18_5_Accessing_Bitcoind_with_Rust.md).
 
 ## 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

18_5_Accessing_Bitcoind_with_Rust.md

@@ -1,4 +1,4 @@
-# 17.5: Accessing Bitcoind with Rust
+# 18.5: Accessing Bitcoind with Rust
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
@@ -135,7 +135,7 @@ Here's the complete code to retrieve a block hash, turn that into a block, and p
 
 ### Run Your Code
 
-You can access the [src code](src/17_5_main-getinfo.rs) and run it. Unfortunately, the "Block" info will come out a bit ugly because this example doesn't include a library to prettify it.
+You can access the [src code](src/18_5_main-getinfo.rs) and run it. Unfortunately, the "Block" info will come out a bit ugly because this example doesn't include a library to prettify it.
 ```
 $ cargo run 
    Compiling btc_test v0.1.0 (/home/standup/btc_test)
@@ -289,7 +289,7 @@ println!("{:?}", txid_sent);
 
 ### Run Your Code
 
-You can now run the complete code from the [src](src/17_5_main-sendtx.rs).
+You can now run the complete code from the [src](src/18_5_main-sendtx.rs).
 
 ```
 $ cargo run
@@ -358,5 +358,5 @@ b0eda3517e6fac69e58ae315d7fe7a1981e3a858996cc1e3135618cac9b79d1a
 
 ## What's Next?
 
-Learn more about "Talking to Bitcoin in Other Languages" in [17.6: Accessing Bitcoin with Swift](17_6_Accessing_Bitcoind_with_Swift.md).
+Learn more about "Talking to Bitcoin in Other Languages" in [18.6: Accessing Bitcoin with Swift](18_6_Accessing_Bitcoind_with_Swift.md).
 

18_6_Accessing_Bitcoind_with_Swift.md

@@ -1,4 +1,4 @@
-# 17.6: Accessing Bitcoind with Swift
+# 18.6: Accessing Bitcoind with Swift
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
@@ -191,7 +191,7 @@ makeCommand(method: method,param: param) { result in
 
 ### Run Your Code
 
-The complete code is available in the [src directory](src/17_6_getinfo.playground). Load it into your Xcode playground and then "Editor -> Run Playground" and you should get results like:
+The complete code is available in the [src directory](src/18_6_getinfo.playground). Load it into your Xcode playground and then "Editor -> Run Playground" and you should get results like:
 ```
 {
     bestblockhash = 00000000000000069725608ebc5b59e520572a8088cbc57ffa5ba87b7f300ac7;
@@ -385,7 +385,7 @@ Sending your transaction is equally simple:
 }
 ```
 
-The code for this transaction sender can be found in the [src directory](src/17_6_sendtx.playground).
+The code for this transaction sender can be found in the [src directory](src/18_6_sendtx.playground).
 
 ## Use Swift in Other Ways
 
@@ -400,7 +400,7 @@ Swift is a robust modern programming language that unfortunately doesn't yet hav
 
 ## What's Next?
 
-Learn about Lightning in [Chapter 18: Understanding Your Lightning Setup](18_0_Understanding_Your_Lightning_Setup.md).
+Learn about Lightning in [Chapter 19: Understanding Your Lightning Setup](19_0_Understanding_Your_Lightning_Setup.md).
 
 ## Variant: Deploy Swift on Ubuntu
 

19_0_Understanding_Your_Lightning_Setup.md

@@ -1,4 +1,4 @@
-# Chapter 18: Understanding Your Lighting Setup
+# Chapter 19: Understanding Your Lighting Setup
 
 > :information_source: **NOTE:** This is a draft in progress, so that I can get some feedback from early reviewers. It is not yet ready for learning.
 
@@ -20,7 +20,7 @@ Supporting objectives include the ability to:
 
 ## Table of Contents
 
-* [Section One: Verifying Your c-lightning Setup](18_1_Verifying_Your_Lightning_Setup.md)
-* [Section Two: Knowing Your c-lightning Setup](18_2_Knowing_Your_lightning_Setup.md)
-   * [Interlude: Accessing a Second Lightning Node](18_2__Interlude_Accessing_a_Second_Lightning_Node.md)
-* [Section Three: Creating a Lightning Channel](18_3_Setting_Up_a_Channel.md)
+* [Section One: Verifying Your c-lightning Setup](19_1_Verifying_Your_Lightning_Setup.md)
+* [Section Two: Knowing Your c-lightning Setup](19_2_Knowing_Your_lightning_Setup.md)
+   * [Interlude: Accessing a Second Lightning Node](19_2__Interlude_Accessing_a_Second_Lightning_Node.md)
+* [Section Three: Creating a Lightning Channel](19_3_Setting_Up_a_Channel.md)

19_1_Verifying_Your_Lightning_Setup.md

@@ -1,5 +1,4 @@
-
-# 18.1: Creating a c-lightning Setup
+# 19.1: Creating a c-lightning Setup
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
@@ -266,7 +265,7 @@ Before you start playing with lightning, you should make sure that your aliases
 
 ## What's Next?
 
-Continue "Understanding Your Lightning Setup" with [§18.2: Knowing Your Lightning Setup](18_2_Knowing_Your_lightning_Setup.md).
+Continue "Understanding Your Lightning Setup" with [§19.2: Knowing Your Lightning Setup](19_2_Knowing_Your_lightning_Setup.md).
 
 ## Variant: Install from Ubuntu ppa
 
@@ -288,5 +287,3 @@ $ cd /
 $ sudo tar xf ~/clightning-v0.9.1-Ubuntu-20.04.tar.xz 
 ```
 Warning: this will require you to have the precise same libraries as were used to create the binary. It's often easier to just recompile.
-
-

19_2_Knowing_Your_lightning_Setup.md

@@ -1,4 +1,4 @@
-# 18.2: Knowing Your c-lightning Setup
+# 19.2: Knowing Your c-lightning Setup
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
@@ -334,6 +334,6 @@ The `~/.lightning` directory contains all of your files, while `lightning-cli he
 
 ## What's Next?
 
-You're going to need to have a second Linode node to test out the actual payment of invoices. If you need support in setting one up, read [Interlude: Accessing a Second Lightning Node](18_2__Interlude_Accessing_a_Second_Lightning_Node.md).
+You're going to need to have a second Linode node to test out the actual payment of invoices. If you need support in setting one up, read [Interlude: Accessing a Second Lightning Node](19_2__Interlude_Accessing_a_Second_Lightning_Node.md).
 
-Otherwise, continue "Understanding Your Lightning Setup" with [§18.3: Setting Up_a_Channel](18_3_Setting_Up_a_Channel.md).
+Otherwise, continue "Understanding Your Lightning Setup" with [§19.3: Setting Up_a_Channel](19_3_Setting_Up_a_Channel.md).

19_2__Interlude_Accessing_a_Second_Lightning_Node.md

@@ -52,7 +52,7 @@ They can then tell you their `id` (`03240a4878a9a64aea6c3921a434e573845267b86e89
 
 ## Create a New c-lightning Node
 
-However, for testing purposes, you probably want to have a second node under you own control. The easiest way to do so is to create a second c-lightning node on a new machine, using either Bitcoin Standup, per [§2.1](02_1_Setting_Up_a_Bitcoin-Core_VPS_with_StackScript.md) or compiling it by hand, per [§18.1](18_1_Verifying_Your_Lightning_Setup.md).
+However, for testing purposes, you probably want to have a second node under you own control. The easiest way to do so is to create a second c-lightning node on a new machine, using either Bitcoin Standup, per [§2.1](02_1_Setting_Up_a_Bitcoin-Core_VPS_with_StackScript.md) or compiling it by hand, per [§19.1](19_1_Verifying_Your_Lightning_Setup.md).
 
 Once you have your node running, you can run `getinfo` to retrieve your information, as shown above.
 
@@ -111,7 +111,7 @@ $ sudo cp $GOPATH/bin/lnd $GOPATH/bin/lncli /usr/bin
 
 Unlike with c-lightning, you will need to create a default config file for LND.
 
-However first, you need to enable ZMQ on your Bitcoind, if you didn't already in [§15.3](15_3_Receiving_Bitcoind_Notifications_with_C.md).
+However first, you need to enable ZMQ on your Bitcoind, if you didn't already in [§16.3](16_3_Receiving_Bitcoind_Notifications_with_C.md).
 
 This requires adding the following to your `~/.bitcoin/bitcoin.conf` file if it's not already there:
 ```
@@ -322,4 +322,4 @@ You always need two Lightning nodes to form a channel. If you don't have someone
 
 Though you've possibly created an LND, c-lightning will remain the heart of our examples until we need to start using both of them, in [Chapter 19](19_0_Understanding_Your_Lightning_Setup.md).
 
-Continue "Understanding Your Lightning Setup" with [§18.3: Setting Up_a_Channel](18_3_Setting_Up_a_Channel.md).
+Continue "Understanding Your Lightning Setup" with [§19.3: Setting Up_a_Channel](19_3_Setting_Up_a_Channel.md).

19_3_Setting_Up_a_Channel.md

@@ -1,4 +1,4 @@
-# 18.3: Creating a Lightning Channel
+# 19.3: Creating a Lightning Channel
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
@@ -80,7 +80,7 @@ Now that you have funded your c-lightning wallet you will need information about
 
 The next thing you need to do is connect your node to a peer. This is done with the `lightning-cli connect` command. Remember that if you want more information on this command, you should type `lightning-cli help connect`.
 
-To connect your node to a remote peer you need its id, which represents the target node’s public key. As a convenience, `id` may be of the form `id@host` or `id@host:port`.  You may have retrieved this with `lightning-cli getinfo` (on c-lightning) or `lncli --network=testnet getinfo` (on LND) as discussed in the [previous interlude](18_2__Interlude_Accessing_a_Second_Lightning_Node.md). 
+To connect your node to a remote peer you need its id, which represents the target node’s public key. As a convenience, `id` may be of the form `id@host` or `id@host:port`.  You may have retrieved this with `lightning-cli getinfo` (on c-lightning) or `lncli --network=testnet getinfo` (on LND) as discussed in the [previous interlude](19_2__Interlude_Accessing_a_Second_Lightning_Node.md). 
 
 We've selected the LND node, `032a7572dc013b6382cde391d79f292ced27305aa4162ec3906279fc4334602543`, which is located at IP address `45.33.35.151`, which we're going to connect to from our c-lightning node:
 
@@ -182,5 +182,4 @@ You need to create a channel with a remote node to be able to receive and send m
 
 ## What's Next?
 
-You're ready to go! Move on to [Chapter Nineteen: Using Lightning](19_0_Using_Lightning.md).
-
+You're ready to go! Move on to [Chapter 20: Using Lightning](20_0_Using_Lightning.md).

20_0_Using_Lightning.md

@@ -1,4 +1,4 @@
-# Chapter Nineteen: Using Lightning
+# Chapter 20: Using Lightning
 
 > :information_source: **NOTE:** This is a draft in progress, so that I can get some feedback from early reviewers. It is not yet ready for learning.
 
@@ -19,7 +19,7 @@ Supporting objectives include the ability to:
    
 ## Table of Contents
 
-* [Section One: Generating a Payment Request](19_1_Generate_a_Payment_Request.md)
-* [Section Two: Paying an Invoice](19_2_Paying_a_Invoice.md)
-* [Section Three: Closing a Lightning Channel](19_3_Closing_a_Channel.md)
-* [Section Four: Expanding the Lightning Network](19_4_Lightning_Network_Review.md)
+* [Section One: Generating a Payment Request](20_1_Generate_a_Payment_Request.md)
+* [Section Two: Paying an Invoice](20_2_Paying_a_Invoice.md)
+* [Section Three: Closing a Lightning Channel](20_3_Closing_a_Channel.md)
+* [Section Four: Expanding the Lightning Network](20_4_Lightning_Network_Review.md)

20_1_Generate_a_Payment_Request.md

@@ -1,9 +1,8 @@
-
-# 19.1: Generating a Payment Request
+# 20.1: Generating a Payment Request
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
-This section describes how payments work on the Lightning Network, how to create a payment request (or _invoice_), and finally how to make sense of it. Issuing invoices depends on your having a second Lightning node, as described in [Accessing a Second Lightning Node](18_2__Interlude_Accessing_a_Second_Lightning_Node.md). These examples will use an LND node as their secondary node, to further demonstrate the possibilities of the Lightning Network. To differentiate between the nodes in these examples, the prompts will be shown as `c$` for the c-lightning node and `lnd$` as the LND node. If you want to reproduce this steps, you should [install your own secondary LND node](18_2__Interlude_Accessing_a_Second_Lightning_Node.md#creating-a-new-lnd-node). 
+This section describes how payments work on the Lightning Network, how to create a payment request (or _invoice_), and finally how to make sense of it. Issuing invoices depends on your having a second Lightning node, as described in [Accessing a Second Lightning Node](19_2__Interlude_Accessing_a_Second_Lightning_Node.md). These examples will use an LND node as their secondary node, to further demonstrate the possibilities of the Lightning Network. To differentiate between the nodes in these examples, the prompts will be shown as `c$` for the c-lightning node and `lnd$` as the LND node. If you want to reproduce this steps, you should [install your own secondary LND node](19_2__Interlude_Accessing_a_Second_Lightning_Node.md#creating-a-new-lnd-node).
 
 > :book: ***What is an Invoice?** Almost all payments made on the Lightning Network require an invoice, which is nothing more than a **request for payment** made by the recipient of the money and sent by variety of means to the paying user.  All payment requests are single use. Lightning invoices use bech32 encoding, which is already used by Segregated Witness for Bitcoin.
 
@@ -98,7 +97,7 @@ Here's what the most relevent elements mean:
 
 > :book: ***What is a Hashed Time Locked Contract (HTLC)?*** A Hashed Time Locked Contract is a conditional payment that use hashlocks and timelocks to ensure payment security. The receiver must present a payment preimage or generate a cryptographic proof of payment before a given time, otherwise the payer can cancel the contract by spending it. These contracts are created as outputs from the **Commitment Transaction**.
 
-> :book: ***What is a Commitment Transaction?*** A Commitment Transaction is a transaction that spends the original funding transaction. Each peer holds the other peer's signature, meaning that either one can spent his commitment transaction whatever he wants. After each new commitment transaction is created the old one is revoked. The commitment transaction is one way that the funding transaction can be unlocked on the blockchain, as discussed in [§19.3](19_3_Closing_a_Channel.md).
+> :book: ***What is a Commitment Transaction?*** A Commitment Transaction is a transaction that spends the original funding transaction. Each peer holds the other peer's signature, meaning that either one can spent his commitment transaction whatever he wants. After each new commitment transaction is created the old one is revoked. The commitment transaction is one way that the funding transaction can be unlocked on the blockchain, as discussed in [§20.3](20_3_Closing_a_Channel.md).
 
 ### Check Your Invoice
 
@@ -108,7 +107,7 @@ There are two crucial elements to check in the invoice. The first, obviously, is
 ```
 You need to check that's the expected recipient.
 
-Looking back at [§18.3](18_3_Setting_Up_a_Channel.md#opening-a-channel), you can see that's indeed the peer ID that you used when you created your channel. You could also verify it on the opposite node with the `getinfo` command.
+Looking back at [§20.3](20_3_Closing_a_Channel.md), you can see that's indeed the peer ID that you used when you created your channel. You could also verify it on the opposite node with the `getinfo` command.
 ```
 lnd$ lncli -n testnet getinfo
 {
@@ -182,4 +181,4 @@ In most cases you need to receive an invoice to use Lightning Network payments.
 
 ## What's Next?
 
-Continue "Using Lightning" with [§19.2: Paying_a_Invoice](19_2_Paying_a_Invoice.md).
+Continue "Using Lightning" with [§20.2: Paying_a_Invoice](20_2_Paying_a_Invoice.md).

20_2_Paying_a_Invoice.md

@@ -1,8 +1,8 @@
-# 19.2: Paying an Invoice
+# 20.2: Paying an Invoice
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
-In this chapter you will learn how to pay an invoice using `lightning-cli pay` command. It assumes that you've already looked over the invoice, per [§19.1](19_1_Generate_a_Payment_Request.md) and determined it was valid.
+In this chapter you will learn how to pay an invoice using `lightning-cli pay` command. It assumes that you've already looked over the invoice, per [§20.1](20_1_Generate_a_Payment_Request.md) and determined it was valid.
 
 ## Check your Balance
 
@@ -203,4 +203,4 @@ Once you've got an invoice, it's easy enough to pay with a single command in Lig
 
 ## What's Next?
 
-Continue "Using Lighting" with [§19.3: Closing a Channel](19_3_Closing_a_Channel.md).
+Continue "Using Lighting" with [§20.3: Closing a Channel](20_3_Closing_a_Channel.md).

20_3_Closing_a_Channel.md

@@ -1,4 +1,4 @@
-# 19.3: Closing a Channel
+# 20.3: Closing a Channel
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 
@@ -179,7 +179,7 @@ $ bitcoin-cli --named getrawtransaction txid=f68de52d80a1076e36c677ef640539c50e3
   "blocktime": 1602713519
 }
 ```
-The input of the transaction is `66694d23ca15efe379e5f4a71d9be1a2d65e383b89ee3abe126ee36a12f23c1d`, which was the funding transaction in [§18.3](18_3_Setting_Up_a_Channel.md). The transaction then has two outputs, one for the remote node and the other for the local c-lightning wallet. The output on index 0 corresponds to the remote node with a value of 0.00010012 BTC; and the output on index 1 corresponds to the local node with a value of 0.00089804 BTC.
+The input of the transaction is `66694d23ca15efe379e5f4a71d9be1a2d65e383b89ee3abe126ee36a12f23c1d`, which was the funding transaction in [§19.3](19_3_Setting_Up_a_Channel.md). The transaction then has two outputs, one for the remote node and the other for the local c-lightning wallet. The output on index 0 corresponds to the remote node with a value of 0.00010012 BTC; and the output on index 1 corresponds to the local node with a value of 0.00089804 BTC.
 
 Lightning will similarly show 89804 satoshis returned as a new UTXO in its wallet:
 ```
@@ -257,4 +257,4 @@ When you close a channel you perform an on-chain transaction ending your financi
 
 ## What's Next?
 
-Continue "Using Lightning" with [§19.4: Expanding the Lightning Network](19_4_Lightning_Network_Review.md).
+Continue "Using Lightning" with [§20.4: Expanding the Lightning Network](20_4_Lightning_Network_Review.md).

20_4_Lightning_Network_Review.md

@@ -1,4 +1,4 @@
-# 19.4: Expanding the Lightning Network
+# 20.4: Expanding the Lightning Network
 
 > :information_source: **NOTE:** This section has been recently added to the course and is an early draft that may still be awaiting review. Caveat reader.
 

A0_Appendices.md

@@ -1,6 +1,6 @@
 # Appendices
 
-The main body of this course suggests a fairly standard setup for Bitcoin testing. What follows is these appendices are a better explanation of that setup and some options for alternatives.
+The main body of this course suggests a fairly standard setup for Bitcoin testing. What follows in these appendices are a better explanation of that setup and some options for alternatives.
 
 ## Objectives for This Section
 

A2_0_Compiling_Bitcoin_from_Source.md

@@ -28,7 +28,7 @@ $ su root
 
 ### Step 1: Update Your System
 
-Fir, update the system using:
+First, update the system using:
 ```
 $ sudo apt-get update
 ```

A3_0_Using_Bitcoin_Regtest.md

@@ -11,7 +11,7 @@ After [setting up your Bitcoin-Core VPS](02_0_Setting_Up_a_Bitcoin-Core_VPS.md)
 $ bitcoind -regtest -daemon -fallbackfee=1.0 -maxtxfee=1.1
 ```
 
-The argments `-fallbackfee=1.0 -maxtxfee=1.1` will prevent the `Fee estimation failed. Fallbackfee is disabled` error. 
+The arguments `-fallbackfee=1.0 -maxtxfee=1.1` will prevent the `Fee estimation failed. Fallbackfee is disabled` error. 
 
 On regtest, usually there are not enough transactions so bitcoind cannot give a reliable estimate and, without it, the wallet will not create transactions unless it is explicitly set the fee.
 
@@ -58,7 +58,7 @@ Because a block must have 100 confirmations before that reward can be spent, you
 
 The output is the block hash of every block generated.
 
-> :book: ***What is a coinbase transaction?*** A coinbase is the inputless transaction created when a new block is mined and given to the miner. It's how new bitcoins enter the ecosystem. The value of coinbase transactions decay over time. On the mainnet, it halves every 210,000 transactions and ends entirely with the 6,929,999th block, which is currently predicted for the 22nd century. As of May 2020, the coinbase reward is 6.25 BTC.
+> :book: ***What is a coinbase transaction?*** A coinbase is the inputless transaction created when a new block is mined and given to the miner. It's how new bitcoins enter the ecosystem. The value of coinbase transactions decay over time. On the mainnet, it halves every 210,000 blocks and ends entirely with the 6,929,999th block, which is currently predicted for the 22nd century. As of May 2020, the coinbase reward is 6.25 BTC.
 
 ### Verify Your Balance
 
@@ -135,11 +135,11 @@ $ bitcoin-cli -regtest -generate 6
 
 ## Test with NodeJS
 
-When you are on regtest, you are able to simulate edge cases and attacks that might happen in the real world, such  as double spend.
+When you are on regtest, you are able to simulate edge cases and attacks that might happen in the real world, such as double spend.
 
 As discussed elsewhere in this course, using software libraries might give you more sophisticated access to some RPC commands. In this case, [bitcointest by dgarage](https://github.com/dgarage/bitcointest) for NodeJS can be used to simulate a transaction from one wallet to another; you can check [their guide](https://www.npmjs.com/package/bitcointest) for more specific attack simulations, such as double spend.
 
-See [§17.3](17_3_Accessing_Bitcoind_with_NodeJS.md) for the most up-to-date info on install NodeJS, then add `bitcointest`:
+See [§18.3](18_3_Accessing_Bitcoind_with_NodeJS.md) for the most up-to-date info on install NodeJS, then add `bitcointest`:
 ```
 $ npm install -g bitcointest
 ```

CLA-signed/CLA.HGRAMS.AED496548E2F3810CCAB.asc

@@ -0,0 +1,74 @@
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA512
+
+# Contributor License Agreement
+
+Version 1.0
+
+Name: hgrams
+
+E-Mail: hgrams@protonmail.ch
+
+Legal Jurisdiction: Wyoming, United States of America
+
+Project: https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line
+
+Date: 11/04/2021
+
+## 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-----
+
+iQIzBAEBCgAdFiEErtSWVI4vOBDMq+zPtqv4+8oqhOAFAmGEPzAACgkQtqv4+8oq
+hOCgTA/+KMuHLFjAK/ifKuRMpKXyQWvfYlQTmaDhEUbwBs3SiF+0bN2XcDQy1/rf
+ha5OEdNB8m7RxfU30fcWAHOlPRFxaaoPTDtZCETreQsIPYoccW4aXViq0B4Ww0/I
+DuO49De423vPwLjfSGF+s4EQEUHVY9lERBkjhrgRKSJ28Bym/QaPhZWaWsQl9HS6
+/MsvR+xbqNHFwnfJkrRHXldQzafMcH5aqWwVMFlkcOvA2rBz5zdFx/CYozOF7pcd
+iV/t6ZTZJwkBWbjlzjoG4OkS+ncOEzkRK9kCfrEU7zKctXKSgh8FVvnP8gfzGh7q
+tZQXecc/ojfcGRp32pcDs9IuTeEirjcJZZjHhVk3cHnULa/Bfq077Iu2yCLEgI+E
+Z1BtfGdd7lvqGg9CtK9hfFSvJ4KyQQ48dOxTfg6jKXnF1t63jQ86AANJ2FCsl2tx
+TWQMhYG4Ahqd/fCajxy5rG+9/muVOow/IFekKsNpb63AIerW3YwpXk28Ozl8htZo
+igScab9opps3rrwEa/w9OqUkph5BpmesZdq09aHCwkBuFS92BMlpb0PXVpzk39kM
+LsEvT3kDwQNsmxZgh4zYYkQFn7JBN+kMsvRvaVpEksUEEcgFFSWh8NPuETUWTBwD
+/kYTr8lmBZ1PE38IWD0Bhjz+3O4vI6/u5c0c2PxiuSwtrvXyYe8=
+=b5Wo
+-----END PGP SIGNATURE-----

CLA-signed/CLA.icculp.C076C96C1110EA901974F2324CE131ACA12429CC.asc

@@ -0,0 +1,85 @@
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+Version: GnuPG v1
+Comment: A revocation certificate should follow
+
+iQGFBCABAgBvBQJg+iKHaB0CQWNjaWRlbnRhbGx5IHVwbG9hZGVkIHByaXZhdGUg
+a2V5IHRvIHB1YmxpYyBnaXRodWIgcmVwbzsgcmVtb3ZlZCBjb21taXRzIGJ1dCBz
+dGlsbCBpdCdzIGJlZW4gb3V0IHRoZXJlAAoJEEzhMayhJCnMhnoH/0HoVE58CR35
+LhSBBtOXrGSOnRo45ss9/G+sNzMsUGAwuwVqS9cELS+BJbJTsA/ZYCsq09AtNqy5
+thr9VrV4eonYZ9rZ2RIw89R15ytYBERO/R1mM+TCaMp7tFk3G9wNbkjaNPxQh4td
+7mf4HExstLWy7LIGgQdsZWn4zcOH6SG4H82jZBNpRnp0L4T+tcDoRYYO2f6pOQm7
+k5ls05gjx50YeCUeVIwqqZYCoCao/NFJNDkL3GzBUes8Cvgx2s+oiZdpdcY4Nb0l
+z52CyHbVhqBcumbL5oirnLjTCLP+bKpb4CjafHZdYygYaZdSkbODIBbq17169g1j
+U7nqW0ryAH0=
+=sc+j
+-----END PGP PUBLIC KEY BLOCK-----
+
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA256
+
+# Contributor License Agreement
+
+Version 1.0
+
+Name: Ian Culp
+
+E-Mail: icculp@gmail.com
+
+Legal Jurisdiction: Oklahoma, United States of America
+
+Project: https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line
+
+Date: 07/03/2021
+
+## 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 ./signed-cla/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-----
+Version: GnuPG v1
+
+iQEcBAEBCAAGBQJg4KFsAAoJEEzhMayhJCnMLoQH/jw2Dchpc5aV/rYcmCAzdqT5
+R13cEr+XHOendw/9SLEGF7io2KWCCJwcZ95jyG9etSbFJHDmwSnONBpJgH7IiMgV
+OYuz0LloM44WiHTwBujsb9ezjVztqgvfQqhFwVc28BB52MnXfiBzCXpfZIvcmj/H
+vbTmk2o6SAyoHiZm9Jwe+R9fiTeHYEM680R1M18CWfjY04JxtTv7tXuPRedBqJzU
+R9BYutO0voUJVDF3CcC3CbGKc+cHcU14MH5gjKZsMi/YPqu8XPU0tjIiDPjtSGxT
+5WyFgTMoH3Wm9Xzg9eFg74feN4LlDJl2XV/ISgfkoXFowMmJlOD74RE0fo9F3iw=
+=qvM2
+-----END PGP SIGNATURE-----

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-----

CLA-signed/CLA.lukedevj.AB4609E35FB50FA1CA970EB1CF23EC813BBF.asc

@@ -0,0 +1,72 @@
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA512
+
+# Contributor License Agreement
+
+Version 1.0
+
+Name: Luke Pavksy
+
+E-Mail: lukedevj.contact@protonmail.com
+
+Legal Jurisdiction: Wyoming, United States of America
+
+Project: https://github.com/BlockchainCommons/bc-lethe-kit
+
+Date: `06/20/2021`
+
+## 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 `Luke Pavksy`, `lukedevj.contact@protonmail.com`, and `06/20/2021` above. Then sign using GPG using the following command `gpg --armor --clearsign --output ./signed-cla/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-----
+
+iQGzBAEBCgAdFiEEiI+rRgnjX7UPocqXDrHPI+yBO78FAmDPoSUACgkQDrHPI+yB
+O78efQv+IJG+7qrfk+DdLLDoubgxTUs9TUPf9SRbt71VM3tuSZ/qdnStbvQ6PRrl
+qCm23cCIh0f/2icwzn1oVnMzVQs3qkmCJm25gkCUY0ABFW+4FsXXIL/kYmr3YV6+
+EoU5IYhTjJJ7w5hP+cjfRQfqCSArVxUHKqazYqVe2dYNydL9drrDfAZrlfksobuE
++tZmXz1ZZ1RCn1BFExSWWK0c4ZNOKJxV3sfm4EblAx8GTFHk3lQYeP+d7uOqJdrw
+BdAcNzp3hYmPCdEwiZB9IC3Jlbb0uBpclB29ADdk3N87OXrA3VpImTz0f4Mf5wla
+U3ZJReuqVJdWd7jWPJELZldjumEZsP4Qfg0Q44tskrukUVUAIYFngkmstpllyabm
+L9VUqpXMcFCzFtBs4waeaiWuWU5I4HJCTXrgiMwyoV8oA99+Sy+JdS0UbpokjzwQ
+zF9b43K6JcOWY1ZEIx0hTeg2IlqVEE/iYJw6JeiaCJHHlR/rG7A15+0zuwppkuh5
+WQp4ouPE
+=M9k+
+-----END PGP SIGNATURE-----

CLA-signed/CLA.maxcrowar.993F06969AB6603D1EEE890D4A6533DB95D4E166.asc

@@ -0,0 +1,72 @@
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA256
+
+# Contributor License Agreement
+
+Version 1.0
+
+Name: Maximiliano Goyheneche
+
+E-Mail: maxigoyheneche@gmail.com
+
+Legal Jurisdiction: Wyoming, United States of America
+
+Project: https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line
+
+Date: 10/22/2021
+
+## 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 ./signed-cla/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-----
+
+iQGzBAEBCAAdFiEEmT8Glpq2YD0e7okNSmUz25XU4WYFAmGMAWcACgkQSmUz25XU
+4WaTKAwAnSq5WktSyRlv+k0MFCpK3PFpaZuYdHF+MrmwIWRboGc8j/NYvcV50eGb
+VoovOetzVqv0lkIU3u2Q8lpLTIz0uLEi0mrOv+MdKXMos7/k1W0F4t+PuPZtk6r0
+bStvN3XC/kwoQW43+pO8g1bWMYzIH13b9QrJXdvGaaVm2x5s77jJCz+xQYY3bDCd
+ujlRJU5mh8iGes037kFCdX+IFgee+LYd3PaoTVBs1GXBDR2eHDJK7/NIZhacsDAs
+fql1lkr/LenM5XwE9+ZbG7qyABjPrGX16rq+Gl/uufxyW3GdQwwPSbPH0eC3WdPb
+pF6tFqKv0mMOmq3cCln8W2M20dK8nrhtOjUIoAaBON7UuR80EiZIrab/nAamukH0
+IEMlHJImNG2OTjbWzmJxMxdxpSah5w0oEYwiD/+9wF+N0mOcV7ICg4ilEBqynwf2
+yq2vCMFpY5VTH3Dku6d+mqPnhcGGmadF/V0wQ70/tlE7K7jDtknB3KtnaWP7t5Ef
+geVUNjwN
+=dh9y
+-----END PGP SIGNATURE-----

CLA-signed/CLA.namcios.55A24BE0AEE5DB4152C6A4108E3A368317269AB4.asc

@@ -0,0 +1,69 @@
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA256
+
+# Contributor License Agreement
+
+Version 1.0
+
+Name: Namcios
+
+E-Mail: namcios@protonmail.com
+
+Legal Jurisdiction: Wyoming, United States of America
+
+Project: https://github.com/BlockchainCommons/bc-lethe-kit
+
+Date: 06/23/2021
+
+## 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 ./signed-cla/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-----
+
+iQEzBAEBCAAdFiEEVaJL4K7l20FSxqQQjjo2gxcmmrQFAmDTgZ4ACgkQjjo2gxcm
+mrRTpQgAoFpCTvov11jIeyu4kNTbFy/lxdx5vXViWSvsPa2I/Q8TgTgWoAcBw84H
+lqCDweT9dFFf3XXh2NTpgpAZ+TYbzBQgC3lNMc9BhKfgUOHnR+UFwAj7HyD2fPiE
+e92BCLEmuSxk4ls8KFZ0wLySXNZGSehOb/K0EdYbw1szPQGEVmOvZq+vTkPfEDqO
+XK3T81r5+YCwazQHNXbOwnpbVryqi700ndF8R7MTZ6Z1LqOKQCfXBLSBiDhQ8Wk6
+BhYbpXpJFGzlSrlfBG1jvQdUq2grAQ8CEhMprNJXPt294a6RAHMZ4bNz65OiAM4e
+d/AaQ/DlwNvVZM7ARxorsucuqYkQUA==
+=sF7Q
+-----END PGP SIGNATURE-----

CLA-signed/CLA.srahalh.F3A6CF9EFEEE0D4908CD72D44613300262C7313C.asc.txt

@@ -0,0 +1,97 @@
+# Contributor License Agreement
+
+Version 1.0
+
+Name: SAID RAHAL
+
+E-Mail: HOLA@SAIDRAHAL.COM
+
+Legal Jurisdiction: MADRID, SPAIN
+
+Project: https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line
+
+Date: 11/11/2021
+
+## 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 ./signed-cla/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 MESSAGE-----
+Version: Keybase OpenPGP v2.0.76
+
+yMXPAnicrVfNbxtFFE8pRWIFEhUXjkNTqR/y2kmQEIo41EnaxMhJTJp+oKhVxrtj
+7+DdGbMzG8twRUgceuDjiITEEcRfwI2vHhBCggPiipBA6gVx4Fp+b2ZtJ3HSUqlK
+lWZ33rz5vd/7vTdvv3325Exw+srzc0+0786/euKHH88VM/zO4PYsW9bK5rJdWJ2z
+poyEMoLVu7kQmVA2CK6L3Eit2Hx1Lgg2eCYW2dV6Y4Vt1dfqzSC4HK5zmS6ytc1m
+/RItuPfV5c31IGiKLk/Za0UuTSwjCy+LbL2+stVYqbCrrXpjIwhauX5TRHaRJdb2
+zWKt1pU2KdrVSGe1pVRHvSjhUi3rLNPK1JqC50qqbrgkbaSlCju5zkKbiJAsuIrD
+plQiCFa4Bcz5+Rr+LcwtzAfB7CxrFXlfG6xuJ9IwPoqQdeWeMGxyGCtPq7Bmc5nB
+OeuLPJPGsSAtU0LEhsFO57HImdWMR5HoW5YNWTTiErZkg0VpDdN9oZjRHTvgOdz5
+mBnw0m7g5l3hDsIGkaZYK8AbzHCwHdJRNuF2vE/v0bEyE1UXV5mzIGiwROSiPWRp
+mcVjY9KLQTBfZSwGdjW0CShlAxA/HYI7eKCLNGYaCPOBNASzk2OL8Ob9YS67ifUw
+RRYEC4/Bcx8ZVLa0arCIE92sLaALwXg7FcRcOor8JZxoivYobrjDb4fKkJ3zjywo
+wsQsskmOBRHVE47DLZFK3paptEPisVDIrLEuQQRgmkgElaYsF+mQ3FpSVHk6oDSQ
+0yFT2sJgT/fEwXV3YJ2UoIQxdBwSm0mH2wXLM9bhGcDw3HOXujrKi1QggYSZ7ZwZ
+6LyHY2LBOiAmkbk44y1unadSQiWRhSELGNA61dSFij+E+CTdM5H1Uz0kdijYKJWO
+dT1QeJXIPtOd40XpIJSYY+3iBnSeGuTeCd2tefDjcjPEjtOLkV1VhgNldGSMVQlT
+aEDnGSeVOFBS7dEKPRna44p24q/iU1EYwEM2XFT/Dz8k6UPQExoqIw4qnhCd9bmS
+YizEjoY2KNQO6jkTWoHC1LgTzUNPqsABdQ8Sn8z3t5WJmNEvvEKWx4W1WvCcw7XY
+rxVSF0m700EzOFRZ2netsl34hMOC5DsuV6A4mD/nMeFgz2UMVLaliql+D+IcnyV8
+mZTV5qoKxNxI0OoaJS5+AJkX88Qb0TGWvgaEqHC59Y3k0NZEe44P9JuB7yHELGUr
+0QNf110K41jYYNglsMFSdJlJV5loltIK5Uz1LCprR9EUjbAuu8yIUBlPGD0OCjHg
+1AtL2Rke2bBd0nx5RNggs0zEErjToddJy3XKxyKSBuspUDjVhKeD0w+P7Qh1OLyb
+dBde1UUeiUcHvV/KaHuxgLPYd2BxKBEVAEA7HF80WKNrfw/Tirs/PDzOJpcGzHaW
+0kKwTd4D/4WKJLouODCsnWv1tvBXkEUwvsnSvNLGBs17AAXrqs67tVQaiz5riihB
+x3LI1hvbo2saDXigQ/JkE7SwMEp5QVf11ZV9FthS7/MI/40GstEUtlCdq/jNdL2X
+WNd1LNKxKQY1/Dy4EksOqbrHNLoHVbJ3btywHqVCSy73cY7CTPVoBkDVUCtFinwD
+HFM/UceKNGAEs02Om/HixYt1g7swH/GY8gH8pXqA7E4Vpy9idGF3JdhEF9bd9yhr
+EtmQIsWOWJI5+NmkQAmpKrWwc0TLvXV+dlzrYXf0FundOVx3sPT1csAMZ+4cqXiY
+01QYGvf+wJ5JT4DaGA0mftxBMNSY6L6nuGKeYW40NIRw6kM0Sh7mxClFmslbPWF9
+fIVWRrUApz1J9dQpb22XiirSEAQhC8MQs7N297b3+sAvhwrrUBSQyu5Zhc+G3Qr+
+EBnKb9d3692zMXDvYprDQFtl2yRX57swJMXV1mr5F2W+oynt9BT5SZ/tdvtdYOJ5
+htND1BG+Ddz2METm+0h+tUbPIqYaqy0369U3Nq9trTa2164tbdTXL/vH1uqVxsbq
+5a3WVmNju8pNxMgyi3ddGSompJMJpssMs/8Q2WLe64Oj9/1VUnb6mlTJXUDl1lYB
+ZrbEW4UwlnLkaKFvC+zaWU7wvWR1H8fWL019A9EUd+s82WOKf7jpherXt5+cOR3M
+PHXqCfrcmwmefm70EfjPuydmPvjur/o7a3d+/vSTj/+8tn7z958+uv/K+63PFu+1
+f2lUb/z61cz91vdnvnjh9WfumuEf1+98eerev3//dvPDk2svfjP3efZy+N7efzAV
+HA0=
+=/+Rt
+-----END PGP MESSAGE-----

CLA.md

@@ -8,7 +8,7 @@ E-Mail: `$email`
 
 Legal Jurisdiction: Wyoming, United States of America
 
-Project: https://github.com/BlockchainCommons/bc-lethe-kit
+Project: https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line
 
 Date: `$date`
 
@@ -52,4 +52,4 @@ I promise not to offer contributions that contain or depend on the work of other
 
 ---
 
-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 ./signed-cla/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).
+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).

CONTRIBUTING.md

@@ -35,7 +35,7 @@ People *love* thorough bug reports. I'm not even kidding.
 
 Simple Pull Requests to fix typos, to document, or to fix small bugs are always welcome.
 
-We ask that more significant improvements to the project be first proposed before anybody starts to code as an [issue](./issues) or as a [draft Pull Request](./pulls), which is a [nice new feature](https://github.blog/2019-02-14-introducing-draft-pull-requests/) that gives other contributors a chance to point you in the right direction, give feedback on the design, and maybe discuss if related work is already under way.
+We ask that more significant improvements to the project be first proposed before anybody starts to code as an [issue](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/issues) or as a [draft Pull Request](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/pulls), which is a [nice new feature](https://github.blog/2019-02-14-introducing-draft-pull-requests/) that gives other contributors a chance to point you in the right direction, give feedback on the design, and maybe discuss if related work is already under way.
 
 ### Use a Consistent Coding Style
 
@@ -61,5 +61,5 @@ In short, when you submit code changes, your submissions are understood to be av
 ## References
 
 Portions of this CONTRIBUTING.md document were adopted from best practices of a number of open source projects, including:
-* [Facebook's Draft](https://github.com/facebook/draft-js/blob/a9316a723f9e918afde44dea68b5f9f39b7d9b00/CONTRIBUTING.md)
+* [Facebook's Draft](https://github.com/facebook/draft-js/blob/master/CONTRIBUTING.md)
 * [IPFS Contributing](https://github.com/ipfs/community/blob/master/CONTRIBUTING.md)

Chapter_word_counts.md

@@ -0,0 +1,109 @@
+## Translatable word counts by chapter
+
+Ignores code blocks and other non-translatable characters
+
+Chapter|Word Count
+---|---
+01_0_Introduction.md|1144
+01_1_Introducing_Bitcoin.md|2735
+02_0_Setting_Up_a_Bitcoin-Core_VPS.md|226
+02_1_Setting_Up_a_Bitcoin-Core_VPS_with_StackScript.md|2746
+02_2_Setting_Up_Bitcoin_Core_Other.md|254
+03_0_Understanding_Your_Bitcoin_Setup.md|248
+03_1_Verifying_Your_Bitcoin_Setup.md|773
+03_2_Knowing_Your_Bitcoin_Setup.md|517
+03_3_Setting_Up_Your_Wallet.md|1699
+03_3__Interlude_Using_Command-Line_Variables.md|347
+03_4_Receiving_a_Transaction.md|1479
+03_5_Understanding_the_Descriptor.md|1349
+04_0_Sending_Bitcoin_Transactions.md|176
+04_1_Sending_Coins_The_Easy_Way.md|1195
+04_2_Creating_a_Raw_Transaction.md|1720
+04_2__Interlude_Using_JQ.md|1956
+04_3_Creating_a_Raw_Transaction_with_Named_Arguments.md|413
+04_4_Sending_Coins_with_a_Raw_Transaction.md|1024
+04_4__Interlude_Using_Curl.md|1643
+04_5_Sending_Coins_with_Automated_Raw_Transactions.md|614
+04_6_Creating_a_Segwit_Transaction.md|1172
+05_0_Controlling_Bitcoin_Transactions.md|149
+05_1_Watching_for_Stuck_Transactions.md|595
+05_2_Resending_a_Transaction_with_RBF.md|1372
+05_3_Funding_a_Transaction_with_CPFP.md|827
+06_0_Expanding_Bitcoin_Transactions_Multisigs.md|155
+06_1_Sending_a_Transaction_to_a_Multisig.md|1764
+06_2_Spending_a_Transaction_to_a_Multisig.md|1079
+06_3_Sending_an_Automated_Multisig.md|613
+07_0_Expanding_Bitcoin_Transactions_PSBTs.md|169
+07_1_Creating_a_Partially_Signed_Bitcoin_Transaction.md|1470
+07_2_Using_a_Partially_Signed_Bitcoin_Transaction.md|1393
+07_3_Integrating_with_Hardware_Wallets.md|2150
+08_0_Expanding_Bitcoin_Transactions_Other.md|139
+08_1_Sending_a_Transaction_with_a_Locktime.md|1483
+08_2_Sending_a_Transaction_with_Data.md|580
+09_0_Introducing_Bitcoin_Scripts.md|196
+09_1_Understanding_the_Foundation_of_Transactions.md|989
+09_2_Running_a_Bitcoin_Script.md|863
+09_3_Testing_a_Bitcoin_Script.md|1000
+09_4_Scripting_a_P2PKH.md|838
+09_5_Scripting_a_P2WPKH.md|845
+10_0_Embedding_Bitcoin_Scripts_in_P2SH_Transactions.md|170
+10_1_Understanding_the_Foundation_of_P2SH.md|1164
+10_2_Building_the_Structure_of_P2SH.md|1284
+10_3_Running_a_Bitcoin_Script_with_P2SH.md|323
+10_4_Scripting_a_Multisig.md|1016
+10_5_Scripting_a_Segwit_Script.md|750
+10_6_Spending_a_P2SH_Transaction.md|384
+11_0_Empowering_Timelock_with_Bitcoin_Scripts.md|108
+11_1_Understanding_Timelock_Options.md|557
+11_2_Using_CLTV_in_Scripts.md|1197
+11_3_Using_CSV_in_Scripts.md|1470
+12_0_Expanding_Bitcoin_Scripts.md|99
+12_1_Using_Script_Conditionals.md|1120
+12_2_Using_Other_Script_Commands.md|407
+13_0_Designing_Real_Bitcoin_Scripts.md|116
+13_1_Writing_Puzzle_Scripts.md|998
+13_2_Writing_Complex_Multisig_Scripts.md|996
+13_3_Empowering_Bitcoin_with_Scripts.md|1467
+14_0_Using_Tor.md|116
+14_1_Verifying_Your_Tor_Setup.md|1568
+14_2_Changing_Your_Bitcoin_Hidden_Services.md|434
+14_3_Adding_SSH_Hidden_Services.md|330
+15_0_Talking_to_Bitcoind.md|254
+15_1_Accessing_Bitcoind_with_C.md|1238
+15_2_Programming_Bitcoind_with_C.md|1427
+15_3_Receiving_Bitcoind_Notifications_with_C.md|650
+16_0_Programming_with_Libwally.md|333
+16_1_Setting_Up_Libwally.md|559
+16_2_Using_BIP39_in_Libwally.md|939
+16_3_Using_BIP32_in_Libwally.md|959
+16_4_Using_PSBTs_in_Libwally.md|989
+16_5_Using_Scripts_in_Libwally.md|785
+16_6_Using_Other_Functions_in_Libwally.md|655
+16_7_Integrating_Libwally_and_Bitcoin-CLI.md|1380
+17_0_Talking_to_Bitcoind_Other.md|286
+17_1_Accessing_Bitcoind_with_Go.md|547
+17_2_Accessing_Bitcoind_with_Java.md|821
+17_3_Accessing_Bitcoind_with_NodeJS.md|393
+17_4_Accessing_Bitcoind_with_Python.md|1158
+17_5_Accessing_Bitcoind_with_Rust.md|829
+17_6_Accessing_Bitcoind_with_Swift.md|1503
+18_0_Understanding_Your_Lightning_Setup.md|192
+18_1_Verifying_Your_Lightning_Setup.md|1294
+18_2_Knowing_Your_lightning_Setup.md|399
+18_2__Interlude_Accessing_a_Second_Lightning_Node.md|886
+18_3_Setting_Up_a_Channel.md|1173
+19_0_Using_Lightning.md|146
+19_1_Generate_a_Payment_Request.md|968
+19_2_Paying_a_Invoice.md|604
+19_3_Closing_a_Channel.md|848
+19_4_Lightning_Network_Review.md|626
+A0_Appendices.md|112
+A1_0_Understanding_Bitcoin_Standup.md|420
+A2_0_Compiling_Bitcoin_from_Source.md|412
+A3_0_Using_Bitcoin_Regtest.md|980
+CLA.md|495
+CONTRIBUTING.md|529
+LICENSE-CC-BY-4.0.md|2716
+README.md|1705
+TRANSLATING.md|686
+TOTAL|89069

README.md

@@ -1,4 +1,4 @@
-# Learning Bitcoin from the Command Line 2.0.1
+# Learning Bitcoin from the Command Line 2.2.0
 ### _by Christopher Allen and Shannon Appelcline_
 
 ![](https://www.blockchaincommons.com/images/projects/lbtc-screen.png)
@@ -9,6 +9,13 @@ Learning Bitcoin from the Command Line is a tutorial for working with Bitcoin (a
 
 _This tutorial assumes that you have some minimal background of how to use the command line interface. If not, there are many tutorials available, and I have one for Mac users at https://github.com/ChristopherA/intro-mac-command-line._
 
+## Translations
+
+* [Portuguese](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/tree/portuguese-translation/pt/README.md) — v2.0.1 translation
+* [Spanish](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/tree/spanish-translation/es/README.md) - v2.0.1 translation
+
+If you'd like to make your own translation, please see [Contributing](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/tree/master#contributing), below.
+
 ## Table of Contents
 
 ### PART ONE: PREPARING FOR BITCOIN
@@ -46,17 +53,17 @@ _This tutorial assumes that you have some minimal background of how to use the c
   * [5.2: Resending a Transaction with RBF](05_2_Resending_a_Transaction_with_RBF.md)
   * [5.3: Funding a Transaction with CPFP](05_3_Funding_a_Transaction_with_CPFP.md)
 * [6.0: Expanding Bitcoin Transactions with Multisigs](06_0_Expanding_Bitcoin_Transactions_Multisigs.md)
-  * [6.1: Sending a Transaction with a Multsig](06_1_Sending_a_Transaction_to_a_Multisig.md)
-  * [6.2: Spending a Transaction with a Multsig](06_2_Spending_a_Transaction_to_a_Multisig.md)
+  * [6.1: Sending a Transaction with a Multisig](06_1_Sending_a_Transaction_to_a_Multisig.md)
+  * [6.2: Spending a Transaction with a Multisig](06_2_Spending_a_Transaction_to_a_Multisig.md)
   * [6.3: Sending & Spending an Automated Multisig](06_3_Sending_an_Automated_Multisig.md)
 * [7.0: Expanding Bitcoin Transactions with PSBTs](07_0_Expanding_Bitcoin_Transactions_PSBTs.md)
   * [7.1: Creating a Partially Signed Bitcoin Transaction](07_1_Creating_a_Partially_Signed_Bitcoin_Transaction.md)
   * [7.2: Using a Partially Signed Bitcoin Transaction](07_2_Using_a_Partially_Signed_Bitcoin_Transaction.md)
   * [7.3: Integrating with Hardware Wallets](07_3_Integrating_with_Hardware_Wallets.md)
-* [8.0: Expanding Bitcoin Transactions in Other Ways](08_0_Expanding_Bitcoin_Transactions_Other.md)  
+* [8.0: Expanding Bitcoin Transactions in Other Ways](08_0_Expanding_Bitcoin_Transactions_Other.md)
   * [8.1: Sending a Transaction with a Locktime](08_1_Sending_a_Transaction_with_a_Locktime.md)
   * [8.2: Sending a Transaction with Data](08_2_Sending_a_Transaction_with_Data.md)
-  
+
 ### PART THREE: BITCOIN SCRIPTING
 
 **Status:** Finished. Updated for 0.20 and btcdeb.
@@ -86,7 +93,7 @@ _This tutorial assumes that you have some minimal background of how to use the c
   * [13.2: Writing Complex Multisig Scripts](13_2_Writing_Complex_Multisig_Scripts.md)
   * [13.3: Empowering Bitcoin with Scripts](13_3_Empowering_Bitcoin_with_Scripts.md)
 
-### PART FOUR: USING TOR
+### PART FOUR: PRIVACY
 
 **Status:** Finished.
 
@@ -95,45 +102,48 @@ _This tutorial assumes that you have some minimal background of how to use the c
   * [14.2: Changing Your Bitcoin Hidden Services](14_2_Changing_Your_Bitcoin_Hidden_Services.md)
   * [14.3: Adding SSH Hidden Services](14_3_Adding_SSH_Hidden_Services.md)
 
+* [15.0: Using i2p](15_0_Using_i2p.md)
+  * [15.1: Bitcoin Core as an I2P (Invisible Internet Project) service](15_1_i2p_service.md)
+
 ### PART FIVE: PROGRAMMING WITH RPC
 
 **Status:** Finished.
 
-* [15.0: Talking to Bitcoind with C](15_0_Talking_to_Bitcoind.md)
-  * [15.1: Accessing Bitcoind in C with RPC Libraries](15_1_Accessing_Bitcoind_with_C.md)
-  * [15.2: Programming Bitcoind in C with RPC Libraries](15_2_Programming_Bitcoind_with_C.md)
-  * [15.3: Receiving Notifications in C with ZMQ Libraries](15_3_Receiving_Bitcoind_Notifications_with_C.md)
-* [16.0: Programming Bitcoin with Libwally](16_0_Programming_with_Libwally.md)
-   * [16.1: Setting Up Libwally](16_1_Setting_Up_Libwally.md)
-   * [16.2: Using BIP39 in Libwally](16_2_Using_BIP39_in_Libwally.md)
-   * [16.3: Using BIP32 in Libwally](16_3_Using_BIP32_in_Libwally.md) 
-   * [16.4: Using PSBTs in Libwally](16_4_Using_PSBTs_in_Libwally.md)
-   * [16.5: Using Scripts in Libwally](16_5_Using_Scripts_in_Libwally.md)
-   * [16.6: Using Other Functions in Libwally](16_6_Using_Other_Functions_in_Libwally.md)
-   * [16.7: Integrating Libwally and Bitcoin-CLI](16_7_Integrating_Libwally_and_Bitcoin-CLI.md)
-* [17.0: Talking to Bitcoind with Other Languages](17_0_Talking_to_Bitcoind_Other.md)
-  * [17.1: Accessing Bitcoind with Go](17_1_Accessing_Bitcoind_with_Go.md)
-  * [17.2: Accessing Bitcoind with Java](17_2_Accessing_Bitcoind_with_Java.md)
-  * [17.3: Accessing Bitcoind with Node JS](17_3_Accessing_Bitcoind_with_NodeJS.md)
-  * [17.4: Accessing Bitcoind with Python](17_4_Accessing_Bitcoind_with_Python.md)
-  * [17.5: Accessing Bitcoind with Rust](17_5_Accessing_Bitcoind_with_Rust.md)
-  * [17.6: Accessing Bitcoind with Swift](17_6_Accessing_Bitcoind_with_Swift.md)
+* [16.0: Talking to Bitcoind with C](16_0_Talking_to_Bitcoind.md)
+  * [16.1: Accessing Bitcoind in C with RPC Libraries](16_1_Accessing_Bitcoind_with_C.md)
+  * [16.2: Programming Bitcoind in C with RPC Libraries](16_2_Programming_Bitcoind_with_C.md)
+  * [16.3: Receiving Notifications in C with ZMQ Libraries](16_3_Receiving_Bitcoind_Notifications_with_C.md)
+* [17.0: Programming Bitcoin with Libwally](17_0_Programming_with_Libwally.md)
+   * [17.1: Setting Up Libwally](17_1_Setting_Up_Libwally.md)
+   * [17.2: Using BIP39 in Libwally](17_2_Using_BIP39_in_Libwally.md)
+   * [17.3: Using BIP32 in Libwally](17_3_Using_BIP32_in_Libwally.md)
+   * [17.4: Using PSBTs in Libwally](17_4_Using_PSBTs_in_Libwally.md)
+   * [17.5: Using Scripts in Libwally](17_5_Using_Scripts_in_Libwally.md)
+   * [17.6: Using Other Functions in Libwally](17_6_Using_Other_Functions_in_Libwally.md)
+   * [17.7: Integrating Libwally and Bitcoin-CLI](17_7_Integrating_Libwally_and_Bitcoin-CLI.md)
+* [18.0: Talking to Bitcoind with Other Languages](18_0_Talking_to_Bitcoind_Other.md)
+  * [18.1: Accessing Bitcoind with Go](18_1_Accessing_Bitcoind_with_Go.md)
+  * [18.2: Accessing Bitcoind with Java](18_2_Accessing_Bitcoind_with_Java.md)
+  * [18.3: Accessing Bitcoind with Node JS](18_3_Accessing_Bitcoind_with_NodeJS.md)
+  * [18.4: Accessing Bitcoind with Python](18_4_Accessing_Bitcoind_with_Python.md)
+  * [18.5: Accessing Bitcoind with Rust](18_5_Accessing_Bitcoind_with_Rust.md)
+  * [18.6: Accessing Bitcoind with Swift](18_6_Accessing_Bitcoind_with_Swift.md)
 
 ### PART SIX: USING LIGHTNING-CLI
 
 **Status:** Finished.
 
-* [18.0: Understanding Your Lightning Setup](18_0_Understanding_Your_Lightning_Setup.md)
-  * [18.1: Verifying Your c-lightning Setup](18_1_Verifying_Your_Lightning_Setup.md)
-  * [18.2: Knowing Your c-lightning Setup](18_2_Knowing_Your_lightning_Setup.md)
-     * [Interlude: Accessing a Second Lightning Node](18_2__Interlude_Accessing_a_Second_Lightning_Node.md)
-  * [18.3: Creating a Lightning Channel](18_3_Setting_Up_a_Channel.md)
-* [19.0: Using Lightning](19_0_Using_Lightning.md)
-  * [19.1: Generating a Payment Request](19_1_Generate_a_Payment_Request.md)
-  * [19.2: Paying an Invoice](19_2_Paying_a_Invoice.md)
-  * [19.3: Closing a Lighnting Channel]((19_3_Closing_a_Channel.md))
-  * [19.4: Expanding the Lightning Network](19_4_Lightning_Network_Review.md)
-   
+* [19.0: Understanding Your Lightning Setup](19_0_Understanding_Your_Lightning_Setup.md)
+  * [19.1: Verifying Your c-lightning Setup](19_1_Verifying_Your_Lightning_Setup.md)
+  * [19.2: Knowing Your c-lightning Setup](19_2_Knowing_Your_lightning_Setup.md)
+     * [Interlude: Accessing a Second Lightning Node](19_2__Interlude_Accessing_a_Second_Lightning_Node.md)
+  * [19.3: Creating a Lightning Channel](19_3_Setting_Up_a_Channel.md)
+* [20.0: Using Lightning](20_0_Using_Lightning.md)
+  * [20.1: Generating a Payment Request](20_1_Generate_a_Payment_Request.md)
+  * [20.2: Paying an Invoice](20_2_Paying_a_Invoice.md)
+  * [20.3: Closing a Lighnting Channel]((20_3_Closing_a_Channel.md))
+  * [20.4: Expanding the Lightning Network](20_4_Lightning_Network_Review.md)
+
 ### APPENDICES
 
 **Status:** Finished.
@@ -142,12 +152,41 @@ _This tutorial assumes that you have some minimal background of how to use the c
   * [Appendix I: Understanding Bitcoin Standup](A1_0_Understanding_Bitcoin_Standup.md)
   * [Appendix II: Compiling Bitcoin from Source](A2_0_Compiling_Bitcoin_from_Source.md)
   * [Appendix III: Using Bitcoin Regtest](A3_0_Using_Bitcoin_Regtest.md)
-  
+
 ## Status - Beta
 
-v2.0.1 of **Learning Bitcoin from the Command Line** is feature complete. It may still be undergoing third-party review or editing, but it can be used for learning.
+v2.1.0 of **Learning Bitcoin from the Command Line** is feature complete and has undergone full editing and integration. It is ready for learning
 
 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).
+* Added fixes to wallet usage from 0.21
+* Updated install to new Bitcoin Scripts for 22.0
+* Incorporated numerous fixes revealed by first translation projects
+
+#### 2.0.1 (June 15, 2021)
+
+* Numerous small patches following 2.0
+* Intended as baseline for translations (2.2.0), but 2.1.0 material on i2p slipped in
+
+#### 2.0.0 (November 3, 2020)
+
+* Second major release of Learning Bitcoin
+* Added material on Segwit, Tor, hardware wallets, lightning, regtest
+* Completely previous unfinished work on programming using a variety of languages
+
+#### 1.0.0 (pre-2020)
+
+* Original, extensive but incomplete version
+* Contained comprehensive sections on setup, bitcoin-cli, and scripting
 
 ## Origin, Authors, Copyright & Licenses
 
@@ -157,21 +196,24 @@ Unless otherwise noted (either in this [/README.md](./README.md) or in the file'
 
 *Learning Bitcoin from the Command Line* is a project of [Blockchain Commons](https://www.blockchaincommons.com/). We are proudly a "not-for-profit" social benefit corporation committed to open source & open development. Our work is funded entirely by donations and collaborative partnerships with people like you. Every contribution will be spent on building open tools, technologies, and techniques that sustain and advance blockchain and internet security infrastructure and promote an open web.
 
-To financially support further development of `$projectname` and other projects, please consider becoming a Patron of Blockchain Commons through ongoing monthly patronage as a [GitHub Sponsor](https://github.com/sponsors/BlockchainCommons). You can also support Blockchain Commons with bitcoins at our [BTCPay Server](https://btcpay.blockchaincommons.com/).
+To financially support further development of *Learning Bitcoin from the Command Line* and other projects, please consider becoming a Patron of Blockchain Commons through ongoing monthly patronage as a [GitHub Sponsor](https://github.com/sponsors/BlockchainCommons). You can also support Blockchain Commons with bitcoins at our [BTCPay Server](https://btcpay.blockchaincommons.com/).
 
 ## Contributing
 
 We encourage public contributions through issues and pull requests! Please review [CONTRIBUTING.md](./CONTRIBUTING.md) for details on our development process. All contributions to this repository require a GPG signed [Contributor License Agreement](./CLA.md).
 
+if you would like to provide a translation of Learning Bitcoin into another language, please additionally see [TRANSLATING.md](./TRANSLATING.md).
+
 ### Discussions
 
 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.
 
@@ -183,17 +225,39 @@ The following people directly contributed to this repository. You can add your n
 | Name              | Role                | Github                                            | Email                                 | GPG Fingerprint                                    |
 | ----------------- | ------------------- | ------------------------------------------------- | ------------------------------------- | -------------------------------------------------- |
 | Christopher Allen | Lead Author | [@ChristopherA](https://github.com/ChristopherA) | \<ChristopherA@LifeWithAlacrity.com\> | FDFE 14A5 4ECB 30FC 5D22  74EF F8D3 6C91 3574 05ED |
-| Shannon Appelcline |  Lead Author | [@shannona](https://github.com/shannona) | \<shannon.appelcline@gmail.com\> | 7EC6 B928 606F 27AD | 
+| Shannon Appelcline |  Lead Author | [@shannona](https://github.com/shannona) | \<shannon.appelcline@gmail.com\> | 7EC6 B928 606F 27AD |
 
 
 Additional contributions are listed below:
 
 | Role                | Names                                    |
 | ------------------- | ---------------------------------------- |
-| ***Contributors:*** | [gg2001](https://github.com/gg2001) (Go, Node.js sections), [gorazdko](https://github.com/gorazdko) (Rust section), [Javier Vargas](https://github.com/javiervargas) (C, Java, Lightning, Tor sections), [jodobear](https://github.com/jodobear) (Appendix: Compiling Bitcoin, Python section)                                   |
+| ***Contributors:*** | [gg2001](https://github.com/gg2001) (Go, Node.js sections), [gorazdko](https://github.com/gorazdko) (Rust section), [Javier Vargas](https://github.com/javiervargas) (C, Java, Lightning, Tor sections), [jodobear](https://github.com/jodobear) (Appendix: Compiling Bitcoin, Python section), [Prayank](    https://github.com/prayank23) (i2p sections)                               |
 | ***Reviewers:***    | Glen Willem [@gwillem](https://github.com/gwillem) |
 | ***Sponsors:***     | Blockstream Corporation                  |
 
+### Translation Credits
+
+Thanks to the volunteers who spent extensive time writing and reviewing other-language translations of the original English-language course.
+
+#### Portuguese Translation
+
+| Name              | Role                | Github                                            | 
+| ----------------- | ------------------- | ------------------------------------------------- | 
+| Namcios | Translator & Reviewer | [@namcios](https://github.com/namcios) | 
+| Korea | Translator & Reviewer | [@KoreaComK](https://github.com/KoreaComK) | 
+| Luke Pavsky | Translator & Reviewer | [@lukedevj](https://github.com/lukedevj) | 
+| hgrams | Translator & Reviewer | [@hgrams](https://github.com/hgrams) | 
+
+#### Spanish Translation
+
+ Name | Role | GitHub |
+| ---------- | -------- | ------------ |
+| Ian Culp | Translator & Reviewer | [@icculp](https://github.com/icculp) |
+| Maxi Goyheneche | Translator | [@maxcrowar](https://github.com/maxcrowar) |
+| Said Rahal | Translator | [@srahalh](https://github.com/srahalh) |
+| César A. Vallero | Translator & Reviewer | [@csralvall](https://github.com/csralvall) |
+| Javier Vargas | Translator & Reviewer | [@javiervargas](https://github.com/javiervargas) |
 
 ## Responsible Disclosure
 

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,25 +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)
+## 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_
+

TRANSLATING.md

@@ -0,0 +1,113 @@
+# Translating Learning Bitcoin from the Command Line
+
+Thank you for your interest in translating Learning Bitcoin from the Command Line! What follows is our standard procedure for doing so. If you have any questions, please file an Issue.
+
+1. **Please Follow Our Normal Contributor Procedure.**
+   * Read over [CONTRIBUTING.md](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/CONTRIBUTING.md).
+   * Fill out a [Contributor License Agreement](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/CLA.md), sign it with GPG, and submit it as a PR. Be sure this is done for everyone who contributes to the translation.
+1. **Choose a Release.**  
+   * Choose a [Release](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/releases) as the basis of your translation. We generally suggest the latest release. This will ensure the consistency of all the files in your translation, will insulate you from any changes we make, and will make it easy to see what has changed when we create a new release. 
+   * If it looks like there hasn't been a new Release in a while, file an Issue saying you're interested in starting a new translation, and asking if it would make sense for there to be a new Release milestone before you do so. If there's been anything notable, and we're not in the middle of things, we'll likely create a new patch or minor version. If we're in the middle of things, we'll just suggest you use the previous Release.
+   * Label your table of contents and each chapter or section with the release used.
+1. **Request a Branch.**
+   * File an [Issue](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/issues) requesting a new branch for your translation.
+   * This will be the master place for us to collect work on the translation over time.
+   * We will create a top-level directory for your complete translation using the [ISO 639-1 language code](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes), for example `es` (Spanish), `fr` (French), or `pt` (Portuguese). Work should be done in that directory.
+1. **Fork the Branch.**
+   * Once we've created a translation branch, you'll then want to fork that into your own GitHub account.
+   * Generally, we suggest that you create one working branch off that translation branch for each separate chapter. This will allow you to work through the process of write/review/revise for each individual chapter without it getting tangled up with your new content for future chapters, and will allow us to merge the chapters as they're completed, which is our preference, and will help everyone to keep track of where things our.
+   * Make sure you [sign your commits](https://docs.github.com/en/github/authenticating-to-github/managing-commit-signature-verification/signing-commits).
+1. **Submit PRs a Chapter at a Time.**
+   * Submit your PRs for the translation from your working fork to our translation branch in batches of no more than a single chapter at a time.
+   * Submit in smaller batches if it makes sense, for example because different people are writing different sections.
+   * Again, we suggest that there be a branch for each chapter, so when you submit your PR for one chapter, you'll usually then create a branch for the next chapter.
+1. **Request Approval from a Native Speaker.**
+   * No one can ever do a great edit of their own work, so we require each section to be approved by someone other than the original translator.
+
+   * This fundamentally means that any translation team _should_ contain at least two members, either one translator and one editor or else two people who trade off roles of translator and editor. If your team doesn't have a second member, we can put out a call for an editor/approver when you submit a PR, but it's possible that we won't be able to find one, and your hard work will languish, so it's s better to have one up front.
+
+   * To make the editing and reviewing process easier, independent, and streamlined, we suggest that you and the reviewer [request access to each other's forks](https://docs.github.com/en/enterprise-server@3.0/github/setting-up-and-managing-your-github-user-account/managing-access-to-your-personal-repositories/inviting-collaborators-to-a-personal-repository). Once invited, the _reviewer_ can then:
+
+     1. Easily checkout the PR into their local machine with [GitHub CLI](https://cli.github.com/) by doing `gh pr checkout <pr-number>`. This will automatically create a branch with the PR code for the reviewer to work on.
+
+     2. Then, perform their changes with signed commits.
+
+     3. And do `git push` after finishing the review to have the changes reflected in the PR.
+1. **Request Approval from the Blockchain Commons Team.**
+   * Once a chapter or section has been approved by a native speaker, request approval from someone on the Blockchain Commons team: currently [@shannona](https://github.com/shannona).
+1. **Continue!**
+   * Continue through the process, no more than one chapter at a time, until you have a full book.
+   * Be aware of the scope of the overall project. As of v2.01, Learning Bitcoin from the Command Line is 120,000 words in length. As a book, that'd be 250-400 pages, depending on the format and layout. (About 90,000 words of that is text to translate, with the remainder being code.) You want to make sure you have the time for that level of commitment before getting started.
+1. **Let Us Know When You're Done.**
+   * When you've completed your translation, file an issue to let us know that the translation branch is ready to be merged into the master.
+   * This will also let us know to announce the completed translation and link it into the master README
+1. **Update Your Translation with New Releases**
+   * It is our hope that translations will stay up to day with new releases, particularly major and minor releases, which are likely to include new content and updates. Currently, these only occur ever few years
+   * If you have decided to stop updating a translation, please let us know in an Issue, so that we can let the community know that we are looking for a new translator to continue updating a translation.
+
+### WORKFLOW EXAMPLE
+
+Chapter 3 has 7 subsections: 3.0, 3.1, 3.2, 3.3, Interlude 3.3, 3.4 and 3.5.
+Suppose you want to translate it to french.
+
+One approach to its translation would be to create a branch `french-3` from
+`french-translation` branch (created in the previous step). Then create a
+translation file for the 3.0 subsection. When you think that chapter 3.0 is
+ready for review you commit your changes and continue with the next file,
+subsection 3.1. Repeat the same process for this file and all the following.
+After this, your branch `french-3` will diverge from the base branch
+(`french-translation` in this case) by 7 different commits, one for each
+subsection, plus some more commits if you forgot to make some changes or need
+to correct others.  At this point you are ready to push your changes to your
+fork and open a pull request to the original repository.
+
+In the review process you will discuss some decisions with your reviewer and
+introduce new changes in the form of commits if you have to change some parts
+of your modifications.  Don't forget to commit those changes in meaningful
+chunks and push them to your fork.  After polishing your changes, your reviewer
+will accept your changes and it will request the merge of those changes on the
+`french-translation` branch.  Note that you can also push your changes and
+create your pull request after your first commit. This will allow the reviewer
+to start reviewing before you finish all chapter translation.
+
+You can track the state of the translation of that particular chapter in the 
+body of the pull request, with the following template:
+
+```
+This pull request creates the <translated_language> version of the chapter
+<chapter_number> of Learning-Bitcoin-from-the-Command-Line.
+
+Things to check:
+- Respect filenames and chapter names from translated [README](local/path/to/README).
+- Correct translation.
+- Term consistency: review ["translation memory"](local/path/to/file) file.
+- Good punctuation.
+- Correct linking.
+- Nice formatting.
+
+| Sub chapter   |       Translated        |         Reviewed        |          Done           |
+| ------------- |   :--------------:      |    :--------------:     |    :--------------:     |
+| _0_           | <ul><li> [ ] </li></ul> | <ul><li> [ ] </li></ul> | <ul><li> [ ] </li></ul> |
+| _1_           | <ul><li> [ ] </li></ul> | <ul><li> [ ] </li></ul> | <ul><li> [ ] </li></ul> |
+| _2_           | <ul><li> [ ] </li></ul> | <ul><li> [ ] </li></ul> | <ul><li> [ ] </li></ul> |
+| _3_           | <ul><li> [ ] </li></ul> | <ul><li> [ ] </li></ul> | <ul><li> [ ] </li></ul> |
+| _etc_         | <ul><li> [ ] </li></ul> | <ul><li> [ ] </li></ul> | <ul><li> [ ] </li></ul> |
+```
+
+### FINAL SUGGESTIONS:
+- _Keep lines under 80 characters_. Markdown parser will format them right
+  (double check that) and the review process will be easier.
+- _Translate `README.md` file first_ and use it as reference for the translation
+  of all the following chapter names, filenames and link names.  The README
+  represents the state of the master branch at the moment of begin the
+  translation process. It will be consulted by all translators to know how to
+  translate file and chapter names. Try to reach an agreement with the other
+  translators about those names before writing any chapter and keep further
+  changes of this file to minimum.
+- _Create a "translation memory" file_ with special words that could have
+  multiple translations under the same contexts and the translation chosen for
+  them. Good candidates to be in this list would be domain specific words,
+  like: multisig, input, output, script, timelock, locktime, hash, etc.
+
+
+Again, thank you!

es/01_0_Introduccion.md

@@ -0,0 +1,63 @@
+# Capítulo uno: Introducción al aprendizaje de Bitcoin Core (y Lightning) desde la línea de comandos
+
+## Introducción
+
+La forma en que realizamos pagos por bienes y servicios ha cambiado drásticamente en las últimas décadas. Donde antes todas las transacciones se realizaban a través de efectivo o cheques, ahora distintos métodos de pago electrónico son la norma. Sin embargo, la mayoría de estos pagos electrónicos aún se realizan a través de sistemas centralizados, donde las compañías de tarjetas de crédito, los bancos o incluso las instituciones financieras basadas en Internet como Paypal mantienen listas de transacciones largas e individualmente correlacionadas lo que les da el poder de censurar las transacciones que no les gustan.
+
+Estos riesgos de centralización fueron algunos de los principales catalizadores detrás de la creación de las criptomonedas, el primero y más exitoso proyecto es Bitcoin. Bitcoin ofrece seudoanonimato; dificulta la correlación de transacciones y hace que la censura por parte de entidades individuales sea casi imposible. Estas ventajas la han convertido en una de las monedas de más rápido crecimiento en el mundo. Ese crecimiento, a su vez, ha convertido a Bitcoin en una empresa en marcha entre empresarios y desarrolladores, ansiosos por crear nuevos servicios para la comunidad de Bitcoin.
+
+Si eres uno de esos emprendedores o desarrolladores, este curso es para ti, porque se trata de aprender a programar Bitcoin. Es un curso introductorio que explica todos los matices y características de Bitcoin a medida que avanza. También toma un rumbo muy específico, al ofrecer lecciones sobre cómo trabajar directamente con Bitcoin Core y con el servidor c-lightning usando sus interfaces RPC.
+
+¿Por qué no utilizar algunas de las bibliotecas más completas que se encuentran en varios lenguajes de programación? ¿Por qué no crear el tuyo propio desde cero? Porque empezar a trabajar con criptomonedas puede ser peligroso. No hay redes de seguridad. Si accidentalmente paga de más en sus tarifas o pierde una llave de firma o crea una transacción no válida o comete una cantidad de errores potenciales, entonces sus monedas desaparecerán para siempre. Gran parte de esa responsabilidad, por supuesto, recaerá en usted como programador de criptomonedas, aunque puede minimizarse el riesgo trabajando con las interfaces de criptomonedas más sólidas, seguras y probadas, las creadas por los propios equipos de programación de criptomonedas: bitcoind y lightningd.
+
+Por lo tanto, gran parte de este libro analiza cómo crear un script de Bitcoin (y Lightning) directamente desde la línea de comandos. Algunos capítulos posteriores tratan sobre lenguajes de programación más sofisticados, pero nuevamente continúan interactuando directamente con los demonios bitcoind y lightningd usando RPC o interactuando con los archivos que crean. Esto le permite pararse sobre los hombros de gigantes y utilizar la tecnología de forma confiable para aprender a crear sus propios sistemas confiables.
+
+# Nivel de habilidad requerido
+
+No es necesario ser técnico para avanzar en la mayor parte de este curso. Todo lo que necesita es la confianza para ejecutar comandos básicos en la línea de comandos de UNIX. Si está familiarizado con cosas como ssh, cd y ls, el curso le proporcionará el resto.
+
+Una parte menor de este curso requiere conocimientos de programación, y debe omitir esas secciones si es necesario como se explica en la siguiente sección.
+
+## Resumen de temas
+
+Este libro se divide a grandes rasgos en las siguientes secciones:
+
+| Parte | Descripción | Habilidades |
+|-------|---------|---------|
+| **Primera parte: Primera parte: prepararse para Bitcoin** | Comprender los conceptos básicos de Bitcoin y configurar un servidor para su uso. | Línea de comandos | 
+| **Segunda parte: Uso de Bitcoin-CLI** | Usando el Bitcoin-CLI para crear transacciones. | Línea de comandos |
+| **Tercera parte: Secuencias de comandos de Bitcoin** | Ampliando su trabajo de Bitcoin con scripts | Conceptos de programación |
+| **Parte Cuatro: Uso de Tor** | Mejorando la seguridad de su nodo con Tor | Línea de comandos |
+| **Parte Cinco: Programación con RPC** | Accediendo a RPC desde C y otros lenguajes | Programación en lenguaje C |
+| **Parte Seis: Uso de Lightning-CLI** | Uso de Lightning-CLI para crear transacciones. | Línea de comandos |
+| **Apendices** | Utilizando configuraciones de Bitcoin menos comunes | Linea de comandos |
+
+# Cómo utilizar este curso
+
+Así que ¿Por dónde se empieza? Este libro está destinado principalmente para leerse de forma secuencial. Simplemente se debe seguir el enlace llamado "¿Qué sigue?" al final de cada sección y / o hacer clic en los enlaces de las secciones individuales en cada página de capítulo. Obtendrá una mejor comprensión de este curso si realmente configura un servidor Bitcoin (siguiendo el Capítulo 2) y luego repasa todos los ejemplos a lo largo del libro: probar ejemplos es una excelente metodología de aprendizaje.
+
+Si tiene diferentes niveles de habilidad o desea aprender cosas diferentes, puede pasar directamente a diferentes partes del libro:
+
+* Si ya tiene un entorno de Bitcoin listo para ser utilizado, vaya al [Capítulo Tres: Comprensión de la configuración de Bitcoin.](03_2_Conociendo_Su_Configuracion_Bitcoin.md)
+* Si solo le interesan las secuencias de comandos de Bitcoin, vaya al [Capítulo nueve: Introducción a las secuencias de comandos de Bitcoin.](09_0_Introduciendo_Bitcoin_Scripts.md)
+* Si solo desea leer sobre el uso de lenguajes de programación, vaya al [Capítulo dieciséis: Comunicarse con el servidor Bitcoin.](16_0_Hablando_a_Bitcoind_con_C.md)
+* Si, por el contrario, no quiere hacer nada relativo a programación, definitivamente omita los capítulos 15-17 mientras lee, y tal vez omita los capítulos 9-13. El resto del curso aún debería tener sentido sin ellos.
+* Si solo está interesado en Lightning, pase al [Capítulo diecinueve: Comprensión de la configuración de Lightning.](19_0_Entendiendo_Su_Configuracion_Lightning.md)
+* Si desea leer el contenido nuevo más importante agregado para la versión 2 del curso (2020), a continuación de la versión 1 (2017), lea [§3.5: Comprensión de los descriptores](03_5_Entendiendo_El_Descriptor.md), [§4.6: Creación de una transacción SegWit](04_6_Creando_una_Transaccion_Segwit.md), [Capítulo 7: Expansión de Bitcoin con PSBT](07_0_Expandiendo_las_Transacciones_Bitcoin_con_PSBTs.md), [§9.5: Scripting con P2WPKH](09_5_Codificando_una_P2WPKH.md), [§10.5: Scripting con SegWit Script](10_5_Codificando_un_Script_Segwit.md), [Capítulo 14: Usando Tor](14_0_Usando_Tor.md), [Capítulo 15: Usando i2p](15_0_Usando_i2p.md), [Capítulo 16: Interactuando con Bitcoind con C](16_0_Hablando_a_Bitcoind_con_C.md), [Capítulo 17: Programando con Libwally](17_0_Programando_Bitcoin_con_Libwally.md), [Capítulo Dieciocho: Interactuando con Bitcoind con otros lenguajes](17_0_Programando_Bitcoin_con_Libwally.md), [Capítulo diecinueve: Comprensión su configuración de Lightning Network](19_0_Entendiendo_Su_Configuracion_Lightning.md) y [Capítulo Veinte: Uso de Lightning.](20_0_Usando_Lightning.md)
+
+# Por qué utilizar este curso
+
+Obviamente está trabajando en este curso porque está interesado en Bitcoin. Además de impartir conocimientos básicos, este curso también ha ayudado a los lectores a unirse (o crear) proyectos de código abierto y a obtener trabajos a nivel inicial en la programación de Bitcoin. Varios pasantes de Blockchain Commons aprendieron sobre Bitcoin en este curso, al igual que algunos miembros de nuestro equipo de programación.
+
+# Cómo apoyar este curso
+
+* Utilice la sección de [Problemas](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/issues) para cualquier pregunta. Blockchain Commons no tiene un equipo de soporte activo, por lo que no podemos abordar problemas o consultas individuales, pero los revisaremos a tiempo y los usaremos para mejorar las iteraciones futuras del curso.
+* Utilice la sección de [PR's](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/pulls) para corregir errores tipográficos o comandos incorrectos (o modificados). Para cambios técnicos o de línea de comandos, es muy útil si también usa los comentarios en los PR's para explicar las razones por las cuales hizo sus cambios y facilitar o evitar la investigación.
+* Utilice el [área de discusión](https://github.com/BlockchainCommons/Community/discussions) de nuestra comunidad para hablar sobre carreras y habilidades. Blockchain Commons ocasionalmente ofrece pasantías, como se explica en nuestro repositorio de la comunidad.
+* Conviértase en un [patrocinador](https://github.com/sponsors/BlockchainCommons) si encuentra útil este curso o si desea ayudar a educar a la próxima generación de programadores de blockchain.
+
+# ¿Que Sigue?
+
+Si desea una introducción básica a Bitcoin, criptografía de clave pública, ECC, blockchains y Lightning, lea el interludio [Introduciendo Bitcoin.](01_1_Introduciendo_Bitcoin.md)
+
+De lo contrario, si está listo para sumergirse en el curso, vaya a [Configuración de un Servidor privado Virtual de Bitcoin-Core.](02_0_Configurando_un_Bitcoin-Core_VPS.md)

es/01_1_Introduciendo_Bitcoin.md

@@ -0,0 +1,148 @@
+# Interludio: Presentación de Bitcoin
+
+Antes de que pueda comenzar a programar sobre Bitcoin (y Lightning), debe tener una comprensión básica de qué son y cómo funcionan. Esta sección proporciona una descripción general. Aparecerán muchas más definiciones dentro del mismo documento con la única intención de sentar las bases.
+
+## Acerca de Bitcoin
+
+Bitcoin es un sistema programático que permite la transferencia de la moneda bitcoin. Está habilitado por un sistema de nodos descentralizado de igual a igual, que incluye nodos completos, billeteras y mineros. De forma conjunta se aseguran de que las transacciones de bitcoin sean rápidas y no repudiadas. Gracias a la naturaleza descentralizada del sistema, estas transacciones también son resistentes a la censura y pueden proporcionar otras ventajas como el uso de seudónimos y la no correlación siempre y cuando se utilicen bien.
+
+Obviamente, Bitcoin es el corazón de este libro, pero también es el creador de muchos otros sistemas, incluidas otras blockchains y Lightning, que se detallan en este tutorial al igual que muchas otras criptomonedas como Ethereum y Litecoin que no son mencionadas.
+
+**_Cómo se transfieren las monedas?_** La moneda Bitcoin no son monedas físicas. En cambio, son una serie interminable de reasignaciones de propiedad. Cuando una persona envía monedas a otra, esa transferencia se almacena como una transacción. Es la transacción la que realmente registra la propiedad del dinero y no un token local en la billetera del propietario o en su máquina.
+
+**_A quién puede enviarle monedas?_** La gran mayoría de las transacciones de bitcoin implican el envío de monedas a personas individuales (o al menos a direcciones de bitcoin individuales). Sin embargo, se pueden utilizar metodologías más complejas para enviar monedas a grupos de personas o scripts. Estas diversas metodologías tienen nombres como P2PKH, multisig y P2SH.
+
+**_Cómo se almacenan las transacciones?_** Las transacciones se combinan en bloques de datos más grandes, que luego se escriben en el libro mayor de la cadena de bloques. Un bloque se construye de tal manera que no se puede reemplazar o reescribir una vez que se han construido varios bloques sobre él (después). Esto es lo que hace que la moneda bitcoin sean irreprochable: el libro de contabilidad global descentralizado donde todo se registra es efectivamente una base de datos permanente e inmutable.
+
+Sin embargo, el proceso de construcción de estos bloques es estocástico: es algo aleatorio, por lo que nunca puede estar seguro de que una transacción se colocará en un bloque específico. También puede haber cambios en los bloques si son muy recientes, pero solo si son muy recientes. Por lo tanto las cosas se vuelven realmente irreprochables (así como permanentes e inmutables) después de un poco de tiempo.
+
+**_Cómo se protegen las transacciones?_** Los fondos contenidos en una transacción de Bitcoin están bloqueados con un rompecabezas criptográfico. Estos acertijos están diseñados para que los pueda resolver fácilmente la persona a la que se enviaron los fondos. Esto se hace utilizando el poder de la criptografía de clave pública. Técnicamente, una transacción está protegida por una firma que demuestra que usted es el propietario de la clave pública a la que se envió una transacción: esta prueba de propiedad es el rompecabezas que se está resolviendo.
+
+Los fondos están aún más protegidos mediante el uso de hashes. Las claves públicas no se almacenan realmente en la cadena de bloques hasta que se gastan los fondos: son los hashes de clave pública los que se guardan. Esto significa que incluso si apareciera la computadora cuántica, las transacciones de Bitcoin permanecerían protegidas por este segundo nivel de criptografía.
+
+**_Cómo se crean las transacciones?_** El corazón de cada transacción de Bitcoin es un lenguaje de secuencias de comandos similar a FORTH que se utiliza para bloquear la transacción. Para volver a gastar el dinero, el destinatario debe proporcionar información específica al guión que demuestra que es el destinatario previsto.
+
+Sin embargo, estos scripts de Bitcoin son el nivel más bajo de funcionalidad de Bitcoin. Gran parte del trabajo de Bitcoin se realiza a través del demonio de Bitcoin llamado `bitcoind`, que es controlado mediante el uso de comandos RPC. Mucha gente envía esos comandos RPC a través del programa `bitcoin-cli`, que proporciona una interfaz aún más simple. Los no programadores ni siquiera se preocupan por estas minucias, sino que utilizan carteras programadas con interfaces más simples.
+
+## Bitcoin - En resumen
+
+Una forma de pensar en Bitcoin es como una secuencia de transacciones atómicas. Cada transacción es autenticada por un remitente con la solución a un rompecabezas criptográfico anterior que se almacenó como un script. La nueva transacción está bloqueada para el destinatario con un nuevo rompecabezas criptográfico que también se almacena como un script. Cada transacción se registra en un libro mayor global inmutable.
+
+## Acerca de la criptografía de clave pública
+
+La criptografía de clave pública es un sistema matemático para proteger los datos y demostrar la propiedad a través de un par asimétrico de claves vinculadas: la clave pública y la clave privada.
+
+Es importante para Bitcoin (y para la mayoría de los sistemas blockchain) porque es la base de gran parte de la criptografía que protege los fondos de criptomonedas. Una transacción de Bitcoin generalmente se envía a una dirección que es hash de una clave pública. Luego, el destinatario puede recuperar el dinero revelando tanto la clave pública como la clave privada.
+
+**_Qué es una clave pública?_** Una clave pública es la clave que se entrega a otras personas. En un sistema típico de clave pública, un usuario genera una clave pública y una clave privada, luego le da la clave pública a todos y cada uno. Esos destinatarios podrán cifrar información con la clave pública, pero no podrán descifrar con la misma clave pública debido a la asimetría del par de claves.
+
+**_Qué es una clave privada?_** Una clave privada está vinculada a una clave pública en un par de claves. En un sistema típico de clave pública, un usuario mantiene segura su clave privada y la usa para descifrar los mensajes que fueron encriptados con su clave pública antes de enviárselos.
+
+**_Qué es una firma?_** Un mensaje (o más comúnmente, un hash de un mensaje) se puede firmar con una clave privada, creando una firma. Cualquiera que tenga la clave pública correspondiente puede validar la firma, lo que verifica que el firmante sea el propietario de la clave privada asociada con la clave pública en cuestión. SegWit es un formato específico para almacenar una firma en la red Bitcoin que encontraremos más adelante.
+
+**_Qué es una función hash?_** Una función hash es un algoritmo que se utiliza con frecuencia en conjunto con la criptografía. Es una forma de asignar una gran cantidad arbitraria de datos a una pequeña cantidad fija de datos. Las funciones hash que se utilizan en criptografía son unidireccionales y resistentes a colisiones, lo que significa que un hash se puede vincular de manera confiable a los datos originales, pero los datos originales no se pueden regenerar a partir del hash. Por tanto, los hashes permiten la transmisión de pequeñas cantidades de datos para representar grandes cantidades de datos, que pueden ser importantes para la eficiencia y los requisitos de almacenamiento.
+
+Bitcoin aprovecha la capacidad de un hash para disfrazar los datos originales, lo que permite ocultar la clave pública real de un usuario, lo que hace que las transacciones sean resistentes a la computación cuántica.
+
+## Criptografía de clave pública: en resumen
+
+Una forma de entender la criptografía de clave pública es: una forma para que cualquier persona proteja los datos de manera que solo una persona autorizada pueda acceder a ellos y de manera que la persona autorizada pueda demostrar que tendrá ese acceso.
+
+## Sobre ECC
+
+ECC significa Criptografía de Curva Elíptica. Es una rama específica de la criptografía de clave pública que depende de cálculos matemáticos realizados utilizando curvas elípticas definidas sobre campos finitos. Es más complejo y más difícil de explicar que la criptografía de clave pública clásica (que utiliza números primos), pero tiene algunas ventajas interesantes.
+
+ECC no recibe mucha atención en este tutorial. Esto se debe a que este tutorial trata sobre la integración con los servidores Bitcoin Core y Lightning, que ya se han ocupado de la criptografía por el lector. De hecho, la intención de este tutorial es que no tenga que preocuparse en absoluto por la criptografía, porque eso es algo de lo que realmente quiere que se ocupen los expertos.
+
+**_Qué es una curva elíptica?_** Una curva elíptica es una curva geométrica que toma la forma `y`<sup>`2`</sup> = `x`<sup>`3`</sup>` + ax + b`. Se elige una curva elíptica específica seleccionando valores específicos de `a` y `b`. Luego, la curva debe examinarse cuidadosamente para determinar si funciona bien para la criptografía. Por ejemplo, la curva secp256k1 utilizada por Bitcoin se define como `a=0` y `b=7`.
+
+Cualquier línea que cruce una curva elíptica lo hará en 1 o 3 puntos ... y esa es la base de la criptografía de curva elíptica.
+
+**_Qué son los campos finitos?_** Un campo finito es un conjunto finito de números, donde toda suma, resta, multiplicación y división se define de modo que da como resultado otros números también en el mismo campo finito. Una forma sencilla de crear un campo finito es mediante el uso de una función de módulo.
+
+**_Cómo se define una curva elíptica sobre un campo finito?_** Una curva elíptica definida sobre un campo finito tiene todos los puntos de su curva extraídos de un campo finito específico. Esto toma la forma: `y`<sup>`2`</sup> `% field-size = (x`<sup>`3`</sup>` + ax + b) % field-size` El campo finito usado para secp256k1 es `2`<sup>`256`</sup>` - 2`<sup>`32`</sup>` - 2`<sup>`9`</sup>` - 2`<sup>`8`</sup>` - 2`<sup>`7`</sup>` - 2`<sup>`6`</sup>` - 2`<sup>`4`</sup>` - 1`.
+
+**_Cómo se utilizan las curvas elípticas en criptografía?_** En la criptografía de curva elíptica, un usuario selecciona un número muy grande (256 bits) como clave privada. Luego agrega un punto base establecido en la curva a sí misma tantas veces. (En secp256k1, el punto base es `G = 04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8`, que antepone las dos partes de la tupla con un `04` para decir que el punto de datos está en forma descomprimida. Si prefiere una definición geométrica recta, es el punto "0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798,0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199") El número resultante es la clave pública. Luego, se pueden usar varias fórmulas matemáticas para demostrar la propiedad de la clave pública, dada la clave privada. Al igual que con cualquier función criptográfica, esta es una trampilla: es fácil pasar de la clave privada a la clave pública y general es imposible pasar de la clave pública a la clave privada.
+
+Esta metodología en particular también explica por qué se utilizan campos finitos en curvas elípticas: asegura que la clave privada no crecerá demasiado. Tenga en cuenta que el campo finito para secp256k1 es un poco más pequeño que 256 bits, lo que significa que todas las claves públicas tendrán 256 bits de longitud, al igual que las claves privadas.
+
+**_Cuáles son las ventajas de ECC?_** La principal ventaja de ECC es que permite la misma seguridad que la criptografía clásica de clave pública con una clave mucho más pequeña. Una clave pública de curva elíptica de 256 bits corresponde a una clave pública tradicional (RSA) de 3072 bits.
+
+### ECC - En resumen
+
+Una forma de pensar en ECC es: una forma de habilitar la criptografía de clave pública que utiliza claves muy pequeñas y matemáticas muy poco conocidas.
+
+### Sobre Cadenas de bloques (Blockchains)
+
+Blockchain es la generalización de la metodología utilizada por Bitcoin para crear un libro mayor distribuido de forma global. Bitcoin es una cadena de bloques al igual que cualquier cantidad de monedas alternativas, cada una de las cuales vive en su propia red y escribe en su propia cadena. Las cadenas laterales como Liquid también son cadenas de bloques. Las cadenas de bloques ni siquiera necesitan tener nada que ver con las finanzas. Por ejemplo, ha habido muchas discusiones sobre el uso de blockchains para proteger identidades soberanas.
+
+Aunque debe comprender los conceptos básicos de cómo funciona una cadena de bloques para comprender cómo funcionan las transacciones en Bitcoin, no necesitará ir más allá. Debido a que las cadenas de bloques se han convertido en una amplia categoría de tecnología, es probable que esos conceptos básicos sean aplicables a muchos otros proyectos en este creciente sector tecnológico. Sin embargo, los comandos de programación específicos aprendidos en este libro no lo serán, ya que son bastante específicos de Bitcoin (y Lightning).
+
+**_Por qué se llama cadena?_** Cada bloque de la cadena de bloques almacena un hash del bloque anterior. Esto une el último bloque actual hasta el "bloque génesis" original a través de una cadena ininterrumpida. Es una forma de crear un orden absoluto entre datos posiblemente conflictivos. Esto también proporciona la seguridad de la cadena de bloques, porque cada bloque se apila sobre uno antiguo, lo que dificulta la recreación del bloque antiguo debido a los algoritmos de prueba de trabajo utilizados en la creación de bloques. Una vez que se han construido varios bloques sobre un bloque de la cadena, es esencialmente irreversible.
+
+**_Qué es una bifurcación (fork)?_** De forma ocasional se crean dos bloques aproximadamente al mismo tiempo. Esto crea temporalmente una bifurcación de un bloque, donde cualquiera de los bloques actuales podría ser el "real". De vez en cuando, una bifurcación puede expandirse para convertirse en dos bloques, tres bloques o incluso cuatro bloques de largo, pero rápidamente se determina que un lado de la bifurcación es el real y el otro queda "huérfano". Esto es parte del proceso estocástico de creación de bloques y demuestra por qué se deben construir varios bloques encima de un bloque antes de que pueda considerarse verdaderamente confiable y no repudiable.
+
+### Blockchain - En resumen
+
+Una forma de pensar en blockchain es: una serie enlazada de bloques de datos inmutables que se remontan al pasado. Otra forma es: una serie enlazada de bloques para ordenar datos de forma absoluta que podrían estar en conflicto.
+
+## Blockchain es adecuado para mí?
+
+Si desea realizar transacciones con bitcoins, obviamente Bitcoin es adecuado para usted. Sin embargo, de manera más generalizada, blockchain se ha convertido en una palabra de moda popular a pesar de que no es una fórmula mágica para todos los problemas técnicos. Dicho esto, hay muchas situaciones específicas en las que blockchain es una tecnología superior.
+
+Las cadenas de bloques probablemente serán útiles si:
+
+* Los usuarios no confían entre sí.
+  * Los usuarios existen a través de varias fronteras.
+* Los usuarios no confían en las autoridades centrales.
+  * Los usuarios quieren controlar sus propios destinos.
+* Los usuarios quieren tecnología transparente.
+* Los usuarios quieren compartir algo.
+  * Y: los usuarios quieren que lo que se comparte se registre de forma permanente.
+* Los usuarios quieren una finalidad de transacción rápida.
+  * Pero: los usuarios no necesitan la finalidad instantánea de las transacciones.
+
+Las cadenas de bloques probablemente no serán útiles si:
+
+* Los usuarios son de confianza:
+  * por ejemplo: las transacciones ocurren dentro de una empresa u organización.
+  * por ejemplo: las transacciones son supervisadas por una autoridad central.
+* Se requiere secreto:
+  * por ejemplo: la información debe ser secreta.
+  * por ejemplo: las transacciones deben ser secretas.
+  * por ejemplo: los Transactores deben ser secretos.
+  * A menos que: Se considere, analice y pruebe cuidadosamente una metodología para el secreto criptográfico.
+ * Los usuarios necesitan la finalidad instantánea de la transacción.
+  * por ejemplo: en menos de 10 minutos en una red similar a Bitcoin, en menos de 2.5 minutos en una red similar a Litecoin, en menos de 15 segundos en una red similar a Ethereum
+  
+Tenga en cuenta que todavía puede haber soluciones para algunas de estas situaciones dentro del ecosistema de Bitcoin. Por ejemplo, los canales de pago están abordando rápidamente cuestiones de liquidez y finalidad del pago.
+
+## Sobre Lightning
+
+Lightning es un protocolo de capa 2 que interactúa con Bitcoin para permitir a los usuarios intercambiar sus bitcoins "fuera de la cadena". Tiene ventajas y desventajas sobre el uso de Bitcoin por sí solo.
+
+Lightning Network también es el enfoque secundario de este tutorial. Aunque se trata principalmente de interactuar directamente con Bitcoin (y el `bitcoind`), presta algo de atención a Lightning porque es una tecnología de próxima aparición que probablemente se convierta en una alternativa popular a Bitcoin en un futuro próximo. Este libro adopta el mismo enfoque para Lightning que para Bitcoin: enseña cómo interactuar directamente con un demonio Lightning confiable desde la línea de comandos.
+
+A diferencia de Bitcoin, en realidad existen varias variantes de Lightning. Este tutorial utiliza la implementación de [c-lightning](https://github.com/ElementsProject/lightning) compatible con el estándar como su servidor Lightning de confianza.
+
+**_Qué es un protocolo de capa 2?_** Un protocolo de Bitcoin de capa 2 funciona sobre Bitcoin. En este caso, Lightning funciona sobre Bitcoin, interactuando con este a través de contratos inteligentes.
+
+**_Qué es un canal Lightning?_** Un canal Lightning es una conexión entre dos usuarios de Lightning. Cada uno de los usuarios bloquea una cierta cantidad de bitcoins en la cadena de bloques de Bitcoin utilizando una transacción multi-firma por ambos. Los dos usuarios pueden intercambiar bitcoins a través de su canal Lightning sin tener que escribir en la cadena de bloques de Bitcoin. Solo cuando quieren cerrar su canal liquidan sus bitcoins, según la división final de monedas.
+
+**_Qué es la red Lightning?_** Al juntar varios canales se crea la red Lightning. Esto permite que dos usuarios que no han creado un canal entre ellos intercambien bitcoins usando Lightning: el protocolo forma una cadena de Canales entre los dos usuarios, luego intercambia las monedas a través de la cadena mediante transacciones de tiempo bloqueado.
+
+**_Cuáles son las ventajas de Lightning?_** Lightning permite transacciones más rápidas con tarifas más bajas. Esto crea la posibilidad real de micropagos financiados con bitcoins. También ofrece una mejor privacidad, ya que está fuera de la cadena y solo se escribe el primer y último estado de la transacción en el libro de contabilidad inmutable de Bitcoin.
+
+**_Cuáles son las desventajas de la red Lightning?_** Lightning sigue siendo una tecnología muy nueva y no se ha probado tan a fondo como Bitcoin. No se trata solo de la implementación tecnológica, sino también el diseño en sí mismo se puede actuar de alguna manera inesperada.
+
+### Lightning - en resumen
+
+Una forma de pensar en Lightning es: una forma de realizar transacciones con bitcoins utilizando canales fuera de la cadena entre pares de personas, de modo que solo se tenga que escribir un primer y último estado en la cadena de bloques.
+
+## Resumen - Introduciendo Bitcoin
+
+Bitcoin es un sistema peer-to-peer que permite la transferencia de fondos a través de transacciones bloqueadas con acertijos. Estos acertijos dependen de la criptografía de curva elíptica de clave pública. Cuando generalizas las ideas detrás de Bitcoin, surge la cadena de bloques, una tecnología que actualmente está creciendo e innovando. Cuando expande las ideas detrás de Bitcoin, obtiene protocolos de capa 2 como Lightning, que expanden el potencial de la moneda.
+
+## Que Sigue?
+
+Continúe a través de la "Preparación para Bitcoin" con el [Capítulo dos: Configuración de un VPS Bitcoin-Core](02_0_Configurando_un_Bitcoin-Core_VPS.md)

es/02_0_Configurando_un_Bitcoin-Core_VPS.md

@@ -0,0 +1,28 @@
+
+# Capítulo dos: Creando un Servidor Privado Virtual de Bitcoin-Core
+
+Para iniciar con Bitcoin, se debe configurar una maquina ejecutando el software de Bitcoin. Los artículos en este capítulo describen como hacerlo, principalmente mediante el uso de un VPS (servidor privado virtual).
+
+
+## Objetivos de este capítulo
+
+Después de trabajar en este capítulo, un desarrollador podrá:
+
+   * Decidir entre los cinco tipos principales de nodos de Bitcoin
+   * Cree un nodo de Bitcoin para desarrollo.
+   * Cree una instancia local de la Blockchain de Bitcoin
+
+Los objetivos de apoyo incluyen la capacidad de:
+
+   * Comprender la configuración de red básica del VPS.
+   * Decidir qué prioridades de seguridad implementar.
+   * Comprender la diferencia entre nodos podados y no podados.
+   * Comprender la diferencia entre los nodos Mainnet, Testnet y Regtest.
+   * Interpretar los conceptos básicos del archivo de configuración de Bitcoin.
+   
+## Tabla de contenido
+
+En realidad, no es necesario leer este capítulo completo. Decida si desea ejecutar un StackScript para configurar un nodo en un VPS Linode (§2.2); o desea configurarlo en un entorno diferente, como en una máquina AWS o Mac (§2.3). Luego puede ir a la sección correspondiente. Información adicional sobre nuestras configuraciones sugeridas también se puede encontrar en el Apéndice I. 
+
+   * [Sección uno: Configurando un VPS Bitcoin-Core con Bitcoin Standup](02_1_Configurando_un_Bitcoin-Core_VPS_con_StackScript.md)
+   * [Sección dos: Configurando una máquina Bitcoin-Core por otros medios](02_2_Configurando_Bitcoin_Core_Otros.md)

es/02_1_Configurando_un_Bitcoin-Core_VPS_con_StackScript.md

@@ -0,0 +1,266 @@
+# 2.1: Configuración de un VPS Bitcoin-Core con Bitcoin Standup
+
+Este documento explica cómo configurar un VPS (Virtual Private Sever) para ejecutar un nodo Bitcoin en Linode.com, instalado usando un StackScript automatizado del [proyecto Bitcoin Standup.](https://github.com/BlockchainCommons/Bitcoin-Standup-Scripts). Solo necesita ingresar algunos comandos e iniciar su VPS. Casi inmediatamente después de arrancar, encontrará su nuevo nodo Bitcoin descargando bloques felizmente.
+
+> :warning: **ADVERTENCIA:** : No use un VPS para una billetera bitcoin con fondos reales significativos; ver [http://blog.thestateofme.com/2012/03/03/lessons-to-be-learned-from-the-linode-bitcoin-incident](http://blog.thestateofme.com/2012/03/03/lessons-to-be-learned-from-the-linode-bitcoin-incident). Es genial poder experimentar con transacciones reales de bitcoins en un nodo en vivo sin tener que conectar un servidor autohospedado en una red local. También es útil poder usar un iPhone o iPad para comunicarse a través de SSH con su VPS para realizar algunas tareas simples de bitcoin. Pero se requiere un mayor nivel de seguridad para fondos importantes.
+
+* Si desea comprender lo que hace esta configuración, lea el [Apéndice I: Entendiendo Bitcoin Standup](A1_0_Entendiendo_Bitcoin_Standup.md) mientras realiza la instalación.
+* Si, en cambio, desea configurar en una máquina que no sea un VPS Linode, como una máquina AWS o una Mac, puede ir a [2.2: Configuración de una máquina Bitcoin-Core a través de otros medios](02_2_Configurando_Bitcoin_Core_Otros.md)
+* Si ya tiene un nodo de Bitcoin en ejecución, vaya al [Capítulo tres: Entendiendo la configuración de Bitcoin](03_0_Entendiendo_Su_Configuracion_Bitcoin.md).
+
+## Introducción a Linode
+
+Linode es un servicio de alojamiento en la nube que ofrece servidores Linux rápidos y económicos con almacenamiento SSD. Los usamos para este tutorial principalmente porque sus StackScripts basados en BASH ofrecen una manera fácil de configurar automáticamente un nodo de Bitcoin sin problemas y sin complicaciones.
+
+### Configurar una cuenta de Linode
+
+Puede crear una cuenta de Linode yendo aquí:
+
+```
+https://www.linode.com
+```
+
+Si lo prefiere, el siguiente código de referencia le dará aproximadamente un mes de uso gratuito, ideal para aprender Bitcoin:
+
+```
+https://www.linode.com/?r=23211828bc517e2cb36e0ca81b91cc8c0e1b2d96
+```
+
+Deberá proporcionar una dirección de correo electrónico y luego precargar dinero de una tarjeta de crédito o PayPal para costos futuros.
+
+Cuando haya terminado, debe aterrizar en [https://cloud.linode.com/dashboard](https://cloud.linode.com/dashboard).
+
+### Considere la autenticación de dos factores
+
+La seguridad de su servidor no estará completa si las personas pueden ingresar a su cuenta de Linode, así que considere configurar la autenticación de dos factores para ello. Puede encontrar esta configuración en su página [Mi perfil: contraseña y autenticación](https://manager.linode.com/profile/auth). Si no hace esto ahora, cree un elemento TODO para volver y hacerlo más tarde.
+
+## Creando la imagen de Linode usando un StackScript
+
+### Cargar el StackScript
+
+Descargue el [Script Linode Standup](https://github.com/BlockchainCommons/Bitcoin-Standup-Scripts/blob/master/Scripts/LinodeStandUp.sh) del repositorio de [Scripts de Bitcoin Standup](https://github.com/BlockchainCommons/Bitcoin-Standup-Scripts). Este script básicamente automatiza todas las instrucciones de configuración para un servidor VPS de Bitcoin. Si prefiere ser particularmente prudente, léelo con atención. Si está satisfecho, puede copiar ese StackScript en su propia cuenta dirigíendose a la [página de Stackscripts](https://cloud.linode.com/stackscripts?type=account) en su cuenta de Linode y seleccionando [Crear nuevo Stackscript](https://cloud.linode.com/stackscripts/create). Dale un buen nombre (usamos `Bitcoin Standup`), luego copia y pega el script. Elija Debian 10 para su imagen de destino y "Guárdelo".
+
+### Realizar la configuración inicial
+
+Ahora está listo para crear un nodo basado en Stackscript.
+
+1. En la página [Stackscripts page](https://cloud.linode.com/stackscripts?type=account), haga clic en "..." a la derecha de su nuevo script y seleccione "Implementar nuevo Linode".
+2. Complete un nombre de host breve y completo.
+   * **Nombre de host corto.** Elija un nombre para su VPS. Por ejemplo, "mybtctest".
+   * **Nombre de host completamente calificado.** Si va a incluir este VPS como parte de una red con registros DNS completos, escriba el nombre de host con su dominio. Por ejemplo, "mybtctest.mydomain.com". De lo contrario, repita el nombre de host corto y agregue ".local", por ejemplo "mybtctest.local".
+3. Ingrese la contraseña para el usuario "standup".
+4. Elija un tipo de instalación en las opciones avanzadas. 
+   * **Tipo de instalación.** Probablemente sea "Mainnet" o "Pruned Mainnet" si está configurando un nodo para su uso y "Testnet" o "Pruned Testnet" si solo está probando. La mayor parte de este tutorial asumirá que eligió "Testnet podado", pero aún debería poder seguir con otros tipos. Consulte la [Synopsis](#synopsis-bitcoin-installation-types) para obtener más información sobre estas opciones. (Tenga en cuenta que si planea probar los capítulos Lightning, probablemente querrá usar un nodo sin podar, ya que trabajar con nodos podados en Lightning es dudoso. Consulte [§19.1](19_1_Verificando_Su_Configuracion_Lightning.md#compiling-the-source-code) para conocer los detalles).
+5. Complete cualquier otra opción avanzada apropiada.
+   * **X25519 Clave pública.** Esta es una clave pública para agregar a la lista de clientes autorizados de Tor. Si no lo usa, cualquiera que obtenga el código QR de su nodo puede acceder a él. Obtendrá esta clave pública de cualquier cliente que esté utilizando para conectarse a su nodo. Por ejemplo, si usa [FullyNoded 2](https://github.com/BlockchainCommons/FullyNoded-2), puede ir a su configuración y "Exportar clave pública de autenticación Tor V3" para usar aquí.
+  * **Clave SSH.** Copie aquí la clave SSH de su computadora local; esto le permite iniciar sesión automáticamente a través de SSH en la cuenta standup. Si aún no ha configurado una clave SSH en su computadora local, hay buenas instrucciones para ello en [Github](https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/). Es posible que también desee agregar su clave SSH en su Linode LISH (Linode Interactive Shell) yendo a su "Página de inicio de Linode / Mis preferencias / Configuración de LISH / Teclas de LISH". El uso de una clave SSH le brindará una forma más sencilla y segura de iniciar sesión en su servidor.
+  * **IP's permitidas por SSH** Esta es una lista de direcciones IP separadas por comas que se permitirán SSH en el VPS. Por ejemplo, "192.168.1.15,192.168.1.16". Si no ingresa ninguna IP, _su VPS no será muy seguro_. Será bombardeado constantemente por atacantes que intentan encontrar un puerta de entrada y es muy posible que lo logren.
+4. Seleccione una imagen
+   * **Imagen de destino.** Si siguió las instrucciones, esto solo le permitirá seleccionar "Debian 10" (aunque "Debian 9" también funcionó con versiones anteriores de este Stackscript y aún podría hacerlo).
+5. Elija una región donde se ubicará el Linode.
+
+*Las preguntas restantes tienen que ver con la mecánica de la implementación del VPS y deben dejarse como están con una excepción: aumente el disco de intercambio de 256 MB a 512 MB, para asegurarse de que tiene suficiente memoria para descargar la cadena de bloques.
+
+Finalmente, deberá completar una contraseña de root, que será la contraseña utilizada para la cuenta de root.
+
+### Elija otras opciones de standup
+
+Blockchain Commons se encuentra actualmente en el proceso de expandir sus scripts de Bitcoin Standup con opciones para instalar Lightning y otras aplicaciones de Bitcoin importantes. Eche un vistazo a las opciones adicionales y vea si son cosas con las que le gustaría jugar. En particular, si Lightning es una opción, sugerimos instalarlo, porque hará que el [Capítulo 19](19_0_Entendiendo_Su_Configuracion_Lightning.md) y el [Capítulo 20](20_0_Usando_Lightning.md) sean mucho más fáciles.
+
+### Elija un plan Linode
+
+A continuación, elegirás un plan Linode.
+
+Un Linode 4GB será suficiente para la mayoría de las configuraciones, incluidas: Mainnet podada, Testnet podada e incluso Testnet no podada. Todos usan menos de 50G de almacenamiento y 4GB es una cantidad cómoda de memoria. Esta es la configuración que sugerimos. Tiene un costo de $ 20 por mes.
+
+Si, en cambio, desea tener una Mainnet no podada en un VPS, deberá instalar un Linode con un disco de más de 280G (!), Que actualmente es el Linode de 16GB, que tiene 320G de almacenamiento y 16G de memoria. y cuesta aproximadamente $ 80 por mes. Nosotros no recomendamos esto.
+
+El siguiente cuadro muestra los requisitos mínimos
+
+| Configuración | Memoria | Almacenamiento | Linode |
+|-------|--------|---------|---------|
+| Mainnet | 2G | 280G | Linode 16GB |
+| Mainnet podada | 2G | ~5G | Linode 4GB |
+| Testnet | 2G | ~15G | Linode 4GB |
+| Testnet podada | 2G | ~5G | Linode 4GB |
+| Regtest | 2G | ~ | Linode 4GB |
+
+Tenga en cuenta que puede haber formas de reducir ambos costos.
+
+* Para las máquinas que sugerimos como **Linode 4GB**, es posible que pueda reducirlo a un Linode 2GB. Algunas versiones de Bitcoin Core han funcionado bien con ese tamaño, algunas ocasionalmente se han quedado sin memoria y luego se han recuperado, y algunas se han quedado sin memoria continuamente. Recuerde aumentar ese espacio de intercambio para maximizar las probabilidades de que esto funcione. Úselo bajo su propio riesgo.
+* Para la red Mainnet sin podar, que sugerimos como **Linode 16GB**, probablemente pueda arreglárselas con un Linode 4GB, pero agregue [Block Storage](https://cloud.linode.com/volumes) suficiente para almacenar la cadena de bloques. Esta es sin duda una mejor solución a largo plazo, ya que los requisitos de almacenamiento de la cadena de bloques de Bitcoin aumentan continuamente si no se poda, mientras que los requisitos de la CPU no lo hacen (o no en el mismo grado). Un almacenamiento de 320 GibiByte costaría $ 32 al mes, que combinado con un Linode 4GB cuesta $ 52 al mes, en lugar de $ 80, y lo que es más importante, puede seguir creciendo. No documentamos completamente esta configuración por dos razones (1) no sugerimos la configuración de la red principal sin podar, por lo que sospechamos que es una configuración mucho menos común y (2) no hemos probado cómo se comparan los volúmenes de Linodes con sus SSD intrínsecos en cuanto a rendimiento y uso. Pero hay documentación completa en la página de almacenamiento de bloques. Debería configurar el nodo Linode, ejecutar su stackscript, pero luego interrumpirlo para mover el almacenamiento de la cadena de bloques en exceso a un volumen recién añadido antes de continuar.
+
+### Hacer la configuración final
+
+Lo último que debe hacer es ingresar una contraseña de root. (¡Si se perdiste algo, se lo dirán ahora!)
+
+Haga clic en "Implementar" para inicializar sus discos y preparar su VPS. Toda la cola debería ejecutarse en menos de un minuto. Cuando haya terminado, debería ver en la "Cola de trabajos del host", y unos botones verdes de "Éxito" que indican "Crear disco desde StackScript - Configuración de contraseña para root" y "Crear sistema de archivos - Imagen de intercambio de 256 MB" que se ha terminado.
+
+Es posible que ahora desee cambiar el nombre de su VPS Linode del predeterminado `linodexxxxxxxx`. Vaya a la pestaña Configuración y cambie la etiqueta para que sea más útil, como el nombre de host corto de su VPS. Por ejemplo, puede llamarlo `bitcoin-testnet-pruned` para diferenciarlo de otros VPS en su cuenta.
+
+### Inicie sesión en su VPS
+
+Si observa su panel de control Linode, debería ver que la nueva computadora gira. Cuando el trabajo haya alcanzado el 100%, podrá iniciar sesión.
+
+Primero, necesitará la dirección IP. Haga clic en la pestaña "Linodes" y debería ver una lista de sus VPS, el hecho de que se está ejecutando, su "plan", su dirección IP y alguna otra información.
+
+Vaya a su consola local e inicie sesión en la cuenta `standup` usando esa dirección:
+
+```
+ssh standup@[IP-ADDRESS]
+```
+
+Por ejemplo:
+
+```
+ssh standup@192.168.33.11
+```
+
+Si configuró su VPS para usar una clave SSH, el inicio de sesión debe ser automático (posiblemente requiera su contraseña SSH para desbloquear su clave). Si no configuró una clave SSH, deberá ingresar la contraseña de user.
+
+
+### Espere unos minutos
+
+Aquí hay un pequeño truco: _su StackScript se está ejecutando en este momento_. El script BASH se ejecuta la primera vez que se inicia el VPS. Eso significa que su VPS aún no está listo.
+
+El tiempo total de ejecución es de unos 10 minutos. Por lo tanto, tome un descanso, tome un espresso o relájese durante unos minutos. Hay dos partes del script que toman un tiempo: la actualización de todos los paquetes Debian; y la descarga del código Bitcoin. No deberían tomar más de 5 minutos cada uno, lo que significa que si regresa en 10 minutos, probablemente estará listo para comenzar.
+
+Si está impaciente, puede saltar y `sudo tail -f /standup.log`, que mostrará el progreso actual de la instalación, como se describe en la siguiente sección.
+
+## Verifique su instalación
+
+Sabrá que stackscrpit está listo cuando la salida del comando `tail` del` standup.log` muestre algo como lo siguiente:
+
+`/root/StackScript - Bitcoin is setup as a service and will automatically start if your VPS reboots and so is Tor
+/root/StackScript - You can manually stop Bitcoin with: sudo systemctl stop bitcoind.service
+/root/StackScript - You can manually start Bitcoin with: sudo systemctl start bitcoind.service`
+
+En ese momento, su directorio de inicio debería verse así:
+
+```
+$ ls
+bitcoin-0.20.0-x86_64-linux-gnu.tar.gz  laanwj-releases.asc  SHA256SUMS.asc
+```
+
+Estos son los diversos archivos que se utilizaron para instalar Bitcoin en su VPS. Ninguno es necesario. Los dejamos en caso de que desee realizar una verificación adicional. De lo contrario, puede eliminarlos:
+
+```
+$ rm *
+```
+
+### Verificar la configuración de Bitcoin
+
+Para garantizar que la versión de Bitcoin descargada sea válida, StackScript verifica tanto la firma como la suma de comprobación SHA. Debe verificar que ambas pruebas hayan salido bien:
+
+```
+$ sudo grep VERIFICATION /standup.log
+```
+
+Si ve algo como lo siguiente, todo debería estar bien:
+
+```
+/root/StackScript - VERIFICATION SUCCESS / SIG: gpg: Good signature from "Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>" [unknown]
+/root/StackScript - VERIFICATION SUCCESS / SHA: 35ec10f87b6bc1e44fd9cd1157e5dfa4```
+```
+
+Sin embargo, si en alguna de esas dos comprobaciones se lee "ERROR DE VERIFICACIÓN", entonces hay un problema. Dado que todo esto está programado, es posible que solo haya habido un cambio menor que haya causado que las comprobaciones del script no funcionen correctamente. (Esto ha sucedido varias veces debido a la existencia del script que se convirtió en Standup). Pero también es posible que alguien esté tratando de persuadirlo a ejecutar una copia falsa del demonio de Bitcoin. Entonces, _¡asegúrese de saber lo que sucedió antes de usar Bitcoin!_
+
+### Leer los registros
+
+También es posible que desee leer todos los archivos de registro de instalación para asegurarse de que no haya ocurrido nada inesperado durante la instalación.
+
+Es mejor revisar el archivo de registro estándar de StackScript, que tiene todos los resultados, incluidos los errores:
+
+`$ sudo more /standup.log`
+
+Tenga en cuenta que es totalmente normal ver _algunos_ errores, particularmente cuando se ejecuta el ruidoso software pgp y cuando varias cosas intentan acceder al dispositivo inexistente `/dev/tty`.
+
+Si, en cambio desea ver un conjunto de información más pequeño, todos los errores deben estar en:
+
+`$ sudo more /standup.err`
+
+Todavía tiene una buena cantidad de información que no son errores, pero es una lectura más rápida.
+
+Si todo se ve bien, felicitaciones, ¡tiene un nodo Bitcoin en funcionamiento usando Linode!
+
+## Lo que hemos hecho
+
+Aunque la imagen predeterminada de Debian 10 que estamos usando para su VPS ha sido modificada por Linode para que sea relativamente segura, su nodo Bitcoin instalado a través de Linode StackScript está configurado con un nivel de seguridad aún mayor. Es posible que encuentre esto limitante o que no pueda hacer las cosas que espera. Aquí hay algunas notas al respecto:
+
+### Servicios protegidos
+
+Su instalación de Bitcoin VPS es mínima y casi no permite ninguna comunicación. Esto se hace a través del sencillo firewall (`ufw`), que bloquea todo excepto las conexiones SSH. También es posible una seguridad adicional para sus puertos RPC, gracias a los servicios ocultos instalados por Tor.
+
+**Ajustando UFW.** ¡Probablemente debería dejar UFW en su etapa superprotegida! No debería utilizar una máquina Bitcoin para otros servicios, ¡porque todos aumentan su vulnerabilidad! Si decide lo contrario, hay varias [guías de UFW](https://www.digitalocean.com/community/tutorials/ufw-essentials-common-firewall-rules-and-commands) que le permitirán agregar servicios. Como se anuncia, no es complicado. Por ejemplo, agregar servicios de correo solo requeriría abrir el puerto de correo: `sudo ufw allow 25`. Pero en general no debería eso.
+
+**Ajuste de Tor.** Es posible que desee proteger mejor servicios tales como SSH. Consulte el [Capítulo 14: Usando Tor](14_0_Usando_Tor.md) para obtener más información sobre Tor.
+
+### Consolas de comando protegidas
+
+Si definió "IP permitidas por SSH", el acceso SSH (y SCP) al servidor está severamente restringido. `/etc/hosts.deny` no permite que nadie inicie sesión. _No sugerimos cambiar esto_. `/etc/hosts.allow` entonces permite direcciones IP específicas. Simplemente agregue más direcciones IP en una lista separada por comas si necesita ofrecer más acceso.
+
+Por ejemplo:
+
+```
+sshd: 127.0.0.1, 192.128.23.1
+```
+
+### Actualizaciones automatizadas
+
+Debian también está configurado para actualizarse automáticamente, para asegurarse de estar al día con los parches de seguridad más recientes.
+
+
+Si por alguna razón quisiera cambiar esto (_no lo sugerimos_), puede hacer esto:
+
+```
+echo "unattended-upgrades unattended-upgrades/enable_auto_updates boolean false" | debconf-set-selections
+```
+
+_Si desea saber más sobre lo que hace el stackscript de Bitcoin Standup, consulte el [Apéndice I: Entendiendo Bitcoin Standup] (A1_0_Entendiendo_la_Configuracion_Inicial_de_Bitcoin.md) ._
+
+## Jugando con Bitcoin
+
+¡Así que ahora probablemente quiera jugar con Bitcoin!
+
+Pero espere, su demonio de Bitcoin probablemente todavía esté descargando bloques. El comando `bitcoin-cli getblockcount` le dirá cómo se encuentra actualmente:
+
+```
+$ bitcoin-cli getblockcount
+1771352
+```
+
+Si es diferente cada vez que escribe el comando, debe esperar antes de trabajar con Bitcoin. Esto toma de 1 a 6 horas actualmente para una configuración podada, dependiendo de su máquina.
+
+Pero, una vez que se establezca en un número, ¡estará listo para continuar!
+
+Aún así, podría ser hora de algunos expresos más. Pero muy pronto, su sistema estará listo para funcionar y estará leyendo para empezar a experimentar.
+
+## Resumen: Configuración de un VPS de Bitcoin-Core a mano
+
+La creación de un VPS de Bitcoin-Core con los scripts Standup hizo que todo el proceso fuera rápido, simple y (con suerte) sin contratiempos.
+
+
+## ¿Que sigue?
+
+Tiene algunas opciones para lo que sigue:
+
+* Lea [StackScript](https://github.com/BlockchainCommons/Bitcoin-Standup-Scripts/blob/master/Scripts/LinodeStandUp.sh) para comprender su configuración.
+
+* Lea lo que hace StackScript en el [Apéndice I](A1_0_Entendiendo_Bitcoin_Standup.md).
+
+* Elija una metodología completamente alternativa en [§2.2: Configuración de una máquina Bitcoin-Core a través de otros medios](02_2_Configurando_Bitcoin_Core_Otros.md).
+
+* Pase a "bitcoin-cli" con el [Capítulo tres: Entendiendo la configuración de Bitcoin](03_0_Entendiendo_Su_Configuracion_Bitcoin.md).
+
+
+## Sinopsis: Tipos de instalación de Bitcoin
+
+**Mainnet.** Esto descargará la totalidad de la cadena de bloques de Bitcoin. Esto es alrededor de 380G de datos (y cada día se aumenta más).
+
+**Mainnet podado.** Esto reducirá la cadena de bloques que está almacenando a solo los últimos 550 bloques. Si no está minando o ejecutando algún otro servicio de Bitcoin, esto debería ser suficiente para la validación.
+
+**Testnet.** Esto le da acceso a una cadena de bloques de Bitcoin alternativa donde los Bitcoins en realidad no tienen valor. Está destinado a la experimentación y las pruebas.
+
+**Testnet podado.** Estos son solo los últimos 550 bloques de Testnet ... porque la cadena de bloques de Testnet también es bastante grande ahora.
+
+**Private Regtest.** Este es el modo de prueba de regresión, que le permite ejecutar un servidor Bitcoin totalmente local. Permite pruebas aún más profundas. No es necesario podar aquí, porque comenzará desde cero. Esta es una configuración muy diferente, por lo que se trata en el [Apéndice 3](A3_0_Usando_Bitcoin_Regtest.md).

es/02_2_Configurando_Bitcoin_Core_Otros.md

@@ -0,0 +1,24 @@
+# 2.2: Configuración de una máquina Bitcoin-Core a través de otros medios
+
+La sección anterior, [§2.1: Configuración de un VPS Bitcoin-Core con Bitcoin Standup](02_1_Configurando_un_Bitcoin-Core_VPS_con_StackScript.md), presumía que 
+estaría creando un nodo completo en un VPS usando un Linode Stackscript. Sin embargo, puede crear una instancia de Bitcoin-Core a través de cualquier metodología de
+su elección y seguir los pasos posteriores de este tutorial.
+
+A continuación, se muestran otras metodologías de configuración que conocemos:
+
+* *[Compilación desde la fuente](A2_0_Compilando_Bitcoin_desde_la_Fuente.md).* Si prefiere compilar Bitcoin Core a mano, eso se trata en el Apéndice 2.
+* *[Usando GordianNode-macOS](https://github.com/BlockchainCommons/GordianNode-macOS).* Si tiene una Mac moderna, puede usar la aplicación *GordianNode* de 
+Blockchain Commons, con tecnología *BitcoinStandup*, para instalar un nodo completo en su Mac.
+* *[Uso de otros scripts de Bitcoin Standup](https://github.com/BlockchainCommons/Bitcoin-Standup-Scripts).* Blockchain Commons también ofrece una versión del 
+script de Linode que se uso anteriormente y que se puede ejecutar desde la línea de comandos en cualquier máquina Debian o Ubuntu. Este tiende a ser un script 
+de vanguardia, lo que significa que es más probable que presente nuevas funciones, como la instalación de Lightning.
+* *[Configuración de un nodo Bitcoin en AWS](https://wolfmcnally.com/115/developer-notes-setting-up-a-bitcoin-node-on-aws/).* @wolfmcnally ha escrito un tutorial 
+paso a paso para configurar Bitcoin-Core con Amazon Web Services (AWS).
+* *[Configuración de un nodo Bitcoin en una Raspberry Pi 3](https://medium.com/@meeDamian/bitcoin-full-node-on-rbp3-revised-88bb7c8ef1d1).* Damian Mee explica 
+cómo configurar una Nodo completo de forma sencilla en una Raspberry Pi 3.
+
+## ¿Que sigue?
+
+A menos que desee volver a una de las otras metodologías para crear un nodo Bitcoin-Core, debe:
+
+* Continúe con "bitcoin-cli" con el [Capítulo tres: Entendiendo su configuración de Bitcoin](03_0_Entendiendo_Su_Configuracion_Bitcoin.md).

es/03_0_Entendiendo_Su_Configuracion_Bitcoin.md

@@ -0,0 +1,31 @@
+# Capítulo Tres: Entendiendo Su Configuración Bitcoin
+
+Ahora está listo para comenzar a trabajar con la interfaz de línea de comandos `bitcoin-cli`. Pero eso primero requiere que comprenda la configuración de Bitcoin y las características de su billetera, que es lo que se explicará en este capítulo.
+
+Para este y futuros capítulos, suponemos que tiene un VPS con Bitcoin instalado, ejecutando `bitcoind`. También suponemos que está conectado a testnet, lo que le permite acceder a bitcoins sin utilizar fondos reales. Puede hacerlo con Bitcoin Standup en Linode.com, según  [§2.1: Configuración de un Servidor Privado Virtual de Bitcoin-Core con Bitcoin Standup](02_1_Configurando_un_Bitcoin-Core_VPS_con_StackScript.md), o por otros medios, según [§2.2: Configuración de una Maquina Bitcoin-Core por Otros Medios](02_2_Configurando_Bitcoin_Core_Otros.md).
+
+## Objetivos de este capítulo
+
+Después de trabajar en este capítulo, un desarrollador podrá:
+
+   * Demostrar que su nodo Bitcoin está instalado y actualizado
+   * Crear una dirección para recibir fondos de Bitcoin
+   * Usar comandos básicos de billetera
+   * Crear una dirección a partir de un descriptor
+   
+Los objetivos de apoyo incluyen la capacidad de:
+
+   * Comprender el diseño básico de archivos de Bitcoin
+   * Usar comandos informativos básicos
+   * Comprenda qué es una dirección de Bitcoin
+   * Comprender qué es una billetera
+   * Comprender cómo importar direcciones
+   
+## Tabla de contenido
+
+* [Sección Uno: Verificando Su Configuración Bitcoin](03_1_Verificando_Su_Configuracion_Bitcoin.md)
+* [Sección Dos: Conociendo Su Configuración Bitcoin](03_2_Conociendo_Su_Configuracion_Bitcoin.md)
+* [Sección Tres: Configurando Su Billetera](03_3_Configurando_Su_Billetera.md)
+   * [Interludio: Usando Variables de la Linea de Comandos](03_3_Interludio_Usando_Variables_Linea_Comando.md)
+* [Sección Cuatro: Recibiendo una Transacción](03_4_Recibiendo_una_Transaccion.md)
+* [Sección Cinco: Entendiendo El Descriptor](03_5_Entendiendo_El_Descriptor.md)

es/03_1_Verificando_Su_Configuracion_Bitcoin.md

@@ -0,0 +1,115 @@
+# 3.1: Verificando su configuración Bitcoin
+
+Antes de comenzar a jugar con Bitcoin, debe asegurarse de que todo esté configurado correctamente.
+
+## Cree sus Alias
+
+Sugerimos crear algunos alias para facilitar el uso de Bitcoin.
+
+Puede hacerlo colocándolos en sus archivos `.bash_profile`, `.bashrc` o `.profile`.
+```
+cat >> ~/.bash_profile <<EOF
+alias btcdir="cd ~/.bitcoin/" #linux default bitcoind path
+alias bc="bitcoin-cli"
+alias bd="bitcoind"
+alias btcinfo='bitcoin-cli getwalletinfo | egrep "\"balance\""; bitcoin-cli getnetworkinfo | egrep "\"version\"|connections"; bitcoin-cli getmininginfo | egrep "\"blocks\"|errors"'
+EOF
+```
+Después de ingresar estos alias, puede ejecutar `source .bash_profile` para cargarlos o cerrar sesion e iniciar sesion de nuevo.
+
+Tenga en cuenta que estos alias incluyen atajos para ejecutar `bitcoin-cli`, para ejecutar `bitcoind` y para posicionarse en el directorio de Bitcoin. 
+Estos alias están destinados principalmente a facilitarle la vida. Le sugerimos que cree otros alias para facilitar el uso de comandos frecuentes 
+(y argumentos) y minimizar los errores. Los alias de este tipo pueden ser aún más útiles si tiene una configuración compleja en la que ejecuta 
+regularmente comandos asociados con Mainnet, con Testnet _y_ con Regtest, como se explica más adelante.
+
+Dicho esto, el uso de estos alias en este documento podría oscurecer accidentalmente las lecciones principales que se enseñan sobre Bitcoin, 
+por lo que el único alias que se usa directamente aquí es `btcinfo` porque encapsula un comando mucho más largo y complejo. De lo contrario, mostramos 
+los comandos completos; ajuste para su propio uso según corresponda.
+
+## Ejecutar Bitcoind
+
+Comenzará su exploración de la red Bitcoin con el comando `bitcoin-cli`. Sin embargo, bitcoind _debe_ estar ejecutándose para usar bitcoin-cli, 
+ya que bitcoin-cli envía comandos JSON-RPC al bitcoind. Si usó nuestra configuración estándar, bitcoind ya debería estar en funcionamiento. 
+Puede verificar dos veces mirando la tabla de procesos.
+
+```
+$ ps auxww | grep bitcoind
+standup    455  1.3 34.4 3387536 1392904 ?     SLsl Jun16  59:30 /usr/local/bin/bitcoind -conf=/home/standup/.bitcoin/bitcoin.conf
+```
+Si no se está ejecutando, querrá ejecutarlo `/usr/local/bin/bitcoind -daemon` manualmente y también colocarlo en su crontab.
+
+## Verifique sus bloques
+
+Debería tener toda la cadena de bloques descargada antes de comenzar a jugar. Simplemente ejecute el alias `bitcoin-cli getblockcount`  para ver si está todo cargado.
+
+```
+$ bitcoin-cli getblockcount
+1772384
+```
+Eso le indica lo que está descargado; luego deberá verificarlo con un servicio en línea que le indique la altura actual del bloque.
+
+> :book: ***¿Qué es la altura del bloque?*** La altura del bloque es la distancia a la que se retira un bloque particular del bloque génesis. La altura del bloque actual es la altura del bloque más nuevo agregado a una cadena de bloques.
+
+Puede hacer esto mirando un explorador de blocknet, tal como [Blockcypher Testnet explorer](https://live.blockcypher.com/btc-testnet/). Su número más reciente coincide con la salida del `getblockcount`? Si es así, está actualizado.
+
+Si desea un alias para ver todo a la vez, lo siguiente funciona actualmente para Testnet, pero puede desaparecer en algún momento en el futuro:
+
+```
+$ 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
+$ source .bash_profile 
+$ btcblock
+1804372/1804372
+```
+
+> :link: **TESTNET vs MAINNET:** Recuerde que este tutorial generalmente asume que está usando testnet. Si en cambio está utilizando la red mainnet, se puede recuperar la altura del bloque actual con: `wget -O - http://blockchain.info/q/getblockcount 2>/dev/null`. Puede reemplazar la segunda mitad del alias `btblock` (después de `/`) con eso.
+
+Si no está actualizado, pero la salida de su `getblockcount` está aumentando, no hay problema. El tiempo total de descarga puede llevar desde una hora hasta varias horas, según su configuración.
+
+## Opcional: conozca los tipos de servidor
+
+> **TESTNET vs MAINNET:** Cuando configura su nodo, usted puede elegir crearlo como un nodo Mainnet, Testnet o Regtest. Aunque este documento presupone una configuración de testnet, vale la pena comprender cómo puede acceder y utilizar los otros tipos de configuración, ¡incluso todos en la misma máquina! Pero, si es un usuario nuevo, omita esto, ya que no es necesario para una configuración básica.
+
+El tipo de configuración se controla principalmente a través del archivo ~/.bitcoin/bitcoin.conf. Si está ejecutando testnet, probablemente contenga esta línea:
+```
+testnet=1
+```
+Si está ejecutando regtest, probablemente contenga esta línea:
+```
+regtest=1
+```
+
+Sin embargo, si desea ejecutar varios tipos diferentes de nodos simultáneamente, debe dejar la marca testnet (o regtest) fuera de su archivo de configuración. Luego puede elegir si está utilizando la red principal, la red de prueba o su registro cada vez que ejecuta bitcoind o bitcoin-cli.
+
+Aquí hay un conjunto de alias que lo facilitarían al crear un alias específico para iniciar y detener el bitcoind, para ir al directorio de bitcoin y para ejecutar bitcoin-cli, para cada una de las redes principales; mainnet (que no tiene indicadores adicionales), testnet (que es -testnet), o regtest (que es -regtest).
+
+```
+cat >> ~/.bash_profile <<EOF
+alias bcstart="bitcoind -daemon"
+alias btstart="bitcoind -testnet -daemon"
+alias brstart="bitcoind -regtest -daemon"
+
+alias bcstop="bitcoin-cli stop"
+alias btstop="bitcoin-cli -testnet stop"
+alias brstop="bitcoin-cli -regtest stop"
+
+alias bcdir="cd ~/.bitcoin/" #linux default bitcoin path
+alias btdir="cd ~/.bitcoin/testnet" #linux default bitcoin testnet path
+alias brdir="cd ~/.bitcoin/regtest" #linux default bitcoin regtest path
+
+alias bc="bitcoin-cli"
+alias bt="bitcoin-cli -testnet"
+alias br="bitcoin-cli -regtest"
+EOF
+```
+
+Para una mayor complejidad, puede hacer que cada uno de sus alias de 'inicio' use el indicador -conf para cargar la configuración desde un archivo diferente. Esto va mucho más allá del alcance de este tutorial, pero lo ofrecemos como punto de partida para cuando sus exploraciones de Bitcoin alcancen el siguiente nivel.
+
+## Resumen: verificación de la configuración de Bitcoin
+
+Antes de comenzar a jugar con bitcoin, debe asegurarse de que sus alias estén configurados, su bitcoind se esté ejecutando y sus bloques estén descargados. Es posible que también desee configurar algún acceso a configuraciones alternativas de Bitcoin, si es un usuario avanzado.
+
+## ¿Que sigue?
+
+Continue "Conociendo su configuración Bitcoin" en [§3.2: Entendiendo su configuración Bitcoin](03_2_Conociendo_Su_Configuracion_Bitcoin.md).