Merge branch 'master' into fixes

04_0_Sending_Bitcoin_Transactions.md

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

04_1_Sending_Coins_The_Easy_Way.md

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

04_6_Creating_a_Segwit_Transaction.md

@@ -12,7 +12,7 @@ The catch? SegWit uses different addresses, some of which are compatible with ol
 
 ## Understand a SegWit Transaction
 
-In classic transactions, signature (witness) information was stored toward the middle of the transaction, while in SegWit transactions, it's at the bottom. This goes hand-in-hand with the blocksize increases that were introduced in the SegWit upgrade. The blocksize was increased from 1M to a variable amount based on how many SegWit transactions are in a block, starting as low as 1M (no SegWit transactions) and going as high as 4M (all SegWit transactions). This variable sized was created to accomodate classic nodes, so that everything remains backward compatible. If a classic node sees a SegWit transaction, it throws out the witness information (resulting in a smaller sized block, under the old 1M limit), while if a new node sees a SegWit transaction, it keeps the witness information (resulting in a larger sized block, up to the new 4M limit).
+In classic transactions, signature (witness) information was stored toward the middle of the transaction, while in SegWit transactions, it's at the bottom. This goes hand-in-hand with the blocksize increases that were introduced in the SegWit upgrade. The blocksize was increased from 1M to a variable amount based on how many SegWit transactions are in a block, starting as low as 1M (no SegWit transactions) and going as high as 4M (all SegWit transactions). This variable size was created to accomodate classic nodes, so that everything remains backward compatible. If a classic node sees a SegWit transaction, it throws out the witness information (resulting in a smaller sized block, under the old 1M limit), while if a new node sees a SegWit transaction, it keeps the witness information (resulting in a larger sized block, up to the new 4M limit).
 
 So that's the what and how of SegWit transactions. Not that you need to know any of it to use them. Most transactions on the Bitcoin network are now SegWit. They're what you're going to natively use for more transactions and receipts of money. The details are no more relevant at this point than the details of how most of Bitcoin works.
 

13_1_Writing_Puzzle_Scripts.md

@@ -481,7 +481,7 @@ This is a nice script because it shows careful use of logic (with the `OP_NOT` a
 
 `btcdeb` can be run to prove the collision (and the script):
 ```
-$ btcdeb '[255044462d312e330a25e2e3cfd30a0a0a312030206f626a0a3c3c2f57696474682032203020522f4865696768742033203020522f547970652034203020522f537562747970652035203020522f46696c7465722036203020522f436f6c6f7253706163652037203020522f4c656e6774682038203020522f42697473506572436f6d706f6e656e7420383e3e0a73747265616d0affd8fffe00245348412d3120697320646561642121212121852fec092339759c39b1a1c63c4c97e1fffe017f46dc93a6b67e013b029aaa1db2560b45ca67d688c7f84b8c4c791fe02b3df614f86db1690901c56b45c1530afedfb76038e972722fe7ad728f0e4904e046c230570fe9d41398abe12ef5bc942be33542a4802d98b5d70f2a332ec37fac3514e74ddc0f2cc1a874cd0c78305a21566461309789606bd0bf3f98cda8044629a1 255044462d312e330a25e2e3cfd30a0a0a312030206f626a0a3c3c2f57696474682032203020522f4865696768742033203020522f547970652034203020522f537562747970652035203020522f46696c7465722036203020522f436f6c6f7253706163652037203020522f4c656e6774682038203020522f42697473506572436f6d706f6e656e7420383e3e0a73747265616d0affd8fffe00245348412d3120697320646561642121212121852fec092339759c39b1a1c63c4c97e1fffe017346dc9166b67e118f029ab621b2560ff9ca67cca8c7f85ba84c79030c2b3de218f86db3a90901d5df45c14f26fedfb3dc38e96ac22fe7bd728f0e45bce046d23c570feb141398bb552ef5a0a82be331fea48037b8b5d71f0e332edf93ac3500eb4ddc0decc1a864790c782c76215660dd309791d06bd0af3f98cda4bc4629b1 OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL']
+$ btcdeb '[255044462d312e330a25e2e3cfd30a0a0a312030206f626a0a3c3c2f57696474682032203020522f4865696768742033203020522f547970652034203020522f537562747970652035203020522f46696c7465722036203020522f436f6c6f7253706163652037203020522f4c656e6774682038203020522f42697473506572436f6d706f6e656e7420383e3e0a73747265616d0affd8fffe00245348412d3120697320646561642121212121852fec092339759c39b1a1c63c4c97e1fffe017f46dc93a6b67e013b029aaa1db2560b45ca67d688c7f84b8c4c791fe02b3df614f86db1690901c56b45c1530afedfb76038e972722fe7ad728f0e4904e046c230570fe9d41398abe12ef5bc942be33542a4802d98b5d70f2a332ec37fac3514e74ddc0f2cc1a874cd0c78305a21566461309789606bd0bf3f98cda8044629a1 255044462d312e330a25e2e3cfd30a0a0a312030206f626a0a3c3c2f57696474682032203020522f4865696768742033203020522f547970652034203020522f537562747970652035203020522f46696c7465722036203020522f436f6c6f7253706163652037203020522f4c656e6774682038203020522f42697473506572436f6d706f6e656e7420383e3e0a73747265616d0affd8fffe00245348412d3120697320646561642121212121852fec092339759c39b1a1c63c4c97e1fffe017346dc9166b67e118f029ab621b2560ff9ca67cca8c7f85ba84c79030c2b3de218f86db3a90901d5df45c14f26fedfb3dc38e96ac22fe7bd728f0e45bce046d23c570feb141398bb552ef5a0a82be331fea48037b8b5d71f0e332edf93ac3500eb4ddc0decc1a864790c782c76215660dd309791d06bd0af3f98cda4bc4629b1 OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL]'
 ```
 
 Peter Todd's other [bounties](https://bitcointalk.org/index.php?topic=293382.0) remain unclaimed at the time of this writing. They're all written in the same manner as the SHA-1 example above.

13_2_Writing_Complex_Multisig_Scripts.md

@@ -130,7 +130,7 @@ First, you test a signature for the buyer and the escrow agent, then a signature
 
 ### Write a Buyer-Centric Escrow Multisig
 
-[BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#Escrow_with_Timeout) offers an different example of this sort of escrow that doesn't have the extra protections to prevent going around the escrow agent, but which does give Alice total control if the escrow fails.
+[BIP 112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki#Escrow_with_Timeout) offers a different example of this sort of escrow that doesn't have the extra protections to prevent going around the escrow agent, but which does give Alice total control if the escrow fails.
 ```
 IF
 

14_3_Adding_SSH_Hidden_Services.md

@@ -54,6 +54,12 @@ Now that you've got Tor installed and know how to use it, you can add other serv
 
 > :fire: ***What's the power of Other Hidden Services?*** Every time you access a service on your server remotely, you leave footprints on the network. Even if the data is encrypted by something like SSH (or TLS), lurkers on the network can see where you're connecting from, where you're connecting to, and what service you're using. Does this matter? This is the question you have to ask. But if the answer is "Yes", you can protect the connection with a hidden service.
 
-Move on to "Programming with RPC" with [Chapter Sixteen: Talking to Bitcoind with C](16_0_Talking_to_Bitcoind.md).
+## What's Next?
 
-Or, if you're not a programmer, you can skip to [Chapter Nineteen: Understanding Your Lightning Setup](19_0_Understanding_Your_Lightning_Setup.md) to continue your command-line education with the Lightning Network.
+Move on to "Using i2p" with [Chapter Fifteen: Using i2p](15_0_Using_i2p.md).
+
+Or, if you prefer, there are two alternate paths:
+
+If you want to stay focused on Bitcoin, move on to "Programming with RPC" with [Chapter Sixteen: Talking to Bitcoind with C](16_0_Talking_to_Bitcoind.md).
+
+Or, if you want to stay focused on the command-line because you're not a programmer, you can skip to [Chapter Nineteen: Understanding Your Lightning Setup](19_0_Understanding_Your_Lightning_Setup.md) to continue your command-line education with the Lightning Network.

16_1_Accessing_Bitcoind_with_C.md

@@ -147,7 +147,7 @@ bitcoinrpc_global_cleanup();
 
 ### Test the Test Code
 
-Test code can be found at [15_1_testbitcoin.c in the src directory](src/15_1_testbitcoin.c). Download it to your testnet machine, then insert the correct RPC password (and change the RPC user if you didn't create your server with StandUp).
+Test code can be found at [16_1_testbitcoin.c in the src directory](src/16_1_testbitcoin.c). Download it to your testnet machine, then insert the correct RPC password (and change the RPC user if you didn't create your server with StandUp).
 
 You can compile and run this as follows:
 ```
@@ -213,7 +213,7 @@ printf("Block Count: %d\n",blocks);
 
 ### Test the Info Code
 
-Retrieve the test code from [the src directory](src/15_1_getmininginfo.c).
+Retrieve the test code from [the src directory](src/16_1_getmininginfo.c).
 ```
 $ cc getmininginfo.c -lbitcoinrpc -ljansson -o getmininginfo
 $ ./getmininginfo 

16_2_Programming_Bitcoind_with_C.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.
 
-[§15.1](15_1_Accessing_Bitcoind_with_C.md) laid out the methodology for creating C programs using RPC and JSON libraries. We're now going to show the potential of those C libraries by laying out a simplistic, first cut of an actual Bitcoin program.
+[§16.1](16_1_Accessing_Bitcoind_with_C.md) laid out the methodology for creating C programs using RPC and JSON libraries. We're now going to show the potential of those C libraries by laying out a simplistic, first cut of an actual Bitcoin program.
 
 ## Plan for Your Code
 
@@ -324,7 +324,7 @@ The entire code, with a _little_ more error-checking appears in the Appendix.
 
 ## Test Your Code
 
-The complete code can be found in the [src directory](src/15_2_sendtoaddress.c).
+The complete code can be found in the [src directory](src/16_2_sendtoaddress.c).
 
 Compile this as usual:
 ```

16_3_Receiving_Bitcoind_Notifications_with_C.md

@@ -121,7 +121,7 @@ Of course when you're done, you should clean up:
 
 ### Test the Notification Code
 
-The source code is in the [src directory](src/15_3_chainlistener.c) as usual. You should compile it:
+The source code is in the [src directory](src/16_3_chainlistener.c) as usual. You should compile it:
 ```
 $ cc -o chainlistener chainlistener.c -I/usr/local/include -L/usr/local/lib -lzmq -lczmq
 ```

17_1_Setting_Up_Libwally.md

@@ -129,7 +129,7 @@ In both cases, the argument is for flags, but is currently set to `0`.
 
 ## Test a Test Libwally Program
 
-The src directory contains [testwally.c](src/16_1_testwally.c), which just shows how the initialize and cleanup functions work.
+The src directory contains [testwally.c](src/17_1_testwally.c), which just shows how the initialize and cleanup functions work.
 
 You can compile it as follows:
 ```

17_2_Using_BIP39_in_Libwally.md

@@ -14,7 +14,7 @@ All Bitcoin keys start with entropy. This first use of Libwally, and its BIP39 m
 
 > :book: ***What is Entropy?*** Entropy is a fancy way of saying randomness, but it's a carefully measured randomness that's used as the foundation of a true-random-number generated (TRG). Its measured in "bits", with more bits of entropy resulting in more randomness (and thus more protection for what's being generated). For Bitcoin, entropy is the foundation of your seed, which in an HD wallet generates all of your addresses.
 
-You'll always start work with Libwally by initializing the library and testing the results, as first demonstrated in [§16.1](16_1_Setting_Up_Libwally.md):
+You'll always start work with Libwally by initializing the library and testing the results, as first demonstrated in [§17.1](17_1_Setting_Up_Libwally.md):
 ```
   int lw_response;
 
@@ -82,7 +82,7 @@ If you've done everything right, you should get back a 64-byte seed. (That's the
 
 ## Test Mnemonic Code
 
-The full code for generating entropy, generating a BIP39 mnemonic, validating the mnemonic, and generating a seed can be found in the [src directory](src/16_2_genmnemonic.c). Download it and compile:
+The full code for generating entropy, generating a BIP39 mnemonic, validating the mnemonic, and generating a seed can be found in the [src directory](src/17_2_genmnemonic.c). Download it and compile:
 ```
 $ cc genmnemonic.c -lwallycore -lsodium -o genmnemonic
 ```
@@ -99,7 +99,7 @@ BIP39 allows you generate a set of 12-24 Mnemonic words from a seed (and the Lib
 
 > :fire: ***What is the power of BIP39?*** Bitcoin seeds and private keys are prone to all sorts of lossage. You mistype a single digit, and your money is gone forever. Mnemonic Words are a much more user-friendly way of representing the same data, but because they're words in the language of the user's choice, they're less prone to mistakes. The power of BIP39 is thus to improve the accessibility, usability, and safety of Bitcoin.
 
-> :fire: ***What is the power of BIP39 in Libwally?*** Bitcoind doesn't currently support mnemonic words, so using Libwally can allow you to generate mnemonic words in conjunction with addresses held by `bitcoind` (though as we'll see in §16.7, it requires a bit of a work-around at present to import your keys into Bitcoin Core).
+> :fire: ***What is the power of BIP39 in Libwally?*** Bitcoind doesn't currently support mnemonic words, so using Libwally can allow you to generate mnemonic words in conjunction with addresses held by `bitcoind` (though as we'll see in §17.7, it requires a bit of a work-around at present to import your keys into Bitcoin Core).
 
 ## What's Next?
 

17_3_Using_BIP32_in_Libwally.md

@@ -115,7 +115,7 @@ There is also a `wally_bip32_key_to_address` function, which can be used to gene
 
 ## Test HD Code
 
-The code for these HD example can, as usual, be found in the [src directory](src/16_3_genhd.c).
+The code for these HD example can, as usual, be found in the [src directory](src/17_3_genhd.c).
 
 You can compile and test it:
 ```

17_4_Using_PSBTs_in_Libwally.md

@@ -116,7 +116,7 @@ Obviously, there's a lot more you could look at in the PSBTs. In fact, looking i
 
 ### Test Your PSBT Reader
 
-Again, the code for this (extremely rudimentary and specific) PSBT reader is in the [src directory](src/16_4_examinepsbt.c). 
+Again, the code for this (extremely rudimentary and specific) PSBT reader is in the [src directory](src/17_4_examinepsbt.c). 
 
 You can compile it as normal:
 ```
@@ -289,7 +289,7 @@ But what you have is not yet a legal PSBT, because of the lack of inputs. You ca
 ```
 ### Test Your PSBT Creation
 
-At this point, you should have an empty, but working PSBT, which you can see by compiling and running [the program](src/16_4_createemptypsbt.c).
+At this point, you should have an empty, but working PSBT, which you can see by compiling and running [the program](src/17_4_createemptypsbt.c).
 ```
 $ cc createemptypsbt.c -lwallycore -o createemptypsbt
 $ ./createemptypsbt 

17_5_Using_Scripts_in_Libwally.md

@@ -98,7 +98,7 @@ As you might expect, you then add that input to your transaction:
   lw_response = wally_tx_add_input(tx,tx_input);
 ```
 
-> **NOTE** Obviously, you'll want to be able to create your own inputs if you're using Libwally for real applications, but this is intended as a first step. And, it can actually be useful for integrating with `bitcoin-cli`, as we'll see in [§16.7](16_7_Integrating_Libwally_and_Bitcoin-CLI.md).
+> **NOTE** Obviously, you'll want to be able to create your own inputs if you're using Libwally for real applications, but this is intended as a first step. And, it can actually be useful for integrating with `bitcoin-cli`, as we'll see in [§16.7](17_7_Integrating_Libwally_and_Bitcoin-CLI.md).
 
 ### Print a Transaction
 
@@ -113,7 +113,7 @@ We'll show how to make use of that in §16.7.
 
 ## Test Your Replacement Script
 
-You can grab the test code from the [src directory](src/16_5_replacewithscript.c) and compile it:
+You can grab the test code from the [src directory](src/17_5_replacewithscript.c) and compile it:
 ```
 $  cc replacewithscript.c -lwallycore -o replacewithscript
 ```

17_6_Using_Other_Functions_in_Libwally.md

@@ -45,7 +45,7 @@ Some relate to the wallet import format (WIF):
    
 ## Use BIP32 Functions
 
-There are additional BIP32 HD-wallet functions, beyond what was covered in [§16.3: Using BIP32 in Libwally](16_3_Using_BIP32_in_Libwally.md).
+There are additional BIP32 HD-wallet functions, beyond what was covered in [§17.3: Using BIP32 in Libwally](17_3_Using_BIP32_in_Libwally.md).
 
    * `bip32_key_get_fingerprint` — Generate a BIP32 fingerprint for an extended key
    * `bip32_key_serialize` — Transform an extended key into serialized bytes
@@ -65,7 +65,7 @@ The main functions are:
    
 ## Use BIP39 Functions
 
-A few BIP39 mnemonic-word functions were just overviewed in [§16.2: Using BIP39 in Libwally](16_2_Using_BIP39_in_Libwally.md):
+A few BIP39 mnemonic-word functions were just overviewed in [§17.2: Using BIP39 in Libwally](17_2_Using_BIP39_in_Libwally.md):
 
    * `bip39_get_languages` — See a list of supported languages
    * `bit39_get_word` — Retrieve a specific word from a language's word list
@@ -73,11 +73,11 @@ A few BIP39 mnemonic-word functions were just overviewed in [§16.2: Using BIP39
    
 ## Use PSBT Functions
 
-Listings of most PSBT functions can be found in [16.4: Using PSBTs in Libwally](16_4_Using_PSBTs_in_Libwally.md).
+Listings of most PSBT functions can be found in [17.4: Using PSBTs in Libwally](17_4_Using_PSBTs_in_Libwally.md).
 
 ## Use Script Functions
 
-[§16.5: Using Scripts in Libwally](16_5_Using_Scripts_in_Libwally.md) just barely touched upon Libwally's Scripts functions.
+[§17.5: Using Scripts in Libwally](17_5_Using_Scripts_in_Libwally.md) just barely touched upon Libwally's Scripts functions.
 
 There's another function that lets you determine the sort of script found in a transaction:
 
@@ -102,7 +102,7 @@ Then there are a slew of functions that create `scriptPubKey` from bytes, `scrip
 
 ## Use Transaction Functions
 
-We also just barely touched upon the functions that can be used to create and convert functions in [§16.5](16_5_Using_Scripts_in_Libwally.md).
+We also just barely touched upon the functions that can be used to create and convert functions in [§17.5](17_5_Using_Scripts_in_Libwally.md).
 
 There are numerous informational functions, some of the more interesting of which are:
 

17_7_Integrating_Libwally_and_Bitcoin-CLI.md

@@ -8,7 +8,7 @@ This final section will offer some examples of using Libwally programs to comple
 
 ## Share a Transaction
 
-[§16.5: Using Scripts in Libwally](16_5_Using_Scripts_in_Libwally.md) detailed how Libwally could be used to rewrite an existing transaction, to do something that `bitcoin-cli` can't: produce a transaction that contains a unique P2SH. Obviously, this is a building block; if you decide to dig further into Libwally you'll create entire transactions on your own. But, this abbreviated methodology also has its own usage: it shows how transactions can be passed back and forth between `bitcoin-cli` and Libwally, demonstrating a first example of using them in a complementary fashion.
+[§17.5: Using Scripts in Libwally](17_5_Using_Scripts_in_Libwally.md) detailed how Libwally could be used to rewrite an existing transaction, to do something that `bitcoin-cli` can't: produce a transaction that contains a unique P2SH. Obviously, this is a building block; if you decide to dig further into Libwally you'll create entire transactions on your own. But, this abbreviated methodology also has its own usage: it shows how transactions can be passed back and forth between `bitcoin-cli` and Libwally, demonstrating a first example of using them in a complementary fashion.
 
 To fully demonstrate this methodology, you'll create a transaction with `bitcoin-cli`, using this UTXO:
 ```
@@ -33,7 +33,7 @@ $ utxo_vout=$(bitcoin-cli listunspent | jq -r '.[0] | .vout')
 $ recipient=tb1qycsmq3jas5wkhf8xrfn8k7438cm5pc8h9ae2k0
 $ rawtxhex=$(bitcoin-cli -named createrawtransaction inputs='''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout' } ]''' outputs='''{ "'$recipient'": 0.0009 }''')
 ```
-Though you placed a recipient and an amount in the output, it's irrelevent, because you'll be rewriting those. A fancier bit of code could read the existing `vout` info before rewriting, but we're keeping things very close to our [original code](src/16_5_replacewithscript.c).
+Though you placed a recipient and an amount in the output, it's irrelevent, because you'll be rewriting those. A fancier bit of code could read the existing `vout` info before rewriting, but we're keeping things very close to our [original code](src/17_5_replacewithscript.c).
 
 Here's the one change necessary, to allow you to specify the satoshi `vout`, without having to hardcode it, as in the original:
 ```
@@ -170,7 +170,7 @@ $ bitcoin-cli decoderawtransaction $signedtx
 ```
 Voila! That's the power of Libwally with `bitcoin-cli`.
 
-Obviously, you can also pass around a PSBT using the functions described in [§16.4](16_4_Using_PSBTs_in_Libwally.md) and that's a more up-to-date methodology for the modern-day usage of Bitcoin, but in either example, the concept of passing transactions from `bitcoin-cli` to Libwally code and back should be similar.
+Obviously, you can also pass around a PSBT using the functions described in [§17.4](17_4_Using_PSBTs_in_Libwally.md) and that's a more up-to-date methodology for the modern-day usage of Bitcoin, but in either example, the concept of passing transactions from `bitcoin-cli` to Libwally code and back should be similar.
 
 ## Import & Export BIP39 Seeds
 
@@ -182,7 +182,7 @@ Unfortunately, not all interactions between Libwally and `bitcoin-cli` go as smo
 
 ## Import Private Keys
 
-Fortunately, you can do much the same thing by importing a private key generated in Libwally. Take a look at [genhd-for-import.c](src/16_7_genhd_for_import.c), a simplified version of the `genhd` program from [§16.3](16_3_Using_BIP32_in_Libwally.md) that also uses the `jansson` library from [§15.1](15_1_Accessing_Bitcoind_with_C.md) for regularized output.
+Fortunately, you can do much the same thing by importing a private key generated in Libwally. Take a look at [genhd-for-import.c](src/17_7_genhd_for_import.c), a simplified version of the `genhd` program from [§17.3](17_3_Using_BIP32_in_Libwally.md) that also uses the `jansson` library from [§16.1](15_1_Accessing_Bitcoind_with_C.md) for regularized output.
 
 The updated code also contains one change of note: it requests a fingerprint from Libwally so that it can properly create a derivation path:
 ```
@@ -195,7 +195,7 @@ The updated code also contains one change of note: it requests a fingerprint fro
 
 > :warning: **WARNING:** Remember that the fingerprint in derivation paths is arbitrary. Because Libwally provides one, we're using it, but if you didn't have one, you could add an arbitrary 4-byte hexcode as a fingerprint to your derivation path.
 
-Be sure to compile the new code with the `jansson` library, after installing it (if necessary) per [§15.1](15_1_Accessing_Bitcoind_with_C.md).
+Be sure to compile the new code with the `jansson` library, after installing it (if necessary) per [§16.1](15_1_Accessing_Bitcoind_with_C.md).
 ```
 $ cc genhd-for-import.c -lwallycore -lsodium -ljansson -o genhd-for-import
 ```

18_1_Accessing_Bitcoind_with_Go.md

@@ -160,7 +160,7 @@ However, a quirk with hashes in `rpcclient` is that they will typically print in
 
 ### Run Your Code
 
-You can download the complete code from the [src directory](src/17_1_blockinfo.go).
+You can download the complete code from the [src directory](src/18_1_blockinfo.go).
 
 You can then run:
 ```
@@ -185,7 +185,7 @@ Due to limitations of the `btcd` `rpcclient`, you can't make a use of the ```get
 ```
 ```client.GetBalance("*")``` requires the ```"*"``` input, due to a quirk with `btcd`. The asterisk signifies that you want to get the balance of all of your wallets.
 
-If you run [the src code](src/17_1_getbalance.go), you should get an output similar to this:
+If you run [the src code](src/18_1_getbalance.go), you should get an output similar to this:
 ```
 $ go run getbalance.go 
 0.000689 BTC
@@ -279,7 +279,7 @@ Only afterward do you use the `getreceivedbyaddress` RPC, on your decoded addres
 
 	fmt.Println(wallet)
 ```
-When you run [the code](src/17_1_getamountreceived.go), you should get output similar to:
+When you run [the code](src/18_1_getamountreceived.go), you should get output similar to:
 ```
 $ go run getamountreceived.go 
 0.0085 BTC
@@ -331,7 +331,7 @@ func main() {
 	fmt.Println(sent)
 }
 ```
-When you run [the code](src/17_1_sendtransaction.go), the txid of the transaction is outputted: 
+When you run [the code](src/18_1_sendtransaction.go), the txid of the transaction is outputted: 
 
 ```
 $ go run sendtransaction.go

18_2_Accessing_Bitcoind_with_Java.md

@@ -154,7 +154,7 @@ PubKey: 0368d0fffa651783524f8b934d24d03b32bf8ff2c0808943a556b3d74b2e5c7d65
 
 ### Run Your Code
 
-The code for these examples can be found in [the src directory](src/17_2_App-getinfo.java) and should be installed into the standard directory structure created here as `~/java-project/src/main/java/com/blockchaincommons/lbtc/App.java`. It can then be compiled and run.
+The code for these examples can be found in [the src directory](src/18_2_App-getinfo.java) and should be installed into the standard directory structure created here as `~/java-project/src/main/java/com/blockchaincommons/lbtc/App.java`. It can then be compiled and run.
 
 ```
 $ mvn compile
@@ -278,7 +278,7 @@ System.out.println("Sent signedRawTx (txID): " + sentRawTransactionID);
 
 ### Run Your Code
 
-You can now run [the transaction code](src/17_2_App-sendtx.java) as `~/java-project/src/main/java/com/blockchaincommons/lbtc/App.java`.
+You can now run [the transaction code](src/18_2_App-sendtx.java) as `~/java-project/src/main/java/com/blockchaincommons/lbtc/App.java`.
 
 ```
 $ mvn compile
@@ -317,7 +317,7 @@ To do this, use `JavaBitcoindRpcClient`'s `BitcoinAcceptor` class, which allows
   acceptor.run();
 ```
 
-See [the src directory](src/17_2_App-listen.java) for the complete code. Every time a transaction is sent or a new block is generated, you should see output on your console:
+See [the src directory](src/18_2_App-listen.java) for the complete code. Every time a transaction is sent or a new block is generated, you should see output on your console:
 ```
 Transaction: {account=Tests, address=mhopuJzgmTwhGfpNLCJ9CRknugY691oXp1, category=receive, amount=5.0E-4, label=Tests, vout=1, confirmations=0, trusted=false, txid=361e8fcff243b74ebf396e595a007636654f67c3c7b55fd2860a3d37772155eb, walletconflicts=[], time=1513132887, timereceived=1513132887, bip125-replaceable=unknown}
 

18_3_Accessing_Bitcoind_with_NodeJS.md

@@ -34,7 +34,7 @@ $ export BITCOIND_PASS=d8340efbcd34e312044c8431c59c792c
 $ export BITCOIND_PORT=18332
 ```
 
-> :warning: **WARNING:** Obviously, you'd never put set your password in an environmental variable in a production environment.
+> :warning: **WARNING:** Obviously, you'd never put your password in an environmental variable in a production environment.
 
 > :link: **MAINNET VS TESTNET:** The port would be 8332 for a mainnet setup.
 
@@ -111,7 +111,7 @@ The result of the BCRPC functions is a JSON object containing information about
 
 ### Run Your Code
 
-You can find the `getinfo` code in [the src directory](src/17_3_getinfo.js).
+You can find the `getinfo` code in [the src directory](src/18_3_getinfo.js).
 ```
 $ node getinfo.js
 1831094
@@ -163,7 +163,7 @@ agent.getWalletInfo(function (err, walletInfo) {
 });
 ```
 
-The source is available as [walletinfo.js](src/17_3_walletinfo.js).
+The source is available as [walletinfo.js](src/18_3_walletinfo.js).
 ```
 $ node walletinfo.js
 0.008498
@@ -261,7 +261,7 @@ You should get an output similar to this:
 }
 ```
 
-The full code is available as [sendtx.js](src/17_3_sendtx.js).
+The full code is available as [sendtx.js](src/18_3_sendtx.js).
 
 ## Summary: Accessing Bitcoind with Node
 

18_4_Accessing_Bitcoind_with_Python.md

@@ -125,7 +125,7 @@ print("---------------------------------------------------------------\n")
 
 ### Run Your Code
 
-You can retrieve [the src code](src/17_4_getinfo.py) and run it with `python3`:
+You can retrieve [the src code](src/18_4_getinfo.py) and run it with `python3`:
 ```
 $ python3 getinfo.py
 ---------------------------------------------------------------
@@ -239,7 +239,7 @@ pprint(utxo_tx_details)
 print("---------------------------------------------------------------\n")
 ```
 
-This code is available at [walletinfo.py](src/17_4_walletinfo.py).
+This code is available at [walletinfo.py](src/18_4_walletinfo.py).
 
 ```
 $ python3 walletinfo.py 
@@ -418,7 +418,7 @@ send_tx = rpc_client.sendrawtransaction(signed_tx['hex'])
 ```
 ### Run Your Code
 
-The [sample code](src/17_4_sendtx.py) is full of `print` statements to demonstrate all of the data available at every point:
+The [sample code](src/18_4_sendtx.py) is full of `print` statements to demonstrate all of the data available at every point:
 ```
 $ python3 sendtx.py 
 Creating a Transaction

18_5_Accessing_Bitcoind_with_Rust.md

@@ -135,7 +135,7 @@ Here's the complete code to retrieve a block hash, turn that into a block, and p
 
 ### Run Your Code
 
-You can access the [src code](src/17_5_main-getinfo.rs) and run it. Unfortunately, the "Block" info will come out a bit ugly because this example doesn't include a library to prettify it.
+You can access the [src code](src/18_5_main-getinfo.rs) and run it. Unfortunately, the "Block" info will come out a bit ugly because this example doesn't include a library to prettify it.
 ```
 $ cargo run 
    Compiling btc_test v0.1.0 (/home/standup/btc_test)
@@ -289,7 +289,7 @@ println!("{:?}", txid_sent);
 
 ### Run Your Code
 
-You can now run the complete code from the [src](src/17_5_main-sendtx.rs).
+You can now run the complete code from the [src](src/18_5_main-sendtx.rs).
 
 ```
 $ cargo run

18_6_Accessing_Bitcoind_with_Swift.md

@@ -191,7 +191,7 @@ makeCommand(method: method,param: param) { result in
 
 ### Run Your Code
 
-The complete code is available in the [src directory](src/17_6_getinfo.playground). Load it into your Xcode playground and then "Editor -> Run Playground" and you should get results like:
+The complete code is available in the [src directory](src/18_6_getinfo.playground). Load it into your Xcode playground and then "Editor -> Run Playground" and you should get results like:
 ```
 {
     bestblockhash = 00000000000000069725608ebc5b59e520572a8088cbc57ffa5ba87b7f300ac7;
@@ -385,7 +385,7 @@ Sending your transaction is equally simple:
 }
 ```
 
-The code for this transaction sender can be found in the [src directory](src/17_6_sendtx.playground).
+The code for this transaction sender can be found in the [src directory](src/18_6_sendtx.playground).
 
 ## Use Swift in Other Ways