mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2025-02-22 12:32:06 +00:00
line breaks and ce check2
This commit is contained in:
Clare Laylock
parent
3a58689799
commit
731fe75319
@ -575,9 +575,9 @@ $ bitcoind -printtoconsole
|
||||
2023-01-28T03:43:39Z Config file arg: [main] txindex="1"
|
||||
2023-01-28T03:43:39Z Setting file arg: wallet = ["msig0"]
|
||||
2023-01-28T03:43:39Z Command-line arg: printtoconsole=""
|
||||
2023-01-28T03:43:39Z Using at most 125 automatic connections (1024 file descriptors available)
|
||||
2023-01-28T03:43:39Z Using 16 MiB out of 16 MiB requested for signature cache, able to store 524288 elements
|
||||
2023-01-28T03:43:39Z Using 16 MiB out of 16 MiB requested for script execution cache, able to store 524288 elements
|
||||
2023-01-28T03:43:39Z Using at most 125 automatic connections
|
||||
2023-01-28T03:43:39Z Using 16 MiB out of 16 MiB requested for signature cache
|
||||
2023-01-28T03:43:39Z Using 16 MiB out of 16 MiB requested for script execution
|
||||
2023-01-28T03:43:39Z Script verification uses 3 additional threads
|
||||
2023-01-28T03:43:39Z scheduler thread start
|
||||
2023-01-28T03:43:39Z [http] creating work queue of depth 16
|
||||
@ -612,13 +612,13 @@ $ bitcoin-cli getblockchaininfo
|
||||
"chain": "main",
|
||||
"blocks": 0,
|
||||
"headers": 83999,
|
||||
"bestblockhash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
|
||||
"bestblockhash": "[...]19d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
|
||||
"difficulty": 1,
|
||||
"time": 1673379796,
|
||||
"mediantime": 1231006505,
|
||||
"verificationprogress": 3.783041623201835e-09,
|
||||
"initialblockdownload": true,
|
||||
"chainwork": "0000000000000000000000000000000000000000000000000000000100010001",
|
||||
"chainwork": "[...]000000000000000000000000000000000000000000000100010001",
|
||||
"size_on_disk": 89087,
|
||||
"pruned": false,
|
||||
"warnings": ""
|
||||
@ -680,7 +680,8 @@ Result:
|
||||
|
||||
Examples:
|
||||
> bitcoin-cli getblockhash 1000
|
||||
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "getblockhash", "params": [1000]}' -H 'content-type: text/plain;' http://127.0.0.1:8332/
|
||||
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest",
|
||||
"method": "getblockhash", "params": [1000]}' -H 'content-type: text/plain;' http://127.0.0.1:8332/
|
||||
----
|
||||
|
||||
At the end of the help information you will see two examples of the RPC
|
||||
@ -735,7 +736,7 @@ $ bitcoin-cli getnetworkinfo
|
||||
"connections_in": 0,
|
||||
"connections_out": 10,
|
||||
"networks": [
|
||||
"...detailed information about all networks (ipv4, ipv6, onion, i2p, and cjdns)..."
|
||||
"...detailed information about all networks..."
|
||||
],
|
||||
"relayfee": 0.00001000,
|
||||
"incrementalfee": 0.00001000,
|
||||
@ -918,16 +919,16 @@ f6cd83c3ca
|
||||
"height": 123456,
|
||||
"version": 1,
|
||||
"versionHex": "00000001",
|
||||
"merkleroot": "0e60651a9934e8f0decd1c5fde39309e48fca0cd1c84a21ddfde95033762d86c",
|
||||
"merkleroot": "0e60651a9934e8f0decd1c[...]48fca0cd1c84a21ddfde95033762d86c",
|
||||
"time": 1305200806,
|
||||
"mediantime": 1305197900,
|
||||
"nonce": 2436437219,
|
||||
"bits": "1a6a93b3",
|
||||
"difficulty": 157416.4018436489,
|
||||
"chainwork": "000000000000000000000000000000000000000000000000541788211ac227bc",
|
||||
"chainwork": "[...]00000000000000000000000000000000000000541788211ac227bc",
|
||||
"nTx": 13,
|
||||
"previousblockhash": "0000000000000b60bc96a44724fd72daf9b92cf8ad00510b5224c6253ac40095",
|
||||
"nextblockhash": "000000000000129f5f02be247070bf7334d3753e4ddee502780c2acaecec6d66",
|
||||
"previousblockhash": "[...]000b60bc96a44724fd72daf9b92cf8ad00510b5224c6253ac40095",
|
||||
"nextblockhash": "[...]00129f5f02be247070bf7334d3753e4ddee502780c2acaecec6d66",
|
||||
"strippedsize": 4179,
|
||||
"size": 4179,
|
||||
"weight": 16716,
|
||||
@ -982,7 +983,8 @@ showed us an example of using +curl+, the versatile command-line HTTP
|
||||
client to construct one of these JSON-RPC calls:
|
||||
|
||||
----
|
||||
$ curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getblockchaininfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
|
||||
$ curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest",
|
||||
"method": "getblockchaininfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
|
||||
----
|
||||
|
||||
This command shows that +curl+ submits an HTTP request to the local host
|
||||
@ -1004,9 +1006,11 @@ any higher-level Bitcoin Core RPC wrappers), as seen in <<cookie_auth>>.
|
||||
$ cat .bitcoin/.cookie
|
||||
__cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0
|
||||
|
||||
$ curl --user __cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getblockchaininfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
|
||||
$ curl
|
||||
--user __cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0 --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getblockchaininfo", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
|
||||
|
||||
{"result":{"chain":"main","blocks":799278,"headers":799278,"bestblockhash":"000000000000000000018387c50988ec705a95d6f765b206b6629971e6978879","difficulty":53911173001054.59,"time":1689703111,"mediantime":1689701260,"verificationprogress":0.9999979206082515,"initialblockdownload":false,"chainwork":"00000000000000000000000000000000000000004f3e111bf32bcb47f9dfad5b","size_on_disk":563894577967,"pruned":false,"warnings":""},"error":null,"id":"curltest"}
|
||||
{"result":{"chain":"main","blocks":799278,"headers":799278,
|
||||
"bestblockhash":"000000000000000000018387c50988ec705a95d6f765b206b6629971e6978879","difficulty":53911173001054.59,"time":1689703111,"mediantime":1689701260,"verificationprogress":0.9999979206082515,"initialblockdownload":false,"chainwork":"00000000000000000000000000000000000000004f3e111bf32bcb47f9dfad5b","size_on_disk":563894577967,"pruned":false,"warnings":""},"error":null,"id":"curltest"}
|
||||
----
|
||||
====
|
||||
|
||||
|
||||
@ -215,8 +215,11 @@ image::images/mbc3_0403.png["ecc-over-F17-math"]
|
||||
So, for example, the following is a point P with coordinates (x,y) that
|
||||
is a point on the +secp256k1+ curve:
|
||||
|
||||
[source, python]
|
||||
----
|
||||
P = (55066263022277343669578718895168534326250603453777594175500187360389116729240, 32670510020758816978083085130507043184471273380659243275938904335757337482424)
|
||||
P =
|
||||
(55066263022277343669578718895168534326250603453777594175500187360389116729240,
|
||||
32670510020758816978083085130507043184471273380659243275938904335757337482424)
|
||||
----
|
||||
|
||||
<<example_4_1>> shows how you can check this yourself using Python.
|
||||
@ -228,9 +231,9 @@ P = (550662630222773436695787188951685343262506034537775941755001873603891167292
|
||||
----
|
||||
Python 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] on linux
|
||||
Type "help", "copyright", "credits" or "license" for more information.
|
||||
>>> p = 115792089237316195423570985008687907853269984665640564039457584007908834671663
|
||||
>>> x = 55066263022277343669578718895168534326250603453777594175500187360389116729240
|
||||
>>> y = 32670510020758816978083085130507043184471273380659243275938904335757337482424
|
||||
> p = 115792089237316195423570985008687907853269984665640564039457584007908834671663
|
||||
> x = 55066263022277343669578718895168534326250603453777594175500187360389116729240
|
||||
> y = 32670510020758816978083085130507043184471273380659243275938904335757337482424
|
||||
>>> (x ** 3 + 7 - y**2) % p
|
||||
0
|
||||
----
|
||||
@ -339,6 +342,7 @@ Implementing the elliptic curve multiplication, we take the private key
|
||||
_k_ generated previously and multiply it with the generator point G to
|
||||
find the public key _K_:
|
||||
|
||||
[source="python"]
|
||||
----
|
||||
K = 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD * G
|
||||
----
|
||||
@ -689,6 +693,7 @@ version prefixes and the resulting base58 characters are shown in
|
||||
[[base58check_versions]]
|
||||
.Base58check version prefix and encoded result examples
|
||||
[options="header"]
|
||||
[cols="1,1,1"]
|
||||
|=======
|
||||
|Type| Version prefix (hex)| Base58 result prefix
|
||||
| Address for pay to public key hash (P2PKH) | 0x00 | 1
|
||||
@ -1233,6 +1238,7 @@ scripts are listed in <<scripts_for_diff_segwit_outputs>>.
|
||||
[[scripts_for_diff_segwit_outputs]]
|
||||
.Scripts for different types of segwit outputs
|
||||
[options="header"]
|
||||
[cols="1,1"]
|
||||
|===
|
||||
|
||||
|Output type
|
||||
@ -1280,8 +1286,8 @@ library for Python to quickly generate those addresses, and then take a
|
||||
deeper look at what's happening:
|
||||
|
||||
----
|
||||
$ wget https://raw.githubusercontent.com/sipa/bech32/master/ref/python/segwit_addr.py
|
||||
2023-01-30 11:59:10 (46.3 MB/s) - ‘segwit_addr.py’ saved [5022/5022]
|
||||
$ github="https://raw.githubusercontent.com"
|
||||
$ wget $github//sipa/bech32/master/ref/python/segwit_addr.py
|
||||
|
||||
$ python
|
||||
>>> from segwit_addr import *
|
||||
@ -1293,9 +1299,11 @@ encode(hrp, witver, witprog)
|
||||
|
||||
>>> encode('bc', 0, unhexlify('2b626ed108ad00a944bb2922a309844611d25468'))
|
||||
'bc1q9d3xa5gg45q2j39m9y32xzvygcgay4rgc6aaee'
|
||||
>>> encode('bc', 0, unhexlify('648a32e50b6fb7c5233b228f60a6a2ca4158400268844c4bc295ed5e8c3d626f'))
|
||||
>>> encode('bc', 0,
|
||||
unhexlify('648a32e50b6fb7c5233b228f60a6a2ca4158400268844c4bc295ed5e8c3d626f'))
|
||||
'bc1qvj9r9egtd7mu2gemy28kpf4zefq4ssqzdzzycj7zjhk4arpavfhsct5a3p'
|
||||
>>> encode('bc', 1, unhexlify('2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311'))
|
||||
>>> encode('bc', 1,
|
||||
unhexlify('2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311'))
|
||||
'bc1p9nh05ha8wrljf7ru236awm4t2x0d5ctkkywmu9sclnm4t0av2vgs4k3au7'
|
||||
>>> encode('bc', 16, unhexlify('0000'))
|
||||
'bc1sqqqqkfw08p'
|
||||
@ -1328,9 +1336,11 @@ use the reference library to decode two of our addresses:
|
||||
decode(hrp, addr)
|
||||
Decode a segwit address.
|
||||
|
||||
>>> _ = decode("bc", "bc1q9d3xa5gg45q2j39m9y32xzvygcgay4rgc6aaee"); _[0], bytes(_[1]).hex()
|
||||
>>> _ = decode("bc", "bc1q9d3xa5gg45q2j39m9y32xzvygcgay4rgc6aaee")
|
||||
>>> _[0], bytes(_[1]).hex()
|
||||
(0, '2b626ed108ad00a944bb2922a309844611d25468')
|
||||
>>> _ = decode("bc", "bc1p9nh05ha8wrljf7ru236awm4t2x0d5ctkkywmu9sclnm4t0av2vgs4k3au7"); _[0], bytes(_[1]).hex()
|
||||
>>> _ = decode("bc", "bc1p9nh05ha8wrljf7ru236awm4t2x0d5ctkkywmu9sclnm4t0av2vgs4k3au7")
|
||||
>>> _[0], bytes(_[1]).hex()
|
||||
(1, '2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311')
|
||||
----
|
||||
|
||||
@ -1404,6 +1414,7 @@ See <<hd_wallets>> for more information.
|
||||
[[table_4-2]]
|
||||
.Private key representations (encoding formats)
|
||||
[options="header"]
|
||||
[cols="1,1,1"]
|
||||
|=======
|
||||
|Type|Prefix|Description
|
||||
| Hex | None | 64 hexadecimal digits
|
||||
@ -1416,6 +1427,7 @@ See <<hd_wallets>> for more information.
|
||||
[[table_4-3]]
|
||||
.Example: Same key, different formats
|
||||
[options="header"]
|
||||
[cols="1,1"]
|
||||
|=======
|
||||
|Format | Private key
|
||||
| Hex | 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd
|
||||
@ -1449,6 +1461,7 @@ confusion
|
||||
[[table_4-4]]
|
||||
.Example: Same key, different formats
|
||||
[options="header"]
|
||||
[cols="1,1"]
|
||||
|=======
|
||||
|Format | Private key
|
||||
| Hex | 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD
|
||||
@ -1554,6 +1567,7 @@ search approximately 100,000 keys per second.
|
||||
[[table_4-12]]
|
||||
.The frequency of a vanity pattern (1KidsCharity) and average search time on a desktop PC
|
||||
[options="header"]
|
||||
[cols="1,1,1,1"]
|
||||
|=======
|
||||
| Length | Pattern | Frequency | Average search time
|
||||
| 1 | 1K | 1 in 58 keys | < 1 milliseconds
|
||||
@ -1635,7 +1649,7 @@ with a "back door." Many bitcoins have been stolen this way. Paper
|
||||
wallets are shown here for informational purposes only and should not be
|
||||
used for storing bitcoin. Use a recovery code to back up your
|
||||
keys, possibly with a hardware signing device to store keys and sign transactions. DO NOT
|
||||
USE PAPER WALLETS.
|
||||
USE PAPER [.keep-together]#WALLETS.#
|
||||
====
|
||||
|
||||
|
||||
|
||||
@ -432,6 +432,7 @@ an example, see <<alice_tx_labels>>.
|
||||
[[alice_tx_labels]]
|
||||
.Alice's transaction history with each transaction labeled
|
||||
[options="header"]
|
||||
[cols="1,1,1"]
|
||||
|===
|
||||
| Date | Label | BTC
|
||||
| 2023-01-01 | Bought bitcoins from Joe | +0.00100
|
||||
@ -514,6 +515,7 @@ paths_. Several popular implicit paths defined by BIPs are shown in <<bip_implic
|
||||
[[bip_implicit_paths]]
|
||||
.Implicit script paths defined by various BIPs
|
||||
[options="header"]
|
||||
[cols="1,1,1"]
|
||||
|===
|
||||
| Standard | Script | BIP32 path
|
||||
| BIP44 | P2PKH | +m/44'/0'/0'+
|
||||
@ -691,6 +693,7 @@ data and the length of recovery code in words.
|
||||
[[table_4-5]]
|
||||
.BIP39: entropy and word length
|
||||
[options="header"]
|
||||
[cols="1,1,1,1"]
|
||||
|=======
|
||||
|Entropy (bits) | Checksum (bits) | Entropy *+* checksum (bits) | Recovery code words
|
||||
| 128 | 4 | 132 | 12
|
||||
@ -776,8 +779,8 @@ some examples of recovery codes and the seeds they produce.
|
||||
| *Entropy input (128 bits)*| +0c1e24e5917779d297e14d45f14e1a1a+
|
||||
| *Recovery Code (12 words)* | +army van defense carry jealous true garbage claim echo media make crunch+
|
||||
| *Passphrase*| (none)
|
||||
| *Seed (512 bits)* | +5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4c67196f57c39+
|
||||
+a88b76373733891bfaba16ed27a813ceed498804c0570+
|
||||
| *Seed (512 bits)* | +5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4+
|
||||
+c67196f57c39a88b76373733891bfaba16ed27a813ceed498804c0570+
|
||||
|=======
|
||||
|
||||
[[bip39_128_w_pass]]
|
||||
@ -787,8 +790,8 @@ some examples of recovery codes and the seeds they produce.
|
||||
| *Entropy input (128 bits)*| +0c1e24e5917779d297e14d45f14e1a1a+
|
||||
| *Recovery Code (12 words)* | +army van defense carry jealous true garbage claim echo media make crunch+
|
||||
| *Passphrase*| SuperDuperSecret
|
||||
| *Seed (512 bits)* | +3b5df16df2157104cfdd22830162a5e170c0161653e3afe6c88defeefb0818c793dbb28ab3ab091897d0+
|
||||
+715861dc8a18358f80b79d49acf64142ae57037d1d54+
|
||||
| *Seed (512 bits)* | +3b5df16df2157104cfdd22830162a5e170c0161653e3afe6c88defeefb0818c793dbb28+
|
||||
+ab3ab091897d0715861dc8a18358f80b79d49acf64142ae57037d1d54+
|
||||
|=======
|
||||
|
||||
|
||||
@ -800,8 +803,8 @@ some examples of recovery codes and the seeds they produce.
|
||||
| *Recovery Code (24 words)* | +cake apple borrow silk endorse fitness top denial coil riot stay wolf
|
||||
luggage oxygen faint major edit measure invite love trap field dilemma oblige+
|
||||
| *Passphrase*| (none)
|
||||
| *Seed (512 bits)* | +3269bce2674acbd188d4f120072b13b088a0ecf87c6e4cae41657a0bb78f5315b33b3a04356e53d062e5+
|
||||
+5f1e0deaa082df8d487381379df848a6ad7e98798404+
|
||||
| *Seed (512 bits)* | +3269bce2674acbd188d4f120072b13b088a0ecf87c6e4cae41657a0bb78f5315b33b3+
|
||||
+a04356e53d062e55f1e0deaa082df8d487381379df848a6ad7e98798404+
|
||||
|=======
|
||||
|
||||
.How Much Entropy Do You Need?
|
||||
@ -1038,13 +1041,15 @@ seen previously.
|
||||
Here's an example of an extended _private_ key, encoded in base58check:
|
||||
|
||||
----
|
||||
xprv9tyUQV64JT5qs3RSTJkXCWKMyUgoQp7F3hA1xzG6ZGu6u6Q9VMNjGr67Lctvy5P8oyaYAL9CAWrUE9i6GoNMKUga5biW6Hx4tws2six3b9c
|
||||
xprv9tyUQV64JT5qs3RSTJkXCWKMyUgoQp7F3hA1xzG6ZGu6u6Q9VMNjGr67Lctvy5P8oyaYAL9CA
|
||||
WrUE9i6GoNMKUga5biW6Hx4tws2six3b9c
|
||||
----
|
||||
|
||||
Here's the corresponding extended _public_ key, encoded in base58check:
|
||||
|
||||
----
|
||||
xpub67xpozcx8pe95XVuZLHXZeG6XWXHpGq6Qv5cmNfi7cS5mtjJ2tgypeQbBs2UAR6KECeeMVKZBPLrtJunSDMstweyLXhRgPxdp14sk9tJPW9
|
||||
xpub67xpozcx8pe95XVuZLHXZeG6XWXHpGq6Qv5cmNfi7cS5mtjJ2tgypeQbBs2UAR6KECeeMVKZBPLrt
|
||||
JunSDMstweyLXhRgPxdp14sk9tJPW9
|
||||
----
|
||||
|
||||
[[public__child_key_derivation]]
|
||||
@ -1281,6 +1286,7 @@ child of key m/x, which is the x-th child of m.
|
||||
[[table_4-8]]
|
||||
.HD wallet path examples
|
||||
[options="header"]
|
||||
[cols="1,1"]
|
||||
|=======
|
||||
|HD path | Key described
|
||||
| m/0 | The first (0) child private key from the master private key (m)
|
||||
@ -1351,6 +1357,7 @@ a few more examples.
|
||||
[[table_4-9]]
|
||||
.BIP44 HD wallet structure examples
|
||||
[options="header"]
|
||||
[cols="1,1"]
|
||||
|=======
|
||||
|HD path | Key described
|
||||
| M/44++'++/0++'++/0++'++/0/2 | The third receiving public key for the primary Bitcoin account
|
||||
|
||||
@ -329,7 +329,8 @@ $ bitcoin-cli getrawtransaction \
|
||||
eb3ae38f27191aa5f3850dc9cad00492b88b72404f9da135698679268041c54a
|
||||
error code: -5
|
||||
error message:
|
||||
No such mempool or blockchain transaction. Use gettransaction for wallet transactions.
|
||||
No such mempool or blockchain transaction.
|
||||
Use gettransaction for wallet transactions.
|
||||
|
||||
$ echo eb3ae38f27191aa5f3850dc9cad00492b88b72404f9da135698679268041c54a \
|
||||
| fold -w2 | tac | tr -d "\n"
|
||||
@ -1120,8 +1121,9 @@ creation of uneconomical outputs as described in
|
||||
[[weight_factors]]
|
||||
.Weight factors for all fields in a Bitcoin transaction
|
||||
[cols="1,1,1"]
|
||||
[option="header"]
|
||||
|===
|
||||
| **Field** | **Factor** | **Weight in Alice's Tx**
|
||||
| Field | Factor | Weight in Alice's Tx
|
||||
| Version | 4 | 16
|
||||
| Marker & Flag | 1 | 2
|
||||
| Inputs Count | 4 | 4
|
||||
@ -1129,7 +1131,7 @@ creation of uneconomical outputs as described in
|
||||
| Input script | 4 | 4
|
||||
| Sequence | 4 | 16
|
||||
| Outputs Count | 4 | 4
|
||||
| Amout | 4 | 64 (2 outputs)
|
||||
| Amount | 4 | 64 (2 outputs)
|
||||
| Output script | 4 | 232 (2 outputs with different scripts)
|
||||
| Witness Count | 1 | 1
|
||||
| Witness items | 1 | 66
|
||||
|
||||
@ -486,7 +486,8 @@ controls and protects against theft, embezzlement, or loss.
|
||||
The resulting script is quite long and looks like this:
|
||||
|
||||
----
|
||||
2 <Mohammed's Public Key> <Partner1 Public Key> <Partner2 Public Key> <Partner3 Public Key> <Attorney Public Key> 5 OP_CHECKMULTISIG
|
||||
2 <Mohammed's Public Key> <Partner1 Public Key> <Partner2 Public Key>
|
||||
<Partner3 Public Key> <Attorney Public Key> 5 OP_CHECKMULTISIG
|
||||
----
|
||||
|
||||
Although multisignature scripts are a powerful feature, they are
|
||||
@ -548,16 +549,8 @@ First, the multisignature script that Mohammed's company uses for all
|
||||
incoming payments from customers:
|
||||
|
||||
----
|
||||
2 <Mohammed's Public Key> <Partner1 Public Key> <Partner2 Public Key> <Partner3 Public Key> <Attorney Public Key> 5 OP_CHECKMULTISIG
|
||||
----
|
||||
|
||||
If the placeholders are replaced by actual public keys (shown here as
|
||||
520-bit numbers starting with 04) you can see that this script becomes
|
||||
very long:
|
||||
|
||||
----
|
||||
2
|
||||
04C16B8698A9ABF84250A7C3EA7EEDEF9897D1C8C6ADF47F06CF73370D74DCCA01CDCA79DCC5C395D7EEC6984D83F1F50C900A24DD47F569FD4193AF5DE762C58704A2192968D8655D6A935BEAF2CA23E3FB87A3495E7AF308EDF08DAC3C1FCBFC2C75B4B0F4D0B1B70CD2423657738C0C2B1D5CE65C97D78D0E34224858008E8B49047E63248B75DB7379BE9CDA8CE5751D16485F431E46117B9D0C1837C9D5737812F393DA7D4420D7E1A9162F0279CFC10F1E8E8F3020DECDBC3C0DD389D99779650421D65CBD7149B255382ED7F78E946580657EE6FDA162A187543A9D85BAAA93A4AB3A8F044DADA618D087227440645ABE8A35DA8C5B73997AD343BE5C2AFD94A5043752580AFA1ECED3C68D446BCAB69AC0BA7DF50D56231BE0AABF1FDEEC78A6A45E394BA29A1EDF518C022DD618DA774D207D137AAB59E0B000EB7ED238F4D800 5 OP_CHECKMULTISIG
|
||||
2 <Mohammed's Public Key> <Partner1 Public Key> <Partner2 Public Key>
|
||||
<Partner3 Public Key> <Attorney Public Key> 5 OP_CHECKMULTISIG
|
||||
----
|
||||
|
||||
This entire script can instead be represented by a 20-byte cryptographic
|
||||
@ -592,7 +585,7 @@ The two scripts are combined in two stages. First, the redeem script is
|
||||
checked against the output script to make sure the hash matches:
|
||||
|
||||
----
|
||||
<2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG> OP_HASH160 <redeem script hash> OP_EQUAL
|
||||
<2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG> OP_HASH160 <script hash> OP_EQUAL
|
||||
----
|
||||
|
||||
If the redeem script hash matches, the redeem script is executed:
|
||||
@ -1261,7 +1254,8 @@ output script:
|
||||
|
||||
.Example P2PKH output script
|
||||
----
|
||||
OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 OP_EQUALVERIFY OP_CHECKSIG
|
||||
OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7
|
||||
OP_EQUALVERIFY OP_CHECKSIG
|
||||
----
|
||||
|
||||
With segregated witness, Alice would create a
|
||||
|
||||
@ -126,6 +126,7 @@ in <<sighash_types_and_their>>.
|
||||
[[sighash_types_and_their]]
|
||||
.[.plain]#++SIGHASH++# types and their meanings
|
||||
[options="header"]
|
||||
[cols="1,1,1"]
|
||||
|=======================
|
||||
|++SIGHASH++ flag| Value | Description
|
||||
| ++ALL++ | ++0x01++ | Signature applies to all inputs and outputs
|
||||
@ -143,6 +144,7 @@ in <<sighash_types_with_modifiers>>.
|
||||
[[sighash_types_with_modifiers]]
|
||||
.[.plain]#++SIGHASH++# types with modifiers and their meanings
|
||||
[options="header"]
|
||||
[cols="1,1,1"]
|
||||
|=======================
|
||||
|++SIGHASH++ flag| Value | Description
|
||||
| ++ALL\|ANYONECANPAY++ | ++0x81++ | Signature applies to one input and all outputs
|
||||
@ -858,7 +860,8 @@ Let's look at
|
||||
the following DER-encoded signature:
|
||||
|
||||
----
|
||||
3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e381301
|
||||
3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204
|
||||
b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e381301
|
||||
----
|
||||
|
||||
That signature is a serialized byte stream of the +R+ and +S+ values
|
||||
|
||||
@ -270,7 +270,7 @@ information, including:
|
||||
+nTime+:: The current time
|
||||
+addrYou+:: The IP address of the remote node as seen from this node
|
||||
+addrMe+:: The IP address of the local node, as discovered by the local node
|
||||
+subver+:: A subversion showing the type of software running on this [.keep-together]#node (e.g.,# pass:[<span class="keep-together"><code>/Satoshi:0.9.2.1/</code></span>])
|
||||
+subver+:: A subversion showing the type of software running on this node (e.g., [.keep-together]#+/Satoshi:0.9.2.1/+#)
|
||||
+BestHeight+:: The block height of this node's blockchain
|
||||
+fRelay+:: A field added by BIP37 for requesting not to receive unconfirmed transactions
|
||||
|
||||
@ -945,11 +945,15 @@ Our primary goal is to allow wallets to learn whether a block contains a
|
||||
transaction affecting that wallet. For a wallet to be effective, it
|
||||
needs to learn two types of information:
|
||||
|
||||
* When it has received money. Specifically, when a transaction
|
||||
When it has received money::
|
||||
|
||||
Specifically, when a transaction
|
||||
output contains a script that the wallet controls (such as by
|
||||
controlling the authorized private key).
|
||||
|
||||
* When it has spent money. Specifically, when a transaction input
|
||||
When it has spent money::
|
||||
|
||||
Specifically, when a transaction input
|
||||
references a previous transaction output that the wallet controlled.
|
||||
|
||||
A secondary goal during the design of compact block filters was to allow
|
||||
|
||||
@ -80,6 +80,7 @@ header. <<block_structure1>> describes how Bitcoin Core stores the structure of
|
||||
[[block_structure1]]
|
||||
.The structure of a block
|
||||
[options="header"]
|
||||
[cols="1,1,1"]
|
||||
|=======
|
||||
|Size| Field | Description
|
||||
| 4 bytes | Block Size | The size of the block, in bytes, following this field
|
||||
@ -97,6 +98,7 @@ block metadata as shown in <<block_header_structure_ch09>>.
|
||||
[[block_header_structure_ch09]]
|
||||
.The structure of the block header
|
||||
[options="header"]
|
||||
[cols="1,1,1"]
|
||||
|=======
|
||||
|Size| Field | Description
|
||||
| 4 bytes | Version | Originally a version field; its use has evolved over time
|
||||
@ -119,8 +121,8 @@ block header twice through the SHA256 algorithm. The resulting 32-byte
|
||||
hash is called the _block hash_ but is more accurately the _block header
|
||||
hash_, pass:[<span class="keep-together">because only the block header is
|
||||
used to compute it. For example,</span>]
|
||||
+000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f+ [.keep-together]#is
|
||||
the block# hash of the first block on Bitcoin's blockchain. The block hash
|
||||
+000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f+ is
|
||||
the block hash of the first block on Bitcoin's blockchain. The block hash
|
||||
identifies a block uniquely and unambiguously and can be independently
|
||||
derived by any node by simply hashing the block header.
|
||||
|
||||
@ -203,7 +205,8 @@ https://blockstream.info/block/000000000019d6689c085ae165831e934ff763ae46a2a6c17
|
||||
Alternatively, you can get the block using Bitcoin Core on the command line:
|
||||
|
||||
----
|
||||
$ bitcoin-cli getblock 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
|
||||
$ bitcoin-cli getblock \
|
||||
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
|
||||
----
|
||||
[source,json]
|
||||
----
|
||||
@ -213,15 +216,15 @@ $ bitcoin-cli getblock 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60
|
||||
"height": 0,
|
||||
"version": 1,
|
||||
"versionHex": "00000001",
|
||||
"merkleroot": "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b",
|
||||
"merkleroot": "4a5e1e4baab89f3a32518a88c3[...]76673e2cc77ab2127b7afdeda33b",
|
||||
"time": 1231006505,
|
||||
"mediantime": 1231006505,
|
||||
"nonce": 2083236893,
|
||||
"bits": "1d00ffff",
|
||||
"difficulty": 1,
|
||||
"chainwork": "0000000000000000000000000000000000000000000000000000000100010001",
|
||||
"chainwork": "[...]000000000000000000000000000000000000000000000100010001",
|
||||
"nTx": 1,
|
||||
"nextblockhash": "00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048",
|
||||
"nextblockhash": "00000000839a8e6886ab5951d7[...]8afc90947ee320161bbf18eb6048",
|
||||
"strippedsize": 285,
|
||||
"size": 285,
|
||||
"weight": 1140,
|
||||
@ -560,11 +563,11 @@ $ bitcoin-cli -testnet getblockchaininfo
|
||||
"chain": "test",
|
||||
"blocks": 1088,
|
||||
"headers": 139999,
|
||||
"bestblockhash": "0000000063d29909d475a1c4ba26da64b368e56cce5d925097bf3a2084370128",
|
||||
"bestblockhash": "0000000063d29909d475a1c[...]368e56cce5d925097bf3a2084370128",
|
||||
"difficulty": 1,
|
||||
"mediantime": 1337966158,
|
||||
"verificationprogress": 0.001644065914099759,
|
||||
"chainwork": "0000000000000000000000000000000000000000000000000000044104410441",
|
||||
"chainwork": "[...]000000000000000000000000000000000000000000044104410441",
|
||||
"pruned": false,
|
||||
"softforks": [
|
||||
|
||||
@ -669,13 +672,13 @@ $ bitcoin-cli -signet getblockchaininfo
|
||||
"chain": "signet",
|
||||
"blocks": 143619,
|
||||
"headers": 143619,
|
||||
"bestblockhash": "000000c46cb3505ddd29653720686b6a3565ad1c5768e2908439382447572a93",
|
||||
"bestblockhash": "000000c46cb3505ddd296537[...]65ad1c5768e2908439382447572a93",
|
||||
"difficulty": 0.003020638517858618,
|
||||
"time": 1684530244,
|
||||
"mediantime": 1684526116,
|
||||
"verificationprogress": 0.999997961940662,
|
||||
"initialblockdownload": false,
|
||||
"chainwork": "0000000000000000000000000000000000000000000000000000019ab37d2194",
|
||||
"chainwork": "[...]000000000000000000000000000000000000000000019ab37d2194",
|
||||
"size_on_disk": 769525915,
|
||||
"pruned": false,
|
||||
"warnings": ""
|
||||
@ -716,11 +719,11 @@ $ bitcoin-cli -regtest getblockchaininfo
|
||||
"chain": "regtest",
|
||||
"blocks": 0,
|
||||
"headers": 0,
|
||||
"bestblockhash": "0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206",
|
||||
"bestblockhash": "0f9188f13cb7b2c71f2a335e3[...]beb436012afca590b1a11466e2206",
|
||||
"difficulty": 4.656542373906925e-10,
|
||||
"mediantime": 1296688602,
|
||||
"verificationprogress": 1,
|
||||
"chainwork": "0000000000000000000000000000000000000000000000000000000000000002",
|
||||
"chainwork": "[...]000000000000000000000000000000000000000000000000000002",
|
||||
"pruned": false,
|
||||
[...]
|
||||
----
|
||||
@ -734,7 +737,8 @@ $ bitcoin-cli -regtest createwallet ""
|
||||
$ bitcoin-cli -regtest getnewaddress
|
||||
bcrt1qwvfhw8pf79kw6tvpmtxyxwcfnd2t4e8v6qfv4a
|
||||
|
||||
$ bitcoin-cli -regtest generatetoaddress 500 bcrt1qwvfhw8pf79kw6tvpmtxyxwcfnd2t4e8v6qfv4a
|
||||
$ bitcoin-cli -regtest generatetoaddress 500 \
|
||||
bcrt1qwvfhw8pf79kw6tvpmtxyxwcfnd2t4e8v6qfv4a
|
||||
[
|
||||
"3153518205e4630d2800a4cb65b9d2691ac68eea99afa7fd36289cb266b9c2c0",
|
||||
"621330dd5bdabcc03582b0e49993702a8d4c41df60f729cc81d94b6e3a5b1556",
|
||||
|
||||
@ -394,7 +394,7 @@ The calculation can be seen in function +GetBlockSubsidy+ in the Bitcoin
|
||||
Core client, as shown in <<getblocksubsidy_source>>.
|
||||
|
||||
[[getblocksubsidy_source]]
|
||||
.Calculating the block reward—Function GetBlockSubsidy, Bitcoin Core Client, main.cpp
|
||||
.Calculating the block reward—Function +GetBlockSubsidy+, Bitcoin Core Client, main.cpp
|
||||
====
|
||||
[role="c_less_space"]
|
||||
[source, cpp]
|
||||
@ -407,7 +407,7 @@ CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
|
||||
return 0;
|
||||
|
||||
CAmount nSubsidy = 50 * COIN;
|
||||
// Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
|
||||
// Subsidy is cut in half every 210,000 blocks.
|
||||
nSubsidy >>= halvings;
|
||||
return nSubsidy;
|
||||
}
|
||||
@ -461,6 +461,7 @@ structure of the coinbase transaction's input.
|
||||
[[table_8-1]]
|
||||
.The structure of a "normal" transaction input
|
||||
[options="header"]
|
||||
[cols="1,1,1"]
|
||||
|=======
|
||||
|Size| Field | Description
|
||||
| 32 bytes | Transaction Hash | Pointer to the transaction containing the UTXO to be spent
|
||||
@ -473,6 +474,7 @@ structure of the coinbase transaction's input.
|
||||
[[table_8-2]]
|
||||
.The structure of a coinbase transaction input
|
||||
[options="header"]
|
||||
[cols="1,1,1"]
|
||||
|=======
|
||||
|Size| Field | Description
|
||||
| 32 bytes | Transaction Hash | All bits are zero: Not a transaction hash reference
|
||||
@ -520,6 +522,7 @@ as listed in <<block_header_structure_ch10>>.
|
||||
[[block_header_structure_ch10]]
|
||||
.The structure of the block header
|
||||
[options="header"]
|
||||
[cols="1,1,1"]
|
||||
|=======
|
||||
|Size| Field | Description
|
||||
| 4 bytes | Version | A multipurpose bitfield
|
||||
@ -533,7 +536,7 @@ as listed in <<block_header_structure_ch10>>.
|
||||
The version field was originally an integer field and was used in three
|
||||
upgrades to the Bitcoin network, those defined in BIPs 34, 66, and 65.
|
||||
Each time, the version number was incremented. Later upgrades defined
|
||||
the version field as a bitfield, called _VersionBits_, allowing up to 29
|
||||
the version field as a bitfield, called _versionbits_, allowing up to 29
|
||||
upgrades to be in progress simultaneously; see <<bip9>> for details.
|
||||
Even later, miners began using some of the versionbits as an auxiliary
|
||||
nonce field.
|
||||
@ -546,9 +549,9 @@ order, with BIP66 (strict DER) occuring before BIP65
|
||||
that order rather than sorted numerically.
|
||||
====
|
||||
|
||||
Today, the VersionBits field has no meaning unless there's an attempt to
|
||||
Today, the versionbits field has no meaning unless there's an attempt to
|
||||
upgrade the consensus protocol underway, in which case you will need to
|
||||
read its documentation to determine how it is using VersionBits.
|
||||
read its documentation to determine how it is using versionbits.
|
||||
|
||||
Next, the mining
|
||||
node needs to add the "Previous Block Hash" (also known as [.keep-together]#+prevhash+).#
|
||||
@ -664,6 +667,7 @@ Fortunately, this isn't difficult, as shown in <<sha256_example_generator_output
|
||||
|
||||
[[sha256_example_generator_output2]]
|
||||
.Simple proof-of-work implementation
|
||||
====
|
||||
----
|
||||
$ for nonce in $( seq 100 ) ; do echo "Hello, world! $nonce" | sha256sum ; done
|
||||
3194835d60e85bf7f728f3e3f4e4e1f5c752398cbcc5c45e048e4dbcae6be782 -
|
||||
@ -672,10 +676,10 @@ bfa474bbe2d9626f578d7d8c3acc1b604ec4a7052b188453565a3c77df41b79e -
|
||||
f75a100821c34c84395403afd1a8135f685ca69ccf4168e61a90e50f47552f61 -
|
||||
09cb91f8250df04a3db8bd98f47c7cecb712c99835f4123e8ea51460ccbec314 -
|
||||
----
|
||||
====
|
||||
|
||||
The phrase "Hello, World! 32" produces the hash
|
||||
+09cb91f8250df04a3db8bd98f47c7cecb712c99835f4123e8ea51460ccbec314+,
|
||||
which fits our criteria. It took 32 attempts to find it. In terms of
|
||||
The phrase "Hello, World! 32" produces the following hash, which fits our criteria:
|
||||
+09cb91f8250df04a3db8bd98f47c7cecb712c99835f4123e8ea51460ccbec314+. It took 32 attempts to find it. In terms of
|
||||
probabilities, if the output of the hash function is evenly distributed
|
||||
we would expect to find a result with a 0 as the hexadecimal prefix once
|
||||
every 16 hashes (one out of 16 hexadecimal digits 0 through F). In
|
||||
@ -854,7 +858,7 @@ resulting in a retargeting bias toward higher difficulty by 0.05%.
|
||||
<<retarget_code>> shows the code used in the Bitcoin Core client.
|
||||
|
||||
[[retarget_code]]
|
||||
.Retargeting the Proof-of-Work—CalculateNextWorkRequired() in pow.cpp
|
||||
.Retargeting the Proof-of-Work—[.plain]#++CalculateNextWorkRequired()++# in pow.cpp
|
||||
====
|
||||
[source,cpp]
|
||||
----
|
||||
@ -1824,7 +1828,7 @@ BIP34 defined a consensus rule change that required the coinbase field
|
||||
(input) of the coinbase transaction to contain the block height. Prior
|
||||
to BIP34, the coinbase could contain any arbitrary data the miners
|
||||
chose to include. After activation of BIP34, valid blocks had to
|
||||
contain a specific block-height at the beginning of the coinbase and be
|
||||
contain a specific block height at the beginning of the coinbase and be
|
||||
identified with a block version number greater than or equal to "2."
|
||||
|
||||
To signal their readiness to enforce the rules of BIP34, miners set the block
|
||||
@ -1837,21 +1841,21 @@ BIP34 defined a two-step activation mechanism, based on a rolling
|
||||
window of 1,000 blocks. A miner would signal their individual
|
||||
readiness for BIP34 by constructing blocks with "2" as the version
|
||||
number. Strictly speaking, these blocks did not yet have to comply with
|
||||
the new consensus rule of including the block-height in the coinbase
|
||||
the new consensus rule of including the block height in the coinbase
|
||||
transaction because the consensus rule had not yet been activated. The
|
||||
consensus rules activated in two steps:
|
||||
|
||||
- If 75% (750 of the most recent 1,000 blocks) are marked with version
|
||||
"2," then version "2" blocks must contain block height in the coinbase
|
||||
transaction or they are rejected as invalid. Version "1" blocks are
|
||||
still accepted by the network and do not need to contain block-height.
|
||||
still accepted by the network and do not need to contain block height.
|
||||
The old and new consensus rules coexist during this period.
|
||||
|
||||
- When 95% (950 of the most recent 1,000 blocks) are version "2," version
|
||||
"1" blocks are no longer considered valid. Version "2" blocks are
|
||||
valid only if they contain the block-height in the coinbase (as per
|
||||
valid only if they contain the block height in the coinbase (as per
|
||||
the previous threshold). Thereafter, all blocks must comply with the
|
||||
new consensus rules, and all valid blocks must contain block-height in
|
||||
new consensus rules, and all valid blocks must contain block height in
|
||||
the coinbase transaction.
|
||||
|
||||
After successful signaling and activation under the BIP34 rules, this
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
++++
|
||||
<ul class="twocolumn">
|
||||
<li>Abdussamad Abdurrazzaq [.keep-together]#(AbdussamadA)#</li>
|
||||
<li>Abdussamad Abdurrazzaq <span class="keep-together">(AbdussamadA)</span></li>
|
||||
<li>Adán SDPC (aesedepece)</li>
|
||||
<li>Akira Chiku (achiku)</li>
|
||||
<li>Alex Waters (alexwaters)</li>
|
||||
@ -117,9 +117,9 @@
|
||||
<li>Maximilian Reichel (phramz)</li>
|
||||
<li>MG-ng (MG-ng)</li>
|
||||
<li>Michalis Kargakis (kargakis)</li>
|
||||
<li>Michael C. Ippolito [.keep-together]#(michaelcippolito)#</li>
|
||||
<li>Michael C. Ippolito <span class="keep-together">(michaelcippolito)</span></li>
|
||||
<li>Michael Galero (mikong)</li>
|
||||
<li>Michael Newman [.keep-together]#(michaelbnewman)#</li>
|
||||
<li>Michael Newman <span class="keep-together">(michaelbnewman)</span></li>
|
||||
<li>Mihail Russu (MihailRussu)</li>
|
||||
<li>mikew (mikew)</li>
|
||||
<li>milansismanovic</li>
|
||||
@ -137,7 +137,7 @@
|
||||
<li>Omar Boukli-Hacene (oboukli)</li>
|
||||
<li>Óscar Nájera (Titan-C)</li>
|
||||
<li>Parzival (Parz-val)</li>
|
||||
<li>Paul Desmond Parker [.keep-together]#(sunwukonga)#</li>
|
||||
<li>Paul Desmond Parker <span class="keep-together">(sunwukonga)</span></li>
|
||||
<li>Philipp Gille (philippgille)</li>
|
||||
<li>ratijas</li>
|
||||
<li>rating89us</li>
|
||||
|
||||
@ -61,7 +61,7 @@ All the code snippets use real values and calculations where possible, so that y
|
||||
|
||||
This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.
|
||||
|
||||
We appreciate, but do not require, attribution. An attribution usually includes [.keep-together]#the title,# author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by Andreas M. Antonopoulos and David A. Harding (O’Reilly). Copyright 2024, ISBN 978-1-491-95438-6.”
|
||||
We appreciate, but do not require, attribution. An attribution usually includes [.keep-together]#the title,# author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by [.keep-together]#Andreas M.# Antonopoulos and David A. Harding (O’Reilly). Copyright 2024, ISBN 978-1-491-95438-6.”
|
||||
|
||||
Some editions of this book are offered under an open source license, such as https://creativecommons.org/licenses/by-nc/4.0/[CC-BY-NC], in which case the terms of that license apply.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user