From 781fd5b87d862c0c5b856c73a60a2dae7d600f6b Mon Sep 17 00:00:00 2001 From: Clare Laylock Date: Wed, 11 Oct 2023 15:29:37 -0400 Subject: [PATCH] table fix --- ch01_intro.adoc | 2 +- ch04_keys.adoc | 387 ++++++++++++++++------- ch05_wallets.adoc | 405 ++++++++++++++++++------- ch06_transactions.adoc | 177 ++++++++--- ch07_authorization-authentication.adoc | 46 ++- ch08_signatures.adoc | 80 +++-- ch11_blockchain.adoc | 103 +++++-- ch12_mining.adoc | 158 +++++++--- 8 files changed, 1014 insertions(+), 344 deletions(-) diff --git a/ch01_intro.adoc b/ch01_intro.adoc index 65d5eebe..b9d8d3ba 100644 --- a/ch01_intro.adoc +++ b/ch01_intro.adoc @@ -284,7 +284,7 @@ examples. ++++ - + diff --git a/ch04_keys.adoc b/ch04_keys.adoc index 7ff21505..f605a80b 100644 --- a/ch04_keys.adoc +++ b/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 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 1-1. Sample recovery codesSample recovery codes
Wallet
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Base58check version prefix and encoded result examples
TypeVersion 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

+++++ 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 -[cols="1,1"] -[options="header"] -|=== - -| HRPs -| Network - -| bc -| Bitcoin mainnet - -| tb -| Bitcoin testnet -|=== +++++ + + + + + + + + + + + + + + + + + + +
Bech32 HRPs for Bitcoin
HRPsNetwork

bc

Bitcoin mainnet

tb

Bitcoin testnet

+++++ 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 <>. // bc1sqqqqkfw08p // O_16 OP_PUSH2 0000 -[[scripts_for_diff_segwit_outputs]] -.Scripts for different types of segwit outputs -[options="header"] -[cols="1,1"] -|=== - -|Output type -|Example script - -| P2WPKH -| OP_0 2b626ed108ad00a944bb2922a309844611d25468 - -| P2WSH -| OP_0 648a32e50b6fb7c5233b228f60a6a2ca4158400268844c4bc295ed5e8c3d626f - -| P2TR -| OP_1 2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311 +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Scripts for different types of segwit outputs
Output typeExample script

P2WPKH

OP_0 2b626ed108ad00a944bb2922a309844611d25468

P2WSH

OP_0 648a32e50b6fb7c5233b228f60a6a2ca4158400268844c4bc295ed5e8c3d626f

P2TR

OP_1 2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311

Future Example

OP_16 0000

+++++ -| 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 <>. A public key is passed into a SHA256 hash @@ -1411,29 +1457,63 @@ See <> 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 -|======= +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + +
Private key representations (encoding formats)
TypePrefixDescription

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

+++++ <> 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 -|======= +++++ + + + + + + + + + + + + + + + + + + + + + + +
Example: Same key, different formats
FormatPrivate key

Hex

1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd

WIF

5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn

WIF-compressed

KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ

+++++ 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 <> 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 -|======= +++++ + + + + + + + + + + + + + + + + + + + + + + +
Example: Same key, different formats
FormatPrivate key

Hex

1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd

WIF

5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn

WIF-compressed

KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ

+++++ 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." <> 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+ -|======= +++++ + + + + + + + + + + + + + + + + + + + + + +
The range of vanity addresses starting with “1Kids”

From

1Kids11111111111111111111111111111

+

1Kids11111111111111111111111111112

+

1Kids11111111111111111111111111113

+

…​

To

1Kidszzzzzzzzzzzzzzzzzzzzzzzzzzzzz

+++++ Let's look at the pattern "1Kids" as a number and see how frequently we might find this pattern in a Bitcoin address (see <>). 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 -|======= +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
The frequency of a vanity pattern (1KidsCharity) and average search time on a desktop PC
LengthPatternFrequencyAverage 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

+++++ As you can see, Eugenia won't be creating the vanity address "1KidsCharity" anytime soon, even if she had access to several thousand diff --git a/ch05_wallets.adoc b/ch05_wallets.adoc index fe0e634c..e8af93ea 100644 --- a/ch05_wallets.adoc +++ b/ch05_wallets.adoc @@ -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'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 -|=== +++++ + + + + + + + + + + + + + + + + + + + + + +
Alice’s transaction history with each transaction labeled
DateLabelBTC

2023-01-01

Bought bitcoins from Joe

+0.00100

2023-01-02

Paid Bob for podcast

−0.00075

+++++ 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]] -.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'+ -|=== +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Implicit script paths defined by various BIPs
StandardScriptBIP32 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'

+++++ 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 from Bitcoin Core documentation (with elision) -[cols="1,1"] -|=== -| Descriptor | Explanation - -| +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 +++++ + + + + + + + + + + + + + + + + + + + + + + +
Sample descriptors from Bitcoin Core documentation (with elision)
DescriptorExplanation

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

+++++ -| +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" <> 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 -|======= +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BIP39: entropy and word length
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

+++++ + +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BIP39: entropy and word length
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

+++++ [[recovery_to_seed]] ===== From recovery code to seed @@ -772,40 +900,77 @@ pass:[#bip39_256_no_pass] 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+ -|======= - -[[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+ -|======= - - -[[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+ -|======= +++++ + + + + + + + + + + + + + + + + + + + + +
128-bit entropy BIP39 recovery code, no passphrase, resulting seed

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

+ + + + + + + + + + + + + + + + + + + + + +
128-bit entropy BIP39 recovery code, with passphrase, resulting seed

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 5-7. 256-bit entropy BIP39 recovery code, no passphrase, resulting seed

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? **** @@ -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 -|======= +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
HD wallet path examples
HD pathKey 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

+++++ ===== 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. <> 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 -|======= +++++ + + + + + + + + + + + + + + + + + + + + + + +
BIP44 HD wallet structure examples
HD pathKey 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

+++++ Many people focus on securing their bitcoins against theft and other attacks, but one of the leading causes of lost bitcoins--perhaps _the_ diff --git a/ch06_transactions.adoc b/ch06_transactions.adoc index 3ce7e548..0655065f 100644 --- a/ch06_transactions.adoc +++ b/ch06_transactions.adoc @@ -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+ -|=== -**** +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ValueBytes usedFormat

>= 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

+++++ 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 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 -|=== +++++ + + + + + + + + + + + + + + + + + + + + + + + +
Terms used for authorization and authentication data in different parts of Bitcoin
+

Authorization

Authentication

Whitepaper

Public key

Signature

Original (Legacy)

Output script

Input script

Segwit

Witness program

Witness structure

+++++ ==== 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 <>. -[[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** -|=== +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Weight factors for all fields in a Bitcoin transaction

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

+++++ We can verify our weight calculation by getting the total for Alice's transaction from Bitcoin Core: diff --git a/ch07_authorization-authentication.adoc b/ch07_authorization-authentication.adoc index 422839c5..4e2ca57b 100644 --- a/ch07_authorization-authentication.adoc +++ b/ch07_authorization-authentication.adoc @@ -519,20 +519,38 @@ redemption time rather than as an output script. <> shows the script without P2SH and <> 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 -|======= +++++ + + + + + + + + + + + + +
Complex script without P2SH

Output script

2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 OP_CHECKMULTISIG

Input script

Sig1 Sig2

+ + + + + + + + + + + + + + + + +
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>

+++++ As you can see from the tables, with P2SH the complex script that details the conditions for spending the output (redeem script) is not diff --git a/ch08_signatures.adoc b/ch08_signatures.adoc index 78ce3213..5b880246 100644 --- a/ch08_signatures.adoc +++ b/ch08_signatures.adoc @@ -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]] -.[.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 -|======================= +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+SIGHASH types and their meanings
SIGHASH flagValueDescription

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

+++++ 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]] -.[.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 -|======================= +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + +
+SIGHASH types with modifiers and their meanings
SIGHASH flagValueDescription

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

+++++ The way +SIGHASH+ flags are applied during signing and verification is that a copy of the transaction is made and certain fields within are diff --git a/ch11_blockchain.adoc b/ch11_blockchain.adoc index 98561c74..c4433451 100644 --- a/ch11_blockchain.adoc +++ b/ch11_blockchain.adoc @@ -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. <> 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 -|======= +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
The structure of a block
SizeFieldDescription

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

+++++ + [[block_header]] === Block Header @@ -95,19 +119,50 @@ header. <> describes how Bitcoin Core stores the structure of The block header consists of block metadata as shown in <>. -[[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 -|======= +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
The structure of the block header
SizeFieldDescription

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

+++++ The nonce, target, and timestamp are used in the mining process and will be discussed in more detail in <>. diff --git a/ch12_mining.adoc b/ch12_mining.adoc index 63213150..f326e4d8 100644 --- a/ch12_mining.adoc +++ b/ch12_mining.adoc @@ -458,31 +458,82 @@ input with a coinbase transaction input. <> shows the structure of a regular transaction, while <> 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 12-1. The structure of a “normal” transaction input
SizeFieldDescription

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 12-2. The structure of a coinbase transaction input
SizeFieldDescription

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

+++++ 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]] -.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 -|======= +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
The structure of the block header
SizeFieldDescription

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

+++++ 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.