02_1_Setting_Up_a_Bitcoin-Core_VPS_with_StackScript.md

@@ -1,6 +1,6 @@
 # 2.1: Setting Up a Bitcoin-Core VPS with Bitcoin Standup
 
-This document explains how to set up a VPS (Virtual Private Sever) to run a Bitcoin node on Linode.com using an automated StackScript from the [Bitcoin Standup project](https://github.com/BlockchainCommons/Bitcoin-Standup-Scripts). You just need to enter a few commands and boot your VPS. Almost immediately after you boot, you'll find your new Bitcoin node happily downloading blocks.
+This document explains how to set up a VPS (Virtual Private Sever) to run a Bitcoin node on Linode.com, installed using an automated StackScript from the [Bitcoin Standup project](https://github.com/BlockchainCommons/Bitcoin-Standup-Scripts). You just need to enter a few commands and boot your VPS. Almost immediately after you boot, you'll find your new Bitcoin node happily downloading blocks.
 
 > :warning: **WARNING:** Don’t use a VPS for a bitcoin wallet with significant real funds; see http://blog.thestateofme.com/2012/03/03/lessons-to-be-learned-from-the-linode-bitcoin-incident/ . It is very nice to be able experiment with real bitcoin transactions on a live node without tying up a self-hosted server on a local network. It's also useful to be able to use an iPhone or iPad to communicate via SSH to your VPS to do some simple bitcoin tasks. But a higher level of safety is required for significant funds.
 
@@ -10,7 +10,7 @@ This document explains how to set up a VPS (Virtual Private Sever) to run a Bitc
 
 ## Getting Started with Linode
 
-Linode (now Akamai Cloud) is a Cloud Hosting service that offers quick, cheap Linux servers with SSD storage. We use them for this tutorial primarily because their BASH-driven StackScripts offer an easy way to automatically set up a Bitcoin node with no fuss and no muss.
+Linode is a Cloud Hosting service that offers quick, cheap Linux servers with SSD storage. We use them for this tutorial primarily because their BASH-driven StackScripts offer an easy way to automatically set up a Bitcoin node with no fuss and no muss.
 
 ### Set Up a Linode Account
 
@@ -26,75 +26,75 @@ If you prefer, the following referral code will give you two months worth of fre
 
 You'll need to provide an email address and later preload money from a credit card or PayPal for future costs.
 
-When you're done, you should land on [https://cloud.linode.com/linodes](https://cloud.linode.com/linodes).
+When you're done, you should land on [https://cloud.linode.com/dashboard](https://cloud.linode.com/dashboard).
 
 ### Consider Two-Factor Authentication
 
-Your server security won't be complete if people can break into your Linode account, so consider setting up Two-Factor Authentication for it. You can find this setting on your [My Profile: Password & Authentication page](https://cloud.linode.com/profile/auth). If you don't do this now, make a TODO item to come back and do it later.
+Your server security won't be complete if people can break into your Linode account, so consider setting up Two-Factor Authentication for it. You can find this setting on your [My Profile: Password & Authentication page](https://manager.linode.com/profile/auth). If you don't do this now, make a TODO item to come back and do it later.
 
 ## Creating the Linode Image using a StackScript
 
 ### 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) 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 13 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
 
 You're now ready to create a node based on the Stackscript.
 
 1. On the [Stackscripts page](https://cloud.linode.com/stackscripts?type=account), click on the "..." to the right of your new script and choose "Deploy New Linode".
-2. Enter the password for the "standup" user. This will be the account that runs `bitcoind`.
-3. Fill in a short and a fully qualified hostname
+2. Fill in a short and a fully qualified hostname
    * **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. Fill in the appropriate advanced options. 
-   * **Installation Type.** This is likely "Mainnet" or "Pruned Mainnet" if you are setting up a node for usage and "Signet" or "Pruned Signet" if you're just playing around. The bulk of this tutorial will assume you chose "Pruned Signet", 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.)
-   * **Timezone.** The timezone your machine is set to.
-   * **Security: Tor 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.
-   * **Security: Standup 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/).  Using an SSH key will give you a simpler and safer way to log in to your server.
-   * **Security: 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.
-   * **Cypherpunkpay.** These are options to install Cypherpunkpay on your server. They're primarily intended for other users of the Standup software and aren't used in this course, so you can just leave them be.
-4. Choose a region for where the Linode will be located.
+   * **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.
+   * **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 13" (though previous versions of this Stackscript worked with Debian 9 through 12, and might still.)
+   * **Target Image.** If you followed the instructions, this will only allow you to select "Debian 12" (though previous versions of this Stackscript worked with Debian 9 or 10 or 12 and might still).
+6. Choose a region for where the Linode will be located.
+
+*The remaining questions all have to do with the mechanics of the VPS deployment and should be left as they are with one exception: bump the Swap Disk from 256MB to 512MB, to ensure that you have enough memory to download the blockchain.*
+
+### Choose Other Standup Options
+
+Blockchain Commons is currently in the process of expanding its Bitcoin Standup Scripts with options to install Lightning and other Bitcoin apps of note. Take a look at any extra options, and see if they're things that you'd like to play with. In particular, if Lightning is an option, we suggest installing it, because it will make [Chapter 18](18_0_Understanding_Your_Lightning_Setup.md) and [Chapter 19](19_0_Using_Lightning.md) much easier. 
 
 ### Choose a Linode Plan
 
-You'll next need to choose a Linode plan.
+You'll next to choose a Linode plan.
 
-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, Pruned Signet, and even non-Pruned Signet. 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 715G(!), which is currently the Linode 64 GB, which has 1280G of storage and 64G of memory and costs approximately $384 per month. We do _not_ suggest this. (But see below for alternatives.)
+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 | Linode  |
 |-------|--------|---------|---------|
-| Mainnet | 2G | ~715G | Linode 64GB |
+| Mainnet | 2G | 280G | Linode 16GB |
 | Pruned Mainnet | 2G | ~5G | Linode 4GB |
-| Signet | 2G | ~15G | Linode 4GB |
-| Pruned Signet | 2G | ~5G | Linode 4GB |
-| Testnet | 2G | ~170G | Linode 16GB |
+| Testnet | 2G | ~15G | Linode 4GB |
 | Pruned Testnet | 2G | ~5G | Linode 4GB |
 | Regtest | 2G | ~ | Linode 4GB |
 
 Note, there may be ways to reduce both costs.
 
-* For the setups 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 64GB**, you can probably get by with a Linode 4GB, but add [Block Storage](https://cloud.linode.com/volumes/create) 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 750 GibiByte storage would be $75 a month, which combined with a Linode 4GB is $95 a month, instead of $384, 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 over to a newly commissioned volume before continuing.
+* 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
 
-You may now want to change your Linode VPS's name from the default `linodexxxxxxxx`. For instance you might name it `bitcoin-signet-pruned` to differentiate it from other VPSs in your account.
-
-The last thing you need to do is enter a root password. (If you missed anything, you'll be told so now!). You'll also have the option to add an SSH key for the root user aat this point. We again suggest doing so for both security and convenience purposes.
-
-Linode at this point offers a few choices that have changed over time, but currently include: disk encryption, VPC, firewall, and VLAN. These are generally security features that you would want to consider for a real-world deployment, but don't need to worry about for a testing deployment. (We'd suggest at least a firewall and the disk encryption for a real-world deployment, but we leave that to you and your security people.)
+The last thing you need to do is enter a root password. (If you missed anything, you'll be told so now!)
 
 Click "Deploy" to initialize your disks and to prepare your VPS. The whole queue should run in less than a minute. When it's done you should see in the "Host Job Queue", green "Success" buttons stating "Disk Create from StackScript - Setting password for root… done." and "Create Filesystem - 256MB Swap Image".
 
+You may now want to change your Linode VPS's name from the default `linodexxxxxxxx`.  Go to the Settings tab, and change the label to be more useful, such as your VPS's short hostname. For instance you might name it `bitcoin-testnet-pruned` to differentiate it from other VPSs in your account.
+
 ## Login to Your VPS
 
 If you watch your Linode control panel, you should see the new computer spin up. When the job has reached 100%, you'll be able to login.
@@ -135,9 +135,7 @@ At that point, your home directory should look like this:
 
 ```
 $ ls
-bitcoin-30.2-x86_64-linux-gnu.tar.gz  wget-btc-output.txt
-SHA256SUMS                            wget-btc-sha-asc-output.txt
-SHA256SUMS.asc                        wget-btc-sha-output.txt
+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:
@@ -157,23 +155,24 @@ $ sudo grep VERIFICATION /standup.log
 If you see something like the following, all should be well:
 
 ```
-/root/StackScript - SIG VERIFICATION SUCCESS: 8 GOOD SIGNATURES FOUND.
-/root/StackScript - SHA VERIFICATION SUCCESS / SHA: bitcoin-30.2-x86_64-linux-gnu.tar.gz: OK
+./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
 ```
 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
-/root/StackScript - SIG VERIFICATION SUCCESS: 8 GOOD SIGNATURES FOUND.
-gpg: Good signature from ".0xB10C <b10c@b10c.me>" [unknown]
-gpg: Good signature from "Ava Chow <me@achow101.com>" [unknown]
+./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 (GitHub key) <32963518+hebasto@users.noreply.github.com>" [unknown]
-gpg: Good signature from "Matthew Zipkin (GitHub Signing Key) <pinheadmz@gmail.com>" [unknown]
-gpg: Good signature from "Sjors Provoost <sjors@sprovoost.nl>" [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!_
 
@@ -197,7 +196,7 @@ If all look good, congratulations, you have a functioning Bitcoin node using Lin
 
 ## What We Have Wrought
 
-Although the default Debian 13 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
 
@@ -236,9 +235,9 @@ So now you probably want to play with Bitcoin!
 But wait, your Bitcoin daemon is probably still downloading blocks. The `bitcoin-cli getblockcount` will tell you how you're currently doing:
 ```
 $ bitcoin-cli getblockcount
-288191
+1771352
 ```
-If it's different every time you type the command, you need to wait before working with Bitcoin. This can take hours for a mainnet setup, but if you're using our suggested setup of pruned signet, it should be done in 15 minutes or so.
+If it's different every time you type the command, you need to wait before working with Bitcoin. This takes 1-6 hours currently for a  pruned setup, depending on your precise machine. 
 
 But, once it settles at a number, you're ready to continue!
 
@@ -263,11 +262,7 @@ You have a few options for what's next:
 
 **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.
 
-**Signet.** This is the newest iteration of a testing network, where Bitcoins don't actually have value, and has largely surpassed Testnet. It's intended for experimentation and testing.  Its big advantage is that its block production is more reliable that Testnet, where Testnet could stall out for a while, then produce a bunch of blocks together. 
-
-**Pruned Signet.** The last 550 blocks of Signet.
-
-**Testnet.** The older testing network, still useful to some for the ability for miners to force block reorgs (and likely for other specific testing purposes). There are two versions: `testnet3` and `testnet4`.
+**Testnet.** This gives you access to an alternative Bitcoin blockchain where the Bitcoins don't actually have value. It's intended for experimentation and testing.
 
 **Pruned Testnet.** This is just the last 550 blocks of Testnet ... because the Testnet blockchain is pretty big now too.
 

03_1_Verifying_Your_Bitcoin_Setup.md

@@ -17,7 +17,7 @@ EOF
 ```
 After you enter these aliases you can either `source .bash_profile` to input them or just log out and back in.
 
-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, with Signet, _and_ with Regtest, as explained further below.
+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 encapsulates  much longer and more complex command. Otherwise, we show the full commands; adjust for your own use as appropriate.
 
@@ -41,30 +41,25 @@ That tells you what's loaded; you'll then need to check that against an online s
 
 > :book: ***What is Block Height?*** Block height is the the distance that a particular block is removed from the genesis block. The current block height is the block height of the newest block added to a blockchain.
 
-You can do this by looking at a blocknet explorer, such as [the Mempool Signet explorer](https://mempool.space/signet). Does its most recent number match your `getblockcount`? If so, you're up to date.
+You can do this by looking at a blocknet explorer, such as [the Blockcypher Testnet explorer](https://live.blockcypher.com/btc-testnet/). Does its most recent number match your `getblockcount`? If so, you're up to date.
 
 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:
 ```
-$ echo "alias btcblock='echo \$(bitcoin-cli -signet getblockcount)/\$(curl -s https://blockstream.info/signet/api/blocks/tip/height)'" >> .bash_profile
+$ echo "alias btcblock='echo \$(bitcoin-cli -testnet getblockcount)/\$(curl -s https://blockstream.info/testnet/api/blocks/tip/height)'" >> .bash_profile
 $ source .bash_profile 
 $ btcblock
-288200/288200
+1804372/1804372
 ```
 
-> :link: **SIGNET vs MAINNET:** Remember that this tutorial generally assumes that you are using signet. 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.
+> :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.
 
 ## Optional: Know Your Server Types
 
-> **SIGNET vs MAINNET:** When you set up your node, you choose to create it as either a Mainnet, Testnet, Signet, or Regtest node. Though this document presumes a signet setup, it's worth understanding how you might access and use the other setup types — even all on the same machine! But, if you're a first-time user, skip on past this, as it's not necessary for a basic setup.
+> **TESTNET vs MAINNET:** When you set up your node, you choose to create it as either a Mainnet, Testnet, or Regtest node. Though this document presumes a testnet setup, it's worth understanding how you might access and use the other setup types — even all on the same machine! But, if you're a first-time user, skip on past this, as it's not necessary for a basic setup.
 
-The type of setup is mainly controlled through the ~/.bitcoin/bitcoin.conf file. 
-If you're running signet, it probably contains this line:
-```
-signet=1
-```
-If you're running testnet, it probably contains this line:
+The type of setup is mainly controlled through the ~/.bitcoin/bitcoin.conf file. If you're running testnet, it probably contains this line:
 ```
 testnet=1
 ```
@@ -72,28 +67,24 @@ If you're running regtest, it probably contains this line:
 ```
 regtest=1
 ```
-However, if you want to run several different sorts of nodes simultaneously, you should leave the signet (or testnet or regtest) flag out of your configuration file. You can then choose whether you're using the mainnet, the signet, the testnet, or your regtest every time you run bitcoind or bitcoin-cli.
+However, if you want to run several different sorts of nodes simultaneously, you should leave the testnet (or regtest) flag out of your configuration file. You can then choose whether you're using the mainnet, the testnet, or your regtest every time you run bitcoind or bitcoin-cli.
 
-Here's a set of aliases that would make that easier by creating a specific alias for starting and stopping the bitcoind, for going to the bitcoin directory, and for running bitcoin-cli, for each of the mainnet (which has no extra flags), the signet (which is -signet), the testnet (which is -testnet), or your regtest (which is -regtest).
+Here's a set of aliases that would make that easier by creating a specific alias for starting and stopping the bitcoind, for going to the bitcoin directory, and for running bitcoin-cli, for each of the mainnet (which has no extra flags), the testnet (which is -testnet), or your regtest (which is -regtest).
 ```
 cat >> ~/.bash_profile <<EOF
 alias bcstart="bitcoind -daemon"
-alias bsstart="bitcoind -signet -daemon"
 alias btstart="bitcoind -testnet -daemon"
 alias brstart="bitcoind -regtest -daemon"
 
 alias bcstop="bitcoin-cli stop"
-alias bsstop="bitcoin-cli -signet stop"
 alias btstop="bitcoin-cli -testnet stop"
 alias brstop="bitcoin-cli -regtest stop"
 
 alias bcdir="cd ~/.bitcoin/" #linux default bitcoin path
-alias bsdir="cd ~/.bitcoin/signet" #linux default bitcoin signet 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 bs="bitcoin-cli -signet"
 alias bt="bitcoin-cli -testnet"
 alias br="bitcoin-cli -regtest"
 EOF

03_2_Knowing_Your_Bitcoin_Setup.md

@@ -9,20 +9,19 @@ To start with, you should understand where everything is kept: the `~/.bitcoin`
 The main directory just contains your config file and the testnet directory:
 ```
 $ ls ~/.bitcoin
-bitcoin.conf  signet
+bitcoin.conf  testnet3
 ```
 The setup guides in [Chapter Two: Creating a Bitcoin-Core VPS](02_0_Setting_Up_a_Bitcoin-Core_VPS.md) laid out a standardized config file. [§3.1: Verifying Your Bitcoin Setup](03_1_Verifying_Your_Bitcoin_Setup.md) suggested how to change it to support more advanced setups. If you're interested in learning even more about the config file, you may wish to consult [Jameson Lopp's Bitcoin Core Config Generator](https://jlopp.github.io/bitcoin-core-config-generator/).
 
-Moving back to your ~/.bitcoin directory, you'll find that the signet directory contains all of the guts:
+Moving back to your ~/.bitcoin directory, you'll find that the testnet3 directory contains all of the guts:
 ```
-$ ls ~/.bitcoin/signet
-banlist.json  chainstate         onion_v3_private_key  wallets
-bitcoind.pid  debug.log          peers.dat
-blocks        fee_estimates.dat  settings.json
+$ ls ~/.bitcoin/testnet3
+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.
 
-> :link: **SIGNET vs MAINNET:** If you're using mainnet, then _everything_ will instead be placed in the main `~/.bitcoin` directory. These various setups _do_ elegantly stack, so if you are using mainnet, signet, testnet, and regtest, you'll find that `~/.bitcoin` contains your config file and your mainnet data, the `~/.bitcoin/signet` directory contains your signet data, the `~/.bitcoin/testnet3` directory contains your testnet data, and the `~/.bitcoin/regtest` directory contains your regtest data.
+> :link: **TESTNET vs MAINNET:** If you're using mainnet, then _everything_ will instead be placed in the main `~/.bitcoin` directory. These various setups _do_ elegantly stack, so if you are using mainnet, testnet, and regtest, you'll find that `~/.bitcoin` contains your config file and your mainnet data, the `~/.bitcoin/testnet3` directory contains your testnet data, and the `~/.bitcoin/regtest` directory contains your regtest data.
 
 ## Know Your Bitcoin-cli Commands
 

03_3_Setting_Up_Your_Wallet.md

@@ -1,6 +1,3 @@
-TODO:
-   * Remove legacy wallets (3.3) and replace them entire with descriptors
-
 # 3.3: Setting Up Your Wallet
 
 You're now ready to start working with Bitcoin. To begin with, you'll need to create a wallet for sending and receiving funds.
@@ -9,11 +6,11 @@ You're now ready to start working with Bitcoin. To begin with, you'll need to cr
 
 > :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/signet/wallets` directory.
+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/signet/wallets
+$ ls ~/.bitcoin/testnet3/wallets
 $
 ```
 
@@ -29,7 +26,7 @@ $ bitcoin-cli -named createwallet wallet_name="" descriptors=false
 
 Now, your `wallets` directory should be populated.
 ```
-$ ls ~/.bitcoin/signet/wallets
+$ ls ~/.bitcoin/testnet3/wallets
 database  db.log  wallet.dat
 ```
 
@@ -58,13 +55,13 @@ You can now create an address. You can require `legacy` address either with the
 $ bitcoin-cli getnewaddress -addresstype legacy
 moKVV6XEhfrBCE3QCYq6ppT7AaMF8KsZ1B
 ```
-Note that this address begins with an "m" (or sometimes an "n") to signify a Signet Legacy address. It would be a "2" for a P2SH address or a "tb1" for a Bech32 address.
+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: **SIGNET vs MAINNET vs TESTNET:** The equivalent mainnet address would start with a "1" (for Legacy), "3" (for P2SH), or "bc1" (for Bech32). Testnet uses the same address as Signet for clarity.
+> :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. 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/signet /wallets` directory.
+> :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_3b_Interlude_Creating_QR_Codes.md

@@ -1,5 +0,0 @@
-TODO:
-
-1. New Interlude: Creating QR Codes (after 3.3)
-   * New Subsection: Creating a QR
-   * New Subsection: Creating a Quick Connect QR

03_4_Receiving_a_Transaction.md

@@ -4,13 +4,13 @@ You're now ready to receive some money at the new address you set up.
 
 ## Get Some Money
 
-To do anything more, you need to get some money. On signet this is done through faucets. Since the money is all pretend, you just go to a faucet, request some money, and it will be sent over to you. We suggest using the faucet at [https://signetfaucet.com/](https://signetfaucet.com/) or [https://signet257.bublina.eu.org/](https://signet257.bublina.eu.org/). If they're not available for some reason, search for "bitcoin signet faucet", and you should find others.
+To do anything more, you need to get some money. On testnet this is done through faucets. Since the money is all pretend, you just go to a faucet, request some money, and it will be sent over to you. We suggest using the faucet at https://testnet-faucet.mempool.co/, https://bitcoinfaucet.uo1.net/, or https://testnet.coinfaucet.eu/en/. If they're not available for some reason, search for "bitcoin testnet faucet", and you should find others.
 
 To use a faucet, you'll usually need to go to a URL and copy and paste in your address. Note that this is one of those cases where you won't be able to use command-line variables, alas. Afterward, a transaction will be created that sends money from the faucet to you.
 
 > :book: ***What is a transaction?*** A transaction is a bitcoin exchange. The owner of some bitcoins uses his private key to access those coins, then locks the transaction using the recipient's public key.
 
-> :link: **SIGNET vs MAINNET:** Sadly, there are no faucets in real life. If you were playing on the mainnet, you'd need to go and actually buy bitcoins at a bitcoin exchange or ATM, or you'd need to get someone to send them to you. Signet life is much easier.
+> :link: **TESTNET vs MAINNET:** Sadly, there are no faucets in real life. If you were playing on the mainnet, you'd need to go and actually buy bitcoins at a bitcoin exchange or ATM, or you'd need to get someone to send them to you. Testnet life is much easier.
 
 ## Verify Your Money
 
@@ -49,7 +49,7 @@ $  bitcoin-cli getbalance "*" 2
 ```
 Obviously, every ten minutes or so this depth will increase.
 
-Of course, on the signet, no one is that worried about how reliable your funds are. You'll be able to spend your money as soon as it's confirmed.
+Of course, on the testnet, no one is that worried about how reliable your funds are. You'll be able to spend your money as soon as it's confirmed.
 
 ## Verify Your Wallet
 
@@ -155,7 +155,7 @@ $ bitcoin-cli listunspent
 ```
 Note that bitcoins are not just a homogeneous mess of cash jammed into your pocket. Each individual transaction that you receive or that you send is placed into the immutable blockchain ledger, in a block. You can see these individual transactions when you look at your unspent money. This means that bitcoin spending isn't quite as anonymous as you'd think. Though the addresses are fairly private, transactions can be examined as they go in and out of addresses. This makes privacy vulnerable to statistical analysis. It also introduces some potential non-fungibility to bitcoins, as you can track back through series of transactions, even if you can't track a specific "bitcoin".
 
-> :book: ***Why are all of these bitcoin amounts in fractions?*** Bitcoins are produced slowly, and so there are relatively few in circulation. As a result, each bitcoin over on the mainnet is worth quite a bit (~ $9,000 at the time of this writing). This means that people usually work in fractions. In fact, the .0101 in Signet coins would be worth about $9000 if they were on the mainnet. For this reason, names have appeared for smaller amounts of bitcoins, including millibitcoins or mBTCs (one-thousandth of a bitcoin), microbitcoins or bits or μBTCs (one-millionth of a bitcoin), and satoshis (one hundred millionth of a bitcoin).
+> :book: ***Why are all of these bitcoin amounts in fractions?*** Bitcoins are produced slowly, and so there are relatively few in circulation. As a result, each bitcoin over on the mainnet is worth quite a bit (~ $9,000 at the time of this writing). This means that people usually work in fractions. In fact, the .0101 in Testnet coins would be worth about $100 if they were on the mainnet. For this reason, names have appeared for smaller amounts of bitcoins, including millibitcoins or mBTCs (one-thousandth of a bitcoin), microbitcoins or bits or μBTCs (one-millionth of a bitcoin), and satoshis (one hundred millionth of a bitcoin).
 
 ## Examine Your Transaction
 
@@ -291,15 +291,15 @@ There is another command, `getrawtransaction`, which allows you to look at trans
 
 Even looking at the verbose information for a transaction can be a little intimidating. The main goal of this tutorial is to teach how to deal with raw transactions from the command line, but we're happy to talk about other tools when they're applicable. One of those tools is a block explorer, which you can use to look at transactions from a web browser in a much friendlier format.
 
-Currently, our preferred block explorer is [https://mempool.space/](https://mempool.space/), which has options for mainnet, signet, testnet3, and testnet4.
+Currently, our preferred block explorer is [https://live.blockcypher.com/](https://live.blockcypher.com/).
 
 You can use it to look up transactions for an address:
 
-[https://mempool.space/signet/address/tb1pffsyra2t3nut94yvdae9evz3feg7tel843pfcv76vt5cwewavtesl3gsph](https://mempool.space/signet/address/tb1pffsyra2t3nut94yvdae9evz3feg7tel843pfcv76vt5cwewavtesl3gsph)
+[https://live.blockcypher.com/btc-testnet/address/mi25UrzHnvn3bpEfFCNqJhPWJn5b77a5NE/](https://live.blockcypher.com/btc-testnet/address/mi25UrzHnvn3bpEfFCNqJhPWJn5b77a5NE/)
 
 You can also use it to look at individual transactions:
 
-[https://mempool.space/signet/tx/e5b8940b2dd5a1bbb032228dedd85cd8c21f0ce5cf4b76c959f71d967de626b3](https://mempool.space/signet/tx/e5b8940b2dd5a1bbb032228dedd85cd8c21f0ce5cf4b76c959f71d967de626b3)
+[https://live.blockcypher.com/btc-testnet/tx/8e2ab10cabe9ec04ed438086a80b1ac72558cc05bb206e48fc9a18b01b9282e9/](https://live.blockcypher.com/btc-testnet/tx/8e2ab10cabe9ec04ed438086a80b1ac72558cc05bb206e48fc9a18b01b9282e9/)
 
 A block explorer doesn't generally provide any more information than a command line look at a raw transaction; it just does a good job of highlighting the important information and putting together the puzzle pieces, including the transaction fees behind a transaction — another concept that we'll be covering in future sections.
 

03_5_Understanding_the_Descriptor.md

@@ -1,10 +1,3 @@
-TODO:
-
-1. Revise Section: Understanding the Descriptor (3.5)
-   * New Content: Descriptor Wallets
-   * New Content: Complex Descriptors
-   * Consider: Breaking into Two Sections
-
 # 3.5: Understanding the Descriptor
 
 > :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.

04_1_Sending_Coins_The_Easy_Way.md

@@ -1,8 +1,3 @@
-TODO:
-* Obviously, this is where the Segwit work starts.
-* Also: 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.
-* Also: sendall as an alternative
-
 # 4.1: Sending Coins the Easy Way
 
 The `bitcoin-cli` offers three major ways to send coins: as a simple command; as a raw transaction; and as a raw transaction with calculation. Each has their own advantages and disadvantages. This first method for sending coins is also the simplest.
@@ -50,7 +45,7 @@ $ echo $txid
 93250d0cacb0361b8e21030ac65bc4c2159a53de1075425d800b2d7a8ab13ba8
 ```
 
-> 🙏 To help keep signet faucets alive, try to use the return address of the same faucet you used in the previous chapter on receiving transactions. 
+> 🙏 To help keep testnet faucets alive, try to use the return address of the same faucet you used in the previous chapter on receiving transactions. 
 
 Make sure the address you write in is where you want the money to go. Make _double_ sure. If you make mistakes in Bitcoin, there's no going back.
 

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 BTC. Yes, that's for the mainnet, not signet or 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_3_Creating_a_Raw_Transaction_with_Named_Arguments.md

@@ -1,7 +1,3 @@
-TODO:
-* Update to non-legayc addresses
-* Also add args parameter
-  
 # 4.3 Creating a Raw Transaction with Named Arguments
 
 It can sometimes be daunting to figure out the right order for the arguments to a bitcoin-cli command. Fortunately, you can use _named arguments_ as an alternative.

04_4_Sending_Coins_with_a_Raw_Transaction.md

@@ -1,6 +1,3 @@
-TODO:
-* Freezing coins
-  
 # 4.4: Sending Coins with Raw Transactions
 
 As noted at the start of this chapter, the `bitcoin-cli` interface offers three major ways to send coins. [§4.1](04_1_Sending_Coins_The_Easy_Way.md) talked about sending them the first way, using the `sendtoaddress` command. Since then, we've been building details on how to send coins a second way, with raw transactions. [§4.2](04_2_Creating_a_Raw_Transaction.md) taught how to create a raw transaction, an [Interlude](04_2__Interlude_Using_JQ.md) explained JQ, and [§4.3](04_3_Creating_a_Raw_Transaction_with_Named_Arguments.md) demonstrated named arguments.

04_4__Interlude_Using_Curl.md

@@ -57,12 +57,12 @@ rpcpassword=8eaf562eaf45c33c3328bc66008f2dd1
 rpcallowip=127.0.0.1
 debug=tor
 prune=550
-signet=1
+testnet=1
 mintxfee=0.001
 txconfirmtarget=1
 [test]
 rpcbind=127.0.0.1
-rpcport=38332
+rpcport=18332
 [main]
 rpcbind=127.0.0.1
 rpcport=8332
@@ -76,18 +76,18 @@ Our user name is `StandUp` and our password is `8eaf562eaf45c33c3328bc66008f2dd1
 
 The secure way to RPC with `bitcoind` is as follows:
 ```
-$ curl --user StandUp --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getmininginfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:38332/
+$ curl --user StandUp --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getmininginfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/
 Enter host password for user 'bitcoinrpc':
 ```
 As noted, you will be prompted for your password.
 
-> :link: **SIGNET vs MAINNET:** Testnet uses a URL with port 38332 and mainnet uses a URL with port 8332. Take a look in your `bitcoin.conf`, it's all laid out there.
+> :link: **TESTNET vs MAINNET:** Testnet uses a URL with port 18332 and mainnet uses a URL with port 8332. Take a look in your `bitcoin.conf`, it's all laid out there.
 
 The insecure way to do so is as follows:
 ```
-$ curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getmininginfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:38332/
+$ 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/
 ```
-> **WARNING:** Entering your password on the command line may put your password into the process table and/or save it into a history. This is even less recommended than putting it in a file, except for testing on signet (or testnet). If you want to do it anywhere else, make sure you know what you're doing!
+> **WARNING:** Entering your password on the command line may put your password into the process table and/or save it into a history. This is even less recommended than putting it in a file, except for testing on testnet. If you want to do it anywhere else, make sure you know what you're doing!
 
 ### Know Your Command & Parameters
 
@@ -110,17 +110,17 @@ 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:38332/
+$ 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.
 
-> **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 38332 (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.
+> **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`:
 ```
-$ curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getmininginfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:38332/ | jq -r '.'
+$ 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/ | jq -r '.'
   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                  Dload  Upload   Total   Spent    Left  Speed
 100   295  100   218  100    77  72666  25666 --:--:-- --:--:-- --:--:-- 98333
@@ -147,7 +147,7 @@ Though you're accessing `bitcoind` directly, you'll still get access to wallet f
 
 Use the `getaddressesbylabel` RPC to list all of your current addresses:
 ```
-$ curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getaddressesbylabel", "params": [""] }' -H 'content-type: text/plain;' http://127.0.0.1:38332/ | jq -r '.'
+$ curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getaddressesbylabel", "params": [""] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/ | jq -r '.'
 {
   "result": {
     "mi25UrzHnvn3bpEfFCNqJhPWJn5b77a5NE": {
@@ -181,7 +181,7 @@ The result is a list of all the addresses that have been used by this wallet ...
 
 Use the `listunspent` RPC to list the funds that you have available:
 ```
-$ curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "listunspent", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:38332/ | jq -r '.'
+$ curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "listunspent", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/ | jq -r '.'
 {
   "result": [
     {
@@ -220,7 +220,7 @@ This is almost exactly the same output that you receive when you type `bitcoin-c
 
 After you know where your funds are, the next step in crafting a transaction is to get a change address. By now you've probably got the hang of this, and you know that for simple RPC commands, all you need to do is adjust the `method` is the `curl` command:
 ```
-$ curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getrawchangeaddress", "params": ["legacy"] }' -H 'content-type: text/plain;' http://127.0.0.1:38332/ | jq -r '.'
+$ curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getrawchangeaddress", "params": ["legacy"] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/ | jq -r '.'
 {
   "result": "mrSqN37TPs89GcidSZTvXmMzjxoJZ6RKoz",
   "error": null,
@@ -232,7 +232,7 @@ $ curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc"
 
 At this point, we can even revert to our standard practice of saving results to variables with additional help from `jq`:
 ```
-$ 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:38332/ | jq -r '.result')
+$ 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
 ```
@@ -248,10 +248,10 @@ Just as with `bitcoin-cli`, in order to create a transaction by curling RPC comm
 
 This example sets up our variables for using the 1.2985 BTC in funds listed in the first unspent transaction above:
 ```
-$ utxo_txid=$(curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "listunspent", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:38332/ | jq -r '.result | .[0] | .txid')
-$ utxo_vout=$(curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "listunspent", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:38332/ | jq -r '.result | .[0] | .vout')
+$ utxo_txid=$(curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "listunspent", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/ | jq -r '.result | .[0] | .txid')
+$ utxo_vout=$(curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "listunspent", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/ | jq -r '.result | .[0] | .vout')
 $ recipient=mwCwTceJvYV27KXBc3NJZys6CjsgsoeHmf
-$ 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:38332/ | jq -r '.result')
+$ 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 $utxo_txid
 e7071092dee0b2ae584bf6c1ee3c22164304e3a17feea7a32c22db5603cd6a0d
@@ -267,7 +267,7 @@ n2jf3MzeFpFGa7wq8rXKVnVuv5FoNSJZ1N
 
 The transaction created with `curl` is very similar to the transaction created with `bitcoin-cli`, but with a few subtle differences:
 ```
-$ curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "createrawtransaction", "params": [''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout' } ]'', ''{ "'$recipient'": 0.0003, "'$changeaddress'": 0.0005}'']}' -H 'content-type: text/plain;' http://127.0.0.1:38332/ | jq -r '.'
+$ curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "createrawtransaction", "params": [''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout' } ]'', ''{ "'$recipient'": 0.0003, "'$changeaddress'": 0.0005}'']}' -H 'content-type: text/plain;' http://127.0.0.1:18332/ | jq -r '.'
 {
   "result": "02000000010d6acd0356db222ca3a7ee7fa1e3044316223ceec1f64b58aeb2e0de921007e70100000000ffffffff0230750000000000001976a914ac19d3fd17710e6b9a331022fe92c693fdf6659588ac50c30000000000001976a9147021efec134057043386decfaa6a6aa4ee5f19eb88ac00000000",
   "error": null,
@@ -286,7 +286,7 @@ However, there's one last thing of note in this example, and it can be _maddenin
 
 Having verified that things work, you probably want to save the hex code into a variable:
 ```
-$ hexcode=$(curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "createrawtransaction", "params": [''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout' } ]'', ''{ "'$recipient'": 0.0003, "'$changeaddress'": 0.0005}'']}' -H 'content-type: text/plain;' http://127.0.0.1:38332/ | jq -r '.result')
+$ hexcode=$(curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "createrawtransaction", "params": [''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout' } ]'', ''{ "'$recipient'": 0.0003, "'$changeaddress'": 0.0005}'']}' -H 'content-type: text/plain;' http://127.0.0.1:18332/ | jq -r '.result')
 ```
 
 ### Sign and Send
@@ -294,9 +294,9 @@ $ hexcode=$(curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '
 Signing and sending your transaction using `curl` is an easy use of the `signrawtransactionwithwallet` and `sendrawtransaction` RPC:
 
 ```
-$ signedhex=$(curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "signrawtransactionwithwallet", "params": ["'$hexcode'"] }' -H 'content-type: text/plain;' http://127.0.0.1:38332/ | jq -r '.result | .hex')
+$ signedhex=$(curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "signrawtransactionwithwallet", "params": ["'$hexcode'"] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/ | jq -r '.result | .hex')
 
-$ curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "sendrawtransaction", "params": ["'$signedhex'"] }' -H 'content-type: text/plain;' http://127.0.0.1:38332/ | jq -r '.'
+$ curl --user StandUp:8eaf562eaf45c33c3328bc66008f2dd1 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "sendrawtransaction", "params": ["'$signedhex'"] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/ | jq -r '.'
 {
   "result": "eb84c5008038d760805d4d9644ace67849542864220cb2685a1ea2c64176b82d",
   "error": null,

05_2_Resending_a_Transaction_with_RBF.md

@@ -1,5 +1,3 @@
-TODO: This is now a default per updates in 24, 29. You don't need to verify any more. (Check that works, and redocument)
-
 # 5.2: Resending a Transaction with RBF
 
 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.

06_1_Sending_a_Transaction_to_a_Multisig.md

@@ -95,7 +95,7 @@ When used correctly, `createmultisig` returns three results, all of which are cr
 
 The _address_ is what you'll give out to people who want to send funds. You'll notice that it has a new prefix of `2`, exactly like those P2SH-SegWit addresses. That's because, like them, `createmultisig` is actually creating a totally new type of address called a P2SH address. It works exactly like a standard P2PKH address for sending funds, but since this one has been built to require multiple addresses, you'll need to do a little more work to spend them. 
 
-> :link: **SIGNET vs MAINNET:** On signet (or testnet) the prefix for P2SH addresses is `2`, while on mainnet, it's `3`.
+> :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 [§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.
 

06_3_Sending_an_Automated_Multisig.md

@@ -1,7 +1,3 @@
-TODO:
-* 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.
-* Might be a new 6.4? or included here
-  
  # 6.3: Sending & Spending an Automated Multisig
 
 The standard technique for creating multisignature addresses and for spending their funds is complex, but it's a worthwhile exercise for understanding a bit more about how they work, and how you can manipulate them at a relatively low level. However, Bitcoin Core has made multisigs a little bit easier in new releases. 

07_1a_Creating_Animated_QR_Codes.md

@@ -1,3 +0,0 @@
-   * New Subsection: Understanding Uniform Resources
-   * New Subsection: Creating an Animated QR
-   * New Subsection: Creating an Animated QR of a PSBT

07_3_Integrating_with_Hardware_Wallets.md

@@ -28,8 +28,6 @@ Once you've gotten Bitcoin Standup running on your local machine, you'll want to
 
 We will be using a Macintosh and Testnet for the examples in this section.
 
-(Currently, MacOS only support Testnet, not Signet; this should be updated.)
-
 ### Create an Alias for Bitcoin-CLI
 
 Create an alias that runs `bitcoin-cli` from the correct directory with any appropriate flags.

08_2_Sending_a_Transaction_with_Data.md

@@ -1,5 +1,3 @@
-TODO: Talk about big expansion (30.0)
-
 # 8.2: Sending a Transaction with Data
 
 The final way to vary how you send a basic transaction is to use the transaction to send data instead of funds (or really, in addition to funds). This gives you the ability to embed information in the blockchain. It is done through a special `OP_RETURN` command.

09_0_Expanding_Bitcoin_Transactions_with_Schnorr.md

@@ -1,53 +0,0 @@
-This was the initial theory for this section:
-
-* 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 [this might be another section]
-
-We also may want some of this:
-
-**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)

09_3_Testing_a_Bitcoin_Script.md

@@ -196,15 +196,15 @@ Assume that these debuggers have the nice advantage of showing things visually a
 
 Even with a great tool like `btcdeb` or transient resources like the various online script testers, you're not working with the real thing. You can't guarantee that they follow Bitcoin's consensus rules, which means you can't guarantee their results. For example, the Script Playground explicitly says that it ignores a bug that's implicit in Bitcoin multisignatures. This means that any multisig code that you successfully test on the Script Playground will break in the real world.
 
-So the only way to _really_ test Bitcoin Scripts is to try them out on Signet.
+So the only way to _really_ test Bitcoin Scripts is to try them out on Testnet.
 
 And how do you do that? As it happens that's the topic of [chapter 10](10_0_Embedding_Bitcoin_Scripts_in_P2SH_Transactions.md), which looks into introducing these abstract scripts to the real world of Bitcoin by embedding them in P2SH transactions. (But even then, you will probably need an API to push your P2SH transaction onto the Bitcoin network, so full testing will still be a ways in the future.)
 
-_Whatever_ other testing methods you've used, testing a script on Signet should be your final test _before_ you put your Script on Mainnet. Don't trust that your code is right; don't just eyeball it. Don't even trust whatever simulators or debuggers you've been using. Doing so is another great way to lose funds on Bitcoin.
+_Whatever_ other testing methods you've used, testing a script on Testnet should be your final test _before_ you put your Script on Mainnet. Don't trust that your code is right; don't just eyeball it. Don't even trust whatever simulators or debuggers you've been using. Doing so is another great way to lose funds on Bitcoin.
 
 ## Summary: Testing a Bitcoin Script
 
-You should install `btcdeb` as a command-line tool to test out your Bitcoin Scripts. As of this writing, it produces accurate results that can step through the entire scripting process. You can also look at some online sites for a more visual representation. When you're all done, you're going to need to go to signet to make sure things are working accurately, before you deploy more generally.
+You should install `btcdeb` as a command-line tool to test out your Bitcoin Scripts. As of this writing, it produces accurate results that can step through the entire scripting process. You can also look at some online sites for a more visual representation. When you're all done, you're going to need to go to testnet to make sure things are working accurately, before you deploy more generally.
 
 ## What's Next?
 

10_1_Understanding_the_Foundation_of_P2SH.md

@@ -39,7 +39,7 @@ The locking script is quite simple looking: `OP_HASH160 a5d106eb8ee51b23cf60d8bd
 
 One of the interesting elements of P2SH transactions is that neither the sender nor the Blockchain actually knows what the `redeemScript` is! A sender just sends to a standardized P2SH address marked with a "2" prefix and they don't worry about how the recipient is going to retrieve the funds at the end.
 
-> :link: **SIGNET vs MAINNET:** on signet (and testnet), the prefix for P2SH addresses is `2`, while on mainnet, it's `3`.
+> :link: **TESTNET vs MAINNET:** on testnet, the prefix for P2SH addresses is `2`, while on mainnet, it's `3`.
 
 ## Understand How to Build a P2SH Script
 

11_1_Understanding_Timelock_Options.md

@@ -1,8 +1,3 @@
-TODO:
-
-* Explanation: Better distinguish differences
-* Reference: consider chart at in https://prestwi.ch/bitcoin-time-locks/
-
 # 11.1: Understanding Timelock Options
 
 In [§8.1: Sending a Transaction with a Locktime](08_1_Sending_a_Transaction_with_a_Locktime.md), `nLocktime` offered a great first option for locking transactions so that they couldn't be spent until some point in the future — based either on time or blockheight. But, that's not the only way to put a timelock on a transaction.

14_1_Verifying_Your_Tor_Setup.md

@@ -72,12 +72,11 @@ The Tor config file is found at `/etc/tor/torrc`. If you look at it, you should
 ```
 HiddenServiceDir /var/lib/tor/standup/
 HiddenServiceVersion 3
-HiddenServicePort 1309 127.0.0.1:38332
 HiddenServicePort 1309 127.0.0.1:18332
 HiddenServicePort 1309 127.0.0.1:18443
 HiddenServicePort 1309 127.0.0.1:8332
 ```
-> :link: **SIGNET vs MAINNET:** Mainnet RPC is run on port 8332, testnet on port 18332, regtest on port 18443, signet on port 38332.
+> :link: **TESTNET vs MAINNET:** Mainnet RPC is run on port 8332, testnet on port 18332.
 
 > :information_source: **NOTE:** The `HiddenServiceDir` is where all the files are kept for this particular service. If you need to lookup your onion address, access keys, or add authorized clients, this is where to do so!
 
@@ -104,14 +103,14 @@ Bitcoin Standup also ensures that your `bitcoind` is set up to optionally commun
 
 You can verify the initial setup of Tor for `bitcoind` by grepping for "tor" in the `debug.log` in your data directory:
 ```
-$ grep "tor:" ~/.bitcoin/signet/debug.log
+$ grep "tor:" ~/.bitcoin/testnet3/debug.log
 2021-06-09T14:07:04Z tor: ADD_ONION successful
-2021-06-09T14:07:04Z tor: Got service ID vazr3k6bgnfafmdpcmbegoe5ju5kqyz4tk7hhntgaqscam2qupdtk2yd, advertising service vazr3k6bgnfafmdpcmbegoe5ju5kqyz4tk7hhntgaqscam2qupdtk2yd.onion:38333
-2021-06-09T14:07:04Z tor: Cached service private key to /home/standup/.bitcoin/signet/onion_v3_private_key
+2021-06-09T14:07:04Z tor: Got service ID vazr3k6bgnfafmdpcmbegoe5ju5kqyz4tk7hhntgaqscam2qupdtk2yd, advertising service vazr3k6bgnfafmdpcmbegoe5ju5kqyz4tk7hhntgaqscam2qupdtk2yd.onion:18333
+2021-06-09T14:07:04Z tor: Cached service private key to /home/standup/.bitcoin/testnet3/onion_v3_private_key
 ```
 > :information_source: **NOTE:** Bitcoin Core does not support v2 addresses anymore. Tor v2 support was removed in [#22050](https://github.com/bitcoin/bitcoin/pull/22050)
 
-> **TESTNET vs MAINNET:** Mainnet `bitcoind` responds on port 8333, testnet on port 18333, signet on 38333.
+> **TESTNET vs MAINNET:** Mainnet `bitcoind` responds on port 8333, testnet on port 18333.
 
 You can verify that a Tor hidden service has been created for Bitcoin with the `getnetworkinfo` RPC call:
 

14_2_Changing_Your_Bitcoin_Hidden_Services.md

@@ -18,15 +18,15 @@ Once you've added an `.auth` file to the `authorized_client` subdirectory, then
 
 ## Reset Your `bitcoind` Onion Address
 
-If you ever want to reset your onion address for `bitcoind`, just remove the `onion_v3_private_key` in your data directory, such as `~/.bitcoin/signet`:
+If you ever want to reset your onion address for `bitcoind`, just remove the `onion_private_key` in your data directory, such as `~/.bitcoin/testnet`:
 ```
-$ cd ~/.bitcoin/signet
-$ rm onion_v3_private_key 
+$ cd ~/.bitcoin/testnet
+$ rm onion_private_key 
 ```
 When you restart, a new onion address will be generated:
 ```
 2020-07-22T23:52:27Z tor: Got service ID pyrtqyiqbwb3rhe7, advertising service pyrtqyiqbwb3rhe7.onion:18333
-2020-07-22T23:52:27Z tor: Cached service private key to /home/standup/.bitcoin/signet/onion_v3_private_key
+2020-07-22T23:52:27Z tor: Cached service private key to /home/standup/.bitcoin/testnet3/onion_private_key
 ```
 
 ## Reset Your RPC Onion Address

15_1_i2p_service.md

@@ -94,7 +94,7 @@ The following will run Bitcoin Core I2P services:
 
 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/signet$ ls
+   ~/.bitcoin/testnet3$ ls
 
    anchors.dat  chainstate         i2p_private_key  settings.json
    banlist.dat  debug.log          mempool.dat      wallets

16_1_Accessing_Bitcoind_with_C.md

@@ -104,7 +104,7 @@ 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 38332 should be correct for the standard signet setup described in these 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
 server=1
@@ -117,7 +117,7 @@ rpcpassword=6305f1b2dbb3bc5a16cd0f4aac7e1eba
 rpcallowip=127.0.0.1
 debug=tor
 prune=550
-signet=1
+testnet=1
 [test]
 rpcbind=127.0.0.1
 rpcport=18332
@@ -134,7 +134,7 @@ bitcoinrpc_cl_t *rpc_client;
 rpc_client = bitcoinrpc_cl_init_params("StandUp", "6305f1b2dbb3bc5a16cd0f4aac7e1eba", "127.0.0.1", 18332);
 ```
 
-> **MAINNET VS SIGNET:** The port would be 8332 for a mainnet setup.
+> **MAINNET VS TESTNET:** The port would be 8332 for a mainnet setup.
 
 If `rpc_client` is successfully initialized, you'll be able to send off RPC commands.
 

17_3_Using_BIP32_in_Libwally.md

@@ -29,9 +29,7 @@ With a seed in hand, you can then generate a master extended key with the `bip32
 ```
 As you can see, you'll need to tell it what version of the key to return, in this case `BIP32_VER_TEST_PRIVATE`, a private testnet key.
 
-> :link: **SIGNET vs MAINNET:** On mainnet, you'd instead ask for `BIP32_VER_MAIN_PRIVATE`.
-
-(Libwally has fallen out of date, and there does not seem to be a Signet option.)
+> :link: **TESTNET vs MAINNET:** On mainnet, you'd instead ask for `BIP32_VER_MAIN_PRIVATE`.
 
 ### Generate xpub & xprv
 
@@ -53,14 +51,14 @@ However, for HD wallets, each of those levels of the hierachy is used in a very
 Altogether, a BIP32 derivation path is defined to have five levels:
 
 1. **Purpose.** This is usually set to `44'` or `84'`, depending on the BIP that is being followed.
-2. **Coin.** For Mainnet bitcoins, this is `0'`, for signet, regtest, or testnet it's `1'`.
+2. **Coin.** For Mainnet bitcoins, this is `0'`, for testnet it's `1'`.
 3. **Account.** A wallet can contain multiple, discrete accounts, starting with `0'`.
 4. **Change.** External addresses (for distribution) are set to `0`, while internal addresses (for change) are set to `1`.
 5. **Index.** The nth address for the hierarchy, starting with `0`.
 
-So on signet (or any of the other testing networks), the zeroth adddress for an external address for the zeroth account for testnet coins using the BIP84 standards is `[m/84'/1'/0'/0/0]`. That's the address you'll be creating momentarily.
+So on testnet, the zeroth adddress for an external address for the zeroth account for testnet coins using the BIP84 standards is `[m/84'/1'/0'/0/0]`. That's the address you'll be creating momentarily.
 
-> :link: **SIGNET vs MAINNET:** For mainnet, that'd be `[m/84'/0'/0'/0/0]`
+> :link: **TESTNET vs MAINNET:** For mainnet, that'd be `[m/84'/0'/0'/0/0]`
 
 ### Understand the Hierarchary in Bitcoin Core
 
@@ -76,7 +74,7 @@ One way to do this is to use the `bip32_key_from_parent_path_alloc` function to
 ```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 testing coins) of the 84th hardened child (that's the BIP84 standard): `[m/84'/1'/0']`.
+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
@@ -111,7 +109,7 @@ Finally, you're ready to generate an address from your final key. All you do is
   printf("[m/84'/1'/0'/0/0]: %s\n",segwit);
 ```  
 
-> :link: **TESTNET vs MAINNET:** The `tb` argument defines a signet or testnet address. For mainnet instead use `bc`.
+> :link: **TESTNET vs MAINNET:** The `tb` argument defines a testnet address. For mainnet instead use `bc`.
 
 There is also a `wally_bip32_key_to_address` function, which can be used to generate a legacy address or a nested Segwit address.
 

A1_0_Understanding_Bitcoin_Standup.md

@@ -12,9 +12,7 @@ Your host's timezone is stored in `/etc/timezone`, then an appropriate file from
 
 ## Step 3: Updating Debian
 
-The `apt-get` package manager is used to bring your machine up to date and to install `gnupg`, `git`, the random-number generators `haveged` and `xxd`,  and the uncomplicated firewall `ufw`. 
-
-The `apt-get` commands are run with `-y`, which should force all questions to be answered "yes", and allow the script to be run without interaction (e.g., as a StackScript). That failed with the Debian 13 update, with some questions going unanswered and locking up the script, so the `-o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold"` options were added to say, "We're really serious, no questions!"
+The `apt-get` package manager is used to bring your machine up to date and to install `gnupg`, the random-number generator `haveged`, and the uncomplicated firewall `ufw`. 
 
 Your machine is setup to automatically stay up to date with `echo "unattended-upgrades unattended-upgrades/enable_auto_updates boolean true" | debconf-set-selections`.
 
@@ -22,7 +20,7 @@ Your machine is setup to automatically stay up to date with `echo "unattended-up
 
 A `standup` user is created, which will be used for your Bitcoin applications. It also has `sudo` permissions, allowing you to take privileged actions with this account.
 
-If you supplied a Standup SSH key, it will allow you access to this account (otherwise, you must use the password you created in setup).
+If you supplied an SSH key, it will allow you access to this account (otherwise, you must use the password you created in setup).
 
 If you supplied an IP address, `ssh` access will be limited to that address, per `/etc/hosts.allow`.
 

A3_0_Using_Bitcoin_Regtest.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.
 
-The majority of this course presumes that you will either use the Mainnet or Testnet. However, those aren't the only choices. While developing Bitcoin applications, you might want to keep your applications isolated from these public blockchains. To do so, you can create a blockchain from scratch using the Regtest, which has one other major advantage over Signet and Testnet: you choose when to create new blocks, so you have complete control over the environment.
+The majority of this course presumes that you will either use the Mainnet or Testnet. However, those aren't the only choices. While developing Bitcoin applications, you might want to keep your applications isolated from these public blockchains. To do so, you can create a blockchain from scratch using the Regtest, which has one other major advantage over Testnet: you choose when to create new blocks, so you have complete control over the environment.
 
 ## Start Bitcoind on Regtest
 
@@ -22,7 +22,7 @@ If you wish, you can later restart your Regtest with a new blockchain.
 Regtest wallets and blockchain state (chainstate) are saved in the regtest subdirectory of the Bitcoin configuration directory:
 ```
 user@mybtc:~/.bitcoin# ls
-bitcoin.conf  regtest  signet
+bitcoin.conf  regtest  testnet3
 ```
 
 To start a brand new Blockchain using regtest, all you have to do is delete the `regtest` folder and restart the Bitcoind:
@@ -40,7 +40,7 @@ $ bitcoin-cli -regtest -named createwallet wallet_name="regtest_desc_wallet" des
 
 ## Generate Blocks
 
-You can generate (mine) new blocks on a regtest chain using the RPC method `generate` with an argument for how many blocks to generate. It only makes sense to use this method on regtest; due to the high difficulty it's very unlikely that it will yield new blocks on the mainnet, signet, or testnet:
+You can generate (mine) new blocks on a regtest chain using the RPC method `generate` with an argument for how many blocks to generate. It only makes sense to use this method on regtest; due to the high difficulty it's very unlikely that it will yield to new blocks on the mainnet or testnet:
 ```
 $ bitcoin-cli -regtest -generate 101
 [
@@ -196,7 +196,7 @@ n2.after (before) = 100
 
 ## Summary: Using Bitcoin Regtest
 
-A regtest environment for Bitcoin works just like any testing environment, except for the fact that you have the ability to easily and quickly generate blocks.
+A regtest environment for Bitcoin works just like any testnet environment, except for the fact that you have the ability to easily and quickly generate blocks.
 
 > :fire: ***What is the power of regtest?*** The biggest power of regtest is that you can quickly mine blocks, allowing you to rush the blockchain along, to test transactions, timelocks, and other features that you'd otherwise have to sit around and wait on. However, the other power is that you can run it privately, without connecting to a public blockchain, allowing you to test our proprietary ideas before releasing them into the world.
 

README.md

@@ -1,4 +1,4 @@
-# Learning Bitcoin from the Command Line 3.0 (in process)
+# Learning Bitcoin from the Command Line 2.2.1
 ### _by Christopher Allen and Shannon Appelcline_
 
 ![](https://www.blockchaincommons.com/images/projects/lbtc-screen.png)
@@ -22,6 +22,8 @@ If you'd like to make your own translation, please see [Contributing](https://gi
 
 ### PART ONE: PREPARING FOR BITCOIN
 
+**Status:** Finished. Updated for 0.20.
+
 * [1.0: Introduction to Programming with Bitcoin Core and Lightning](01_0_Introduction.md)
     * [Interlude: Introducing Bitcoin](01_1_Introducing_Bitcoin.md)
 * [2.0: Setting Up a Bitcoin-Core VPS](02_0_Setting_Up_a_Bitcoin-Core_VPS.md)
@@ -30,132 +32,119 @@ If you'd like to make your own translation, please see [Contributing](https://gi
 
 ### PART TWO: USING BITCOIN-CLI
 
+**Status:** Finished. Updated for 0.20.
+
 * [3.0: Understanding Your Bitcoin Setup](03_0_Understanding_Your_Bitcoin_Setup.md)
   * [3.1: Verifying Your Bitcoin Setup](03_1_Verifying_Your_Bitcoin_Setup.md)
   * [3.2: Knowing Your Bitcoin Setup](03_2_Knowing_Your_Bitcoin_Setup.md)
-  * [3.3: Setting Up Your Wallet](03_3_Setting_Up_Your_Wallet.md) [**TO UPDATE**]
-    * [Interlude: Using Command-Line Variables](03_3a_Interlude_Using_Command-Line_Variables.md)
-    * [Interlude: Creating QR Codes](03_3b_Interlude_Creating_QR_Codes.md) [**TO WRITE**]
-  * [3.4: Understanding the Descriptor](03_5_Understanding_the_Descriptor.md) [**TO UPDATE**]
-  * [3.5: Receiving a Transaction](03_4_Receiving_a_Transaction.md) [**TO REVISE**]
-* [4.0: Sending Bitcoin Transactions](04_0_Sending_Bitcoin_Transactions.md) [**TO UPDATE FOR SEGWIT**]
-  * [4.1: Sending Coins the Easy Way](04_1_Sending_Coins_The_Easy_Way.md) [**TO UPDATE FOR SEGWIT**]
-  * [4.2: Creating a Raw Transaction](04_2_Creating_a_Raw_Transaction.md) [**TO UPDATE FOR SEGWIT**]
-     * [Interlude: Using JQ](04_2a_Interlude_Using_JQ.md) [**TO UPDATE FOR SEGWIT**]
-  * [4.3: Creating a Raw Transaction with Named Arguments](04_3_Creating_a_Raw_Transaction_with_Named_Arguments.md) [**TO UPDATE FOR SEGWIT**]
-  * [4.4: Sending Coins with Raw Transactions](04_4_Sending_Coins_with_a_Raw_Transaction.md) [**TO UPDATE**]
-     * [Interlude: Using Curl](04_4a_Interlude_Using_Curl.md)
-  * [4.5: Sending Coins with Automated Raw Transactions](04_5_Sending_Coins_with_Automated_Raw_Transactions.md) [**TO UPDATE FOR SEGWIT**]
-  * [4.6: Creating a Segwit Transaction](04_6_Creating_a_Segwit_Transaction.md) [**TO REMOVE**]
-  * [4.6: Sending Other Types of Transactions](04_6_Sending_Other_Types_of_Transactions.md) [**TO WRITE**]
+  * [3.3: Setting Up Your Wallet](03_3_Setting_Up_Your_Wallet.md)
+    * [Interlude: Using Command-Line Variables](03_3__Interlude_Using_Command-Line_Variables.md)
+  * [3.4: Receiving a Transaction](03_4_Receiving_a_Transaction.md)
+  * [3.5: Understanding the Descriptor](03_5_Understanding_the_Descriptor.md)
+* [4.0: Sending Bitcoin Transactions](04_0_Sending_Bitcoin_Transactions.md)
+  * [4.1: Sending Coins the Easy Way](04_1_Sending_Coins_The_Easy_Way.md)
+  * [4.2: Creating a Raw Transaction](04_2_Creating_a_Raw_Transaction.md)
+     * [Interlude: Using JQ](04_2__Interlude_Using_JQ.md)
+  * [4.3: Creating a Raw Transaction with Named Arguments](04_3_Creating_a_Raw_Transaction_with_Named_Arguments.md)
+  * [4.4: Sending Coins with Raw Transactions](04_4_Sending_Coins_with_a_Raw_Transaction.md)
+     * [Interlude: Using Curl](04_4__Interlude_Using_Curl.md)
+  * [4.5: Sending Coins with Automated Raw Transactions](04_5_Sending_Coins_with_Automated_Raw_Transactions.md)
+  * [4.6: Creating a Segwit Transaction](04_6_Creating_a_Segwit_Transaction.md)
 * [5.0: Controlling Bitcoin Transactions](05_0_Controlling_Bitcoin_Transactions.md)
   * [5.1 Watching for Stuck Transactions](05_1_Watching_for_Stuck_Transactions.md)
-  * [5.2: Resending a Transaction with RBF](05_2_Resending_a_Transaction_with_RBF.md) [**TO UPDATE**]
+  * [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 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) [**TO UPDATE**]
+  * [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)
-     * [Interlude: Creating Animated QR Codes](07_1a_Creating_Animated_QR_Codes.md) [**TO WRITE**]
   * [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.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) [**TO UPDATE**]
-* [9.0: Expanding Bitcoin Transactions with Schnorr](09_0_Expanding_Bitcoin_Transactions_with_Schnorr.md) [**TO WRITE**]
-  * [9.1: Understanding Schnorr & Taproot](09_1_Understanding_Schnorr_Taproot.md) [**TO WRITE**]
-  * [9.2: Sending Schnorr Signed Transactions](09_2_Sending_Schnorr_Signed_Transactions.md) [**TO WRITE**]
-  * [9.3: Sending a Schnorr Multisig](09_3_Sending_a_Schnorr_Multisig.md) [**TO WRITE**]    
-  * [9.4: Sending FROST Signed Transactions](09_4_Sending_FROST_Signed_Transactions.md) [**TO WRITE**]
-* [10.0: Expanding Bitcoin Transactions with Taproot](10_0_Expanding_Bitcoin_Transactions_with_Taproot.md) [**TO WRITE**]
-  * [10.1: Sending Basic Taproot Transactions](10_1_Sending_Basic_Taproot_Transactions.md) [**TO WRITE**]
-  * [10.2: Sending Advanced Taproot Transactions](10_2_Sending_Advanced_Taproot_Transactions.md) [**TO WRITE**]
+  * [8.2: Sending a Transaction with Data](08_2_Sending_a_Transaction_with_Data.md)
 
-### PART THREE: SCRIPTING WITH BITCOIN
+### PART THREE: BITCOIN SCRIPTING
 
-* [11.0: Introducing Bitcoin Scripts](11_0_Introducing_Bitcoin_Scripts.md)
-  * [11.1: Understanding the Foundation of Transactions](11_1_Understanding_the_Foundation_of_Transactions.md)
-  * [11.2: Running a Bitcoin Script](11_2_Running_a_Bitcoin_Script.md)
-  * [11.3: Testing a Bitcoin Script](11_3_Testing_a_Bitcoin_Script.md)
-  * [11.4: Scripting a P2PKH](11_4_Scripting_a_P2PKH.md)
-  * [11.5: Scripting a P2WPKH](11_5_Scripting_a_P2WPKH.md)
-* [12.0: Embedding Bitcoin Scripts in P2SH Transactions](12_0_Embedding_Bitcoin_Scripts_in_P2SH_Transactions.md)
-  * [12.1: Understanding the Foundation of P2SH](12_1_Understanding_the_Foundation_of_P2SH.md)
-  * [12.2: Building the Structure of P2SH](12_2_Building_the_Structure_of_P2SH.md)
-  * [12.3: Running a Bitcoin Script with P2SH](12_3_Running_a_Bitcoin_Script_with_P2SH.md)
-  * [12.4: Scripting a Multisig](12_4_Scripting_a_Multisig.md)
-  * [12.5: Scripting a Segwit Script](12_5_Scripting_a_Segwit_Script.md)
-  * [12.6: Spending a P2SH Transaction](12_6_Spending_a_P2SH_Transaction.md)
-* [13.0: Empowering Timelock with Bitcoin Scripts](13_0_Empowering_Timelock_with_Bitcoin_Scripts.md)
-  * [13.1: Understanding Timelock Options](13_1_Understanding_Timelock_Options.md) [**TO UPDATE**]
-  * [13.2: Using CLTV in Scripts](13_2_Using_CLTV_in_Scripts.md)
-  * [13.3: Using CSV in Scripts](13_3_Using_CSV_in_Scripts.md)
-* [14.0: Expanding Bitcoin Scripts](14_0_Expanding_Bitcoin_Scripts.md)
-  * [14.1: Using Script Conditionals](14_1_Using_Script_Conditionals.md)
-  * [14.2: Using Other Script Commands](14_2_Using_Other_Script_Commands.md)
-* [15.0: Improving Bitcoin Scripts with Taproot](15_0_Improving_Bitcoin_Scripts_with_Taproot.md) [**TO WRITE**]
-   * SECTIONS TBD, BASED ON WHAT'S IN NEW CHAPTERS 9 + 10
-* [16.0: Designing Real Bitcoin Scripts](16_0_Designing_Real_Bitcoin_Scripts.md)
-  * [16.1: Writing Puzzles Scripts](16_1_Writing_Puzzle_Scripts.md)
-  * [16.2: Writing Complex Multisig Scripts](16_2_Writing_Complex_Multisig_Scripts.md)
-  * [16.3: Empowering Bitcoin with Scripts](16_3_Empowering_Bitcoin_with_Scripts.md)
+**Status:** Finished. Updated for 0.20 and btcdeb.
 
-### PART FOUR: MAINTAINING PRIVACY
+* [9.0: Introducing Bitcoin Scripts](09_0_Introducing_Bitcoin_Scripts.md)
+  * [9.1: Understanding the Foundation of Transactions](09_1_Understanding_the_Foundation_of_Transactions.md)
+  * [9.2: Running a Bitcoin Script](09_2_Running_a_Bitcoin_Script.md)
+  * [9.3: Testing a Bitcoin Script](09_3_Testing_a_Bitcoin_Script.md)
+  * [9.4: Scripting a P2PKH](09_4_Scripting_a_P2PKH.md)
+  * [9.5: Scripting a P2WPKH](09_5_Scripting_a_P2WPKH.md)
+* [10.0: Embedding Bitcoin Scripts in P2SH Transactions](10_0_Embedding_Bitcoin_Scripts_in_P2SH_Transactions.md)
+  * [10.1: Understanding the Foundation of P2SH](10_1_Understanding_the_Foundation_of_P2SH.md)
+  * [10.2: Building the Structure of P2SH](10_2_Building_the_Structure_of_P2SH.md)
+  * [10.3: Running a Bitcoin Script with P2SH](10_3_Running_a_Bitcoin_Script_with_P2SH.md)
+  * [10.4: Scripting a Multisig](10_4_Scripting_a_Multisig.md)
+  * [10.5: Scripting a Segwit Script](10_5_Scripting_a_Segwit_Script.md)
+  * [10.6: Spending a P2SH Transaction](10_6_Spending_a_P2SH_Transaction.md)
+* [11.0: Empowering Timelock with Bitcoin Scripts](11_0_Empowering_Timelock_with_Bitcoin_Scripts.md)
+  * [11.1: Understanding Timelock Options](11_1_Understanding_Timelock_Options.md)
+  * [11.2: Using CLTV in Scripts](11_2_Using_CLTV_in_Scripts.md)
+  * [11.3: Using CSV in Scripts](11_3_Using_CSV_in_Scripts.md)
+* [12.0: Expanding Bitcoin Scripts](12_0_Expanding_Bitcoin_Scripts.md)
+  * [12.1: Using Script Conditionals](12_1_Using_Script_Conditionals.md)
+  * [12.2: Using Other Script Commands](12_2_Using_Other_Script_Commands.md)
+* [13.0: Designing Real Bitcoin Scripts](13_0_Designing_Real_Bitcoin_Scripts.md)
+  * [13.1: Writing Puzzles Scripts](13_1_Writing_Puzzle_Scripts.md)
+  * [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)
 
-* [17.0: Using Tor](16_0_Using_Tor.md)
-  * [17.1: Verifying Your Tor Setup](17_1_Verifying_Your_Tor_Setup.md)
-  * [17.2: Changing Your Bitcoin Hidden Services](17_2_Changing_Your_Bitcoin_Hidden_Services.md)
-  * [17.3: Adding SSH Hidden Services](17_3_Adding_SSH_Hidden_Services.md)
+### PART FOUR: PRIVACY
 
-* [18.0: Using i2p](18_0_Using_i2p.md)
-  * [18.1: Bitcoin Core as an I2P (Invisible Internet Project) service](18_1_i2p_service.md)
+**Status:** Finished.
 
-[TODO: CONSIDER IF CJDNS Network FITS IN HERE, possibly as 18.2, with the section renamed "Other Privacy Options" or something]
+* [14.0: Using Tor](14_0_Using_Tor.md)
+  * [14.1: Verifying Your Tor Setup](14_1_Verifying_Your_Tor_Setup.md)
+  * [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)
 
----
-
-_Everything over this line is on the backburner currently; files are being labeled P1, P2, P3, and L1, L2 and we'll figure out what to do with them later._
+* [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.
 
-* [P1.0: Talking to Bitcoind with C](P1_0_Talking_to_Bitcoind.md)
-  * [P1.1: Accessing Bitcoind in C with RPC Libraries](P1_1_Accessing_Bitcoind_with_C.md)
-  * [P1.2: Programming Bitcoind in C with RPC Libraries](P1_2_Programming_Bitcoind_with_C.md)
-  * [P1.3: Receiving Notifications in C with ZMQ Libraries](P1_3_Receiving_Bitcoind_Notifications_with_C.md)
-* [P2.0: Programming Bitcoin with Libwally](P2_0_Programming_with_Libwally.md)
-   * [P2.1: Setting Up Libwally](P2_1_Setting_Up_Libwally.md)
-   * [P2.2: Using BIP39 in Libwally](P2_2_Using_BIP39_in_Libwally.md)
-   * [P2.3: Using BIP32 in Libwally](P2_3_Using_BIP32_in_Libwally.md)
-   * [P2.4: Using PSBTs in Libwally](P2_4_Using_PSBTs_in_Libwally.md)
-   * [P2.5: Using Scripts in Libwally](P2_5_Using_Scripts_in_Libwally.md)
-   * [P2.6: Using Other Functions in Libwally](P2_6_Using_Other_Functions_in_Libwally.md)
-   * [P2.7: Integrating Libwally and Bitcoin-CLI](P2_7_Integrating_Libwally_and_Bitcoin-CLI.md)
-* [P3.0: Talking to Bitcoind with Other Languages](P3_0_Talking_to_Bitcoind_Other.md)
-  * [P3.1: Accessing Bitcoind with Go](P3_1_Accessing_Bitcoind_with_Go.md)
-  * [P3.2: Accessing Bitcoind with Java](P3_2_Accessing_Bitcoind_with_Java.md)
-  * [P3.3: Accessing Bitcoind with Node JS](P3_3_Accessing_Bitcoind_with_NodeJS.md)
-  * [P3.4: Accessing Bitcoind with Python](P3_4_Accessing_Bitcoind_with_Python.md)
-  * [P3.5: Accessing Bitcoind with Rust](P3_5_Accessing_Bitcoind_with_Rust.md)
-  * [P3.6: Accessing Bitcoind with Swift](P3_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.
 
-* [L1.0: Understanding Your Lightning Setup](L1_0_Understanding_Your_Lightning_Setup.md)
-  * [L1.1: Verifying Your core lightning Setup](L1_1_Verifying_Your_Lightning_Setup.md)
-  * [L1.2: Knowing Your core lightning Setup](L1_2_Knowing_Your_lightning_Setup.md)
-     * [Interlude: Accessing a Second Lightning Node](L1_2a_Interlude_Accessing_a_Second_Lightning_Node.md)
-  * [L1.3: Creating a Lightning Channel](L1_3_Setting_Up_a_Channel.md)
-* [L2.0: Using Lightning](L2_0_Using_Lightning.md)
-  * [L2.1: Generating a Payment Request](L2_1_Generate_a_Payment_Request.md)
-  * [L2.2: Paying an Invoice](L2_2_Paying_a_Invoice.md)
-  * [L2.3: Closing a Lighnting Channel]((L2_3_Closing_a_Channel.md))
-  * [L2.4: Expanding the Lightning Network](L2_4_Lightning_Network_Review.md)
+* [19.0: Understanding Your Lightning Setup](19_0_Understanding_Your_Lightning_Setup.md)
+  * [19.1: Verifying Your core lightning Setup](19_1_Verifying_Your_Lightning_Setup.md)
+  * [19.2: Knowing Your core 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
 
@@ -168,14 +157,11 @@ _Everything over this line is on the backburner currently; files are being label
 
 ## Status - Beta
 
-v2.2.2 of **Learning Bitcoin from the Command Line** is feature complete and has undergone full editing and integration. It is ready for learning. However, it is out-of-date, focused on Bitcoin Core 22.0. We are currently working on [v3.0](TODO.md) of the course, for release toward the end of 2026. 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.
+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.2 (January 22, 2026)
-
-* Updated §2.1 and Appendix 1 to accomodate recent updates to [Bitcoin-Standup-Scripts](https://github.com/BlockchainCommons/Bitcoin-Standup-Scripts) as well as changes to the Linode interface.
-
 #### 2.2.1 (January 15, 2026)
 
 * Incorporation of PRs and Issues, to close out previous iteration of course, in prep for big 3.0 update.

TODO.md

@@ -2,52 +2,51 @@
 
 The following TODO items are intended for a 3.0 version of Learning Bitcoin from the Command Line
 
-## Immediate TODO (for 2/5): Descriptor Wallets
+## Immediate TODO (for 1/29)
 
-1. Edit §3.1-3.2, esp. for any references to legacy addresses
-2. Update §3.3 to use a descriptor wallet 
-3. Update any mentions of classic wallets
-4. Thoroughly rewrite §3.4 for new focus on descriptors, possibly expanding to two sections.
-5. Update §3.5 to fit into new flow
-6. Remove all references to things appearing at certain versions (they're all pretty standardized now)
-7. But write a note early on about potential missing features
+1. Update Stackscripts to support/default signet
+2. Update non-Linode script too
+3. Revise §2.1 for newest Stackscript
+4. Puzzle out organization for overall project (largely based on updates below and remaining Issues)
+5. Change testnet to signet + list out network options
 
-## Immediate TODO (for 2/19): Segwit
-
-1. Change §4.1-4.5 to use Bech32 (incorporate existing §4.6)
-2. Create a new chapter §4.6
-   * Lay out new table of all the address types
-   * Demonstrate how to send legacy & wrapped Segwit transactions
-3. Remove legacy address references from the rest of the course
-
-## Longer-Term TODO (Small Tasks)
+## Revisions
 
 The following updates involve updates or the creation of new chapters, but their additions are generally bounded and known.
 
 1. Big changes to defaults
-   * <strike>Signet</strike>
+   * Signet
    * SEGWIT
       * Talk about address types: https://www.unchained.com/blog/bitcoin-address-types-compared
    * Descriptor Wallets
-1. Revise 4.4
-   * freezing coins
-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. Revise Section: Understanding the Descriptor (3.5)
+   * New Content: Descriptor Wallets
+   * Possibly also remove legacy wallets (3.3) and replace them entire with descriptors
+   * New Content: Complex Descriptors
+   * Consider: Breaking into Two Sections
 1. Revise Section: Understanding Timelock Options (11.1)
    * Explanation: Better distinguish differences
    * Reference: consider chart at in https://prestwi.ch/bitcoin-time-locks/
+1. Revise 4.5
+   * freezing coins
   
 The next step in revisions is:
 
 1. Run through entire course & make sure all commands & responses are still accurate (likely redoing them all).
 
-## Longer-Longer-Term TODO (Big Tasks)
+## Additions
 
 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** (currently new chapters 9+10, with revised TOC)
+1. New Interlude: Creating QR Codes (after 3.3)
+   * New Subsection: Creating a QR
+   * New Subsection: Creating a Quick Connect QR
+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
+
+**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
@@ -67,7 +66,7 @@ The following updates involve the large-scale work done on Schnorr and Taproot i
    * New Subsection: Using Schnorr with Taproot   
 * Update Chapter 6 (Multisigs) to Integrate with Schnorr
 
-**Chapter Y: Improving Bitcoin Scripts with Taproot** (currently new chapter 15, with plans to revise TOC)
+**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
@@ -99,9 +98,9 @@ The following updates involve the large-scale work done on Schnorr and Taproot i
    * Mention Taproot in 9.1 or 9.2
    * Add New Section 9.6: Scripting a P2TR (mostly a pointer to Chapter Y)
 
-## Further Updates (TIME PERMITTING)
+## Further Updates
 
-The following updates could be part of v3.0 or could be further future, depending on how long the above takes. My guess is that they'll get incorporated come late spring or summer.
+The following updates could be part of v3.0 or could be further future, depending on how long the above takes.
 
 1. New Graphics: Animated GIFs for key demos.
    * Reference: https://github.com/faressoft/terminalizer
@@ -238,14 +237,3 @@ 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.
-     
----
-
-
-## Immediate TODO (for 1/22): Signet
-
-1. <strike>Update Stackscripts to support/default signet</strike>
-2. <strike>Update non-Linode script too</strike>
-3. <strike>Revise §2.1 for newest Stackscript</strike>
-4. <strike>Puzzle out organization for overall project (largely based on updates below and remaining Issues)</strike>
-5. <strike>Change testnet to signet + list out network options</strike>