line breaks and ce check2

develop
Clare Laylock 7 months ago
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++&#x27;++/0++&#x27;++/0++&#x27;++/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&#x2014;Function GetBlockSubsidy, Bitcoin Core Client, main.cpp
.Calculating the block reward&#x2014;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&#x2014;CalculateNextWorkRequired() in pow.cpp
.Retargeting the Proof-of-Work&#x2014;[.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 youre 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 OReilly 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 products 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 (OReilly). 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 (OReilly). 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…
Cancel
Save