Merge pull request #626 from muaawiyahtucker/AbuShafrah-review

AbuShafrah-review

Author: shannona

08_1_Sending_a_Transaction_with_a_Locktime.md

@@ -42,7 +42,7 @@ Once you've figured out the current height, you can decide how far in the future
 
 Once you have figured out your locktime, all you need to do is write up a typical raw transaction, with a third variable for `locktime`:
 ```
-$ rawtxhex=$(bitcoin-cli -named createrawtransaction inputs='''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout' } ]''' outputs='''{ "'$recipient'": 0.001, "'$changeaddress'": 0.00095 }''' locktime=1774650)
+$ rawtxhex=$(bitcoin-cli -named createrawtransaction inputs='''[ { "txid": "'$utxo_txid'", "vout": '$utxo_vout' } ]''' outputs='''[{ "'$recipient'": 0.001, "'$changeaddress'": 0.00095 }]''' locktime=1774650)
 ```
 Note that this usage of `locktime` is under 500 million, which means that it defines a block height. In this case, it's just a few blocks past the current block height at the time of this writing, meant to exemplify how locktime works without sitting around for a long time to wait and see what happens.
 

11_3_Using_CSV_in_Scripts.md

@@ -12,19 +12,19 @@ A relative timelock is a lock that's placed on a specific input of a transaction
 
 Easy!
 
-> :information_source: **NOTE — SEQUENCE:** This is the third use of the `nSequence` value in Bitcoin. Any `nSequence` value without the 32nd bit set (1<<31), so 0x00000001 to 0x7ffffffff, will be interpreted as a relative timelock if `nVersion ≥ 2` (which is the default starting in Bitcoin Core 0.14.0). You should be careful to ensure that relative timelocks don't conflict with the other two uses of `nSequence`, for signalling `nTimeLock` and RBF. `nTimeLock` usually sets a value of 0xffffffff-1, where a relative timelock is disallowed; and RBF usually sets a value of "1", where a relative timelock is irrelevent, because it defines a timelock of 1 block. 
+> :information_source: **NOTE — SEQUENCE:** This is the third use of the `nSequence` value in Bitcoin. Any `nSequence` value without the 32nd bit set (1<<31), so 0x00 00 00 01 to 0x7f ff ff ff, will be interpreted as a relative timelock if `nVersion ≥ 2` (which is the default starting in Bitcoin Core 0.14.0). You should be careful to ensure that relative timelocks don't conflict with the other two uses of `nSequence`, for signalling `nLockTime` and RBF. `nLockTime` usually sets a value of 0xff ff ff ff-1, where a relative timelock is disallowed; and RBF usually sets a value of "1", where a relative timelock is irrelevent, because it defines a timelock of 1 block. 
 
 > In general, remember: with a `nVersion` value of 2, a `nSequence` value of 0x00000001 to 0x7ffffff allows relative timelock, RBF, and `nTimeLock`; a `nSequence` value of 0x7fffffff to 0xffffffff-2 allows RBF and `nTimeLock`; a `nSequence` value of 0xffffffff-1 allows only `nTimeLock`; a `nSequence` value of 0xffffffff allows none; and `nVersion` can be set to 1 to disallow relative timelocks for any value of `nSequence`. Whew!
 
 ### Create a CSV Relative Block Time
 
-The format for using `nSequence` to represent relative time locks is defined in [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) and is slightly more complex than just inputting a number, like you did for `nTimeLock`. Instead, the BIP specifications breaks up the four byte number into three parts:
+The format for using `nSequence` to represent relative time locks is defined in [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) and is slightly more complex than just inputting a number, like you did for `nLockTime`. Instead, the BIP specifications breaks up the four byte number into three parts:
 
 * The first two bytes are used to specify a relative locktime.
 * The 23rd bit is used to positively signal if the lock refers to a time rather than a blockheight.
 * The 32nd bit is used to positively signal if relative timelocks are deactivated.
 
-With that said, the construction of a block-based relative timelock is still quite easy, because the two flagged bits are set to `0`, so you just set `nSequence` to a value between 1 and 0xffff (65535). The new transaction can be mined that number of blocks after the associated UTXO was mined.
+With that said, the construction of a block-based relative timelock is still quite easy, because the two flagged bits are set to `0`, so you just set `nSequence` to a value between 1 and 0xff ff (65535). The new transaction can be mined that number of blocks after the associated UTXO was mined.
 
 ### Create a CSV Relative Time
 
@@ -51,6 +51,8 @@ Finally, bitwise-or the 23rd bit into the hex value you created:
 ```
 $ relativevalue=$(printf '%x\n' $((0x$hexvalue | 0x400000)))
 $ echo $relativevalue
+4076a7
+$ printf "%d\n" "0x$relativevalue"
 4224679
 ```
 If you convert that back you'll see that 4224679 = 10000000111011010100111. The 23rd digit is set to a "1"; meanwhile the first 2 bytes, 0111011010100111, convert to 76A7 in hex or 30375 in decimal. Multiply that by 512 and you get 15.55 million seconds, which indeed is 180 days.
@@ -65,7 +67,7 @@ Except pretty much no one does this. The [BIP 68](https://github.com/bitcoin/bip
 
 |                      | Absolute Timelock | Relative Timelock |
 |:--------------------:|-------------------|-------------------|
-| **Lock Transaction** | nTimeLock         | nSequence         |
+| **Lock Transaction** | nLockTime         | nSequence         |
 | **Lock Output**      | OP_CHECKLOCKTIMEVERIFY| OP_CHECKSEQUENCEVERIFY |
 
 ## Understand the CSV Opcode
@@ -93,7 +95,7 @@ CSV has many of the same subtleties in usage as CLTV:
 
 * The `nVersion` field must be set to 2 or more.
 * The `nSequence` field must be set to less than 0x80000000.
-* When CSV is run, there must be an operand on the stack that's between 0 and 0xf0000000-1.
+* When CSV is run, there must be an operand on the stack that's between 0 and 0xf0 00 00 00-1.
 * Both the stack operand and `nSequence` must have the same value on the 23rd bit.
 * The `nSequence` must be greater than or equal to the stack operand.
 

12_1_Using_Script_Conditionals.md

@@ -89,7 +89,7 @@ ELSE
 ENDIF
 
 ```
-Remember your reverse Polish notation! That `IF` statement if referring to the `OP_EQUAL` before it, not the `OP_CHECKSIG` after it!
+Remember your reverse Polish notation! That `IF` statement is referring to the `OP_EQUAL` before it, not the `OP_CHECKSIG` after it!
 
 #### Run the True Branch
 
@@ -136,7 +136,7 @@ Stack: [ True ]
 ```
 #### Run the False Branch
 
-Here's how it actally runs if unlocked with `<signatureB> <pubKeyB>`:
+Here's how it actually runs if unlocked with `<signatureB> <pubKeyB>`:
 ```
 Script: <signatureB> <pubKeyB> OP_DUP OP_HASH160 <pubKeyHashA> OP_EQUAL IF OP_CHECKSIG ELSE OP_DUP OP_HASH160 <pubKeyHashB> OP_EQUALVERIFY OP_CHECKSIG ENDIF
 Stack: [ ]

12_2_Using_Other_Script_Commands.md

@@ -78,7 +78,7 @@ Also see: `OP_CODESEPARATOR` (0xab), `OP_CHECKSIGVERIFY` (0xad), and `OP_CHECKMU
 
 ## Summary: Using Other Script Commands
 
-Bitcoin Script includes a wide array of arithemetic, stack, and cryptographic opcodes. Most of these additional opcodes are probably not as common as the ones discussed in previous sections, but nonetheless they're available if they're just what you need to write your Script!
+Bitcoin Script includes a wide array of arithmetic, stack, and cryptographic opcodes. Most of these additional opcodes are probably not as common as the ones discussed in previous sections, but nonetheless they're available if they're just what you need to write your Script!
 
 ## What's Next?
 

13_0_Designing_Real_Bitcoin_Scripts.md

@@ -1,6 +1,6 @@
 # Chapter 13: Designing Real Bitcoin Scripts
 
-Our Bitcoin Scripts to date have been largely theoretical examples, because we've still been putting together the puzzle pieces. Now, with the full Bitcoin Script repetoire in hand, we're ready to dig into several real-world Bitcoin Scripts and see how they work.
+Our Bitcoin Scripts to date have been largely theoretical examples, because we've still been putting together the puzzle pieces. Now, with the full Bitcoin Script repertoire in hand, we're ready to dig into several real-world Bitcoin Scripts and see how they work.
 
 ## Objectives for This Chapter
 

14_2_Changing_Your_Bitcoin_Hidden_Services.md

@@ -63,7 +63,7 @@ See [Bitcoin Onion Nodes](https://github.com/emmanuelrosa/bitcoin-onion-nodes) f
 
 Afterward, restart `tor` and `bitcoind`.
 
-You should now be communicating exlusively on Tor. But, unless you are in a hostile state, this level of anonymity is probably not required. It also is not particularly recommended: you might greatly decrease your number of potential peers, inviting problems of censorship or even correlation. You may also see lag. And, this setup may give you a false sense of anonymity that really doesn't exist on the Bitcoin network.
+You should now be communicating exclusively on Tor. But, unless you are in a hostile state, this level of anonymity is probably not required. It also is not particularly recommended: you might greatly decrease your number of potential peers, inviting problems of censorship or even correlation. You may also see lag. And, this setup may give you a false sense of anonymity that really doesn't exist on the Bitcoin network.
 
 > :warning: **WARNING:** This setup is untested! Use at your own risk!
 

17_4_Using_PSBTs_in_Libwally.md

@@ -279,7 +279,7 @@ The creator role is tasked with creating a PSBT with at least one input.
 A PSBT is created with a simple use of `wally_psbt_init_alloc`, telling it how many inputs and outputs you will eventually add:
 ```
   struct wally_psbt *psbt;
-  lw_response = wally_psbt_init_alloc(0,1,1,0,&psbt);
+  lw_response = wally_psbt_init_alloc(0,1,1,0,0,&psbt);
 ```
 But what you have is not yet a legal PSBT, because of the lack of inputs. You can create those by creating a transaction and setting it as the global transaction in the PSBT, which updates all the inputs and outputs:
 ```

17_5_Using_Scripts_in_Libwally.md

@@ -41,7 +41,7 @@ a9 / 14 / 3f58b4f7b14847a9083694b9b3b52a4cea2569ed / 87
 ```
 That's our old friend `OP_HASH160 3f58b4f7b14847a9083694b9b3b52a4cea2569ed OP_EQUAL`.
 
-Basically, Libwally took your serialized redeem script, hashed it for you with SHA-256 and RIPEMD-160, and the applied the standard framing to turn it into a proper P2SH; You did similar work in [§10.2](10_2_Building_the_Structure_of_P2SH.md), but with an excess of shell commands.
+Basically, Libwally took your serialized redeem script, hashed it for you with SHA-256 and RIPEMD-160, and then applied the standard framing to turn it into a proper P2SH; You did similar work in [§10.2](10_2_Building_the_Structure_of_P2SH.md), but with an excess of shell commands.
 
 In fact, you can double-check your work using the same commands from §10.2:
 ```

17_7_Integrating_Libwally_and_Bitcoin-CLI.md

@@ -316,7 +316,6 @@ $ bitcoin-cli getaddressesbylabel "LibwallyWO"
     "purpose": "receive"
   }
 }
-}
 ```
 
 ## Summary: Integrating Libwally and Bitcoin-CLI

18_1_Accessing_Bitcoind_with_Go.md

@@ -242,7 +242,7 @@ tb1qutkcj34pw0aq7n9wgp3ktmz780szlycwddfmza
 
 ### Decode an Address
 
-Creating an address took a look extra work, in specifying the appropiate chain. Using an address also will because you'll have to decode it prior to use. 
+Creating an address took a little extra work, in specifying the appropriate chain. Using an address also will because you'll have to decode it prior to use. 
 
 The means that you'll have to import both the ```"github.com/btcsuite/btcutil"``` and ```"github.com/btcsuite/btcd/chaincfg"``` libraries.
    * ```btcutil``` allows for a Bitcoin address to be decoded in a way that the`rpcclient` can understand. This is necessary when working with addresses in `rpcclient`.