mirror of
https://github.com/ChristopherA/Learning-Bitcoin-from-the-Command-Line.git
synced 2026-02-16 14:12:48 +00:00
Compare commits
8 Commits
fc7b5c5f45
...
803ab08f3f
| Author | SHA1 | Date | |
|---|---|---|---|
|
803ab08f3f | ||
|
|
3a18bf867d | ||
|
|
de5d5037dd | ||
|
|
82dfefae0b | ||
|
|
bd60d250f0 | ||
|
|
89b3ab60d4 | ||
|
|
d34cb1a0ff | ||
|
|
3fed2110a5 |
@ -2,6 +2,9 @@
|
||||
|
||||
To get started with Bitcoin, you first need to set up a machine running Bitcoin. The articles in this chapter describe how to do so, primarily by using a VPS (Virtual Private Server).
|
||||
|
||||
> :warning: **VERSION WARNING:** This version of the course was built
|
||||
with Bitcoin Core 30.2 (January 2026).
|
||||
|
||||
## Objectives for this Chapter
|
||||
|
||||
After working through this chapter, a developer will be able to:
|
||||
|
||||
@ -43,21 +43,22 @@ That tells you what's loaded; you'll then need to check that against an online s
|
||||
|
||||
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.
|
||||
|
||||
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:
|
||||
If you'd like an alias to look at everything at once, the following currently works for Signet, 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
|
||||
$ source .bash_profile
|
||||
$ btcblock
|
||||
|
||||
288200/288200
|
||||
```
|
||||
|
||||
> :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: **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 (between `/\$(` and `)'"`) 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.
|
||||
> **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.
|
||||
|
||||
The type of setup is mainly controlled through the ~/.bitcoin/bitcoin.conf file.
|
||||
If you're running signet, it probably contains this line:
|
||||
|
||||
@ -13,16 +13,15 @@ bitcoin.conf signet
|
||||
```
|
||||
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 `signet` 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
|
||||
banlist.json blocks debug.log peers.dat wallets
|
||||
bitcoind.pid chainstate onion_v3_private_key settings.json
|
||||
```
|
||||
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.
|
||||
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 will contain your personal wallet (when we set it up). 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: **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` or `~/.bitcoin/testnet4` directory contains your testnet data, and the `~/.bitcoin/regtest` directory contains your regtest data.
|
||||
|
||||
## Know Your Bitcoin-cli Commands
|
||||
|
||||
@ -30,31 +29,43 @@ Most of your early work will be done with the `bitcoin-cli` command, which offer
|
||||
```
|
||||
$ bitcoin-cli help
|
||||
== Blockchain ==
|
||||
dumptxoutset "path" ( "type" {"rollback":n,...} )
|
||||
getbestblockhash
|
||||
getblock "blockhash" ( verbosity )
|
||||
getblockchaininfo
|
||||
getblockcount
|
||||
getblockfilter "blockhash" ( "filtertype" )
|
||||
getblockfrompeer "blockhash" peer_id
|
||||
getblockhash height
|
||||
getblockheader "blockhash" ( verbose )
|
||||
getblockstats hash_or_height ( stats )
|
||||
getchainstates
|
||||
getchaintips
|
||||
getchaintxstats ( nblocks "blockhash" )
|
||||
getdeploymentinfo ( "blockhash" )
|
||||
getdescriptoractivity ["blockhash",...] [scanobjects,...] ( include_mempool )
|
||||
getdifficulty
|
||||
getmempoolancestors "txid" ( verbose )
|
||||
getmempooldescendants "txid" ( verbose )
|
||||
getmempoolentry "txid"
|
||||
getmempoolinfo
|
||||
getrawmempool ( verbose )
|
||||
getrawmempool ( verbose mempool_sequence )
|
||||
gettxout "txid" n ( include_mempool )
|
||||
gettxoutproof ["txid",...] ( "blockhash" )
|
||||
gettxoutsetinfo
|
||||
gettxoutsetinfo ( "hash_type" hash_or_height use_index )
|
||||
gettxspendingprevout [{"txid":"hex","vout":n},...]
|
||||
importmempool "filepath" ( options )
|
||||
loadtxoutset "path"
|
||||
preciousblock "blockhash"
|
||||
pruneblockchain height
|
||||
savemempool
|
||||
scanblocks "action" ( [scanobjects,...] start_height stop_height "filtertype" options )
|
||||
scantxoutset "action" ( [scanobjects,...] )
|
||||
verifychain ( checklevel nblocks )
|
||||
verifytxoutproof "proof"
|
||||
waitforblock "blockhash" ( timeout )
|
||||
waitforblockheight height ( timeout )
|
||||
waitfornewblock ( timeout "current_tip" )
|
||||
|
||||
== Control ==
|
||||
getmemoryinfo ( "mode" )
|
||||
@ -64,27 +75,25 @@ logging ( ["include_category",...] ["exclude_category",...] )
|
||||
stop
|
||||
uptime
|
||||
|
||||
== Generating ==
|
||||
generatetoaddress nblocks "address" ( maxtries )
|
||||
generatetodescriptor num_blocks "descriptor" ( maxtries )
|
||||
|
||||
== Mining ==
|
||||
getblocktemplate ( "template_request" )
|
||||
getblocktemplate {"mode":"str","capabilities":["str",...],"rules":["segwit","str",...],"longpollid":"str","data":"hex"}
|
||||
getmininginfo
|
||||
getnetworkhashps ( nblocks height )
|
||||
getprioritisedtransactions
|
||||
prioritisetransaction "txid" ( dummy ) fee_delta
|
||||
submitblock "hexdata" ( "dummy" )
|
||||
submitheader "hexdata"
|
||||
|
||||
== Network ==
|
||||
addnode "node" "command"
|
||||
addnode "node" "command" ( v2transport )
|
||||
clearbanned
|
||||
disconnectnode ( "address" nodeid )
|
||||
getaddednodeinfo ( "node" )
|
||||
getaddrmaninfo
|
||||
getconnectioncount
|
||||
getnettotals
|
||||
getnetworkinfo
|
||||
getnodeaddresses ( count )
|
||||
getnodeaddresses ( count "network" )
|
||||
getpeerinfo
|
||||
listbanned
|
||||
ping
|
||||
@ -96,25 +105,31 @@ analyzepsbt "psbt"
|
||||
combinepsbt ["psbt",...]
|
||||
combinerawtransaction ["hexstring",...]
|
||||
converttopsbt "hexstring" ( permitsigdata iswitness )
|
||||
createpsbt [{"txid":"hex","vout":n,"sequence":n},...] [{"address":amount},{"data":"hex"},...] ( locktime replaceable )
|
||||
createrawtransaction [{"txid":"hex","vout":n,"sequence":n},...] [{"address":amount},{"data":"hex"},...] ( locktime replaceable )
|
||||
createpsbt [{"txid":"hex","vout":n,"sequence":n},...] [{"address":amount,...},{"data":"hex"},...] ( locktime replaceable version )
|
||||
createrawtransaction [{"txid":"hex","vout":n,"sequence":n},...] [{"address":amount,...},{"data":"hex"},...] ( locktime replaceable version )
|
||||
decodepsbt "psbt"
|
||||
decoderawtransaction "hexstring" ( iswitness )
|
||||
decodescript "hexstring"
|
||||
descriptorprocesspsbt "psbt" ["",{"desc":"str","range":n or [n,n]},...] ( "sighashtype" bip32derivs finalize )
|
||||
finalizepsbt "psbt" ( extract )
|
||||
fundrawtransaction "hexstring" ( options iswitness )
|
||||
getrawtransaction "txid" ( verbose "blockhash" )
|
||||
getrawtransaction "txid" ( verbosity "blockhash" )
|
||||
joinpsbts ["psbt",...]
|
||||
sendrawtransaction "hexstring" ( maxfeerate )
|
||||
sendrawtransaction "hexstring" ( maxfeerate maxburnamount )
|
||||
signrawtransactionwithkey "hexstring" ["privatekey",...] ( [{"txid":"hex","vout":n,"scriptPubKey":"hex","redeemScript":"hex","witnessScript":"hex","amount":amount},...] "sighashtype" )
|
||||
submitpackage ["rawtx",...] ( maxfeerate maxburnamount )
|
||||
testmempoolaccept ["rawtx",...] ( maxfeerate )
|
||||
utxoupdatepsbt "psbt" ( ["",{"desc":"str","range":n or [n,n]},...] )
|
||||
|
||||
== Signer ==
|
||||
enumeratesigners
|
||||
|
||||
== Util ==
|
||||
createmultisig nrequired ["key",...] ( "address_type" )
|
||||
deriveaddresses "descriptor" ( range )
|
||||
estimatesmartfee conf_target ( "estimate_mode" )
|
||||
getdescriptorinfo "descriptor"
|
||||
getindexinfo ( "index_name" )
|
||||
signmessagewithprivkey "privkey" "message"
|
||||
validateaddress "address"
|
||||
verifymessage "address" "signature" "message"
|
||||
@ -122,83 +137,98 @@ verifymessage "address" "signature" "message"
|
||||
== Wallet ==
|
||||
abandontransaction "txid"
|
||||
abortrescan
|
||||
addmultisigaddress nrequired ["key",...] ( "label" "address_type" )
|
||||
backupwallet "destination"
|
||||
bumpfee "txid" ( options )
|
||||
createwallet "wallet_name" ( disable_private_keys blank "passphrase" avoid_reuse )
|
||||
dumpprivkey "address"
|
||||
dumpwallet "filename"
|
||||
createwallet "wallet_name" ( disable_private_keys blank "passphrase" avoid_reuse descriptors load_on_startup external_signer )
|
||||
createwalletdescriptor "type" ( {"internal":bool,"hdkey":"str",...} )
|
||||
encryptwallet "passphrase"
|
||||
getaddressesbylabel "label"
|
||||
getaddressinfo "address"
|
||||
getbalance ( "dummy" minconf include_watchonly avoid_reuse )
|
||||
getbalances
|
||||
gethdkeys ( {"active_only":bool,"private":bool,...} )
|
||||
getnewaddress ( "label" "address_type" )
|
||||
getrawchangeaddress ( "address_type" )
|
||||
getreceivedbyaddress "address" ( minconf )
|
||||
getreceivedbylabel "label" ( minconf )
|
||||
getreceivedbyaddress "address" ( minconf include_immature_coinbase )
|
||||
getreceivedbylabel "label" ( minconf include_immature_coinbase )
|
||||
gettransaction "txid" ( include_watchonly verbose )
|
||||
getunconfirmedbalance
|
||||
getwalletinfo
|
||||
importaddress "address" ( "label" rescan p2sh )
|
||||
importmulti "requests" ( "options" )
|
||||
importprivkey "privkey" ( "label" rescan )
|
||||
importdescriptors requests
|
||||
importprunedfunds "rawtransaction" "txoutproof"
|
||||
importpubkey "pubkey" ( "label" rescan )
|
||||
importwallet "filename"
|
||||
keypoolrefill ( newsize )
|
||||
listaddressgroupings
|
||||
listdescriptors ( private )
|
||||
listlabels ( "purpose" )
|
||||
listlockunspent
|
||||
listreceivedbyaddress ( minconf include_empty include_watchonly "address_filter" )
|
||||
listreceivedbylabel ( minconf include_empty include_watchonly )
|
||||
listsinceblock ( "blockhash" target_confirmations include_watchonly include_removed )
|
||||
listreceivedbyaddress ( minconf include_empty include_watchonly "address_filter" include_immature_coinbase )
|
||||
listreceivedbylabel ( minconf include_empty include_watchonly include_immature_coinbase )
|
||||
listsinceblock ( "blockhash" target_confirmations include_watchonly include_removed include_change "label" )
|
||||
listtransactions ( "label" count skip include_watchonly )
|
||||
listunspent ( minconf maxconf ["address",...] include_unsafe query_options )
|
||||
listwalletdir
|
||||
listwallets
|
||||
loadwallet "filename"
|
||||
lockunspent unlock ( [{"txid":"hex","vout":n},...] )
|
||||
loadwallet "filename" ( load_on_startup )
|
||||
lockunspent unlock ( [{"txid":"hex","vout":n},...] persistent )
|
||||
migratewallet ( "wallet_name" "passphrase" )
|
||||
psbtbumpfee "txid" ( options )
|
||||
removeprunedfunds "txid"
|
||||
rescanblockchain ( start_height stop_height )
|
||||
sendmany "" {"address":amount} ( minconf "comment" ["address",...] replaceable conf_target "estimate_mode" )
|
||||
sendtoaddress "address" amount ( "comment" "comment_to" subtractfeefromamount replaceable conf_target "estimate_mode" avoid_reuse )
|
||||
sethdseed ( newkeypool "seed" )
|
||||
restorewallet "wallet_name" "backup_file" ( load_on_startup )
|
||||
send [{"address":amount,...},{"data":"hex"},...] ( conf_target "estimate_mode" fee_rate options version )
|
||||
sendall ["address",{"address":amount,...},...] ( conf_target "estimate_mode" fee_rate options )
|
||||
sendmany ( "" ) {"address":amount,...} ( minconf "comment" ["address",...] replaceable conf_target "estimate_mode" fee_rate verbose )
|
||||
sendtoaddress "address" amount ( "comment" "comment_to" subtractfeefromamount replaceable conf_target "estimate_mode" avoid_reuse fee_rate verbose )
|
||||
setlabel "address" "label"
|
||||
settxfee amount
|
||||
setwalletflag "flag" ( value )
|
||||
signmessage "address" "message"
|
||||
signrawtransactionwithwallet "hexstring" ( [{"txid":"hex","vout":n,"scriptPubKey":"hex","redeemScript":"hex","witnessScript":"hex","amount":amount},...] "sighashtype" )
|
||||
unloadwallet ( "wallet_name" )
|
||||
walletcreatefundedpsbt [{"txid":"hex","vout":n,"sequence":n},...] [{"address":amount},{"data":"hex"},...] ( locktime options bip32derivs )
|
||||
simulaterawtransaction ( ["rawtx",...] {"include_watchonly":bool,...} )
|
||||
unloadwallet ( "wallet_name" load_on_startup )
|
||||
walletcreatefundedpsbt ( [{"txid":"hex","vout":n,"sequence":n,"weight":n},...] ) [{"address":amount,...},{"data":"hex"},...] ( locktime options bip32derivs version )
|
||||
walletdisplayaddress "address"
|
||||
walletlock
|
||||
walletpassphrase "passphrase" timeout
|
||||
walletpassphrasechange "oldpassphrase" "newpassphrase"
|
||||
walletprocesspsbt "psbt" ( sign "sighashtype" bip32derivs )
|
||||
walletprocesspsbt "psbt" ( sign "sighashtype" bip32derivs finalize )
|
||||
|
||||
== Zmq ==
|
||||
getzmqnotifications
|
||||
|
||||
```
|
||||
You can also type `bitcoin-cli help [command]` to get even more extensive info on that command. For example:
|
||||
```
|
||||
$ bitcoin-cli help getmininginfo
|
||||
$ bitcoin-cli help createwallet
|
||||
...
|
||||
Returns a json object containing mining-related information.
|
||||
createwallet "wallet_name" ( disable_private_keys blank "passphrase" avoid_reuse descriptors load_on_startup external_signer )
|
||||
|
||||
Creates and loads a new wallet.
|
||||
|
||||
Arguments:
|
||||
1. wallet_name (string, required) The name for the new wallet. If this is a path, the wallet will be created at the path location.
|
||||
2. disable_private_keys (boolean, optional, default=false) Disable the possibility of private keys (only watchonlys are possible in this mode).
|
||||
3. blank (boolean, optional, default=false) Create a blank wallet. A blank wallet has no keys.
|
||||
4. passphrase (string, optional) Encrypt the wallet with this passphrase.
|
||||
5. avoid_reuse (boolean, optional, default=false) Keep track of coin reuse, and treat dirty and clean coins differently with privacy considerations in mind.
|
||||
6. descriptors (boolean, optional, default=true) If set, must be "true"
|
||||
7. load_on_startup (boolean, optional) Save wallet name to persistent settings and load on startup. True to add wallet to startup list, false to remove, null to leave unchanged.
|
||||
8. external_signer (boolean, optional, default=false) Use an external signer such as a hardware wallet. Requires -signer to be configured. Wallet creation will fail if keys cannot be fetched. Requires disable_private_keys and descriptors set to true.
|
||||
|
||||
Result:
|
||||
{ (json object)
|
||||
"blocks" : n, (numeric) The current block
|
||||
"currentblockweight" : n, (numeric, optional) The block weight of the last assembled block (only present if a block was ever assembled)
|
||||
"currentblocktx" : n, (numeric, optional) The number of block transactions of the last assembled block (only present if a block was ever assembled)
|
||||
"difficulty" : n, (numeric) The current difficulty
|
||||
"networkhashps" : n, (numeric) The network hashes per second
|
||||
"pooledtx" : n, (numeric) The size of the mempool
|
||||
"chain" : "str", (string) current network name (main, test, regtest)
|
||||
"warnings" : "str" (string) any network and blockchain warnings
|
||||
{ (json object)
|
||||
"name" : "str", (string) The wallet name if created successfully. If the wallet was created using a full path, the wallet_name will be the full path.
|
||||
"warnings" : [ (json array, optional) Warning messages, if any, related to creating and loading the wallet.
|
||||
"str", (string)
|
||||
...
|
||||
]
|
||||
}
|
||||
|
||||
Examples:
|
||||
> bitcoin-cli getmininginfo
|
||||
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "getmininginfo", "params": []}' -H 'content-type: text/plain;' http://127.0.0.1:8332/
|
||||
> bitcoin-cli createwallet "testwallet"
|
||||
> curl --user myusername --data-binary '{"jsonrpc": "2.0", "id": "curltest", "method": "createwallet", "params": ["testwallet"]}' -H 'content-type: application/json' http://127.0.0.1:8332/
|
||||
> bitcoin-cli -named createwallet wallet_name=descriptors avoid_reuse=true load_on_startup=true
|
||||
> curl --user myusername --data-binary '{"jsonrpc": "2.0", "id": "curltest", "method": "createwallet", "params": {"wallet_name":"descriptors","avoid_reuse":true,"load_on_startup":true}}' -H 'content-type: application/json' http://127.0.0.1:8332/
|
||||
|
||||
```
|
||||
> :book: ***What is RPC?*** `bitcoin-cli` is just a handy interface that lets you send commands to the `bitcoind`. More specifically, it's an interface that lets you send RPC (or Remote Procedure Protocol) commands to the `bitcoind`. Often, the `bitcoin-cli` command and the RPC command have identical names and interfaces, but some `bitcoin-cli` commands instead provide shortcuts for more complex RPC requests. Generally, the `bitcoin-cli` interface is much cleaner and simpler than trying to send RPC commands by hand, using `curl` or some other method. However, it also has limitations as to what you can ultimately do.
|
||||
|
||||
@ -234,7 +264,7 @@ Transaction fee rate (-paytxfee) (BTC/kvB): 0.00000000
|
||||
|
||||
```
|
||||
|
||||
Other commands to get information about blockchain, mining, network, wallet etc.
|
||||
Other commands allow you to get information about blockchain, mining, network, wallet etc.
|
||||
|
||||
```
|
||||
$ bitcoin-cli getblockchaininfo
|
||||
@ -247,18 +277,21 @@ For example `bitcoin-cli getnetworkinfo` gives you a variety of information on y
|
||||
```
|
||||
$ bitcoin-cli getnetworkinfo
|
||||
{
|
||||
"version": 200000,
|
||||
"subversion": "/Satoshi:0.20.0/",
|
||||
"protocolversion": 70015,
|
||||
"localservices": "0000000000000408",
|
||||
"version": 300200,
|
||||
"subversion": "/Satoshi:30.2.0/",
|
||||
"protocolversion": 70016,
|
||||
"localservices": "0000000000000c08",
|
||||
"localservicesnames": [
|
||||
"WITNESS",
|
||||
"NETWORK_LIMITED"
|
||||
"NETWORK_LIMITED",
|
||||
"P2P_V2"
|
||||
],
|
||||
"localrelay": true,
|
||||
"timeoffset": 0,
|
||||
"networkactive": true,
|
||||
"connections": 10,
|
||||
"connections": 11,
|
||||
"connections_in": 0,
|
||||
"connections_out": 11,
|
||||
"networks": [
|
||||
{
|
||||
"name": "ipv4",
|
||||
@ -280,31 +313,46 @@ $ bitcoin-cli getnetworkinfo
|
||||
"reachable": true,
|
||||
"proxy": "127.0.0.1:9050",
|
||||
"proxy_randomize_credentials": true
|
||||
},
|
||||
{
|
||||
"name": "i2p",
|
||||
"limited": true,
|
||||
"reachable": false,
|
||||
"proxy": "",
|
||||
"proxy_randomize_credentials": false
|
||||
},
|
||||
{
|
||||
"name": "cjdns",
|
||||
"limited": true,
|
||||
"reachable": false,
|
||||
"proxy": "",
|
||||
"proxy_randomize_credentials": false
|
||||
}
|
||||
],
|
||||
"relayfee": 0.00001000,
|
||||
"incrementalfee": 0.00001000,
|
||||
"relayfee": 0.00000100,
|
||||
"incrementalfee": 0.00000100,
|
||||
"localaddresses": [
|
||||
{
|
||||
"address": "45.79.111.171",
|
||||
"port": 18333,
|
||||
"address": "172.239.66.235",
|
||||
"port": 38333,
|
||||
"score": 1
|
||||
},
|
||||
{
|
||||
"address": "2600:3c01::f03c:92ff:fecc:fdb7",
|
||||
"port": 18333,
|
||||
"address": "2a01:7e03::2000:92ff:fe75:3ec",
|
||||
"port": 38333,
|
||||
"score": 1
|
||||
},
|
||||
{
|
||||
"address": "4wrr3ktm6gl4sojx.onion",
|
||||
"port": 18333,
|
||||
"address": "km4bnrbemttglfbkafav2nf5mcy4x3l5jmi24fwtjjm3uba2ygycutyd.onion",
|
||||
"port": 38333,
|
||||
"score": 4
|
||||
}
|
||||
],
|
||||
"warnings": "Warning: unknown new rules activated (versionbit 28)"
|
||||
"warnings": [
|
||||
]
|
||||
}
|
||||
```
|
||||
Feel free to reference any of these and to use "bitcoin-cli help" if you want more information on what any of them do.
|
||||
Feel free to test out any of these and to use "bitcoin-cli help" if you want more information on what any of them do.
|
||||
|
||||
## Summary: Knowing Your Bitcoin Setup
|
||||
|
||||
|
||||
@ -1,94 +1,74 @@
|
||||
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.
|
||||
|
||||
> :warning: **VERSION WARNING:** Bitcoin Core is constantly
|
||||
evolving. To reflect this, previous versions of this course offered
|
||||
"VERSION WARNING"s for features that had been recently introduced. For
|
||||
example, Bitcoin Core v0.21.0 (January 2021) stopped creating wallets
|
||||
by default and introduced experimental descriptor wallets, which then
|
||||
became default with Bitcoin v23.0 (April 2022).
|
||||
>
|
||||
> These WARNINGS have
|
||||
largely been removed in recent versions of this course, as they quickly become out of date. The
|
||||
exception is for interoperable features that may or may not have been
|
||||
adopted by remote nodes (e.g., new address types). But for your own
|
||||
machine, just make sure you are using at least the version of Bitcoin
|
||||
Core that is flagged in [Chapter
|
||||
2](02_0_Setting_Up_a_Bitcoin-Core_VPS.md) and you'll have access to
|
||||
all the functions herein.
|
||||
>
|
||||
> Be aware that sometimes functions
|
||||
are deprecated and removed, so if you are using a newer version
|
||||
there's a small chance that something may no longer be available.
|
||||
|
||||
## Create a Wallet
|
||||
|
||||
> :warning: **VERSION WARNING:** Newer versions of Bitcoin Core, starting with v0.21.0, will no longer automatically create a default wallet on startup. So, you will need to manually create one. But if you're running an older version of Bitcoin Core, a new wallet has already been created for you, in which case you can skip ahead to [Create an Address](#create-an-address).
|
||||
|
||||
The first thing you need to do is create a new wallet, which can be done with the `bitcoin-cli createwallet` command. By creating a new wallet, you'll be creating your public-private key pair. Your public key is the source from which your addresses will be created, and your private key is what will allow you to spend any funds you receive into your addresses. Bitcoin Core will automatically save that information into a `wallet.dat` file in your `~/.bitcoin/signet/wallets` directory.
|
||||
|
||||
If you check your `wallets` directory, you'll see that it's currently empty.
|
||||
```
|
||||
$ ls ~/.bitcoin/signet/wallets
|
||||
$
|
||||
```
|
||||
|
||||
Although Bitcoin Core won't create a new wallet for you, it will still load a top-level unnamed ("") wallet on startup by default. You can take advantage of this by creating a new unnamed wallet.
|
||||
That's because Bitcoin Core doesn't create a wallet by default, but creating one is quite simple. You just run `bitcoin-cli createwallet` and choose a name for your wallet, such as `"mainwallet"`.
|
||||
```
|
||||
$ bitcoin-cli -named createwallet wallet_name="" descriptors=false
|
||||
|
||||
$ bitcoin-cli createwallet "mainwallet"
|
||||
{
|
||||
"name": "",
|
||||
"warning": ""
|
||||
"name": "mainwallet"
|
||||
}
|
||||
```
|
||||
|
||||
Now, your `wallets` directory should be populated.
|
||||
```
|
||||
$ ls ~/.bitcoin/signet/wallets
|
||||
database db.log wallet.dat
|
||||
mainwallet
|
||||
$ ls ~/.bitcoin/signet/wallets/mainwallet
|
||||
wallet.dat wallet.dat-journal
|
||||
```
|
||||
|
||||
> :book: ***What is a Bitcoin wallet?*** A Bitcoin wallet is the digital equivalent of a physical wallet on the Bitcoin network. It stores information on the amount of bitcoins you have and where it's located (addresses), as well as the ways you can use to spend it. Spending physical money is intuitive, but to spend bitcoins users need to provide the correct _private key_. We will explain this in more detail throughout the course, but what you should know for now is that this public-private key dynamic is part of what makes Bitcoin secure and trustless. Your key pair information is saved in the `wallet.dat` file, in addition to data about preferences and transactions. For the most part, you won't have to worry about that private key: `bitcoind` will use it when it's needed. However, this makes the `wallet.dat` file extremely important: if you lose it, you lose your private keys, and if you lose your private keys, you lose your funds!
|
||||
As this indicates, each wallet will have its own directory. (The main directory is used if you choose `""` for your wallet name.) Each directory will then have a `wallet.dat` file (which is a SQLite database) and a `wallet.dat-journal` file (which is an SQLite rollback journal).
|
||||
|
||||
Sweet, now you have a Bitcoin wallet. But a wallet will be of little use for receiving bitcoins if you don't create an address first.
|
||||
> :book: ***What is a Bitcoin wallet?*** A Bitcoin wallet is the digital equivalent of a physical wallet. It stores information on the amount of bitcoins you have and where it's located (addresses), as well as the ways you can use to spend it. Spending physical money is intuitive, but to spend Bitcoin, users need to provide the correct _private key_. We will explain this in more detail throughout the course, but what you should know for now is that this public-private key dynamic is part of what makes Bitcoin secure and trustless. Your key pair information is saved in the `wallet.dat` file, in addition to data about preferences and transactions. For the most part, you won't have to worry about that private key: `bitcoind` will use it when it's needed. However, this makes the `wallet.dat` file extremely important: if you lose it, you lose your private keys, and if you lose your private keys, you lose your funds!
|
||||
|
||||
> :warning: **VERSION WARNING:** Starting in Bitcoin Core v 23.0, descriptor wallets became the default. That's great, because descriptor wallets are very powerful, except they don't currently work with multisigs! So, we turn them off with the "descriptors=false" argument. See [§3.5](https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/03_5_Understanding_the_Descriptor.md) for more on descriptors.
|
||||
You now have a Bitcoin wallet. But you can't receive funds with a wallet. For that you need an address, which is a specific repository for funds, derived from the private key information in your wallet: its one private key can generate many addresses.
|
||||
|
||||
## Create an Address
|
||||
|
||||
The next thing you need to do is create an address for receiving payments. This is done with the `bitcoin-cli getnewaddress` command. Remember that if you want more information on this command, you should type `bitcoin-cli help getnewaddress`. Currently, there are three types of addresses: `legacy` and the two types of SegWit address, `p2sh-segwit` and `bech32`. If you do not otherwise specify, you'll get the default, which is currently `bech32`.
|
||||
The next thing you need to do is create an address for receiving payments. This is done with the `bitcoin-cli getnewaddress` command. Remember that if you want more information on this command, you should type `bitcoin-cli help getnewaddress`. There are a variety of types of addresses, due to Bitcoin's evolution over the years. [§4.1](04_1_Sending_Coins_The_Easy_Way.md) covers them all. For now, though we're just going to create an address of the default type, which is Bech32.
|
||||
|
||||
However, for the next few sections we're instead going to be using `legacy` addresses, both because `bitcoin-cli` had some teething problems with its early versions of SegWit addresses, and because other people might not be able to send to `bech32` addresses. This is all unlikely to be a problem for you now, but for the moment we want to get your started with transaction examples that are (mostly) guaranteed to work.
|
||||
```
|
||||
$ bitcoin-cli getnewaddress
|
||||
tb1qmuqycfqfffvkys2h8rwqpgw6n0v6s0uhd235sj
|
||||
```
|
||||
Note that this address begins with an "tb1", which [means](https://en.bitcoin.it/wiki/List_of_address_prefixes) that it's a Bech32 address on either signet or testnet. The discussion of different address types in §4.1 will also talk about all of their identifying prefixes.
|
||||
|
||||
First, restart `bitcoind` so your new unnamed wallet is set as default and automatically loaded.
|
||||
```
|
||||
$ bitcoin-cli stop
|
||||
Bitcoin Core stopping # wait a minute so it stops completely
|
||||
$ bitcoind -daemon
|
||||
Bitcoin Core starting # wait a minute so it starts completely
|
||||
```
|
||||
|
||||
You can now create an address. You can require `legacy` address either with the second argument to `getnewaddress` or with the named `addresstype` argument.
|
||||
```
|
||||
$ bitcoin-cli getnewaddress -addresstype legacy
|
||||
moKVV6XEhfrBCE3QCYq6ppT7AaMF8KsZ1B
|
||||
```
|
||||
Note that this address begins with an "m" (or sometimes an "n") to signify a Signet 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: **SIGNET vs MAINNET vs TESTNET:** The equivalent mainnet address would start with a "bc1".
|
||||
|
||||
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. It's based on 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. If you keep reusing the same address, then this becomes even easier.
|
||||
|
||||
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.
|
||||
|
||||
### Knowing Your Bitcoin Addresses
|
||||
|
||||
There are three types of Bitcoin addresses that you can create with the `getnewaddress` RPC command. You'll be using a `legacy` (P2PKH) address here, while you'll move over to a SegWit (P2SH-SegWit) or Bech32 address in [§4.6: Creating a Segwit Transaction](04_6_Creating_a_Segwit_Transaction.md).
|
||||
|
||||
As noted above, the foundation of a Bitcoin address is a public key: someone sends funds to your public key, and then you use your private key to redeem it. Easy? Except putting your public key out there isn't entirely secure. At the moment, if someone has your public key, then they can't retrieve your private key (and thus your funds); that's the basis of cryptography, which uses a trap-door function to ensure that you can only go from private to public key, and not vice-versa. But the problem is that we don't know what the future might bring. Except we do know that cryptography systems eventually get broken by the relentless advance of technology, so it's better not to put raw public keys on the 'net, to future-proof your transactions.
|
||||
|
||||
Classic Bitcoin transactions created P2PKH addresses that added an additional cryptographic step to protect public keys.
|
||||
|
||||
> :book: ***What is a Legacy (P2PKH) address?*** This is a Legacy address of the sort used by the early Bitcoin network. We'll be using it in examples for the next few sections. It's called a Pay to PubKey Hash (or P2PKH) address because the address is a 160-bit hash of a public key. Using a hash of your public key as your address creates a two-step process where to spend funds you need to reveal both the private key and the public key, and it increases future security accordingly. This sort of address remains important for receiving funds from people with out-of-date wallet software.
|
||||
|
||||
As described more fully in [§4.6: Creating a Segwit Transaction](04_6_Creating_a_Segwit_Transaction.md), the Block Size Wars of the late '10s resulted in a new sort of address: SegWit. This is the preferred sort of address currently, and should be fully integrated into Bitcoin-Core at this point, but nonetheless we're saving it for §4.6.
|
||||
|
||||
SegWit simply means "segregated witness" and it's a way of separating the transaction signatures out from the rest of the transaction to reduce transaction size. Some SegWit addresses will sneak into some of our examples prior to §4.6 as change addresses, which you'll see as addresses that begin with "tb". This is fine because the `bitcoin-cli` entirely supports their usage. But we won't use them otherwise.
|
||||
|
||||
There are two addresses of this sort:
|
||||
|
||||
> :book: ***What is a P2SH-SegWit (aka Nested SegWit) address?*** This is the first generation of SegWit. It wraps the SegWit address in a Script hash to ensure backward compatibility. The result creates transactions that are about 25%+ smaller (with corresponding reductions in transaction fees).
|
||||
|
||||
> :book: ***What is a Bech32 (aka Native SegWit, aka P2WPKH) address?*** This is the second generation of SegWit. It's fully described in [BIP 173](https://en.bitcoin.it/wiki/BIP_0173). It creates transactions that are even smaller but more notably also has some advantages in creating addresses that are less prone to human error and have some implicit error-correction beyond that. It is *not* backward compatible like P2SH-SegWit was, and so some people may not be able to send to it.
|
||||
|
||||
There are other sorts of Bitcoin addresses, such as P2PK (which paid to a bare public key, and is deprecated because of its future insecurity) and P2SH (which pays to a Script Hash, and which is used by the first-generation Nested SegWit addresses; we'll meet it more fully in a few chapters).
|
||||
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/{walletname}` directory. With a single address in hand, you could jump straight [§3.5: Receiving a Transaction](03_5_Receiving_a_Transaction.md) and begin receiving funds. However, before we get there, we're going to briefly discuss a few optional wallet commands that you might want to use in the future.
|
||||
|
||||
## Optional: Sign a Message
|
||||
|
||||
|
||||
@ -11,8 +11,6 @@ TODO:
|
||||
|
||||
You may have noticed a weird `desc:` field in the `listunspent` command of the previous section. Here's what's all about (and how it can be used to transfer addresses).
|
||||
|
||||
> :warning: **VERSION WARNING:** This is an innovation from Bitcoin Core v 0.17.0 that had continued to be expanded through Bitcoin Core 0.20.0. Most of the commands in this section are from 0.17.0, but the updated `importmulti` that support descriptors is from 0.18.0.
|
||||
|
||||
## Know about Transferring Addresses
|
||||
|
||||
Most of this course presumes that you're working entirely from a single node where you manage your own wallet, sending and receiving payments with the addresses created by that wallet. However, that's not necessarily how the larger Bitcoin ecosystem works. There, you're more likely to be moving addresses between wallets and even setting up wallets to watch over funds controlled by different wallets.
|
||||
|
||||
@ -3,6 +3,32 @@ TODO:
|
||||
* 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
|
||||
|
||||
==
|
||||
UNDERSTANDING ADDRESSES MIGHT BE A WHOLE NEW SECTION
|
||||
==
|
||||
### Knowing Your Bitcoin Addresses
|
||||
|
||||
There are three types of Bitcoin addresses that you can create with the `getnewaddress` RPC command. You'll be using a `legacy` (P2PKH) address here, while you'll move over to a SegWit (P2SH-SegWit) or Bech32 address in [§4.6: Creating a Segwit Transaction](04_6_Creating_a_Segwit_Transaction.md).
|
||||
|
||||
As noted above, the foundation of a Bitcoin address is a public key: someone sends funds to your public key, and then you use your private key to redeem it. Easy? Except putting your public key out there isn't entirely secure. At the moment, if someone has your public key, then they can't retrieve your private key (and thus your funds); that's the basis of cryptography, which uses a trap-door function to ensure that you can only go from private to public key, and not vice-versa. But the problem is that we don't know what the future might bring. Except we do know that cryptography systems eventually get broken by the relentless advance of technology, so it's better not to put raw public keys on the 'net, to future-proof your transactions.
|
||||
|
||||
Classic Bitcoin transactions created P2PKH addresses that added an additional cryptographic step to protect public keys.
|
||||
|
||||
> :book: ***What is a Legacy (P2PKH) address?*** This is a Legacy address of the sort used by the early Bitcoin network. We'll be using it in examples for the next few sections. It's called a Pay to PubKey Hash (or P2PKH) address because the address is a 160-bit hash of a public key. Using a hash of your public key as your address creates a two-step process where to spend funds you need to reveal both the private key and the public key, and it increases future security accordingly. This sort of address remains important for receiving funds from people with out-of-date wallet software.
|
||||
|
||||
As described more fully in [§4.6: Creating a Segwit Transaction](04_6_Creating_a_Segwit_Transaction.md), the Block Size Wars of the late '10s resulted in a new sort of address: SegWit. This is the preferred sort of address currently, and should be fully integrated into Bitcoin-Core at this point, but nonetheless we're saving it for §4.6.
|
||||
|
||||
SegWit simply means "segregated witness" and it's a way of separating the transaction signatures out from the rest of the transaction to reduce transaction size. Some SegWit addresses will sneak into some of our examples prior to §4.6 as change addresses, which you'll see as addresses that begin with "tb". This is fine because the `bitcoin-cli` entirely supports their usage. But we won't use them otherwise.
|
||||
|
||||
There are two addresses of this sort:
|
||||
|
||||
> :book: ***What is a P2SH-SegWit (aka Nested SegWit) address?*** This is the first generation of SegWit. It wraps the SegWit address in a Script hash to ensure backward compatibility. The result creates transactions that are about 25%+ smaller (with corresponding reductions in transaction fees).
|
||||
|
||||
> :book: ***What is a Bech32 (aka Native SegWit, aka P2WPKH) address?*** This is the second generation of SegWit. It's fully described in [BIP 173](https://en.bitcoin.it/wiki/BIP_0173). It creates transactions that are even smaller but more notably also has some advantages in creating addresses that are less prone to human error and have some implicit error-correction beyond that. It is *not* backward compatible like P2SH-SegWit was, and so some people may not be able to send to it.
|
||||
|
||||
There are other sorts of Bitcoin addresses, such as P2PK (which paid to a bare public key, and is deprecated because of its future insecurity) and P2SH (which pays to a Script Hash, and which is used by the first-generation Nested SegWit addresses; we'll meet it more fully in a few chapters).
|
||||
==
|
||||
|
||||
# 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.
|
||||
|
||||
@ -6,8 +6,6 @@ TODO:
|
||||
|
||||
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.
|
||||
|
||||
> :warning: **VERSION WARNING:** This is an innovation from Bitcoin Core v 0.14.0. If you used our setup scripts, that's what you should have, but double-check your version if you have any problems. There is also a bug in the `createrawtransaction` command's use of named arguments that will presumably be fixed in 0.14.1.
|
||||
|
||||
## Create a Named Argument Alias
|
||||
|
||||
To use a named argument you must run `bitcoin-cli` with the `-named` argument. If you plan to do this regularly, you'll probably want to create an alias:
|
||||
@ -88,8 +86,6 @@ e70dd2aa13422d12c222481c17ca21a57071f92ff86bdcffd7eaca71772ba172
|
||||
```
|
||||
Voila! You've sent out another raw transaction, but this time using named arguments for clarity and to reduce errors.
|
||||
|
||||
> :warning: **VERSION WARNING:** There is where the bug in Bitcoin Core 0.14 shows up: the 'inputs' argument for 'createrawtransaction' is misnamed 'transactions'. So, if you're on Bitcoin Core 0.14.0, substitute the named argument 'inputs' with 'transactions' for this and future examples. However, as of Bitcoin Core 0.14.1, this code should work as shown.
|
||||
|
||||
## Summary: Creating a Raw Transaction with Named Arguments
|
||||
|
||||
By running `bitcoin-cli` with the `-named` flag, you can use named arguments rather than depending on ordered arguments. `bitcoin-cli help` will always show you the right name for each argument. This can result in more robust, easier-to-read, less error-prone code.
|
||||
|
||||
@ -6,10 +6,6 @@ Once upon a time, the Bitcoin heavens shook with the blocksize wars. Fees were s
|
||||
|
||||
The catch? SegWit uses different addresses, some of which are compatible with older nodes, and some of which are not.
|
||||
|
||||
> :warning: **VERSION WARNING:** SegWit was introduced in BitCoin 0.16.0 with what was described at the time as "full support". With that said, there were some flaws in its integration with `bitcoin-cli` at the time which prevented signing from working correctly on new P2SH-SegWit addresses. The non-backward-compatible Bech32 address was also introduced in Bitcoin 0.16.0 and was made the default addresstype in Bitcoin 0.19.0. All of this functionality should now fully work with regard to `bitcoin-cli` functions (and thus this tutorial).
|
||||
|
||||
> The catch comes in interacting with the wider world. Everyone should be able to send to a P2SH-SegWit address because it was purposefully built to support backward compatibility by wrapping the SegWit functionality in a Bitcoin Script. The same isn't true for Bech32 addresses: if someone tells you that they're unable to send to your Bech32 address, this is why, and you need to generate a `legacy` or P2SH-SegWit address for their usage. (Many sites, particularly exchanges, can also not generate or receive on SegWit addresses, particularly Bech32 addresses, but that's a whole different issue and doesn't affect your usage of them.)
|
||||
|
||||
## 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 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).
|
||||
|
||||
@ -4,8 +4,6 @@ TODO: This is now a default per updates in 24, 29. You don't need to verify any
|
||||
|
||||
If your Bitcoin transaction is stuck, and you're the sender, you can resend it using RBF (replace-by-fee). However, that's not all that RBF can do: it's generally a powerful and multipurpose feature that allows Bitcoin senders to recreate transactions for a variety of reasons.
|
||||
|
||||
> :warning: **VERSION WARNING:** This is an innovation from Bitcoin Core v 0.12.0, that reached full maturity in the Bitcoin Core wallet with Bitcoin Core v 0.14.0. Obviously, most people should be using it by now.
|
||||
|
||||
## Opt-In for RBF
|
||||
|
||||
RBF is an opt-in Bitcoin feature. Transactions are only eligible for using RBF if they've been created with a special RBF flag. This is done by setting any of the transaction's UTXO sequence numbers (which are typically set automatically), so that it's more than 0 and less than 0xffffffff-1 (4294967294).
|
||||
@ -50,8 +48,6 @@ The `bip125-replaceable` flag will stay `yes` until the transaction receives con
|
||||
|
||||
If you prefer, you can _always_ opt in for RBF. Do so by running your `bitcoind` with the `-walletrbf` command. Once you've done this (and restarted your `bitcoind`), then all UTXOs should have a lower sequence number and the transaction should be marked as `bip125-replaceable`.
|
||||
|
||||
> :warning: **VERSION WARNING:** The walletrbf flag require Bitcoin Core v.0.14.0.
|
||||
|
||||
## Understand How RBF Works
|
||||
|
||||
The RBF functionality is based on [BIP 125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki), which lists the following rules for using RBF:
|
||||
@ -202,8 +198,6 @@ $ bitcoin-cli -named gettransaction txid=75208c5c8cbd83081a0085cd050fc7a4064d87c
|
||||
}
|
||||
```
|
||||
|
||||
> :warning: **VERSION WARNING:** The `bumpfee` RPC requires Bitcoin Core v.0.14.0.
|
||||
|
||||
## Summary: Resending a Transaction with RBF
|
||||
|
||||
If a transaction is stuck, and you don't want to wait for it to expire entirely, if you opted-in to RBF, then you can double-spend using RBF to create a replacement transaction (or just use `bumpfee`).
|
||||
|
||||
@ -2,8 +2,6 @@
|
||||
|
||||
If your Bitcoin transaction is stuck, and you're the _recipient_, you can clear it using CPFP (child-pays-for-parent). This is alternative to the _sender's_ ability to do so with RBF.
|
||||
|
||||
> :warning: **VERSION WARNING:** This is an innovation from Bitcoin Core v 0.13.0, which again means that most people should be using it by now.
|
||||
|
||||
## Understand How CPFP Works
|
||||
|
||||
RBF was all about the sender. He messed up and needed to increase the fee, or he wanted to be smart and combine transactions for a variety of reasons. It was a powerful sender-oriented feature. In some ways, CPFP is RBF's opposite, because it empowers the recipient who knows that his money hasn't arrived yet and wants to speed it up. However, it's also a much simpler feature, with less wide applicability.
|
||||
|
||||
@ -85,8 +85,6 @@ machine1$ bitcoin-cli -named createmultisig nrequired=2 keys='''["'$pubkey1'","0
|
||||
"descriptor": "sh(multi(2,02da2f10746e9778dd57bd0276a4f84101c4e0a711f9cfd9f09cde55acbdd2d191,02bfde48be4aa8f4bf76c570e98a8d287f9be5638412ab38dede8e78df82f33fa3))#0pazcr4y"
|
||||
}
|
||||
```
|
||||
> :warning: **VERSION WARNING:** Some versions of `createmultisig` have allowed entry of public keys or addresses, some have required public keys only. Currently, either one seems to be allowed.
|
||||
|
||||
When creating the multisignature address, you list how many signatures are required with the `nrequired` argument (that's "m" in a "m-of-n" multisignature), then you list the total set of possible signatures with the `keys` argument (that's "n"). Note that the the `keys` entries likely came from different places. In this case, we included `$pubkey1` from the local machine and `02bfde48be4aa8f4bf76c570e98a8d287f9be5638412ab38dede8e78df82f33fa3` from a remote machine.
|
||||
|
||||
> :information_source: **NOTE — M-OF-N VS N-OF-N:** This example shows the creation of a simple 2-of-2 multisig. If you instead want to create an m-of-n signature where "m < n", you adjust the `nrequired` field and/or the number of signatures in the `keys` JSON object. For a 1-of-2 multisig, you'd set `nrequired=1` and also list two keys, while for a 2-of-3 multisig, you'd leave `nrequired=2`, but add one more public key to the `keys` listing.
|
||||
@ -141,8 +139,6 @@ If you look at the `desc`riptor for the multisig that you created above, you'll
|
||||
```
|
||||
However, if it imports an address with type `sortedmulti`, it'll do the right thing, which is the whole point of descriptors!
|
||||
|
||||
> :warning: **VERSION WARNING:** Bitcoin Core only understands the `sortedmulti` descriptor function beginning with v 0.20.0. Try and access the descriptor on an earlier version of Bitcoin Core and you'll get an error such as `A function is needed within P2WSH`.
|
||||
|
||||
## Send to a Multisig Address
|
||||
|
||||
If you've got a multisignature in a convenient P2SH format, like the one generated by `bitcoin-cli`, it can be sent to exactly like a normal address.
|
||||
|
||||
@ -6,8 +6,6 @@ TODO:
|
||||
|
||||
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.
|
||||
|
||||
> :warning: **VERSION WARNING:** The `addmultisigaddress` command is available in Bitcoin Core v 0.10 or higher.
|
||||
|
||||
## Create a Multisig Address in Your Wallet
|
||||
|
||||
In order to make funds sent to multisig addresses easier to spend, you just need to do some prep using the `addmultisigaddress` command. It's probably not what you'd want to do if you were writing multisig wallet programs, but if you were just trying to receive some funds by hand, it might save you some hair-pulling.
|
||||
|
||||
@ -4,8 +4,6 @@
|
||||
|
||||
Partially Signed Bitcoin Transactions (PSBTs) are the newest way to vary the creation of basic Bitcoin transactions. They do so by introducing collaboration into every step of the process, allowing people (or programs) to not just authenticate transactions together (as with multisigs), but also to easily create, fund, and broadcast collaboratively.
|
||||
|
||||
> :warning: **VERSION WARNING:** This is an innovation from Bitcoin Core v 0.17.0. Earlier versions of Bitcoin Core will not be able to work with the PSBT while it is in progress (though they will still be able to recognize the final transaction). Some updates and upgrades for PSBTs have continued through 0.20.0.
|
||||
|
||||
## Understand How PSBTs Work
|
||||
|
||||
Multisignatures were great for the very specific case of jointly holding funds and setting rules for whom among the joint signers could authenticate the use of those funds. There are many use cases, such as: a spousal joint bank account (a 1-of-2 signature); a fiduciary requirement for dual control (a 2-of-2 signature); and an escrow (a 2-of-3 signature).
|
||||
|
||||
@ -6,8 +6,6 @@ Now that you've learned the basic workflow of generating a PSBT, you probably wa
|
||||
|
||||
Following are three examples of using PSBTs for: multi-sigs, pooling money, and joining coins.
|
||||
|
||||
> :warning: **VERSION WARNING:** This is an innovation from Bitcoin Core v 0.17.0. Earlier versions of Bitcoin Core will not be able to work with the PSBT while it is in progress (though they will still be able to recognize the final transaction).
|
||||
|
||||
## Use a PSBT to Spend MultiSig Funds
|
||||
|
||||
Assume you've created a multisig address, just like you did in [§6.3](06_3_Sending_an_Automated_Multisig.md).
|
||||
|
||||
@ -8,8 +8,6 @@ One of the greatest powers of PSBTs is the ability to hand transactions off to h
|
||||
|
||||
You have three options for moving through this chapter on hardware wallets: (1) read along without testing the code; (2) install Bitcoin on a local machine to fully test these commands; or (3) skip straight ahead to [Chapter 8: Expanding Bitcoin Transactions in Other Ways](08_0_Expanding_Bitcoin_Transactions_Other.md). We suggest option #1, but if you really want to get your hands dirty we'll also give some support for #2 by talking about using a Macintosh (a hardware-platform supported by [Bitcoin Standup](https://github.com/BlockchainCommons/Bitcoin-Standup)) for testing.
|
||||
|
||||
> :warning: **VERSION WARNING:** PSBTs are an innovation from Bitcoin Core v 0.17.0. Earlier versions of Bitcoin Core will not be able to work with the PSBT while it is in progress (though they will still be able to recognize the final transaction). The HWI interface appeared in Bitcoin Core v 0.18.0, but as long as you are using our suggested setup with Bitcoin Standup, it should work.
|
||||
|
||||
The methodology described in this chapter for integrating with a hardware wallet depends on the [Bitcoin Hardware Wallet Interface](https://github.com/bitcoin-core/HWI) released through Bitcoin Core and builds on the [installation](https://github.com/bitcoin-core/HWI/blob/master/README.md) and [usage](https://hwi.readthedocs.io) instructions found there.
|
||||
|
||||
> :warning: **FRESHNESS WARNING:** The HWI interface is very new and raw around the edges as of Bitcoin Core v 0.20.0. It may be hard to install correctly, and it may have unintuitive errors. What follows is a description of a working setup, but it took several tries to get it right, and your setup may vary.
|
||||
|
||||
@ -15,8 +15,6 @@ Here's the gotcha for using Bitcoin Scripts: for security reasons, most Bitcoin
|
||||
|
||||
So how do you write a more complex Bitcoin Script? The answer is in that last sort of standard transaction, the P2SH. You can put any sort of long and complex script into a P2SH transaction, and as long as you follow the standard rules for embedding your script and for redeeming the funds, you'll get the full benefits of Bitcoin Scripting.
|
||||
|
||||
> :warning: **VERSION WARNING:** Arbitrary P2SH scripts only became standard as of Bitcoin Core 0.10.0. Before that, only P2SH Multisigs were allowed.
|
||||
|
||||
## Understand the P2SH Script
|
||||
|
||||
You already saw a P2SH transaction when you created a multisig in [§6.1: Sending a Transaction to a Multisig](06_1_Sending_a_Transaction_to_a_Multisig.md). Though multisig is one of the standard transaction types, `bitcoin-cli` simplifies the usage of its multisigs by embedding them into P2SH transactions, as described more fully in [§10.4: Scripting a Multisig](10_4_Scripting_a_Multisig.md).
|
||||
|
||||
@ -2,8 +2,6 @@
|
||||
|
||||
`OP_CHECKLOCKTIMEVERIFY` (or CLTV) is the natural complement to `nLockTime`. It moves the idea of locking transactions by an absolute time or blockheight into the realm of opcodes, allowing for the locking of individual UTXOs.
|
||||
|
||||
> :warning: **VERSION WARNING:** CLTV became available with Bitcoin Core 0.11.2, but should be fairly widely deployed at this time.
|
||||
|
||||
## Remember nLockTime
|
||||
|
||||
Before digging into CLTV, we should first recall how `nLockTime` works.
|
||||
|
||||
@ -2,8 +2,6 @@
|
||||
|
||||
`nLockTime` and `OP_CHECKLOCKTIMEVERIFY` (or CLTV) are just one side of the timelock equation. On the other side are `nSequence` and `OP_CHECKSEQUENCEVERIFY`, which can be used to check against relative times rather than absolute times.
|
||||
|
||||
> :warning: **VERSION WARNING:** CSV became available with Bitcoin Core 0.12.1, in spring 2016.
|
||||
|
||||
## Understand nSequence
|
||||
|
||||
Every input into a transaction has an `nSequence` (or if you prefer `sequence`) value. It's been a prime tool for Bitcoin expansions as discussed previously in [§5.2: Resending a Transaction with RBF](05_2_Resending_a_Transaction_with_RBF.md) and [§8.1 Sending a Transaction with a Locktime](08_1_Sending_a_Transaction_with_a_Locktime.md), where it was used to signal RBF and `nLockTime`, respectively. However, there's one more use for `nSequence`, described by [BIP 68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki): you can use it to create a relative timelock on a transaction.
|
||||
|
||||
6
TODO.md
6
TODO.md
@ -4,13 +4,13 @@ The following TODO items are intended for a 3.0 version of Learning Bitcoin from
|
||||
|
||||
## Immediate TODO (for 2/5): Descriptor Wallets
|
||||
|
||||
1. Edit §3.1-3.2, esp. for any references to legacy addresses
|
||||
1. <strike>Edit §3.1-3.2, esp. for any references to legacy addresses</strike> (Still need to update `bitcoin-cli -getinfo` command)
|
||||
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
|
||||
6. <strike>Remove all references to things appearing at certain versions (they're all pretty standardized now)</strike>
|
||||
7. <strike>But write a note early on about potential missing features</strike>
|
||||
|
||||
## Immediate TODO (for 2/19): Segwit
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user