diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml new file mode 100644 index 0000000..7980326 --- /dev/null +++ b/.github/FUNDING.yml @@ -0,0 +1,4 @@ +# These are supported funding model platforms + +github: ChristopherA +custom: https://btcpay.blockchaincommons.com diff --git a/02_1_Setting_Up_a_Bitcoin-Core_VPS_by_Hand.md b/02_1_Setting_Up_a_Bitcoin-Core_VPS_by_Hand.md index 2184ca9..6930d64 100644 --- a/02_1_Setting_Up_a_Bitcoin-Core_VPS_by_Hand.md +++ b/02_1_Setting_Up_a_Bitcoin-Core_VPS_by_Hand.md @@ -2,7 +2,7 @@ > **NOTE:** This is a draft in progress, so that I can get some feedback from early reviewers. It is not yet ready for learning. -This document explains how to set up a VPS (Virtual Private Sever) by hand to run a Bitcoin node on a cloud computer. You'll need to set up your computer yourself, but then this document will provide you with important commands to secure your VPS and to get it running Bitcoin. The setup should all be done in my session, so you don't lose the variables `export`ed at the start. +This document explains how to set up a VPS (Virtual Private Server) by hand to run a Bitcoin node on a cloud computer. You'll need to set up your computer yourself, but then this document will provide you with important commands to secure your VPS and to get it running Bitcoin. The setup should all be done in my session, so you don't lose the variables `export`ed at the start. > **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. I’ve also found it useful to be able to use an iPhone or iPad to communicate via SSH to my VPS to do some simple bitcoin tasks. But a higher level of safety is required for significant funds. @@ -260,7 +260,8 @@ alias btcdir="cd ~/.bitcoin/" #linux default bitcoind path alias bc="bitcoin-cli" alias bd="bitcoind" alias btcinfo='bitcoin-cli getwalletinfo | egrep "\"balance\""; bitcoin-cli getinfo | egrep "\"version\"|connections"; bitcoin-cli getmininginfo | egrep "\"blocks\"|errors"' -alias btcblock="echo \\\`bitcoin-cli getblockcount 2>&1\\\`/\\\`wget -O - http://blockexplorer.com/testnet/q/getblockcount 2> /dev/null | cut -d : -f2 | rev | cut -c 2- | rev\\\`" +# next alias not working; blockexplorer.com is not redirecting properly +# alias btcblock="echo \\\`bitcoin-cli getblockcount 2>&1\\\`/\\\`wget -O - http://blockexplorer.com/testnet/q/getblockcount 2> /dev/null | cut -d : -f2 | rev | cut -c 2- | rev\\\`" EOF ``` diff --git a/02_2_Setting_Up_a_Bitcoin-Core_VPS_with_StackScript.md b/02_2_Setting_Up_a_Bitcoin-Core_VPS_with_StackScript.md index 0634b77..f86214e 100644 --- a/02_2_Setting_Up_a_Bitcoin-Core_VPS_with_StackScript.md +++ b/02_2_Setting_Up_a_Bitcoin-Core_VPS_with_StackScript.md @@ -46,7 +46,7 @@ There's a copy of our Bitcoin VPS Setup StackScript in [the repo here](02_2__Scr You'll next need to click to your Linodes tab and select "Add a Linode". -A Linode 2048 will suffice for most setups, including: Pruned Mainnet, Pruned Testnet, and even non-Pruned Testnet. They all use less than 30G of storage and they can barely get by with 2G of memory. This is the setup we suggest. +A Linode 2G will suffice for most setups, including: Pruned Mainnet, Pruned Testnet, and even non-Pruned Testnet. They all use less than 50G of storage and they can barely get by with 2G of memory. This is the setup we suggest. 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 120G, which is currently the Linode 12288, which has 192G of storage and 12G of memory and costs approximately $80 per month. We do _not_ suggest this. diff --git a/03_1_Verifying_Your_Bitcoin_Setup.md b/03_1_Verifying_Your_Bitcoin_Setup.md index c603352..3f62bed 100644 --- a/03_1_Verifying_Your_Bitcoin_Setup.md +++ b/03_1_Verifying_Your_Bitcoin_Setup.md @@ -85,11 +85,11 @@ alias bc="bitcoin-cli" alias bt="bitcoin-cli -testnet" alias br="bitcoin-cli -regtest" ``` -For even more complexity, you could have each of your 'start' aliases use the -conf flag to load configuration from a different file. This goes far beyond the scope of this tutorial, but we offer it as a starting point for when your explorations of Bitcoin reach the next level. +For even more complexity, you could have each of your 'start' aliases use the -conf flag to load configuration from a different file. This goes far beyond the scope of this tutorial, but we offer it as a starting point for when your explorations of Bitcoin reaches the next level. ## Summary: Verifying Your Bitcoin Setup -Before you start playing with bitcoin, you should make sure that your aliases are setup, your bitcoind is running, and your blocks are downloaded. You may also want to set up some access to alternative Bitcoin setups, if you're an advanced user. +Before you start playing with bitcoin, you should make sure that your aliases are set up, your bitcoind is running, and your blocks are downloaded. You may also want to set up some access to alternative Bitcoin setups, if you're an advanced user. ## What's Next? diff --git a/03_3_Setting_Up_Your_Wallet.md b/03_3_Setting_Up_Your_Wallet.md index 7217b3f..42abb4f 100644 --- a/03_3_Setting_Up_Your_Wallet.md +++ b/03_3_Setting_Up_Your_Wallet.md @@ -66,7 +66,6 @@ $ bitcoin-cli importwallet backup.dat Sometimes, you might want to actually look at the private keys associated with your Bitcoin addresses. Perhaps you want to be able to sign a message or spend bitcoins from a different machine. Perhaps you just want to back up certain important private keys. -To look at _all_ the keys in your wallet, type `bitcoin-cli ~/dumpwallet mywallet.txt`. To look at _all_ the keys in your wallet, type `bitcoin-cli dumpwallet ~/mywallet.txt`. ``` $ bitcoin-cli dumpwallet ~/mywallet.txt diff --git a/03_4_Receiving_a_Transaction.md b/03_4_Receiving_a_Transaction.md index c362cc7..0354f75 100644 --- a/03_4_Receiving_a_Transaction.md +++ b/03_4_Receiving_a_Transaction.md @@ -6,7 +6,7 @@ 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 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.manu.backend.hamburg/faucet. If it's not available for some reason, search for "bitcoin testnet faucet", and you should find others. We suggest http://tpfaucet.appspot.com/ as an excellent alternative. Another testnet faucet is https://testnet.coinfaucet.eu/en/. +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.coinfaucet.eu/en/. If it's 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. diff --git a/04_1_Sending_Coins_The_Easy_Way.md b/04_1_Sending_Coins_The_Easy_Way.md index 9bd0508..43c7aae 100644 --- a/04_1_Sending_Coins_The_Easy_Way.md +++ b/04_1_Sending_Coins_The_Easy_Way.md @@ -76,7 +76,7 @@ $ bitcoin-cli gettransaction $txid "hex": "0200000001a8b61dba544525ad267644cb78f07c1ba58586ff9089aec3ac24d8764dc21dfb000000006a47304402204c38c2530d3283200e4fd3b2d22e609fc6dc941fd3ac4bc8b73ad5a86607e723022050056ae6cfc3233fb38459a6fd5e63d54e4c85e17b91d66fb915e3977a1c77dd0121027a313901f2ac34c87761513cabe69ca9ca61e2db3c7e6f89d7eccd7fc0a5917cfeffffff0280969800000000001976a914e7c1345fc8f87c68170b3aa798a956c2fe6a9eff88ac4082820b000000001976a914a091d978794d50e5caa3e5454cc8633240640d6688aca6de1000" } ``` -You can see not only the amount transferred (.1 BTC) but also a transaction fee (.000226 BTC), which is about a quarter of the .001 BC/kB minimum fee that was set, which suggests that the transaction was about a quarter of a kB in size. +You can see not only the amount transferred (.1 BTC) but also a transaction fee (.000226 BTC), which is about a quarter of the .001 BTC/kB minimum fee that was set, which suggests that the transaction was about a quarter of a kB in size. While you are waiting for this transaction to clear, you'll note that `bitcoin-cli getbalance` shows that all of your money is gone (or, at least, all of your money from a single incoming transaction). Similarly, `bitcoin-cli listunspent` would show an appropriately sized blob of incoming money was gone. There's a reason for this: whenever you get money in, you have to send it _all_ out together, and you have to perform some gymnastics if you actually want to keep some of it! Once again, `sendtoaddress` takes care of this all for you, which means you don't have to worry about it in full until you use a raw transaction to send out money. diff --git a/04_2_Creating_a_Raw_Transaction.md b/04_2_Creating_a_Raw_Transaction.md index 181f5c9..b3833dc 100644 --- a/04_2_Creating_a_Raw_Transaction.md +++ b/04_2_Creating_a_Raw_Transaction.md @@ -183,7 +183,7 @@ To date, your raw transaction is just something theoretical: you _could_ send it First, you need to sign your raw transaction: ``` -$ bitcoin-cli signrawtransaction $rawtxhex +$ bitcoin-cli signrawtransactionwithwallet $rawtxhex { "hex": "0100000001720e9d33eaf2b60e631c71bf59838f3a308ba4d1c394ba4e24f67162670598ee000000006b483045022100d8f17dadc2501596f75f2c90b8279130e588638d4f7a4f7d5ebb10fea15252f702200ceb164e81335c430893780d06cfe194c36acec26886f180408e3ac4a7d2292f0121035de6239e70523c8f392e32f98e65f6ef704c4b6b0df994e407212b839bf51048ffffffff01b04e7900000000001976a914e7c1345fc8f87c68170b3aa798a956c2fe6a9eff88ac00000000", "complete": true @@ -229,7 +229,7 @@ $ bitcoin-cli listunspent $ bitcoin-cli getbalance 0.15600000 ``` -However, `listtransactions` should soon show a confirmed transaction of category 'send". +Soon `listtransactions` should show a confirmed transaction of category 'send". ``` { "account": "", diff --git a/04_2__Interlude_Using_JQ.md b/04_2__Interlude_Using_JQ.md index 7d2a3db..1d91d3f 100644 --- a/04_2__Interlude_Using_JQ.md +++ b/04_2__Interlude_Using_JQ.md @@ -380,7 +380,7 @@ $ echo "$btcin-$btcout"| /usr/bin/bc ``` And that's also a good example of why you double-check your fees: we'd intended to send a transaction fee of 5,000 satoshis, but sent 255,000 satoshis instead. Whoops! -> **WARNING:** The first time we wrote up this lesson, we genuinely miscalculated our fee and didn't see it until we ran our fee calclator. It's *that* easy, then your money is gone. (The example above is actually from our second iteration of the calculator, and that time we made the mistake on purpose.) +> **WARNING:** The first time we wrote up this lesson, we genuinely miscalculated our fee and didn't see it until we ran our fee calculator. It's *that* easy, then your money is gone. (The example above is actually from our second iteration of the calculator, and that time we made the mistake on purpose.) For more JSON magic (and if any of this isn't clear), please read the [JSON Manual](https://stedolan.github.io/jq/manual/) and the [JSON Cookbook](https://github.com/stedolan/jq/wiki/Cookbook). We'll be regularly using JQ in future examples. diff --git a/04_3_Creating_a_Raw_Transaction_with_Named_Arguments.md b/04_3_Creating_a_Raw_Transaction_with_Named_Arguments.md index e40c837..ab04185 100644 --- a/04_3_Creating_a_Raw_Transaction_with_Named_Arguments.md +++ b/04_3_Creating_a_Raw_Transaction_with_Named_Arguments.md @@ -78,7 +78,7 @@ $ bitcoin-cli -named decoderawtransaction hexstring=$rawtxhex ] } -$ signedtx=$(bitcoin-cli -named signrawtransaction hexstring=$rawtxhex | jq -r '.hex') +$ signedtx=$(bitcoin-cli -named signrawtransactionwithwallet hexstring=$rawtxhex | jq -r '.hex') $ bitcoin-cli -named sendrawtransaction hexstring=$signedtx 8000dca7b1e7ab70f4056bc4512af6ffff7727d1588436521da3e5d886dbcddf ``` diff --git a/04_4_Sending_Coins_with_a_Raw_Transaction.md b/04_4_Sending_Coins_with_a_Raw_Transaction.md index 039bc94..8892590 100644 --- a/04_4_Sending_Coins_with_a_Raw_Transaction.md +++ b/04_4_Sending_Coins_with_a_Raw_Transaction.md @@ -96,7 +96,7 @@ $ btctxfee $rawtxhex2 You can now sign, seal, and deliver your transaction, and it's yours (and the faucet's): ``` -$ signedtx2=$(bitcoin-cli -named signrawtransaction hexstring=$rawtxhex2 | jq -r '.hex') +$ signedtx2=$(bitcoin-cli -named signrawtransactionwithwallet hexstring=$rawtxhex2 | jq -r '.hex') $ bitcoin-cli -named sendrawtransaction hexstring=$signedtx2 69c9ef4d1adb48596c470146ee9b60593023b6eb870b79ef666a8c9369768469 ``` diff --git a/04_4__Interlude_Using_Curl.md b/04_4__Interlude_Using_Curl.md index bdc7774..0731baf 100644 --- a/04_4__Interlude_Using_Curl.md +++ b/04_4__Interlude_Using_Curl.md @@ -318,10 +318,10 @@ $ hexcode=$(curl --user bitcoinrpc:73bd45ba60ab8f9ff9846b6404769487 --data-binar ### Sign and Send -Signing and sending your transaction using `curl` is an easy use of the `signrawtransaction` and `sendrawtransaction` RPC: +Signing and sending your transaction using `curl` is an easy use of the `signrawtransactionwithwallet` and `sendrawtransaction` RPC: ``` -$ signedhex=$(curl --user bitcoinrpc:73bd45ba60ab8f9ff9846b6404769487 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "signrawtransaction", "params": ["'$hexcode'"] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/ | jq -r '.result | .hex') +$ signedhex=$(curl --user bitcoinrpc:73bd45ba60ab8f9ff9846b6404769487 --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 bitcoinrpc:73bd45ba60ab8f9ff9846b6404769487 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "sendrawtransaction", "params": ["'$signedhex'"] }' -H 'content-type: text/plain;' http://127.0.0.1:18332/ | jq -r '.' { diff --git a/04_5_Sending_Coins_with_Automated_Raw_Transactions.md b/04_5_Sending_Coins_with_Automated_Raw_Transactions.md index 0306d2b..cd07649 100644 --- a/04_5_Sending_Coins_with_Automated_Raw_Transactions.md +++ b/04_5_Sending_Coins_with_Automated_Raw_Transactions.md @@ -126,14 +126,13 @@ Note the `ismine` results. At this point you can sign and send the transaction as usual. ``` -$ signedtx3=$(bitcoin-cli -named signrawtransaction hexstring=$rawtxhex3 | jq -r '.hex') +$ signedtx3=$(bitcoin-cli -named signrawtransactionwithwallet hexstring=$rawtxhex3 | jq -r '.hex') $ bitcoin-cli -named sendrawtransaction hexstring=$signedtx3 ``` In several minutes, you'll have your change back: ``` $ bitcoin-cli listunspent [ - { "txid": "37698ad6e7f62df07c2fbc549339aa680a7fa18328d7ad14ecb72b21c505cbc6", "vout": 0, diff --git a/05_1_Watching_for_Stuck_Transactions.md b/05_1_Watching_for_Stuck_Transactions.md index d9b79ec..b7f84c7 100644 --- a/05_1_Watching_for_Stuck_Transactions.md +++ b/05_1_Watching_for_Stuck_Transactions.md @@ -38,7 +38,7 @@ $ bitcoin-cli -named gettransaction txid=0f618e38efe887028a5dd04d0e12241431978b ``` A transaction can be considered stuck if it stays in this state for an extended amount of time. Not too many years ago, you could be sure that every transaction would go out _eventually_. But, that's no longer the case due to the increased usage of Bitcoin. Now, if a transaction is stuck too long, it will drop out of the mempool and then be lost from the Bitcoin network. -_What is the mempool?_ The Bitcoin mempool (or Memory Pool) is the pool of all unconfirmed transactions. When a miner makes a block, he uses transactions from his mempool. Then, when a block is verified, all the miners remove the transactions it contains from their pools. As of Bitcoin 0.12, unconfirmed transactions can also expire from mempools if they're old enough: typically, 72 hours or more. Mining pools might have their own mempool-management mechanisms. Though the mempool should be largely the same across the Bitcoin network, there will be variations on each machine: different transactions might have propogated to a specific node or (more notably) it might have different limits on how much it's willing to store. +_What is mempool?_ Mempool (or Memory Pool) is a pool of all unconfirmed transactions at a bitcoin node. These are the transactions that a node has received from the p2p network which are not yet included in a block. Each bitcoin node can have a slightly different set of transactions in its mempool: different transactions might have propogated to a specific node. This depends on when the node was last started and also its limits on how much it's willing to store. When a miner makes a block, he uses transactions from his mempool. Then, when a block is verified, all the miners remove the transactions it contains from their pools. As of Bitcoin 0.12, unconfirmed transactions can also expire from mempools if they're old enough, typically, 72 hours, and as of version 0.14.0 eviction time was increased to 2 weeks. Mining pools might have their own mempool-management mechanisms. This list of all [unconfirmed transactions](https://blockchain.info/unconfirmed-transactions) might not match any individual machine's mempool, but it should (mostly) be a superset of them. diff --git a/05_3_Funding_a_Transaction_with_CPFP.md b/05_3_Funding_a_Transaction_with_CPFP.md index f9a7d52..7f74b9c 100644 --- a/05_3_Funding_a_Transaction_with_CPFP.md +++ b/05_3_Funding_a_Transaction_with_CPFP.md @@ -12,7 +12,7 @@ RBF was all about the sender. He messed up and needed to increase the fee, or he Basically, the idea of CPFP is that a recipient has a transaction that hasn't been confirmed in a block that he wants to spend. So, he includes that unconfirmed transaction in a new transaction and pays a high-enough fee to encourage a miner to include both the original (parent) transaction and the new (child) transaction in a block. As a result, the parent and child transactions clear simultaneously. -It should be noted that CPFP is not a new protocol feature, like RBF. It's just a new incentivization scheme that can be used for transaction selection by miners. This also means that it's not as reliable as a protocol change like RBF: there might be reasons that the parent is never put into a block, and that will prevent the child from ever bring put into a block. +It should be noted that CPFP is not a new protocol feature, like RBF. It's just a new incentivization scheme that can be used for transaction selection by miners. This also means that it's not as reliable as a protocol change like RBF: there might be reasons that the child is not selected to be put into a block, and that will prevent the parent from ever being put into a block. ## Spend Unconfirmed UTXOs @@ -20,7 +20,7 @@ Funding a transaction with CPFP is a very simple process using the methods you'r 1. Find the `txid` and `vout` of the unconfirmed transaction. This may be the trickiest part, as `bitcoin-cli` generally tries to protect you from unconfirmed transactions. The sender might be able to send you this info; even with just the `txid`, you should be able to figure out the `vout` in a blockchain explorer. - You do have one other option: use `bitcoin-cli getmempool`, which can be used to list the contents of your entire mempool, where the unconfirmed transactions will be. You may have to dig through several if the mempool is particularly busy. You can then get more information on a specific transaction with `bitcoin-cli getrawtransaction`: + You do have one other option: use `bitcoin-cli getrawmempool`, which can be used to list the contents of your entire mempool, where the unconfirmed transactions will be. You may have to dig through several if the mempool is particularly busy. You can then get more information on a specific transaction with `bitcoin-cli getrawtransaction` with the verbose flag set to `true`: ``` $ bitcoin-cli getrawmempool [ @@ -80,14 +80,13 @@ $ rawtxhex=$(bitcoin-cli -named createrawtransaction inputs='''[ { "txid": "'$ut $ bitcoin-cli -named signrawtransaction hexstring=$rawtxhex | jq -r '.hex' 02000000012b137ef780666ba214842ff6ea2c3a0b36711bcaba839c3710f763e3d9687fed000000006a473044022003ca1f6797d781ef121ba7c2d1d41d763a815e9dad52aa8bc5ea61e4d521f68e022036b992e8e6bf2c44748219ca6e0056a88e8250f6fd0794dc69f79a2e8993671601210317b163ab8c8862e09c71767112b828abd3852e315441893fa0f535de4fa39b8dffffffff01905abd07000000001976a91450b1d90a130c4f3f1e5fbfa7320fd36b7265db0488ac00000000 -user1@blockstream:~$ signedtx=$(bitcoin-cli -named signrawtransaction hexstring=$rawtxhex | jq -r '.hex') $ signedtx=$(bitcoin-cli -named signrawtransaction hexstring=$rawtxhex | jq -r '.hex') $ bitcoin-cli -named sendrawtransaction hexstring=$signedtx 6a184a2f07fa30189f4831d6f041d52653a103b3883d2bec2f79187331fd7f0e ``` - 4. Cross your fingers. + 4. Crossing your fingers is not needed. You have verified your data is correct. From this point on, things are out of your hands. Your transactions may go through quickly. They may not. It all depends on whether the miners who are randomly generating the current blocks have the CPFP patch or not. But you've given your transactions the best chance. diff --git a/07_2_Running_a_Bitcoin_Script.md b/07_2_Running_a_Bitcoin_Script.md index 47b6250..58d9382 100644 --- a/07_2_Running_a_Bitcoin_Script.md +++ b/07_2_Running_a_Bitcoin_Script.md @@ -19,12 +19,7 @@ $ git clone https://github.com/kallewoof/btcdeb.git ``` Then, get C++ and other packages installed, so that you can get `btcdeb` running. ```Bash -$ sudo apt-get install autoconf -$ sudo apt-get install libtool -$ sudo apt-get install g++ -$ sudo apt-get install pkg-config -$ sudo apt-get install make - +$ sudo apt-get install autoconf libtool g++ pkg-config make $ cd btcdeb $ ./autogen.sh $ ./configure @@ -222,7 +217,7 @@ As we've seen, every input for a Bitcoin transaction contains a `scriptSig` that So, presume that a UTXO were locked with a `scriptPubKey` that read `OP_ADD 99 OP_EQUAL`, requiring as input two numbers that add up to ninety-nine, and presume that the `scriptSig` of `1 98` were run to unlock it. The two scripts would effectively be run in order as `1 98 OP_ADD 99 OP_EQUAL`. -Evaulate the result: +Evaluate the result: ``` Script: 1 98 OP_ADD 99 OP_EQUAL Stack: [] diff --git a/08_1_Understanding_the_Foundation_of_P2SH.md b/08_1_Understanding_the_Foundation_of_P2SH.md index b8be65e..84b4ad2 100644 --- a/08_1_Understanding_the_Foundation_of_P2SH.md +++ b/08_1_Understanding_the_Foundation_of_P2SH.md @@ -2,7 +2,7 @@ > **NOTE:** This is a draft in progress, so that I can get some feedback from early reviewers. It is not yet ready for learning. -You know that Bitcoin Scripts can be used to control the redemption of UTXOs. The next step is creating Scripts of your own ... but that requires a very specific techniques. +You know that Bitcoin Scripts can be used to control the redemption of UTXOs. The next step is creating Scripts of your own ... but that requires a very specific technique. ## Know the Bitcoin Standards @@ -38,7 +38,7 @@ The locking script is quite simple looking: `OP_HASH160 babf9063cee8ab6e9334f95f _What is a redeemScript?_ Each P2SH transaction carries the fingerprint of a hidden locking script within it as a 20-byte hash. When a P2SH transaction is redeemed, the full (unhashed) `redeemScript` is included as part of the `scriptSig`. Bitcoin will make sure the `redeemScript` matches the hash; then it actually runs the `redeemScript` to see if the funds can be spent (or not). -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 addressesd marked with a "2" prefix and they don't worry about how the recipient is going to retrieve the funds at the end. +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. > **TESTNET vs MAINNET:** Reminder: on testnet, the prefix for P2SH addresses is `2`, while on mainnet, it's `3`. diff --git a/README.md b/README.md index d880a76..0d67fcc 100644 --- a/README.md +++ b/README.md @@ -1,7 +1,7 @@ # Programming with Bitcoin Core and Lightning ## (Or: Programming Bitcoind and Lightningd) -_This is a tutorial for working with Bitcoin (and Lightning) that teaches direct interact with the severs themselves, as the most robust and secure way to begin cryptocurrency work._ +_This is a tutorial for working with Bitcoin (and Lightning) that teaches direct interaction with the servers themselves, as the most robust and secure way to begin cryptocurrency work._ > NOTE: This is a draft in progress, so that I can get some feedback from early reviewers. It is not yet ready for use.