mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-11-22 16:18:11 +00:00
table fix
This commit is contained in:
Clare Laylock
parent
956782a94d
commit
781fd5b87d
@ -284,7 +284,7 @@ examples.
|
||||
|
||||
++++
|
||||
<table id="recovery_code_sample">
|
||||
<caption><span class="label">Table 1-1. </span>Sample recovery codes</caption>
|
||||
<caption>Sample recovery codes</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Wallet</th>
|
||||
|
||||
387
ch04_keys.adoc
387
ch04_keys.adoc
@ -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
|
||||
<<base58check_versions>>.
|
||||
|
||||
[[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
|
||||
| Address for pay to script hash (P2SH) | 0x05 | 3
|
||||
| Testnet Address for P2PKH | 0x6F | m or n
|
||||
| Testnet Address for P2SH | 0xC4 | 2
|
||||
| Private Key WIF | 0x80 | 5, K, or L
|
||||
| BIP32 Extended Public Key | 0x0488B21E | xpub
|
||||
|=======
|
||||
++++
|
||||
<table id="base58check_versions">
|
||||
<caption>Base58check version prefix and encoded result examples</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Type</th>
|
||||
<th>Version prefix (hex)</th>
|
||||
<th>Base58 result prefix</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<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
|
||||
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
|
||||
<<bech32_hrps_for_bitcoin>>.
|
||||
|
||||
[[bech32_hrps_for_bitcoin]]
|
||||
.Bech32 HRPs for Bitcoin
|
||||
[cols="1,1"]
|
||||
[options="header"]
|
||||
|===
|
||||
|
||||
| HRPs
|
||||
| Network
|
||||
|
||||
| bc
|
||||
| Bitcoin mainnet
|
||||
|
||||
| tb
|
||||
| Bitcoin testnet
|
||||
|===
|
||||
++++
|
||||
<table id="bech32_hrps_for_bitcoin">
|
||||
<caption>Bech32 HRPs for Bitcoin</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>HRPs</th>
|
||||
<th>Network</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>bc</p></td>
|
||||
<td><p>Bitcoin mainnet</p></td>
|
||||
</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
|
||||
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
|
||||
// O_16 OP_PUSH2 0000
|
||||
|
||||
[[scripts_for_diff_segwit_outputs]]
|
||||
.Scripts for different types of segwit outputs
|
||||
[options="header"]
|
||||
[cols="1,1"]
|
||||
|===
|
||||
++++
|
||||
<table id="scripts_for_diff_segwit_outputs">
|
||||
<caption>Scripts for different types of segwit outputs</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Output type</th>
|
||||
<th>Example script</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>P2WPKH</p></td>
|
||||
<td><p>OP_0 2b626ed108ad00a944bb2922a309844611d25468</p></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><p>P2WSH</p></td>
|
||||
<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>
|
||||
++++
|
||||
|
||||
|Output type
|
||||
|Example script
|
||||
|
||||
| P2WPKH
|
||||
| OP_0 2b626ed108ad00a944bb2922a309844611d25468
|
||||
|
||||
| P2WSH
|
||||
| OP_0 648a32e50b6fb7c5233b228f60a6a2ca4158400268844c4bc295ed5e8c3d626f
|
||||
|
||||
| P2TR
|
||||
| OP_1 2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311
|
||||
|
||||
| Future Example
|
||||
| OP_16 0000
|
||||
|===
|
||||
|
||||
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
|
||||
@ -1411,29 +1457,63 @@ 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
|
||||
| WIF | 5 | Base58check encoding: base58 with version prefix of 128 and 32-bit checksum
|
||||
| WIF-compressed | K or L | As above, with added suffix 0x01 before encoding
|
||||
|=======
|
||||
++++
|
||||
<table id="table_4-2">
|
||||
<caption>Private key representations (encoding formats)</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Type</th>
|
||||
<th>Prefix</th>
|
||||
<th>Description</th>
|
||||
</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]]
|
||||
.Example: Same key, different formats
|
||||
[options="header"]
|
||||
[cols="1,1"]
|
||||
|=======
|
||||
|Format | Private key
|
||||
| Hex | 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd
|
||||
| WIF | 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn
|
||||
| WIF-compressed | KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ
|
||||
|=======
|
||||
++++
|
||||
<table id="table_4-3">
|
||||
<caption>Example: Same key, different formats</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Format</th>
|
||||
<th>Private key</th>
|
||||
</tr>
|
||||
</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
|
||||
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]]
|
||||
.Example: Same key, different formats
|
||||
[options="header"]
|
||||
[cols="1,1"]
|
||||
|=======
|
||||
|Format | Private key
|
||||
| Hex | 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD
|
||||
| WIF | 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn
|
||||
| Hex-compressed | 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD01
|
||||
| WIF-compressed | KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ
|
||||
|=======
|
||||
++++
|
||||
<table id="table_4-3">
|
||||
<caption>Example: Same key, different formats</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Format</th>
|
||||
<th>Private key</th>
|
||||
</tr>
|
||||
</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>
|
||||
++++
|
||||
|
||||
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
|
||||
@ -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
|
||||
prefix 1Kids.
|
||||
|
||||
[[table_4-11]]
|
||||
.The range of vanity addresses starting with "1Kids"
|
||||
|=======
|
||||
| *From* | +1Kids11111111111111111111111111111+
|
||||
| | +1Kids11111111111111111111111111112+
|
||||
| | +1Kids11111111111111111111111111113+
|
||||
| | +...+
|
||||
| *To* | +1Kidszzzzzzzzzzzzzzzzzzzzzzzzzzzzz+
|
||||
|=======
|
||||
++++
|
||||
<table id="table_4-11">
|
||||
<caption>The range of vanity addresses starting with “1Kids”</caption>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p><strong>From</strong></p></td>
|
||||
<td><p><code>1Kids11111111111111111111111111111</code></p></td>
|
||||
</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
|
||||
might find this pattern in a Bitcoin address (see <<table_4-12>>). An
|
||||
average desktop computer PC, without any specialized hardware, can
|
||||
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
|
||||
| 2 | 1Ki| 1 in 3,364 | 50 milliseconds
|
||||
| 3 | 1Kid | 1 in 195,000 | < 2 seconds
|
||||
| 4 | 1Kids | 1 in 11 million | 1 minute
|
||||
| 5 | 1KidsC | 1 in 656 million | 1 hour
|
||||
| 6 | 1KidsCh | 1 in 38 billion | 2 days
|
||||
| 7 | 1KidsCha | 1 in 2.2 trillion | 3–4 months
|
||||
| 8 | 1KidsChar | 1 in 128 trillion | 13–18 years
|
||||
| 9 | 1KidsChari | 1 in 7 quadrillion | 800 years
|
||||
| 10 | 1KidsCharit | 1 in 400 quadrillion | 46,000 years
|
||||
| 11 | 1KidsCharity | 1 in 23 quintillion | 2.5 million years
|
||||
|=======
|
||||
++++
|
||||
<table id="table_4-12">
|
||||
<caption>The frequency of a vanity pattern (1KidsCharity) and average search time on a desktop PC</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Length</th>
|
||||
<th>Pattern</th>
|
||||
<th>Frequency</th>
|
||||
<th>Average search time</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>1</p></td>
|
||||
<td><p>1K</p></td>
|
||||
<td><p>1 in 58 keys</p></td>
|
||||
<td><p>< 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>< 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>3–4 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>13–18 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
|
||||
"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
|
||||
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
|
||||
| 2023-01-02 | Paid Bob for podcast | −0.00075
|
||||
|===
|
||||
++++
|
||||
<table id="alice_tx_labels">
|
||||
<caption>Alice’s transaction history with each transaction labeled</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Date</th>
|
||||
<th>Label</th>
|
||||
<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
|
||||
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
|
||||
paths_. Several popular implicit paths defined by BIPs are shown in <<bip_implicit_paths>>
|
||||
|
||||
[[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'+
|
||||
| BIP49 | Nested P2WPKH | +m/49'/1'/0'+
|
||||
| BIP84 | P2WPKH | +m/84'/0'/0'+
|
||||
| BIP86 | P2TR Single-key | +m/86'/0'/0'+
|
||||
|===
|
||||
++++
|
||||
<table id="bip_implicit_paths">
|
||||
<caption>Implicit script paths defined by various BIPs</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Standard</th>
|
||||
<th>Script</th>
|
||||
<th>BIP32 path</th>
|
||||
</tr>
|
||||
</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
|
||||
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.
|
||||
A few example descriptors are shown in <<sample_descriptors>>.
|
||||
|
||||
[[sample_descriptors]]
|
||||
.Sample descriptors from Bitcoin Core documentation (with elision)
|
||||
[cols="1,1"]
|
||||
|===
|
||||
| Descriptor | Explanation
|
||||
++++
|
||||
<table id="sample_descriptors">
|
||||
<caption>Sample descriptors from Bitcoin Core documentation (with elision)</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Descriptor</th>
|
||||
<th>Explanation</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<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(02c6...9ee5)+
|
||||
| P2PKH script for the provided public key
|
||||
|
||||
| +sh(multi(2,022f...2a01,03ac...ccbe))+
|
||||
| P2SH multisignature requring two signatures corresponding to these two keys
|
||||
|
||||
| +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
|
||||
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
|
||||
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
|
||||
| 160 | 5 | 165 | 15
|
||||
| 192 | 6 | 198 | 18
|
||||
| 224 | 7 | 231 | 21
|
||||
| 256 | 8 | 264 | 24
|
||||
|=======
|
||||
++++
|
||||
<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>
|
||||
++++
|
||||
|
||||
++++
|
||||
<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]]
|
||||
===== From recovery code to seed
|
||||
@ -772,41 +900,78 @@ pass:[<a data-type="xref" href="#bip39_256_no_pass"
|
||||
data-xrefstyle="select: labelnumber">#bip39_256_no_pass</a>] show
|
||||
some examples of recovery codes and the seeds they produce.
|
||||
|
||||
[[bip39_128_no_pass]]
|
||||
.128-bit entropy BIP39 recovery code, no passphrase, resulting seed
|
||||
[cols="h,"]
|
||||
|=======
|
||||
| *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)* | +5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4+
|
||||
+c67196f57c39a88b76373733891bfaba16ed27a813ceed498804c0570+
|
||||
|=======
|
||||
++++
|
||||
<table id="bip39_128_no_pass">
|
||||
<caption>128-bit entropy BIP39 recovery code, no passphrase, resulting seed</caption>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p><strong>Entropy input (128 bits)</strong></p></td>
|
||||
<td><p><code>0c1e24e5917779d297e14d45f14e1a1a</code></p></td>
|
||||
</tr>
|
||||
<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>
|
||||
</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>5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4</code>
|
||||
<code>c67196f57c39a88b76373733891bfaba16ed27a813ceed498804c0570</code></p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
[[bip39_128_w_pass]]
|
||||
.128-bit entropy BIP39 recovery code, with passphrase, resulting seed
|
||||
[cols="h,"]
|
||||
|=======
|
||||
| *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)* | +3b5df16df2157104cfdd22830162a5e170c0161653e3afe6c88defeefb0818c793dbb28+
|
||||
+ab3ab091897d0715861dc8a18358f80b79d49acf64142ae57037d1d54+
|
||||
|=======
|
||||
<table id="bip39_128_w_pass">
|
||||
<caption>128-bit entropy BIP39 recovery code, with passphrase, resulting seed</caption>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p><strong>Entropy input (128 bits)</strong></p></td>
|
||||
<td><p><code>0c1e24e5917779d297e14d45f14e1a1a</code></p></td>
|
||||
</tr>
|
||||
<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>
|
||||
</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>
|
||||
++++
|
||||
|
||||
|
||||
[[bip39_256_no_pass]]
|
||||
.256-bit entropy BIP39 recovery code, no passphrase, resulting seed
|
||||
[cols="h,"]
|
||||
|=======
|
||||
| *Entropy input (256 bits)* | +2041546864449caff939d32d574753fe684d3c947c3346713dd8423e74abcf8c+
|
||||
| *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)* | +3269bce2674acbd188d4f120072b13b088a0ecf87c6e4cae41657a0bb78f5315b33b3+
|
||||
+a04356e53d062e55f1e0deaa082df8d487381379df848a6ad7e98798404+
|
||||
|=======
|
||||
|
||||
.How Much Entropy Do You Need?
|
||||
****
|
||||
BIP32 allows seeds to be from 128 to 512 bits. BIP39 accepts from 128
|
||||
@ -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
|
||||
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)
|
||||
| m/0/0 | The first grandchild private key from the first child (m/0)
|
||||
| m/0'/0 | The first normal grandchild private key from the first _hardened_ child (m/0')
|
||||
| m/1/0 | The first grandchild private key from the second child (m/1)
|
||||
| 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
|
||||
|=======
|
||||
++++
|
||||
<table id="table_4-8">
|
||||
<caption>HD wallet path examples</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>HD path</th>
|
||||
<th>Key described</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<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
|
||||
|
||||
@ -1354,16 +1540,31 @@ third receiving address for payments in the primary account
|
||||
would be M/44++'++/0++'++/0++'++/0/2. <<table_4-9>> shows
|
||||
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
|
||||
| M/44++'++/0++'++/3++'++/1/14 | The fifteenth change-address public key for the fourth Bitcoin account
|
||||
| m/44++'++/2++'++/0++'++/0/1 | The second private key in the Litecoin main account, for signing transactions
|
||||
|=======
|
||||
++++
|
||||
<table id="table_4-9">
|
||||
<caption>BIP44 HD wallet structure examples</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>HD path</th>
|
||||
<th>Key described</th>
|
||||
</tr>
|
||||
</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
|
||||
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
|
||||
unsigned integers:
|
||||
|
||||
[cols="1,1,1"]
|
||||
[options="header"]
|
||||
|===
|
||||
| Value | Bytes used | Format
|
||||
| >= +0+ && \<= +252+ (++0xfc++) | +1+ | +uint8_t+
|
||||
| >= +253+ && \<= +0xffff+ | 3 | +0xfd+ followed by the number as +uint16_t+
|
||||
| >= +0x10000+ && \<= +0xffffffff+ | +5+ | +0xfe+ followed by the number as +uint32_t+
|
||||
| >= +0x100000000+ && \<= +0xffffffffffffffff+ | +9+ | +0xff+ followed by the number as +uint64_t+
|
||||
|===
|
||||
****
|
||||
++++
|
||||
<table>
|
||||
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Value</th>
|
||||
<th>Bytes used</th>
|
||||
<th>Format</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>>= <code>0</code> && <= <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>>= <code>253</code> && <= <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>>= <code>0x10000</code> && <= <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>>= <code>0x100000000</code> && <= <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:
|
||||
|
||||
@ -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
|
||||
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
|
||||
[cols="1,1,1"]
|
||||
|===
|
||||
| | **Authorization** | **Authentication**
|
||||
| **Whitepaper** | Public key | Signature
|
||||
| **Original (Legacy)** | Output script | Input script
|
||||
| **Segwit** | Witness program | Witness structure
|
||||
|===
|
||||
++++
|
||||
<table id="terms_used_authorization_authentication">
|
||||
<caption>Terms used for authorization and authentication data in different parts of Bitcoin</caption>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td/>
|
||||
<td><p><strong>Authorization</strong></p></td>
|
||||
<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
|
||||
|
||||
@ -1118,26 +1160,83 @@ reduce the weight used when spending a UTXO. This helps discourage the
|
||||
creation of uneconomical outputs as described in
|
||||
<<uneconomical_outputs>>.
|
||||
|
||||
[[weight_factors]]
|
||||
.Weight factors for all fields in a Bitcoin transaction
|
||||
[cols="1,1,1"]
|
||||
[option="header"]
|
||||
|===
|
||||
| Field | Factor | Weight in Alice's Tx
|
||||
| Version | 4 | 16
|
||||
| Marker & Flag | 1 | 2
|
||||
| Inputs Count | 4 | 4
|
||||
| Outpoint | 4 | 144
|
||||
| Input script | 4 | 4
|
||||
| Sequence | 4 | 16
|
||||
| Outputs Count | 4 | 4
|
||||
| Amount | 4 | 64 (2 outputs)
|
||||
| Output script | 4 | 232 (2 outputs with different scripts)
|
||||
| Witness Count | 1 | 1
|
||||
| Witness items | 1 | 66
|
||||
| Lock time | 4 | 16
|
||||
| **Total** | _N/A_ | **569**
|
||||
|===
|
||||
++++
|
||||
<table id="weight_factors">
|
||||
<caption>Weight factors for all fields in a Bitcoin transaction</caption>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>Field</p></td>
|
||||
<td><p>Factor</p></td>
|
||||
<td><p>Weight in Alice’s Tx</p></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><p>Version</p></td>
|
||||
<td><p>4</p></td>
|
||||
<td><p>16</p></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><p>Marker & Flag</p></td>
|
||||
<td><p>1</p></td>
|
||||
<td><p>2</p></td>
|
||||
</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
|
||||
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
|
||||
with P2SH.
|
||||
|
||||
[[without_p2sh]]
|
||||
.Complex script without P2SH
|
||||
|=======
|
||||
| Output script | 2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 OP_CHECKMULTISIG
|
||||
| Input script | Sig1 Sig2
|
||||
|=======
|
||||
|
||||
[[with_p2sh]]
|
||||
.Complex script as P2SH
|
||||
|=======
|
||||
| Redeem script | 2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 OP_CHECKMULTISIG
|
||||
| Output script | OP_HASH160 <20-byte hash of redeem script> OP_EQUAL
|
||||
| Input script | Sig1 Sig2 <redeem script>
|
||||
|=======
|
||||
++++
|
||||
<table id="without_p2sh">
|
||||
<caption>Complex script without P2SH</caption>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>Output script</p></td>
|
||||
<td><p>2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 OP_CHECKMULTISIG</p></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><p>Input script</p></td>
|
||||
<td><p>Sig1 Sig2</p></td>
|
||||
</tr>
|
||||
</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 <20-byte hash of redeem script> OP_EQUAL</p></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><p>Input script</p></td>
|
||||
<td><p>Sig1 Sig2 <redeem script></p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
++++
|
||||
|
||||
As you can see from the tables, with P2SH the complex script that
|
||||
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
|
||||
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
|
||||
| ++NONE++ | ++0x02++ | Signature applies to all inputs, none of the outputs
|
||||
| ++SINGLE++ | ++0x03++ | Signature applies to all inputs but only the one output with the same index number as the signed input
|
||||
|=======================
|
||||
++++
|
||||
<table id="sighash_types_and_their">
|
||||
<caption>
|
||||
<span class="plain"><code>SIGHASH</code></span> types and their meanings</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th><code>SIGHASH</code> flag</th>
|
||||
<th>Value</th>
|
||||
<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
|
||||
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
|
||||
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
|
||||
| ++NONE\|ANYONECANPAY++ | ++0x82++ | Signature applies to one input, none of the outputs
|
||||
| ++SINGLE\|ANYONECANPAY++ | ++0x83++ | Signature applies to one input and the output with the same index number
|
||||
|=======================
|
||||
++++
|
||||
<table id="sighash_types_with_modifiers">
|
||||
<caption>
|
||||
<span class="plain"><code>SIGHASH</code></span> types with modifiers and their meanings</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th><code>SIGHASH</code> flag</th>
|
||||
<th>Value</th>
|
||||
<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
|
||||
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
|
||||
header. <<block_structure1>> describes how Bitcoin Core stores the structure of a block.
|
||||
|
||||
[[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
|
||||
| 80 bytes | Block Header | Several fields form the block header
|
||||
| 1–3 bytes (compactSize) | Transaction Counter | How many transactions follow
|
||||
| Variable | Transactions | The transactions recorded in this block
|
||||
|=======
|
||||
++++
|
||||
<table id="block_structure1">
|
||||
<caption>The structure of a block</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Size</th>
|
||||
<th>Field</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
</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>1–3 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
|
||||
@ -95,19 +119,50 @@ header. <<block_structure1>> describes how Bitcoin Core stores the structure of
|
||||
The block header consists of
|
||||
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
|
||||
| 32 bytes | Previous Block Hash | A hash of the previous (parent) block in the chain
|
||||
| 32 bytes | Merkle Root | The root hash of the merkle tree of this block's transactions
|
||||
| 4 bytes | Timestamp | The approximate creation time of this block (Unix epoch time)
|
||||
| 4 bytes | Target | A compact encoding of the proof-of-work target for this block
|
||||
| 4 bytes | Nonce | Arbitrary data used for the proof-of-work algorithm
|
||||
|=======
|
||||
++++
|
||||
<table id="block_header_structure_ch09">
|
||||
<caption>The structure of the block header</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Size</th>
|
||||
<th>Field</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<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 block’s 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
|
||||
process and will be discussed in more detail in <<mining>>.
|
||||
|
||||
158
ch12_mining.adoc
158
ch12_mining.adoc
@ -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 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
|
||||
| 4 bytes | Output Index | The index number of the UTXO to be spent, first one is 0
|
||||
| 1–9 bytes (compactSize) | Script Size | Script length in bytes, to follow
|
||||
| Variable | Input Script | A script that fulfills the conditions of the UTXO output script
|
||||
| 4 bytes | Sequence Number | Multipurpose field used for BIP68 timelocks and transaction replacement signaling
|
||||
|=======
|
||||
|
||||
[[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
|
||||
| 4 bytes | Output Index | All bits are ones: 0xFFFFFFFF
|
||||
| 1 byte | Coinbase Data Size | Length of the coinbase data, from 2 to 100 bytes
|
||||
| Variable | Coinbase Data | Arbitrary data used for extra nonce and mining tags. In v2 blocks; must begin with block height
|
||||
| 4 bytes | Sequence Number | Set to 0xFFFFFFFF
|
||||
|=======
|
||||
++++
|
||||
<table id="table_8-1">
|
||||
<caption><span class="label">Table 12-1. </span>The structure of a “normal” 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>Pointer to the transaction containing the UTXO to be spent</p></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><p>4 bytes</p></td>
|
||||
<td><p>Output Index</p></td>
|
||||
<td><p>The index number of the UTXO to be spent, first one is 0</p></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><p>1–9 bytes (compactSize)</p></td>
|
||||
<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
|
||||
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,
|
||||
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
|
||||
| 32 bytes | Previous Block Hash | A reference to the hash of the previous (parent) block in the chain
|
||||
| 32 bytes | Merkle Root | A hash that is the root of the merkle tree of this block's transactions
|
||||
| 4 bytes | Timestamp | The approximate creation time of this block (seconds from Unix Epoch)
|
||||
| 4 bytes | Target | The Proof-of-Work algorithm target for this block
|
||||
| 4 bytes | Nonce | A counter used for the Proof-of-Work algorithm
|
||||
|=======
|
||||
++++
|
||||
<table id="block_header_structure_ch10">
|
||||
<caption>The structure of the block header</caption>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Size</th>
|
||||
<th>Field</th>
|
||||
<th>Description</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<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 block’s 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
|
||||
upgrades to the Bitcoin network, those defined in BIPs 34, 66, and 65.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user