develop
Clare Laylock 8 months ago
parent 956782a94d
commit 781fd5b87d

@ -284,7 +284,7 @@ examples.
++++ ++++
<table id="recovery_code_sample"> <table id="recovery_code_sample">
<caption><span class="label">Table 1-1. </span>Sample recovery codes</caption> <caption>Sample recovery codes</caption>
<thead> <thead>
<tr> <tr>
<th>Wallet</th> <th>Wallet</th>

@ -690,19 +690,50 @@ a base58check-encoded private key wallet import format (WIF) that starts with a
version prefixes and the resulting base58 characters are shown in version prefixes and the resulting base58 characters are shown in
<<base58check_versions>>. <<base58check_versions>>.
[[base58check_versions]] ++++
.Base58check version prefix and encoded result examples <table id="base58check_versions">
[options="header"] <caption>Base58check version prefix and encoded result examples</caption>
[cols="1,1,1"] <thead>
|======= <tr>
|Type| Version prefix (hex)| Base58 result prefix <th>Type</th>
| Address for pay to public key hash (P2PKH) | 0x00 | 1 <th>Version prefix (hex)</th>
| Address for pay to script hash (P2SH) | 0x05 | 3 <th>Base58 result prefix</th>
| Testnet Address for P2PKH | 0x6F | m or n </tr>
| Testnet Address for P2SH | 0xC4 | 2 </thead>
| Private Key WIF | 0x80 | 5, K, or L <tbody>
| BIP32 Extended Public Key | 0x0488B21E | xpub <tr>
|======= <td><p>Address for pay to public key hash (P2PKH)</p></td>
<td><p>0x00</p></td>
<td><p>1</p></td>
</tr>
<tr>
<td><p>Address for pay to script hash (P2SH)</p></td>
<td><p>0x05</p></td>
<td><p>3</p></td>
</tr>
<tr>
<td><p>Testnet Address for P2PKH</p></td>
<td><p>0x6F</p></td>
<td><p>m or n</p></td>
</tr>
<tr>
<td><p>Testnet Address for P2SH</p></td>
<td><p>0xC4</p></td>
<td><p>2</p></td>
</tr>
<tr>
<td><p>Private Key WIF</p></td>
<td><p>0x80</p></td>
<td><p>5, K, or L</p></td>
</tr>
<tr>
<td><p>BIP32 Extended Public Key</p></td>
<td><p>0x0488B21E</p></td>
<td><p>xpub</p></td>
</tr>
</tbody>
</table>
++++
Putting together public keys, hash-based commitments, and base58check Putting together public keys, hash-based commitments, and base58check
encoding, we can see the illustration of the conversion of a public key encoding, we can see the illustration of the conversion of a public key
@ -1160,21 +1191,27 @@ rules in BIP173 for creating your own HRPs, but for Bitcoin you only
need to know about the HRPs already chosen, shown in need to know about the HRPs already chosen, shown in
<<bech32_hrps_for_bitcoin>>. <<bech32_hrps_for_bitcoin>>.
[[bech32_hrps_for_bitcoin]] ++++
.Bech32 HRPs for Bitcoin <table id="bech32_hrps_for_bitcoin">
[cols="1,1"] <caption>Bech32 HRPs for Bitcoin</caption>
[options="header"] <thead>
|=== <tr>
<th>HRPs</th>
| HRPs <th>Network</th>
| Network </tr>
</thead>
| bc <tbody>
| Bitcoin mainnet <tr>
<td><p>bc</p></td>
| tb <td><p>Bitcoin mainnet</p></td>
| Bitcoin testnet </tr>
|=== <tr>
<td><p>tb</p></td>
<td><p>Bitcoin testnet</p></td>
</tr>
</tbody>
</table>
++++
The HRP is followed by a separator, the number "1." Earlier proposals The HRP is followed by a separator, the number "1." Earlier proposals
for a protocol separator used a colon but some operating systems and for a protocol separator used a colon but some operating systems and
@ -1235,27 +1272,36 @@ scripts are listed in <<scripts_for_diff_segwit_outputs>>.
// bc1sqqqqkfw08p // bc1sqqqqkfw08p
// O_16 OP_PUSH2 0000 // O_16 OP_PUSH2 0000
[[scripts_for_diff_segwit_outputs]] ++++
.Scripts for different types of segwit outputs <table id="scripts_for_diff_segwit_outputs">
[options="header"] <caption>Scripts for different types of segwit outputs</caption>
[cols="1,1"] <thead>
|=== <tr>
<th>Output type</th>
|Output type <th>Example script</th>
|Example script </tr>
</thead>
| P2WPKH <tbody>
| OP_0 2b626ed108ad00a944bb2922a309844611d25468 <tr>
<td><p>P2WPKH</p></td>
| P2WSH <td><p>OP_0 2b626ed108ad00a944bb2922a309844611d25468</p></td>
| OP_0 648a32e50b6fb7c5233b228f60a6a2ca4158400268844c4bc295ed5e8c3d626f </tr>
<tr>
| P2TR <td><p>P2WSH</p></td>
| OP_1 2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311 <td><p>OP_0 648a32e50b6fb7c5233b228f60a6a2ca4158400268844c4bc295ed5e8c3d626f</p></td>
</tr>
<tr>
<td><p>P2TR</p></td>
<td><p>OP_1 2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311</p></td>
</tr>
<tr>
<td><p>Future Example</p></td>
<td><p>OP_16 0000</p></td>
</tr>
</tbody>
</table>
++++
| Future Example
| OP_16 0000
|===
For the P2WPKH output, the witness program contains a commitment constructed in exactly the same For the P2WPKH output, the witness program contains a commitment constructed in exactly the same
way as the commitment for a P2PKH output seen in <<addresses_for_p2pkh>>. A public key is passed into a SHA256 hash way as the commitment for a P2PKH output seen in <<addresses_for_p2pkh>>. A public key is passed into a SHA256 hash
@ -1411,29 +1457,63 @@ See <<hd_wallets>> for more information.
**** ****
[[table_4-2]] ++++
.Private key representations (encoding formats) <table id="table_4-2">
[options="header"] <caption>Private key representations (encoding formats)</caption>
[cols="1,1,1"] <thead>
|======= <tr>
|Type|Prefix|Description <th>Type</th>
| Hex | None | 64 hexadecimal digits <th>Prefix</th>
| WIF | 5 | Base58check encoding: base58 with version prefix of 128 and 32-bit checksum <th>Description</th>
| WIF-compressed | K or L | As above, with added suffix 0x01 before encoding </tr>
|======= </thead>
<tbody>
<tr>
<td><p>Hex</p></td>
<td><p>None</p></td>
<td><p>64 hexadecimal digits</p></td>
</tr>
<tr>
<td><p>WIF</p></td>
<td><p>5</p></td>
<td><p>Base58check encoding: base58 with version prefix of 128 and 32-bit checksum</p></td>
</tr>
<tr>
<td><p>WIF-compressed</p></td>
<td><p>K or L</p></td>
<td><p>As above, with added suffix 0x01 before encoding</p></td>
</tr>
</tbody>
</table>
++++
<<table_4-3>> shows the private key generated in several different formats. <<table_4-3>> shows the private key generated in several different formats.
[[table_4-3]] ++++
.Example: Same key, different formats <table id="table_4-3">
[options="header"] <caption>Example: Same key, different formats</caption>
[cols="1,1"] <thead>
|======= <tr>
|Format | Private key <th>Format</th>
| Hex | 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd <th>Private key</th>
| WIF | 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn </tr>
| WIF-compressed | KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ </thead>
|======= <tbody>
<tr>
<td><p>Hex</p></td>
<td><p>1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd</p></td>
</tr>
<tr>
<td><p>WIF</p></td>
<td><p>5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn</p></td>
</tr>
<tr>
<td><p>WIF-compressed</p></td>
<td><p>KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ</p></td>
</tr>
</tbody>
</table>
++++
All of these representations are different ways of showing the same All of these representations are different ways of showing the same
number, the same private key. They look different, but any one format number, the same private key. They look different, but any one format
@ -1458,17 +1538,31 @@ confusion
<<table_4-4>> shows the same key, encoded in WIF and WIF-compressed formats. <<table_4-4>> shows the same key, encoded in WIF and WIF-compressed formats.
[[table_4-4]] ++++
.Example: Same key, different formats <table id="table_4-3">
[options="header"] <caption>Example: Same key, different formats</caption>
[cols="1,1"] <thead>
|======= <tr>
|Format | Private key <th>Format</th>
| Hex | 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD <th>Private key</th>
| WIF | 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn </tr>
| Hex-compressed | 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD01 </thead>
| WIF-compressed | KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ <tbody>
|======= <tr>
<td><p>Hex</p></td>
<td><p>1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd</p></td>
</tr>
<tr>
<td><p>WIF</p></td>
<td><p>5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn</p></td>
</tr>
<tr>
<td><p>WIF-compressed</p></td>
<td><p>KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ</p></td>
</tr>
</tbody>
</table>
++++
Notice that the hex-compressed private key format has one extra byte at Notice that the hex-compressed private key format has one extra byte at
the end (01 in hex). While the base58 encoding version prefix is the the end (01 in hex). While the base58 encoding version prefix is the
@ -1549,39 +1643,120 @@ like "1Kids" can be seen as searching for an address in the range from
"1Kids." <<table_4-11>> shows the range of addresses that have the "1Kids." <<table_4-11>> shows the range of addresses that have the
prefix 1Kids. prefix 1Kids.
[[table_4-11]] ++++
.The range of vanity addresses starting with "1Kids" <table id="table_4-11">
|======= <caption>The range of vanity addresses starting with “1Kids”</caption>
| *From* | +1Kids11111111111111111111111111111+ <tbody>
| | +1Kids11111111111111111111111111112+ <tr>
| | +1Kids11111111111111111111111111113+ <td><p><strong>From</strong></p></td>
| | +...+ <td><p><code>1Kids11111111111111111111111111111</code></p></td>
| *To* | +1Kidszzzzzzzzzzzzzzzzzzzzzzzzzzzzz+ </tr>
|======= <tr>
<td/>
<td><p><code>1Kids11111111111111111111111111112</code></p></td>
</tr>
<tr>
<td/>
<td><p><code>1Kids11111111111111111111111111113</code></p></td>
</tr>
<tr>
<td/>
<td><p><code>…​</code></p></td>
</tr>
<tr>
<td><p><strong>To</strong></p></td>
<td><p><code>1Kidszzzzzzzzzzzzzzzzzzzzzzzzzzzzz</code></p></td>
</tr>
</tbody>
</table>
++++
Let's look at the pattern "1Kids" as a number and see how frequently we Let's look at the pattern "1Kids" as a number and see how frequently we
might find this pattern in a Bitcoin address (see <<table_4-12>>). An might find this pattern in a Bitcoin address (see <<table_4-12>>). An
average desktop computer PC, without any specialized hardware, can average desktop computer PC, without any specialized hardware, can
search approximately 100,000 keys per second. 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 <table id="table_4-12">
[options="header"] <caption>The frequency of a vanity pattern (1KidsCharity) and average search time on a desktop PC</caption>
[cols="1,1,1,1"] <thead>
|======= <tr>
| Length | Pattern | Frequency | Average search time <th>Length</th>
| 1 | 1K | 1 in 58 keys | < 1 milliseconds <th>Pattern</th>
| 2 | 1Ki| 1 in 3,364 | 50 milliseconds <th>Frequency</th>
| 3 | 1Kid | 1 in 195,000 | < 2 seconds <th>Average search time</th>
| 4 | 1Kids | 1 in 11 million | 1 minute </tr>
| 5 | 1KidsC | 1 in 656 million | 1 hour </thead>
| 6 | 1KidsCh | 1 in 38 billion | 2 days <tbody>
| 7 | 1KidsCha | 1 in 2.2 trillion | 34 months <tr>
| 8 | 1KidsChar | 1 in 128 trillion | 1318 years <td><p>1</p></td>
| 9 | 1KidsChari | 1 in 7 quadrillion | 800 years <td><p>1K</p></td>
| 10 | 1KidsCharit | 1 in 400 quadrillion | 46,000 years <td><p>1 in 58 keys</p></td>
| 11 | 1KidsCharity | 1 in 23 quintillion | 2.5 million years <td><p>&lt; 1 milliseconds</p></td>
|======= </tr>
<tr>
<td><p>2</p></td>
<td><p>1Ki</p></td>
<td><p>1 in 3,364</p></td>
<td><p>50 milliseconds</p></td>
</tr>
<tr>
<td><p>3</p></td>
<td><p>1Kid</p></td>
<td><p>1 in 195,000</p></td>
<td><p>&lt; 2 seconds</p></td>
</tr>
<tr>
<td><p>4</p></td>
<td><p>1Kids</p></td>
<td><p>1 in 11 million</p></td>
<td><p>1 minute</p></td>
</tr>
<tr>
<td><p>5</p></td>
<td><p>1KidsC</p></td>
<td><p>1 in 656 million</p></td>
<td><p>1 hour</p></td>
</tr>
<tr>
<td><p>6</p></td>
<td><p>1KidsCh</p></td>
<td><p>1 in 38 billion</p></td>
<td><p>2 days</p></td>
</tr>
<tr>
<td><p>7</p></td>
<td><p>1KidsCha</p></td>
<td><p>1 in 2.2 trillion</p></td>
<td><p>34 months</p></td>
</tr>
<tr>
<td><p>8</p></td>
<td><p>1KidsChar</p></td>
<td><p>1 in 128 trillion</p></td>
<td><p>1318 years</p></td>
</tr>
<tr>
<td><p>9</p></td>
<td><p>1KidsChari</p></td>
<td><p>1 in 7 quadrillion</p></td>
<td><p>800 years</p></td>
</tr>
<tr>
<td><p>10</p></td>
<td><p>1KidsCharit</p></td>
<td><p>1 in 400 quadrillion</p></td>
<td><p>46,000 years</p></td>
</tr>
<tr>
<td><p>11</p></td>
<td><p>1KidsCharity</p></td>
<td><p>1 in 23 quintillion</p></td>
<td><p>2.5 million years</p></td>
</tr>
</tbody>
</table>
++++
As you can see, Eugenia won't be creating the vanity address As you can see, Eugenia won't be creating the vanity address
"1KidsCharity" anytime soon, even if she had access to several thousand "1KidsCharity" anytime soon, even if she had access to several thousand

@ -429,15 +429,30 @@ wallets--not shared with the network--protecting their privacy
and keeping unnecessary personal data out of the blockchain. For and keeping unnecessary personal data out of the blockchain. For
an example, see <<alice_tx_labels>>. an example, see <<alice_tx_labels>>.
[[alice_tx_labels]] ++++
.Alice's transaction history with each transaction labeled <table id="alice_tx_labels">
[options="header"] <caption>Alices transaction history with each transaction labeled</caption>
[cols="1,1,1"] <thead>
|=== <tr>
| Date | Label | BTC <th>Date</th>
| 2023-01-01 | Bought bitcoins from Joe | +0.00100 <th>Label</th>
| 2023-01-02 | Paid Bob for podcast | 0.00075 <th>BTC</th>
|=== </tr>
</thead>
<tbody>
<tr>
<td><p>2023-01-01</p></td>
<td><p>Bought bitcoins from Joe</p></td>
<td><p>+0.00100</p></td>
</tr>
<tr>
<td><p>2023-01-02</p></td>
<td><p>Paid Bob for podcast</p></td>
<td><p>0.00075</p></td>
</tr>
</tbody>
</table>
++++
However, because address and transaction labels are stored only in each However, because address and transaction labels are stored only in each
user's wallet database and because they aren't deterministic, they can't user's wallet database and because they aren't deterministic, they can't
@ -512,17 +527,40 @@ the keys in that path both when it is first started and after a
restoration from a recovery code. We call this solution _implicit restoration from a recovery code. We call this solution _implicit
paths_. Several popular implicit paths defined by BIPs are shown in <<bip_implicit_paths>> paths_. Several popular implicit paths defined by BIPs are shown in <<bip_implicit_paths>>
[[bip_implicit_paths]] ++++
.Implicit script paths defined by various BIPs <table id="bip_implicit_paths">
[options="header"] <caption>Implicit script paths defined by various BIPs</caption>
[cols="1,1,1"] <thead>
|=== <tr>
| Standard | Script | BIP32 path <th>Standard</th>
| BIP44 | P2PKH | +m/44'/0'/0'+ <th>Script</th>
| BIP49 | Nested P2WPKH | +m/49'/1'/0'+ <th>BIP32 path</th>
| BIP84 | P2WPKH | +m/84'/0'/0'+ </tr>
| BIP86 | P2TR Single-key | +m/86'/0'/0'+ </thead>
|=== <tbody>
<tr>
<td><p>BIP44</p></td>
<td><p>P2PKH</p></td>
<td><p><code>m/44'/0'/0'</code></p></td>
</tr>
<tr>
<td><p>BIP49</p></td>
<td><p>Nested P2WPKH</p></td>
<td><p><code>m/49'/1'/0'</code></p></td>
</tr>
<tr>
<td><p>BIP84</p></td>
<td><p>P2WPKH</p></td>
<td><p><code>m/84'/0'/0'</code></p></td>
</tr>
<tr>
<td><p>BIP86</p></td>
<td><p>P2TR Single-key</p></td>
<td><p><code>m/86'/0'/0'</code></p></td>
</tr>
</tbody>
</table>
++++
The second solution is to back up the path information with the recovery The second solution is to back up the path information with the recovery
code, making it clear which path is used with which scripts. We call code, making it clear which path is used with which scripts. We call
@ -582,21 +620,32 @@ _descriptors_ for short) as specified in BIPs 380, 381, 382, 383, 384,
describe a script and the keys (or key paths) to be used with it. describe a script and the keys (or key paths) to be used with it.
A few example descriptors are shown in <<sample_descriptors>>. A few example descriptors are shown in <<sample_descriptors>>.
[[sample_descriptors]] ++++
.Sample descriptors from Bitcoin Core documentation (with elision) <table id="sample_descriptors">
[cols="1,1"] <caption>Sample descriptors from Bitcoin Core documentation (with elision)</caption>
|=== <thead>
| Descriptor | Explanation <tr>
<th>Descriptor</th>
| +pkh(02c6...9ee5)+ <th>Explanation</th>
| P2PKH script for the provided public key </tr>
</thead>
| +sh(multi(2,022f...2a01,03ac...ccbe))+ <tbody>
| P2SH multisignature requring two signatures corresponding to these two keys <tr>
<td><p><code>pkh(02c6…9ee5)</code></p></td>
<td><p>P2PKH script for the provided public key</p></td>
</tr>
<tr>
<td><p><code>sh(multi(2,022f…2a01,03ac…ccbe))</code></p></td>
<td><p>P2SH multisignature requring two signatures corresponding to these two keys</p></td>
</tr>
<tr>
<td><p><code>pkh([d34db33f/44'/0'/0']xpub6ERA…RcEL/1/*)</code></p></td>
<td><p>P2PKH scripts for the BIP32 <code>d34db33f</code> with the extended public key (xpub) at the path <code>M/44'/0'/0'</code>, which is <code>xpub6ERA…RcEL</code>, using the keys at <code>M/1/*</code> of that xpub</p></td>
</tr>
</tbody>
</table>
++++
| +pkh([d34db33f/44'/0'/0']xpub6ERA...RcEL/1/*)+
| P2PKH scripts for the BIP32 +d34db33f+ with the extended public key (xpub) at the path +M/44'/0'/0'+, which is +xpub6ERA...RcEL+, using the keys at +M/1/*+ of that xpub
|===
It has long been the trend for wallet applications designed only for It has long been the trend for wallet applications designed only for
single signature scripts to use implicit paths. Wallet applications single signature scripts to use implicit paths. Wallet applications
@ -690,18 +739,97 @@ image::images/mbc3_0504.png["Generating entropy and encoding as a recovery code"
<<table_4-5>> shows the relationship between the size of the entropy <<table_4-5>> shows the relationship between the size of the entropy
data and the length of recovery code in words. data and the length of recovery code in words.
[[table_4-5]] ++++
.BIP39: entropy and word length <table id="table_4-5">
[options="header"] <caption>BIP39: entropy and word length</caption>
[cols="1,1,1,1"] <thead>
|======= <tr>
|Entropy (bits) | Checksum (bits) | Entropy *+* checksum (bits) | Recovery code words <th>Entropy (bits)</th>
| 128 | 4 | 132 | 12 <th>Checksum (bits)</th>
| 160 | 5 | 165 | 15 <th>Entropy <strong>+</strong> checksum (bits)</th>
| 192 | 6 | 198 | 18 <th>Recovery code words</th>
| 224 | 7 | 231 | 21 </tr>
| 256 | 8 | 264 | 24 </thead>
|======= <tbody>
<tr>
<td><p>128</p></td>
<td><p>4</p></td>
<td><p>132</p></td>
<td><p>12</p></td>
</tr>
<tr>
<td><p>160</p></td>
<td><p>5</p></td>
<td><p>165</p></td>
<td><p>15</p></td>
</tr>
<tr>
<td><p>192</p></td>
<td><p>6</p></td>
<td><p>198</p></td>
<td><p>18</p></td>
</tr>
<tr>
<td><p>224</p></td>
<td><p>7</p></td>
<td><p>231</p></td>
<td><p>21</p></td>
</tr>
<tr>
<td><p>256</p></td>
<td><p>8</p></td>
<td><p>264</p></td>
<td><p>24</p></td>
</tr>
</tbody>
</table>
++++
++++
<table id="table_4-5">
<caption>BIP39: entropy and word length</caption>
<thead>
<tr>
<th>Entropy (bits)</th>
<th>Checksum (bits)</th>
<th>Entropy <strong>+</strong> checksum (bits)</th>
<th>Recovery code words</th>
</tr>
</thead>
<tbody>
<tr>
<td><p>128</p></td>
<td><p>4</p></td>
<td><p>132</p></td>
<td><p>12</p></td>
</tr>
<tr>
<td><p>160</p></td>
<td><p>5</p></td>
<td><p>165</p></td>
<td><p>15</p></td>
</tr>
<tr>
<td><p>192</p></td>
<td><p>6</p></td>
<td><p>198</p></td>
<td><p>18</p></td>
</tr>
<tr>
<td><p>224</p></td>
<td><p>7</p></td>
<td><p>231</p></td>
<td><p>21</p></td>
</tr>
<tr>
<td><p>256</p></td>
<td><p>8</p></td>
<td><p>264</p></td>
<td><p>24</p></td>
</tr>
</tbody>
</table>
++++
[[recovery_to_seed]] [[recovery_to_seed]]
===== From recovery code to seed ===== From recovery code to seed
@ -772,40 +900,77 @@ pass:[<a data-type="xref" href="#bip39_256_no_pass"
data-xrefstyle="select: labelnumber">#bip39_256_no_pass</a>] show data-xrefstyle="select: labelnumber">#bip39_256_no_pass</a>] show
some examples of recovery codes and the seeds they produce. some examples of recovery codes and the seeds they produce.
[[bip39_128_no_pass]] ++++
.128-bit entropy BIP39 recovery code, no passphrase, resulting seed <table id="bip39_128_no_pass">
[cols="h,"] <caption>128-bit entropy BIP39 recovery code, no passphrase, resulting seed</caption>
|======= <tbody>
| *Entropy input (128 bits)*| +0c1e24e5917779d297e14d45f14e1a1a+ <tr>
| *Recovery Code (12 words)* | +army van defense carry jealous true garbage claim echo media make crunch+ <td><p><strong>Entropy input (128 bits)</strong></p></td>
| *Passphrase*| (none) <td><p><code>0c1e24e5917779d297e14d45f14e1a1a</code></p></td>
| *Seed (512 bits)* | +5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4+ </tr>
+c67196f57c39a88b76373733891bfaba16ed27a813ceed498804c0570+ <tr>
|======= <td><p><strong>Recovery Code (12 words)</strong></p></td>
<td><p><code>army van defense carry jealous true garbage claim echo media make crunch</code></p></td>
[[bip39_128_w_pass]] </tr>
.128-bit entropy BIP39 recovery code, with passphrase, resulting seed <tr>
[cols="h,"] <td><p><strong>Passphrase</strong></p></td>
|======= <td><p>(none)</p></td>
| *Entropy input (128 bits)*| +0c1e24e5917779d297e14d45f14e1a1a+ </tr>
| *Recovery Code (12 words)* | +army van defense carry jealous true garbage claim echo media make crunch+ <tr>
| *Passphrase*| SuperDuperSecret <td><p><strong>Seed (512 bits)</strong></p></td>
| *Seed (512 bits)* | +3b5df16df2157104cfdd22830162a5e170c0161653e3afe6c88defeefb0818c793dbb28+ <td><p><code>5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4</code>
+ab3ab091897d0715861dc8a18358f80b79d49acf64142ae57037d1d54+ <code>c67196f57c39a88b76373733891bfaba16ed27a813ceed498804c0570</code></p></td>
|======= </tr>
</tbody>
</table>
[[bip39_256_no_pass]]
.256-bit entropy BIP39 recovery code, no passphrase, resulting seed <table id="bip39_128_w_pass">
[cols="h,"] <caption>128-bit entropy BIP39 recovery code, with passphrase, resulting seed</caption>
|======= <tbody>
| *Entropy input (256 bits)* | +2041546864449caff939d32d574753fe684d3c947c3346713dd8423e74abcf8c+ <tr>
| *Recovery Code (24 words)* | +cake apple borrow silk endorse fitness top denial coil riot stay wolf <td><p><strong>Entropy input (128 bits)</strong></p></td>
luggage oxygen faint major edit measure invite love trap field dilemma oblige+ <td><p><code>0c1e24e5917779d297e14d45f14e1a1a</code></p></td>
| *Passphrase*| (none) </tr>
| *Seed (512 bits)* | +3269bce2674acbd188d4f120072b13b088a0ecf87c6e4cae41657a0bb78f5315b33b3+ <tr>
+a04356e53d062e55f1e0deaa082df8d487381379df848a6ad7e98798404+ <td><p><strong>Recovery Code (12 words)</strong></p></td>
|======= <td><p><code>army van defense carry jealous true garbage claim echo media make crunch</code></p></td>
</tr>
<tr>
<td><p><strong>Passphrase</strong></p></td>
<td><p>SuperDuperSecret</p></td>
</tr>
<tr>
<td><p><strong>Seed (512 bits)</strong></p></td>
<td><p><code>3b5df16df2157104cfdd22830162a5e170c0161653e3afe6c88defeefb0818c793dbb28</code>
<code>ab3ab091897d0715861dc8a18358f80b79d49acf64142ae57037d1d54</code></p></td>
</tr>
</tbody>
</table>
<table id="bip39_256_no_pass">
<caption><span class="label">Table 5-7. </span>256-bit entropy BIP39 recovery code, no passphrase, resulting seed</caption>
<tbody>
<tr>
<td><p><strong>Entropy input (256 bits)</strong></p></td>
<td><p><code>2041546864449caff939d32d574753fe684d3c947c3346713dd8423e74abcf8c</code></p></td>
</tr>
<tr>
<td><p><strong>Recovery Code (24 words)</strong></p></td>
<td><p><code>cake apple borrow silk endorse fitness top denial coil riot stay wolf
luggage oxygen faint major edit measure invite love trap field dilemma oblige</code></p></td>
</tr>
<tr>
<td><p><strong>Passphrase</strong></p></td>
<td><p>(none)</p></td>
</tr>
<tr>
<td><p><strong>Seed (512 bits)</strong></p></td>
<td><p><code>3269bce2674acbd188d4f120072b13b088a0ecf87c6e4cae41657a0bb78f5315b33b3</code>
<code>a04356e53d062e55f1e0deaa082df8d487381379df848a6ad7e98798404</code></p></td>
</tr>
</tbody>
</table>
++++
.How Much Entropy Do You Need? .How Much Entropy Do You Need?
**** ****
@ -1283,18 +1448,39 @@ master key from which it was derived. For example, identifier m/x/y/z
describes the key that is the z-th child of key m/x/y, which is the y-th describes the key that is the z-th child of key m/x/y, which is the y-th
child of key m/x, which is the x-th child of m. child of key m/x, which is the x-th child of m.
[[table_4-8]] ++++
.HD wallet path examples <table id="table_4-8">
[options="header"] <caption>HD wallet path examples</caption>
[cols="1,1"] <thead>
|======= <tr>
|HD path | Key described <th>HD path</th>
| m/0 | The first (0) child private key from the master private key (m) <th>Key described</th>
| m/0/0 | The first grandchild private key from the first child (m/0) </tr>
| m/0'/0 | The first normal grandchild private key from the first _hardened_ child (m/0') </thead>
| m/1/0 | The first grandchild private key from the second child (m/1) <tbody>
| M/23/17/0/0 | The first great-great-grandchild public key from the first great-grandchild from the 18th grandchild from the 24th child <tr>
|======= <td><p>m/0</p></td>
<td><p>The first (0) child private key from the master private key (m)</p></td>
</tr>
<tr>
<td><p>m/0/0</p></td>
<td><p>The first grandchild private key from the first child (m/0)</p></td>
</tr>
<tr>
<td><p>m/0'/0</p></td>
<td><p>The first normal grandchild private key from the first <em>hardened</em> child (m/0')</p></td>
</tr>
<tr>
<td><p>m/1/0</p></td>
<td><p>The first grandchild private key from the second child (m/1)</p></td>
</tr>
<tr>
<td><p>M/23/17/0/0</p></td>
<td><p>The first great-great-grandchild public key from the first great-grandchild from the 18th grandchild from the 24th child</p></td>
</tr>
</tbody>
</table>
++++
===== Navigating the HD wallet tree structure ===== Navigating the HD wallet tree structure
@ -1354,16 +1540,31 @@ third receiving address for payments in the primary account
would be M/44++&#x27;++/0++&#x27;++/0++&#x27;++/0/2. <<table_4-9>> shows would be M/44++&#x27;++/0++&#x27;++/0++&#x27;++/0/2. <<table_4-9>> shows
a few more examples. a few more examples.
[[table_4-9]] ++++
.BIP44 HD wallet structure examples <table id="table_4-9">
[options="header"] <caption>BIP44 HD wallet structure examples</caption>
[cols="1,1"] <thead>
|======= <tr>
|HD path | Key described <th>HD path</th>
| M/44++&#x27;++/0++&#x27;++/0++&#x27;++/0/2 | The third receiving public key for the primary Bitcoin account <th>Key described</th>
| M/44++&#x27;++/0++&#x27;++/3++&#x27;++/1/14 | The fifteenth change-address public key for the fourth Bitcoin account </tr>
| m/44++&#x27;++/2++&#x27;++/0++&#x27;++/0/1 | The second private key in the Litecoin main account, for signing transactions </thead>
|======= <tbody>
<tr>
<td><p>M/44<code>'</code>/0<code>'</code>/0<code>'</code>/0/2</p></td>
<td><p>The third receiving public key for the primary Bitcoin account</p></td>
</tr>
<tr>
<td><p>M/44<code>'</code>/0<code>'</code>/3<code>'</code>/1/14</p></td>
<td><p>The fifteenth change-address public key for the fourth Bitcoin account</p></td>
</tr>
<tr>
<td><p>m/44<code>'</code>/2<code>'</code>/0<code>'</code>/0/1</p></td>
<td><p>The second private key in the Litecoin main account, for signing transactions</p></td>
</tr>
</tbody>
</table>
++++
Many people focus on securing their bitcoins against theft and other Many people focus on securing their bitcoins against theft and other
attacks, but one of the leading causes of lost bitcoins--perhaps _the_ attacks, but one of the leading causes of lost bitcoins--perhaps _the_

@ -216,16 +216,40 @@ encoding familiar to any programmer. For other numbers up to
length—but otherwise the numbers look like regular C-language encoded length—but otherwise the numbers look like regular C-language encoded
unsigned integers: unsigned integers:
[cols="1,1,1"] ++++
[options="header"] <table>
|===
| Value | Bytes used | Format <thead>
| >= +0+ && \<= +252+ (++0xfc++) | +1+ | +uint8_t+ <tr>
| >= +253+ && \<= +0xffff+ | 3 | +0xfd+ followed by the number as +uint16_t+ <th>Value</th>
| >= +0x10000+ && \<= +0xffffffff+ | +5+ | +0xfe+ followed by the number as +uint32_t+ <th>Bytes used</th>
| >= +0x100000000+ && \<= +0xffffffffffffffff+ | +9+ | +0xff+ followed by the number as +uint64_t+ <th>Format</th>
|=== </tr>
**** </thead>
<tbody>
<tr>
<td><p>&gt;= <code>0</code> &amp;&amp; &lt;= <code>252</code> (<code>0xfc</code>)</p></td>
<td><p><code>1</code></p></td>
<td><p><code>uint8_t</code></p></td>
</tr>
<tr>
<td><p>&gt;= <code>253</code> &amp;&amp; &lt;= <code>0xffff</code></p></td>
<td><p>3</p></td>
<td><p><code>0xfd</code> followed by the number as <code>uint16_t</code></p></td>
</tr>
<tr>
<td><p>&gt;= <code>0x10000</code> &amp;&amp; &lt;= <code>0xffffffff</code></p></td>
<td><p><code>5</code></p></td>
<td><p><code>0xfe</code> followed by the number as <code>uint32_t</code></p></td>
</tr>
<tr>
<td><p>&gt;= <code>0x100000000</code> &amp;&amp; &lt;= <code>0xffffffffffffffff</code></p></td>
<td><p><code>9</code></p></td>
<td><p><code>0xff</code> followed by the number as <code>uint64_t</code></p></td>
</tr>
</tbody>
</table>
++++
Each input in a transaction must contain three fields: Each input in a transaction must contain three fields:
@ -954,15 +978,33 @@ bitcoins to be received to output scripts and spent with input scripts.
Later experience with contract protocols inspired allowing bitcoins to Later experience with contract protocols inspired allowing bitcoins to
be received to witness programs and spent with the witness structure. The terms and fields used in different versions of Bitcoin are shown in <<terms_used_authorization_authentication>>. be received to witness programs and spent with the witness structure. The terms and fields used in different versions of Bitcoin are shown in <<terms_used_authorization_authentication>>.
[[terms_used_authorization_authentication]] ++++
.Terms used for authorization and authentication data in different parts of Bitcoin <table id="terms_used_authorization_authentication">
[cols="1,1,1"] <caption>Terms used for authorization and authentication data in different parts of Bitcoin</caption>
|=== <tbody>
| | **Authorization** | **Authentication** <tr>
| **Whitepaper** | Public key | Signature <td/>
| **Original (Legacy)** | Output script | Input script <td><p><strong>Authorization</strong></p></td>
| **Segwit** | Witness program | Witness structure <td><p><strong>Authentication</strong></p></td>
|=== </tr>
<tr>
<td><p><strong>Whitepaper</strong></p></td>
<td><p>Public key</p></td>
<td><p>Signature</p></td>
</tr>
<tr>
<td><p><strong>Original (Legacy)</strong></p></td>
<td><p>Output script</p></td>
<td><p>Input script</p></td>
</tr>
<tr>
<td><p><strong>Segwit</strong></p></td>
<td><p>Witness program</p></td>
<td><p>Witness structure</p></td>
</tr>
</tbody>
</table>
++++
==== Witness Structure Serialization ==== Witness Structure Serialization
@ -1118,26 +1160,83 @@ reduce the weight used when spending a UTXO. This helps discourage the
creation of uneconomical outputs as described in creation of uneconomical outputs as described in
<<uneconomical_outputs>>. <<uneconomical_outputs>>.
[[weight_factors]] ++++
.Weight factors for all fields in a Bitcoin transaction <table id="weight_factors">
[cols="1,1,1"] <caption>Weight factors for all fields in a Bitcoin transaction</caption>
[option="header"] <tbody>
|=== <tr>
| Field | Factor | Weight in Alice's Tx <td><p>Field</p></td>
| Version | 4 | 16 <td><p>Factor</p></td>
| Marker & Flag | 1 | 2 <td><p>Weight in Alices Tx</p></td>
| Inputs Count | 4 | 4 </tr>
| Outpoint | 4 | 144 <tr>
| Input script | 4 | 4 <td><p>Version</p></td>
| Sequence | 4 | 16 <td><p>4</p></td>
| Outputs Count | 4 | 4 <td><p>16</p></td>
| Amount | 4 | 64 (2 outputs) </tr>
| Output script | 4 | 232 (2 outputs with different scripts) <tr>
| Witness Count | 1 | 1 <td><p>Marker &amp; Flag</p></td>
| Witness items | 1 | 66 <td><p>1</p></td>
| Lock time | 4 | 16 <td><p>2</p></td>
| **Total** | _N/A_ | **569** </tr>
|=== <tr>
<td><p>Inputs Count</p></td>
<td><p>4</p></td>
<td><p>4</p></td>
</tr>
<tr>
<td><p>Outpoint</p></td>
<td><p>4</p></td>
<td><p>144</p></td>
</tr>
<tr>
<td><p>Input script</p></td>
<td><p>4</p></td>
<td><p>4</p></td>
</tr>
<tr>
<td><p>Sequence</p></td>
<td><p>4</p></td>
<td><p>16</p></td>
</tr>
<tr>
<td><p>Outputs Count</p></td>
<td><p>4</p></td>
<td><p>4</p></td>
</tr>
<tr>
<td><p>Amount</p></td>
<td><p>4</p></td>
<td><p>64 (2 outputs)</p></td>
</tr>
<tr>
<td><p>Output script</p></td>
<td><p>4</p></td>
<td><p>232 (2 outputs with different scripts)</p></td>
</tr>
<tr>
<td><p>Witness Count</p></td>
<td><p>1</p></td>
<td><p>1</p></td>
</tr>
<tr>
<td><p>Witness items</p></td>
<td><p>1</p></td>
<td><p>66</p></td>
</tr>
<tr>
<td><p>Lock time</p></td>
<td><p>4</p></td>
<td><p>16</p></td>
</tr>
<tr>
<td><p><strong>Total</strong></p></td>
<td><p><em>N/A</em></p></td>
<td><p><strong>569</strong></p></td>
</tr>
</tbody>
</table>
++++
We can verify our weight calculation by getting the total for Alice's We can verify our weight calculation by getting the total for Alice's
transaction from Bitcoin Core: transaction from Bitcoin Core:

@ -519,20 +519,38 @@ redemption time rather than as an output script. <<without_p2sh>> shows
the script without P2SH and <<with_p2sh>> shows the same script encoded the script without P2SH and <<with_p2sh>> shows the same script encoded
with P2SH. with P2SH.
[[without_p2sh]] ++++
.Complex script without P2SH <table id="without_p2sh">
|======= <caption>Complex script without P2SH</caption>
| Output script | 2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 OP_CHECKMULTISIG <tbody>
| Input script | Sig1 Sig2 <tr>
|======= <td><p>Output script</p></td>
<td><p>2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 OP_CHECKMULTISIG</p></td>
[[with_p2sh]] </tr>
.Complex script as P2SH <tr>
|======= <td><p>Input script</p></td>
| Redeem script | 2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 OP_CHECKMULTISIG <td><p>Sig1 Sig2</p></td>
| Output script | OP_HASH160 <20-byte hash of redeem script> OP_EQUAL </tr>
| Input script | Sig1 Sig2 <redeem script> </tbody>
|======= </table>
<table id="with_p2sh">
<caption>Complex script as P2SH</caption>
<tbody>
<tr>
<td><p>Redeem script</p></td>
<td><p>2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 OP_CHECKMULTISIG</p></td>
</tr>
<tr>
<td><p>Output script</p></td>
<td><p>OP_HASH160 &lt;20-byte hash of redeem script&gt; OP_EQUAL</p></td>
</tr>
<tr>
<td><p>Input script</p></td>
<td><p>Sig1 Sig2 &lt;redeem script&gt;</p></td>
</tr>
</tbody>
</table>
++++
As you can see from the tables, with P2SH the complex script that As you can see from the tables, with P2SH the complex script that
details the conditions for spending the output (redeem script) is not details the conditions for spending the output (redeem script) is not

@ -123,16 +123,36 @@ and updating a partially signed transaction.
There are three +SIGHASH+ flags: +ALL+, +NONE+, and +SINGLE+, as shown There are three +SIGHASH+ flags: +ALL+, +NONE+, and +SINGLE+, as shown
in <<sighash_types_and_their>>. in <<sighash_types_and_their>>.
[[sighash_types_and_their]] ++++
.[.plain]#++SIGHASH++# types and their meanings <table id="sighash_types_and_their">
[options="header"] <caption>
[cols="1,1,1"] <span class="plain"><code>SIGHASH</code></span> types and their meanings</caption>
|======================= <thead>
|++SIGHASH++ flag| Value | Description <tr>
| ++ALL++ | ++0x01++ | Signature applies to all inputs and outputs <th><code>SIGHASH</code> flag</th>
| ++NONE++ | ++0x02++ | Signature applies to all inputs, none of the outputs <th>Value</th>
| ++SINGLE++ | ++0x03++ | Signature applies to all inputs but only the one output with the same index number as the signed input <th>Description</th>
|======================= </tr>
</thead>
<tbody>
<tr>
<td><p><code>ALL</code></p></td>
<td><p><code>0x01</code></p></td>
<td><p>Signature applies to all inputs and outputs</p></td>
</tr>
<tr>
<td><p><code>NONE</code></p></td>
<td><p><code>0x02</code></p></td>
<td><p>Signature applies to all inputs, none of the outputs</p></td>
</tr>
<tr>
<td><p><code>SINGLE</code></p></td>
<td><p><code>0x03</code></p></td>
<td><p>Signature applies to all inputs but only the one output with the same index number as the signed input</p></td>
</tr>
</tbody>
</table>
++++
In addition, there is a modifier flag, +SIGHASH_ANYONECANPAY+, which can In addition, there is a modifier flag, +SIGHASH_ANYONECANPAY+, which can
be combined with each of the preceding flags. When +ANYONECANPAY+ is be combined with each of the preceding flags. When +ANYONECANPAY+ is
@ -141,16 +161,36 @@ numbers) open for modification. The +ANYONECANPAY+ has the value +0x80+
and is applied by bitwise OR, resulting in the combined flags as shown and is applied by bitwise OR, resulting in the combined flags as shown
in <<sighash_types_with_modifiers>>. in <<sighash_types_with_modifiers>>.
[[sighash_types_with_modifiers]] ++++
.[.plain]#++SIGHASH++# types with modifiers and their meanings <table id="sighash_types_with_modifiers">
[options="header"] <caption>
[cols="1,1,1"] <span class="plain"><code>SIGHASH</code></span> types with modifiers and their meanings</caption>
|======================= <thead>
|++SIGHASH++ flag| Value | Description <tr>
| ++ALL\|ANYONECANPAY++ | ++0x81++ | Signature applies to one input and all outputs <th><code>SIGHASH</code> flag</th>
| ++NONE\|ANYONECANPAY++ | ++0x82++ | Signature applies to one input, none of the outputs <th>Value</th>
| ++SINGLE\|ANYONECANPAY++ | ++0x83++ | Signature applies to one input and the output with the same index number <th>Description</th>
|======================= </tr>
</thead>
<tbody>
<tr>
<td><p><code>ALL|ANYONECANPAY</code></p></td>
<td><p><code>0x81</code></p></td>
<td><p>Signature applies to one input and all outputs</p></td>
</tr>
<tr>
<td><p><code>NONE|ANYONECANPAY</code></p></td>
<td><p><code>0x82</code></p></td>
<td><p>Signature applies to one input, none of the outputs</p></td>
</tr>
<tr>
<td><p><code>SINGLE|ANYONECANPAY</code></p></td>
<td><p><code>0x83</code></p></td>
<td><p>Signature applies to one input and the output with the same index number</p></td>
</tr>
</tbody>
</table>
++++
The way +SIGHASH+ flags are applied during signing and verification is The way +SIGHASH+ flags are applied during signing and verification is
that a copy of the transaction is made and certain fields within are that a copy of the transaction is made and certain fields within are

@ -77,17 +77,41 @@ up to about 4,000,000 bytes. A complete block,
with all transactions, can therefore be almost 50,000 times larger than the block with all transactions, can therefore be almost 50,000 times larger than the block
header. <<block_structure1>> describes how Bitcoin Core stores the structure of a block. header. <<block_structure1>> describes how Bitcoin Core stores the structure of a block.
[[block_structure1]] ++++
.The structure of a block <table id="block_structure1">
[options="header"] <caption>The structure of a block</caption>
[cols="1,1,1"] <thead>
|======= <tr>
|Size| Field | Description <th>Size</th>
| 4 bytes | Block Size | The size of the block, in bytes, following this field <th>Field</th>
| 80 bytes | Block Header | Several fields form the block header <th>Description</th>
| 13 bytes (compactSize) | Transaction Counter | How many transactions follow </tr>
| Variable | Transactions | The transactions recorded in this block </thead>
|======= <tbody>
<tr>
<td><p>4 bytes</p></td>
<td><p>Block Size</p></td>
<td><p>The size of the block, in bytes, following this field</p></td>
</tr>
<tr>
<td><p>80 bytes</p></td>
<td><p>Block Header</p></td>
<td><p>Several fields form the block header</p></td>
</tr>
<tr>
<td><p>13 bytes (compactSize)</p></td>
<td><p>Transaction Counter</p></td>
<td><p>How many transactions follow</p></td>
</tr>
<tr>
<td><p>Variable</p></td>
<td><p>Transactions</p></td>
<td><p>The transactions recorded in this block</p></td>
</tr>
</tbody>
</table>
++++
[[block_header]] [[block_header]]
=== Block Header === Block Header
@ -95,19 +119,50 @@ header. <<block_structure1>> describes how Bitcoin Core stores the structure of
The block header consists of The block header consists of
block metadata as shown in <<block_header_structure_ch09>>. block metadata as shown in <<block_header_structure_ch09>>.
[[block_header_structure_ch09]] ++++
.The structure of the block header <table id="block_header_structure_ch09">
[options="header"] <caption>The structure of the block header</caption>
[cols="1,1,1"] <thead>
|======= <tr>
|Size| Field | Description <th>Size</th>
| 4 bytes | Version | Originally a version field; its use has evolved over time <th>Field</th>
| 32 bytes | Previous Block Hash | A hash of the previous (parent) block in the chain <th>Description</th>
| 32 bytes | Merkle Root | The root hash of the merkle tree of this block's transactions </tr>
| 4 bytes | Timestamp | The approximate creation time of this block (Unix epoch time) </thead>
| 4 bytes | Target | A compact encoding of the proof-of-work target for this block <tbody>
| 4 bytes | Nonce | Arbitrary data used for the proof-of-work algorithm <tr>
|======= <td><p>4 bytes</p></td>
<td><p>Version</p></td>
<td><p>Originally a version field; its use has evolved over time</p></td>
</tr>
<tr>
<td><p>32 bytes</p></td>
<td><p>Previous Block Hash</p></td>
<td><p>A hash of the previous (parent) block in the chain</p></td>
</tr>
<tr>
<td><p>32 bytes</p></td>
<td><p>Merkle Root</p></td>
<td><p>The root hash of the merkle tree of this blocks transactions</p></td>
</tr>
<tr>
<td><p>4 bytes</p></td>
<td><p>Timestamp</p></td>
<td><p>The approximate creation time of this block (Unix epoch time)</p></td>
</tr>
<tr>
<td><p>4 bytes</p></td>
<td><p>Target</p></td>
<td><p>A compact encoding of the proof-of-work target for this block</p></td>
</tr>
<tr>
<td><p>4 bytes</p></td>
<td><p>Nonce</p></td>
<td><p>Arbitrary data used for the proof-of-work algorithm</p></td>
</tr>
</tbody>
</table>
++++
The nonce, target, and timestamp are used in the mining The nonce, target, and timestamp are used in the mining
process and will be discussed in more detail in <<mining>>. process and will be discussed in more detail in <<mining>>.

@ -458,31 +458,82 @@ input with a coinbase transaction input. <<table_8-1>> shows the
structure of a regular transaction, while <<table_8-2>> shows the structure of a regular transaction, while <<table_8-2>> shows the
structure of the coinbase transaction's input. structure of the coinbase transaction's input.
[[table_8-1]] ++++
.The structure of a "normal" transaction input <table id="table_8-1">
[options="header"] <caption><span class="label">Table 12-1. </span>The structure of a “normal” transaction input</caption>
[cols="1,1,1"] <thead>
|======= <tr>
|Size| Field | Description <th>Size</th>
| 32 bytes | Transaction Hash | Pointer to the transaction containing the UTXO to be spent <th>Field</th>
| 4 bytes | Output Index | The index number of the UTXO to be spent, first one is 0 <th>Description</th>
| 1&#x2013;9 bytes (compactSize) | Script Size | Script length in bytes, to follow </tr>
| Variable | Input Script | A script that fulfills the conditions of the UTXO output script </thead>
| 4 bytes | Sequence Number | Multipurpose field used for BIP68 timelocks and transaction replacement signaling <tbody>
|======= <tr>
<td><p>32 bytes</p></td>
[[table_8-2]] <td><p>Transaction Hash</p></td>
.The structure of a coinbase transaction input <td><p>Pointer to the transaction containing the UTXO to be spent</p></td>
[options="header"] </tr>
[cols="1,1,1"] <tr>
|======= <td><p>4 bytes</p></td>
|Size| Field | Description <td><p>Output Index</p></td>
| 32 bytes | Transaction Hash | All bits are zero: Not a transaction hash reference <td><p>The index number of the UTXO to be spent, first one is 0</p></td>
| 4 bytes | Output Index | All bits are ones: 0xFFFFFFFF </tr>
| 1 byte | Coinbase Data Size | Length of the coinbase data, from 2 to 100 bytes <tr>
| Variable | Coinbase Data | Arbitrary data used for extra nonce and mining tags. In v2 blocks; must begin with block height <td><p>19 bytes (compactSize)</p></td>
| 4 bytes | Sequence Number | Set to 0xFFFFFFFF <td><p>Script Size</p></td>
|======= <td><p>Script length in bytes, to follow</p></td>
</tr>
<tr>
<td><p>Variable</p></td>
<td><p>Input Script</p></td>
<td><p>A script that fulfills the conditions of the UTXO output script</p></td>
</tr>
<tr>
<td><p>4 bytes</p></td>
<td><p>Sequence Number</p></td>
<td><p>Multipurpose field used for BIP68 timelocks and transaction replacement signaling</p></td>
</tr>
</tbody>
</table>
<table id="table_8-2">
<caption><span class="label">Table 12-2. </span>The structure of a coinbase transaction input</caption>
<thead>
<tr>
<th>Size</th>
<th>Field</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td><p>32 bytes</p></td>
<td><p>Transaction Hash</p></td>
<td><p>All bits are zero: Not a transaction hash reference</p></td>
</tr>
<tr>
<td><p>4 bytes</p></td>
<td><p>Output Index</p></td>
<td><p>All bits are ones: 0xFFFFFFFF</p></td>
</tr>
<tr>
<td><p>1 byte</p></td>
<td><p>Coinbase Data Size</p></td>
<td><p>Length of the coinbase data, from 2 to 100 bytes</p></td>
</tr>
<tr>
<td><p>Variable</p></td>
<td><p>Coinbase Data</p></td>
<td><p>Arbitrary data used for extra nonce and mining tags. In v2 blocks; must begin with block height</p></td>
</tr>
<tr>
<td><p>4 bytes</p></td>
<td><p>Sequence Number</p></td>
<td><p>Set to 0xFFFFFFFF</p></td>
</tr>
</tbody>
</table>
++++
In a coinbase transaction, the first two fields are set to values that In a coinbase transaction, the first two fields are set to values that
do not represent a UTXO reference. Instead of a "transaction hash," the do not represent a UTXO reference. Instead of a "transaction hash," the
@ -519,19 +570,50 @@ To
construct the block header, the mining node needs to fill in six fields, construct the block header, the mining node needs to fill in six fields,
as listed in <<block_header_structure_ch10>>. as listed in <<block_header_structure_ch10>>.
[[block_header_structure_ch10]] ++++
.The structure of the block header <table id="block_header_structure_ch10">
[options="header"] <caption>The structure of the block header</caption>
[cols="1,1,1"] <thead>
|======= <tr>
|Size| Field | Description <th>Size</th>
| 4 bytes | Version | A multipurpose bitfield <th>Field</th>
| 32 bytes | Previous Block Hash | A reference to the hash of the previous (parent) block in the chain <th>Description</th>
| 32 bytes | Merkle Root | A hash that is the root of the merkle tree of this block's transactions </tr>
| 4 bytes | Timestamp | The approximate creation time of this block (seconds from Unix Epoch) </thead>
| 4 bytes | Target | The Proof-of-Work algorithm target for this block <tbody>
| 4 bytes | Nonce | A counter used for the Proof-of-Work algorithm <tr>
|======= <td><p>4 bytes</p></td>
<td><p>Version</p></td>
<td><p>A multipurpose bitfield</p></td>
</tr>
<tr>
<td><p>32 bytes</p></td>
<td><p>Previous Block Hash</p></td>
<td><p>A reference to the hash of the previous (parent) block in the chain</p></td>
</tr>
<tr>
<td><p>32 bytes</p></td>
<td><p>Merkle Root</p></td>
<td><p>A hash that is the root of the merkle tree of this blocks transactions</p></td>
</tr>
<tr>
<td><p>4 bytes</p></td>
<td><p>Timestamp</p></td>
<td><p>The approximate creation time of this block (seconds from Unix Epoch)</p></td>
</tr>
<tr>
<td><p>4 bytes</p></td>
<td><p>Target</p></td>
<td><p>The Proof-of-Work algorithm target for this block</p></td>
</tr>
<tr>
<td><p>4 bytes</p></td>
<td><p>Nonce</p></td>
<td><p>A counter used for the Proof-of-Work algorithm</p></td>
</tr>
</tbody>
</table>
++++
The version field was originally an integer field and was used in three 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. upgrades to the Bitcoin network, those defined in BIPs 34, 66, and 65.

Loading…
Cancel
Save