mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-11-21 15:48:09 +00:00
QC2 and checklist edits
This commit is contained in:
Clare Laylock
parent
cc8a155b5f
commit
7e9339ef12
@ -1,6 +1,7 @@
|
||||
[[satoshi_whitepaper]]
|
||||
[appendix]
|
||||
== The Bitcoin Whitepaper by Satoshi Nakamoto
|
||||
== The Bitcoin Whitepaper [.keep-together]#by Satoshi Nakamoto#
|
||||
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
[appendix]
|
||||
== Bitcoin Improvement Proposals
|
||||
|
||||
Bitcoin Improvement Proposals are design documents providing information to the Bitcoin community, or for describing a new feature for Bitcoin or its processes or environment.
|
||||
Bitcoin Improvement Proposals are design documents providing information to the Bitcoin community or describing a new feature for Bitcoin or its processes or environment.
|
||||
|
||||
As per BIP1 _BIP Purpose and Guidelines_, there are three((("BIPs (Bitcoin Improvement Proposals)", "types of"))) kinds of BIPs:
|
||||
|
||||
@ -30,37 +30,37 @@ BIPs that are ((("BIPs (Bitcoin Improvement Proposals)", "implemented by Bitcoin
|
||||
- BIP31: The 'pong' protocol message (and the protocol version bump to 60001) has been implemented since v0.6.1 (PR #1081).
|
||||
- BIP32: Hierarchical Deterministic Wallets has been implemented since v0.13.0 (PR #8035).
|
||||
- BIP34: The rule that requires blocks to contain their height (number) in the coinbase input, and the introduction of version 2 blocks has been implemented since v0.7.0. The rule took effect for version 2 blocks as of block 224413 (March 5th 2013), and version 1 blocks are no longer allowed since block 227931 (March 25th 2013) (PR #1526).
|
||||
- BIP35: The 'mempool' protocol message (and the protocol version bump to 60002) has been implemented since v0.7.0 (PR #1641). As of v0.13.0, this is only available for NODE_BLOOM (BIP111) peers.
|
||||
- BIP35: The 'mempool' protocol message (and the protocol version bump to 60002) has been implemented since v0.7.0 (PR #1641). As of v0.13.0, this is only available for +NODE_BLOOM+ (BIP111) peers.
|
||||
|
||||
[role="less_space pagebreak-before"]
|
||||
- BIP37: The bloom filtering for transaction relaying, partial Merkle trees for blocks, and the protocol version bump to 70001 (enabling low-bandwidth lightweight clients) has been implemented since v0.8.0 (PR #1795). Disabled by default since v0.19.0, can be enabled by the -peerbloomfilters option.
|
||||
- BIP37: The bloom filtering for transaction relaying, partial Merkle trees for blocks, and the protocol version bump to 70001 (enabling low-bandwidth lightweight clients) has been implemented since v0.8.0 (PR #1795). Disabled by default since v0.19.0, can be enabled by the +-peerbloomfilters+ option.
|
||||
- BIP42: The bug that would have caused the subsidy schedule to resume after block 13440000 was fixed in v0.9.2 (PR #3842).
|
||||
- BIP43: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP43. (PR #16528)
|
||||
- BIP44: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP44. (PR #16528)
|
||||
- BIP49: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP49. (PR #16528)
|
||||
- BIP61: The 'reject' protocol message (and the protocol version bump to 70002) was added in v0.9.0 (PR #3185). Starting v0.17.0, whether to send reject messages can be configured with the -enablebip61 option, and support is deprecated (disabled by default) as of v0.18.0. Support was removed in v0.20.0 (PR #15437).
|
||||
- BIP65: The CHECKLOCKTIMEVERIFY soft fork was merged in v0.12.0 (PR #6351), and backported to v0.11.2 and v0.10.4. Mempool-only CLTV was added in PR #6124.
|
||||
- BIP43: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP43 (PR #16528).
|
||||
- BIP44: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP44 (PR #16528).
|
||||
- BIP49: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP49 (PR #16528).
|
||||
- BIP61: The 'reject' protocol message (and the protocol version bump to 70002) was added in v0.9.0 (PR #3185). Starting v0.17.0, whether to send reject messages can be configured with the ++-enablebip61++ option, and support is deprecated (disabled by default) as of v0.18.0. Support was removed in v0.20.0 (PR #15437).
|
||||
- BIP65: The ++CHECKLOCKTIMEVERIFY++ soft fork was merged in v0.12.0 (PR #6351), and backported to v0.11.2 and v0.10.4. Mempool-only +CLTV+ was added in PR #6124.
|
||||
- BIP66: The strict DER rules and associated version 3 blocks have been implemented since v0.10.0 (PR #5713).
|
||||
- BIP68: Sequence locks have been implemented as of v0.12.1 (PR #7184), and have been buried since v0.19.0 (PR #16060).
|
||||
- BIP70 71 72: Payment Protocol support has been available in Bitcoin Core GUI since v0.9.0 (PR #5216). Support can be optionally disabled at build time since v0.18.0 (PR 14451), and it is disabled by default at build time since v0.19.0 (PR #15584). It has been removed as of v0.20.0 (PR 17165).
|
||||
- BIP84: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP84. (PR #16528)
|
||||
- BIP86: Descriptor wallets by default use the Hierarchical Deterministic Wallet derivation proposed by BIP86 since v23.0 (PR #22364).
|
||||
- BIP90: Trigger mechanism for activation of BIPs 34, 65, and 66 has been simplified to block height checks since v0.14.0 (PR #8391).
|
||||
- BIP111: NODE_BLOOM service bit added and enforced for all peer versions as of v0.13.0 (PR #6579 and PR #6641).
|
||||
- BIP112: The CHECKSEQUENCEVERIFY opcode has been implemented since v0.12.1 (PR #7524), and has been buried since v0.19.0 (PR #16060).
|
||||
- BIP111: +NODE_BLOOM+ service bit added and enforced for all peer versions as of v0.13.0 (PR #6579 and PR #6641).
|
||||
- BIP112: The +CHECKSEQUENCEVERIFY+ opcode has been implemented since v0.12.1 (PR #7524), and has been buried since v0.19.0 (PR #16060).
|
||||
- BIP113: Median time past lock-time calculations have been implemented since v0.12.1 (PR #6566), and has been buried since v0.19.0 (PR #16060).
|
||||
- BIP125: Opt-in full replace-by-fee signaling partially implemented. See doc/policy/mempool-replacements.md.
|
||||
- BIP130: direct headers announcement is negotiated with peer versions >=70012 as of v0.12.0 (PR 6494).
|
||||
- BIP133: feefilter messages are respected and sent for peer versions >=70013 as of v0.13.0 (PR 7542).
|
||||
- BIP125: Opt-in full replace-by-fee signaling partially implemented.
|
||||
- BIP130: direct headers announcement is negotiated with peer versions ≥70012 as of v0.12.0 (PR 6494).
|
||||
- BIP133: feefilter messages are respected and sent for peer versions ≥70013 as of v0.13.0 (PR 7542).
|
||||
- BIP141: Segregated Witness (Consensus Layer) as of v0.13.0 (PR 8149), defined for mainnet as of v0.13.1 (PR 8937), and buried since v0.19.0 (PR #16060).
|
||||
- BIP143: Transaction Signature Verification for Version 0 Witness Program as of v0.13.0 (PR 8149), defined for mainnet as of v0.13.1 (PR 8937), and buried since v0.19.0 (PR #16060).
|
||||
- BIP144: Segregated Witness as of 0.13.0 (PR 8149).
|
||||
- BIP145: getblocktemplate updates for Segregated Witness as of v0.13.0 (PR 8149).
|
||||
- BIP147: NULLDUMMY soft fork as of v0.13.1 (PR 8636 and PR 8937), buried since v0.19.0 (PR #16060).
|
||||
- BIP147: +NULLDUMMY+ soft fork as of v0.13.1 (PR 8636 and PR 8937), buried since v0.19.0 (PR #16060).
|
||||
- BIP152: Compact block transfer and related optimizations are used as of v0.13.0 (PR 8068).
|
||||
- BIP155: The 'addrv2' and 'sendaddrv2' messages which enable relay of Tor V3 addresses (and other networks) are supported as of v0.21.0 (PR 19954).
|
||||
- BIP157 158: Compact Block Filters for Light Clients can be indexed as of v0.19.0 (PR #14121) and served to peers on the P2P network as of v0.21.0 (PR #16442).
|
||||
- BIP159: The NODE_NETWORK_LIMITED service bit is signalled as of v0.16.0 (PR 11740), and such nodes are connected to as of v0.17.0 (PR 10387).
|
||||
- BIP159: The +NODE_NETWORK_LIMITED+ service bit is signalled as of v0.16.0 (PR 11740), and such nodes are connected to as of v0.17.0 (PR 10387).
|
||||
- BIP173: Bech32 addresses for native Segregated Witness outputs are supported as of v0.16.0 (PR 11167). Bech32 addresses are generated by default as of v0.20.0 (PR 16884).
|
||||
- BIP174: RPCs to operate on Partially Signed Bitcoin Transactions (PSBT) are present as of v0.17.0 (PR 13557).
|
||||
- BIP176: Bits Denomination [QT only] is supported as of v0.16.0 (PR 12035).
|
||||
@ -70,4 +70,4 @@ BIPs that are ((("BIPs (Bitcoin Improvement Proposals)", "implemented by Bitcoin
|
||||
- BIP350: Addresses for native v1+ segregated Witness outputs use bech32m instead of bech32 as of v22.0 (PR 20861).
|
||||
- BIP371: Taproot fields for PSBT as of v24.0 (PR 22558).
|
||||
- BIP380 381 382 383 384 385: Output Script Descriptors, and most of Script Expressions are implemented as of v0.17.0 (PR 13697).
|
||||
- BIP386: tr() Output Script Descriptors are implemented as((("BIPs (Bitcoin Improvement Proposals)", "implemented by Bitcoin Core", startref="bips-implement")))((("Bitcoin Core", "BIPs implemented by", startref="bitcoin-core-bips"))) of v22.0 (PR 22051).
|
||||
- BIP386: +tr()+ Output Script Descriptors are implemented as((("BIPs (Bitcoin Improvement Proposals)", "implemented by Bitcoin Core", startref="bips-implement")))((("Bitcoin Core", "BIPs implemented by", startref="bitcoin-core-bips"))) of v22.0 (PR 22051).
|
||||
|
||||
@ -9,5 +9,5 @@
|
||||
|
||||
<p>As a bitcoin entrepreneur, Andreas has founded a number of Bitcoin businesses and launched several community open source projects. He serves as an advisor to several bitcoin and cryptocurrency companies. He is a widely published author of articles and blog posts on bitcoin, a permanent host on the popular Let’s Talk Bitcoin podcast, and a frequent speaker at technology and security conferences worldwide.</p>
|
||||
|
||||
<p><strong>David A. Harding</strong> is a technical writer focused on creating documentation for open source software. He is the coauthor of the Bitcoin Optech weekly newsletter (2018–23), 21.co Bitcoin Computer tutorials (2015–17), and Bitcoin.org developer documentation (2014–15). He is also a Brink.dev grant committee member (2022–23) and former board member (2020–22).</p>
|
||||
<p><strong>David A. Harding</strong> is a technical writer focused on creating documentation for open source software. He is the coauthor of the Bitcoin Optech weekly newsletter (2018–2023), 21.co Bitcoin Computer tutorials (2015–2017), and Bitcoin.org developer documentation (2014–2015). He is also a Brink.dev grant committee member (2022–2023) and former board member (2020–2022).</p>
|
||||
</section>
|
||||
|
||||
@ -374,7 +374,7 @@ nodes (called "peers"), consuming upload internet bandwidth. If your
|
||||
internet connection is limited, has a low data cap, or is metered
|
||||
(charged by the gigabit), you should probably not run a Bitcoin node on
|
||||
it, or run it in a way that constrains its bandwidth (see
|
||||
<<constrained_resources>>). You may connect your node instead to an
|
||||
<<bitcoincorenode_config>>). You may connect your node instead to an
|
||||
alternative network, such as a free satellite data provider like
|
||||
https://oreil.ly/cIwf3[Blockstream Satellite].
|
||||
|
||||
@ -390,7 +390,7 @@ transactions or update account balances until the full blockchain
|
||||
dataset is downloaded. Make sure you have enough disk space, bandwidth,
|
||||
and time to complete the initial synchronization. You can configure
|
||||
Bitcoin Core to reduce the size of the blockchain by discarding old
|
||||
blocks (see <<constrained_resources>>), but it will still download the
|
||||
blocks, but it will still download the
|
||||
entire dataset.
|
||||
====
|
||||
|
||||
@ -423,6 +423,7 @@ If you're reading this book and interested in strong security, superior
|
||||
privacy, or developing Bitcoin software, you should be running your ((("Bitcoin Core", "nodes", "running", startref="bitcoin-core-nodes-running")))((("nodes", "running", startref="nodes-running")))((("running nodes", startref="running-nodes")))own
|
||||
node.
|
||||
|
||||
[[bitcoincorenode_config]]
|
||||
=== Configuring the Bitcoin Core Node
|
||||
|
||||
Bitcoin Core will((("Bitcoin Core", "nodes", "configuring", id="bitcoin-core-nodes-configure")))((("nodes", "configuring", id="nodes-configure")))((("configuring", "nodes", id="configure-nodes"))) look for a
|
||||
@ -813,11 +814,11 @@ returned by +getrawtransaction+ and paste it as a parameter to
|
||||
|
||||
++++
|
||||
<pre data-type="programlisting">
|
||||
$ bitcoin-cli decoderawtransaction 01000000000101eb3ae38f27191aa5f3850dc9cad0↵
|
||||
0492b88b72404f9da135698679268041c54a0100000000ffffffff02204e00000000000022512↵
|
||||
03b41daba4c9ace578369740f15e5ec880c28279ee7f51b07dca69c7061e07068f82401000000↵
|
||||
00001600147752c165ea7be772b2c0acb7f4d6047ae6f4768e0141cf5efe2d8ef13ed0af21d4f↵
|
||||
4cb82422d6252d70324f6f4576b727b7d918e521c00b51be739df2f899c49dc267c0ad280aca6↵
|
||||
$ bitcoin-cli decoderawtransaction 01000000000101eb3ae38f27191aa5f3850dc9cad0\
|
||||
0492b88b72404f9da135698679268041c54a0100000000ffffffff02204e00000000000022512\
|
||||
03b41daba4c9ace578369740f15e5ec880c28279ee7f51b07dca69c7061e07068f82401000000\
|
||||
00001600147752c165ea7be772b2c0acb7f4d6047ae6f4768e0141cf5efe2d8ef13ed0af21d4f\
|
||||
4cb82422d6252d70324f6f4576b727b7d918e521c00b51be739df2f899c49dc267c0ad280aca6\
|
||||
dab0d2fa2b42a45182fc83e817130100000000
|
||||
</pre>
|
||||
++++
|
||||
@ -909,7 +910,7 @@ the parameter:
|
||||
|
||||
++++
|
||||
<pre data-type="programlisting">
|
||||
$ bitcoin-cli getblock 0000000000002917ed80650c6174aac8dfc46f5fe36480aaef682f↵
|
||||
$ bitcoin-cli getblock 0000000000002917ed80650c6174aac8dfc46f5fe36480aaef682f\
|
||||
f6cd83c3ca
|
||||
</pre>
|
||||
++++
|
||||
@ -973,10 +974,9 @@ The
|
||||
and testing functions. But the whole point of an API is to access functions programmatically. In this section we
|
||||
will demonstrate accessing Bitcoin Core from another program.
|
||||
|
||||
Bitcoin Core's API is a JSON-RPC interface. JSON stands for JavaScript
|
||||
Object Notation, and it is a very convenient way to present data that
|
||||
both humans and programs can easily read. RPC stands for Remote
|
||||
Procedure Call, which means that we are calling procedures (functions)
|
||||
Bitcoin Core's API is a JSON-RPC interface. JSON is a very convenient way to present data that
|
||||
both humans and programs can easily read. RPC stands for remote
|
||||
procedure call, which means that we are calling procedures (functions)
|
||||
that are remote (on the Bitcoin Core node) via a network protocol. In
|
||||
this case, the network protocol is HTTP.
|
||||
|
||||
@ -1168,7 +1168,7 @@ and more are created all the time.
|
||||
If you followed the instructions in this chapter, you now have Bitcoin
|
||||
Core running and have begun exploring the network and blockchain using
|
||||
your own full node. From now on you can independently use software you
|
||||
control, on a computer you control, to verify any bitcoins you receive
|
||||
control—on a computer you control—to verify that any bitcoins you receive
|
||||
follow every rule in the Bitcoin system without having to trust any
|
||||
outside authority. In the coming chapters, we'll learn more about the
|
||||
rules of the system and how your node and your wallet use them to secure
|
||||
|
||||
@ -384,7 +384,7 @@ geometric operation on the curve.
|
||||
[TIP]
|
||||
====
|
||||
Many Bitcoin implementations use
|
||||
the https://oreil.ly/wD60m[libsecp256k1 crytographic
|
||||
the https://oreil.ly/wD60m[libsecp256k1 cryptographic
|
||||
library] to do the elliptic curve((("public keys", "generating", startref="public-key-generate")))((("elliptic curve multiplication", startref="elliptic-multiply"))) math.
|
||||
====
|
||||
|
||||
@ -620,7 +620,7 @@ output, causing them to be lost forever. In the next section, we'll
|
||||
look at compact encoding and reliable ((("public key cryptography", "hash functions and", startref="pub-key-hash")))((("hash functions", "Bitcoin payments and", startref="hash-payment")))((("payments", "with hash functions", secondary-sortas="hash functions", startref="payment-hash")))((("P2PKH (pay to public key hash)", startref="p2pkh-legacy")))((("addresses", "P2PKH (pay to public key hash)", startref="address-p2pkh-legacy")))((("commitments", startref="commitment")))checksums.
|
||||
|
||||
[[base58]]
|
||||
=== Base58Check Encoding
|
||||
=== Base58check Encoding
|
||||
|
||||
In order((("public key cryptography", "base58check encoding", id="pub-key-base58")))((("base58check encoding", id="base58-ch4")))((("encoding", "base58check", id="encode-base58"))) to represent long numbers in a compact way,
|
||||
using fewer symbols, many computer systems use mixed-alphanumeric
|
||||
@ -690,7 +690,7 @@ encoding process.
|
||||
|
||||
[[base58check_encoding]]
|
||||
.Base58check encoding: a base58, versioned, and checksummed format for unambiguously encoding bitcoin data.
|
||||
image::images/mbc3_0406.png["Base58CheckEncoding"]
|
||||
image::images/mbc3_0406.png["Base58checkEncoding"]
|
||||
|
||||
++++
|
||||
<p class="fix_tracking2">
|
||||
@ -786,7 +786,7 @@ coordinate and reducing the size of the key and the space required to
|
||||
store it by 256 bits. An almost 50% reduction in size in every
|
||||
transaction adds up to a lot of data saved over time!
|
||||
|
||||
Here's the public key generated by the private key we created in
|
||||
Here is the public key generated by the private key we created in
|
||||
<<public_key_derivation>>:
|
||||
|
||||
----
|
||||
@ -800,7 +800,7 @@ y+:
|
||||
|
||||
++++
|
||||
<pre data-type="programlisting">
|
||||
K = 04F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF579DC341A↵
|
||||
K = 04F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF579DC341A\
|
||||
07CF33DA18BD734C600B96A72BBC4749D5141C90EC8AC328AE52DDFE2E505BDB
|
||||
</pre>
|
||||
++++
|
||||
@ -1082,7 +1082,7 @@ The "32" stands for the number of characters in the bech32 alphabet
|
||||
|
||||
- Bech32 uses only numbers and a single case of letters (preferably
|
||||
rendered in lowercase). Despite its alphabet being almost half the
|
||||
size of the base58check alphabet, a bech32 address for a P2WPKH script
|
||||
size of the base58check alphabet, a bech32 address for a pay to witness public key hash (P2WPKH) script
|
||||
is only slightly longer than a legacy address for an equivalent P2PKH
|
||||
script.
|
||||
|
||||
@ -1331,7 +1331,7 @@ function. The resultant 32-byte digest is then passed into a RIPEMD-160
|
||||
hash function. The digest of that function (the commitment) is placed
|
||||
in the witness program.
|
||||
|
||||
For the P2WSH output, we don't use the P2SH algorithm. Instead we take
|
||||
For the pay to witness script hash (P2WSH) output, we don't use the P2SH algorithm. Instead we take
|
||||
the script, pass it into a SHA256 hash function, and use the 32-byte
|
||||
digest of that function in the witness program. For P2SH, the SHA256
|
||||
digest was hashed again with RIPEMD-160, but that may not be secure in
|
||||
|
||||
@ -508,7 +508,7 @@ and automatically create complete backups of their wallet database
|
||||
encrypted by one of the keys derived from their seed. Bitcoin keys must
|
||||
be unguessable and modern encryption algorithms are considered very
|
||||
secure, so nobody should be able to open the encrypted backup except
|
||||
someone who can generate the seed, making it safe to store the backup on
|
||||
someone who can generate the seed. This makes it safe to store the backup on
|
||||
untrusted computers such as cloud hosting services or even random
|
||||
network peers.
|
||||
|
||||
@ -807,7 +807,7 @@ data and the length of recovery code in((("wallets", "recovery codes", "generati
|
||||
The ((("wallets", "recovery codes", "seed generation", id="wallet-recovery-bip39-seed")))((("recovery codes", "seed generation", id="recovery-code-bip39-seed")))((("BIP39 recovery codes", "seed generation", primary-sortas="BIP039", id="bip39-recovery-seed")))((("entropy", "seed generation", id="entropy-seed-generate")))((("seeds", "generating", id="seed-generate")))((("key-stretching functions", id="key-stretch")))recovery code
|
||||
represents entropy with a length of 128 to 256 bits. The entropy is then
|
||||
used to derive a longer (512-bit) seed through the use of the
|
||||
key-stretching function PBKDF2. The seed produced is then used to build
|
||||
https://oreil.ly/6lwbd[key-stretching function PBKDF2]. The seed produced is then used to build
|
||||
a deterministic wallet and derive its keys.
|
||||
|
||||
The key-stretching function takes two
|
||||
@ -1061,14 +1061,14 @@ wallet is shown in <<HDWalletFromSeed>>.
|
||||
image::images/mbc3_0506.png["HDWalletFromRootSeed"]
|
||||
|
||||
The root seed is input into the HMAC-SHA512 algorithm and the resulting
|
||||
hash is used to create a _master private key_ (m) and a _master chain
|
||||
code_ (c).
|
||||
hash is used to create a _master private key_ (_m_) and a _master chain
|
||||
code_ (_c_).
|
||||
|
||||
The master private key (m) then generates a corresponding master public
|
||||
key (M) using the normal elliptic curve multiplication process m × _G_
|
||||
The master private key (_m_) then generates a corresponding master public
|
||||
key (_M_) using the normal elliptic curve multiplication process _m_ × _G_
|
||||
that we saw in <<public_key_derivation>>.
|
||||
|
||||
The chain code (c) is used to introduce entropy in the function that
|
||||
The master chain code (_c_) is used to introduce entropy in the function that
|
||||
creates child keys from parent keys, as we will see in the next section.
|
||||
|
||||
===== Private child key derivation
|
||||
|
||||
@ -193,7 +193,7 @@ The validation software combines the scripts:
|
||||
2 3 OP_ADD 5 OP_EQUAL
|
||||
----
|
||||
|
||||
As we saw in <<simplemath_script>>, when
|
||||
As we see in <<simplemath_script>>, when
|
||||
this script is executed, the result is +OP_TRUE+, making the transaction
|
||||
valid. Not only have we shown a valid transaction output script, but
|
||||
the resulting UTXO could be spent by anyone with the arithmetic skills
|
||||
@ -242,7 +242,7 @@ a vulnerability known as the +1 OP_RETURN+ bug. In the current
|
||||
implementation, the scripts are executed separately with the stack
|
||||
transferred between the two executions.
|
||||
|
||||
First, the input script executed using the stack execution
|
||||
First, the input script is executed using the stack execution
|
||||
engine. If the input script is executed without errors and has
|
||||
no operations left over, the stack is copied and the
|
||||
output script is executed. If the result of executing the output script
|
||||
@ -376,7 +376,7 @@ scripts wrapped in another structure like P2SH, P2WSH, or P2TR.
|
||||
P2SH multisignature scripts are limited by both policy and consensus to
|
||||
15 keys, allowing for up to a 15-of-15 multisignature. We will learn about
|
||||
P2SH in <<p2sh>>. All other scripts are consensus limited to 20 keys
|
||||
per +OP_CHECKMULTSIG+ or +OP_CHECKMULTISIGVERIFY+ opcode, although one
|
||||
per +OP_CHECKMULTISIG+ or +OP_CHECKMULTISIGVERIFY+ opcode, although one
|
||||
script may include multiple of those opcodes.
|
||||
|
||||
[role="less_space pagebreak-before"]
|
||||
@ -417,7 +417,7 @@ replicated forever. Therefore a script should look
|
||||
like this:
|
||||
|
||||
----
|
||||
OP_0 <Sign B> <Sig C> 2 <Pubkey A> <Pubkey B> <Pubkey C> 3 OP_CHECKMULTISIG
|
||||
OP_0 <Sig B> <Sig C> 2 <Pubkey A> <Pubkey B> <Pubkey C> 3 OP_CHECKMULTISIG
|
||||
----
|
||||
|
||||
Thus the input script actually used in multisig is not:
|
||||
@ -780,7 +780,7 @@ It is important to understand the limitations of transaction lock time. The only
|
||||
In ((("transactions", "timelocks", "verifying", id="transaction-timelock-op-cltv")))((("timelocks", "verifying", id="timelock-op-cltv")))((("lock time", "verifying", id="lock-time-op-cltv")))((("OP_CLTV script operator", id="op-cltv")))((("verifying", "lock time", id="verify-lock-time")))((("scripts", "timelocks", "verifying", id="script-timelock-verify")))December 2015, a new form of
|
||||
timelock was introduced to Bitcoin as a soft fork upgrade. Based on a
|
||||
specification in BIP65, a new script operator called
|
||||
_OP_CHECKLOCKTIMEVERIFY_ (_CLTV_) was added to the scripting language.
|
||||
+OP_CHECKLOCKTIMEVERIFY+ (+OP_CLTV+) was added to the scripting language.
|
||||
+OP_CLTV+ is a per-output timelock rather than a per-transaction timelock,
|
||||
as is the case with lock time. This allows for additional
|
||||
flexibility in the way timelocks are applied.
|
||||
@ -1184,7 +1184,7 @@ account directly after he gains access to the capital account's
|
||||
transaction records.
|
||||
|
||||
<<variable_timelock_multisig>> is the redeem script that Mohammed designs to achieve this (line
|
||||
number prefixed as XX).
|
||||
number have been prefixed).
|
||||
|
||||
[[variable_timelock_multisig]]
|
||||
.Variable multi-signature with timelock
|
||||
@ -1467,7 +1467,7 @@ backward-compatible upgrade, where _old and new clients can coexist_.
|
||||
Wallet developers independently upgraded wallet software to add
|
||||
segwit capabilities.
|
||||
Legacy P2PKH and
|
||||
P2SH continue to work for nonupgraded wallets. That leaves two
|
||||
P2SH continue to work for [.keep-together]#nonupgraded# wallets. That leaves two
|
||||
important scenarios, which are addressed in the next section:
|
||||
|
||||
- Ability of a spender's wallet that is not segwit-aware to make a
|
||||
@ -1962,7 +1962,7 @@ called _tapscript_. The major differences include:
|
||||
|
||||
[role="less_space pagebreak-before"]
|
||||
Scripted multisignature changes::
|
||||
The old +OP_CHECKMULTSIG+ and +OP_CHECKMULTISIGVERIFY+ opcodes are
|
||||
The old +OP_CHECKMULTISIG+ and +OP_CHECKMULTISIGVERIFY+ opcodes are
|
||||
removed. Those opcodes don't combine well with one of the other
|
||||
changes in the taproot soft fork, the ability to use schnorr signatures
|
||||
with batch validation (see <<schnorr_signatures>>). A new +OP_CHECKSIGADD+ opcode is provided
|
||||
|
||||
@ -416,7 +416,7 @@ The nonce (k)::
|
||||
In step 1, ((("digital signatures", "schnorr signature algorithm", "security features")))((("schnorr signature algorithm", "security features")))Alice chooses a number that Bob doesn't
|
||||
know and can't guess and gives him the scaled form of that number,
|
||||
_kG_. At that point, Bob also already has her public key (_xG_),
|
||||
which is the scaled form of _x_), her private key. That means when Bob is working on
|
||||
which is the scaled form of _x_, her private key. That means when Bob is working on
|
||||
the final equation (_sG_ = _kG_ + _exG_), there are two independent
|
||||
variables that Bob doesn't know (_x_ and _k_). It's possible to use
|
||||
simple algebra to solve an equation with one unknown variable but not
|
||||
@ -520,10 +520,10 @@ full commitment _hash_(_kG_ || _xG_ || _m_).
|
||||
Now that we've described each part of the BIP340 schnorr signature
|
||||
algorithm and explained what it does for us, we can define the protocol.
|
||||
Multiplication of integers are performed _modulus p_, indicating that the
|
||||
result of the operation divided by the number _p_ (as defined in the
|
||||
result of the operation is divided by the number _p_ (as defined in the
|
||||
secp256k1 standard) and the remainder is used. The number _p_ is very
|
||||
large, but if it was 3 and the result of an operation was 5, the actual
|
||||
number we would use is 2 (i.e., 5 divided by 3 is 2).
|
||||
number we would use is 2 (i.e., 5 divided by 3 has a remainder of 2).
|
||||
|
||||
Setup: Alice chooses a large random number (_x_) as her private key
|
||||
(either directly or by using a protocol like BIP32 to deterministically
|
||||
@ -620,10 +620,10 @@ simple multisignature protocol:
|
||||
|
||||
3. Alice produces the scalar _q_ = _a_ + _ey_. Bob produces the scalar
|
||||
_r_ = _b_ + _ez_. They add the scalars together to produce
|
||||
_s_ = _q_ + _r_. Their signature is the two values _kG_ and _s_.
|
||||
_s_ = _q_ + _r_. Their signature is the two values _kG_ [.keep-together]#and _s_.#
|
||||
|
||||
4. The verifiers check their public key and signature using the normal
|
||||
equation: _sG_ == _kG_ + _hash_(_kG_ || _xG_ || _m_) × _xG_.
|
||||
equation: [.keep-together]#_sG_ ==# _kG_ + _hash_(_kG_ || _xG_ || _m_) × _xG_.
|
||||
|
||||
Alice and Bob have proven that they know the sum of their private keys without
|
||||
either one of them revealing their private key to the other or anyone
|
||||
|
||||
@ -6,11 +6,11 @@
|
||||
The digital signature we saw Alice create in <a data-type="xref" href="#c_signatures">#c_signatures</a> only
|
||||
proves that she knows her private key and that she committed to a
|
||||
transaction that pays Bob. She can create another signature that
|
||||
instead commits to a transaction paying Carol--a transaction that spends
|
||||
instead commits to a transaction paying Carol—a transaction that spends
|
||||
the same output (bitcoins) that she used to pay Bob. Those two
|
||||
transactions are now <em>conflicting transactions</em> because only one
|
||||
transaction spending a particular output can be included in the valid
|
||||
blockchain with the most proof of work--the blockchain that full nodes
|
||||
blockchain with the most proof of work—the blockchain that full nodes
|
||||
use to determine which keys control which bitcoins.
|
||||
</p>
|
||||
++++
|
||||
@ -39,7 +39,7 @@ previous transaction and is also an exception to several other rules
|
||||
that apply to other transactions. Coinbase transactions don't pay
|
||||
transaction fees, don't need to be fee bumped, aren't subject to
|
||||
transaction pinning, and are largely uninteresting to the following
|
||||
discussion about fees--so we're going to ignore them in this chapter.
|
||||
discussion about fees—so we're going to ignore them in this chapter.
|
||||
</p>
|
||||
</div>
|
||||
++++
|
||||
@ -133,7 +133,7 @@ fee rates.
|
||||
Be careful ((("absurd fees")))((("excessive fees")))((("transaction fees", "overpaying")))((("overpaying transaction fees")))accepting input for fee rates. If a user copies and pastes a
|
||||
fee rate printed in one denominator into a field using a different
|
||||
denominator, they could overpay fees by 1,000 times. If they instead
|
||||
switch the denominator, they could theoretically overpay by 100,000,000
|
||||
switch the numerator, they could theoretically overpay by 100,000,000
|
||||
times. Wallets should make it hard for the user to pay an excessive
|
||||
fee rate and may want to prompt the user to confirm any fee rate that was
|
||||
not generated by the wallet itself using a trusted data source.
|
||||
@ -639,7 +639,7 @@ you intended.
|
||||
Fee sniping ((("transaction fees", "fee sniping", id="transaction-fee-sniping")))((("fee sniping", id="fee-snipe")))((("timelocks", "fee sniping and", id="timelock-fee-snipe")))((("lock time", "fee sniping and", id="lock-time-fee-snipe")))is a theoretical
|
||||
attack scenario where miners attempting to rewrite past blocks "snipe"
|
||||
higher-fee transactions from future blocks to maximize their
|
||||
profitability.
|
||||
[.keep-together]#profitability.#
|
||||
|
||||
For example, let's say the highest block in existence is block
|
||||
#100,000. If instead of attempting to mine block #100,001 to extend the
|
||||
|
||||
@ -523,7 +523,7 @@ both tourists can verify the existence of a street by visiting it, the
|
||||
tourist without a map doesn't know what lies down any of the side
|
||||
streets and doesn't know what other streets exist. Positioned in front
|
||||
of 23 Church Street, the tourist without a map cannot know if there are
|
||||
a dozen other "23 Church Street" addresses in the city and whether this
|
||||
a dozen other [.keep-together]#"23 Church# Street" addresses in the city and whether this
|
||||
is the right one. The mapless tourist's best chance is to ask enough
|
||||
people and hope some of them are not trying to mug him.
|
||||
|
||||
@ -720,7 +720,7 @@ pattern is definitely((("Bitcoin network", "bloom filters", "operational overvie
|
||||
.Testing the existence of pattern "Y" in the bloom filter. The result is a definitive negative match, meaning "Definitely Not!"
|
||||
image::images/mbc3_1010.png[]
|
||||
|
||||
=== How Lightweight Clients Use Bloom Filters
|
||||
==== How Lightweight Clients Use Bloom Filters
|
||||
|
||||
Bloom filters ((("Bitcoin network", "bloom filters", "lightweight clients and", id="bitcoin-network-bloom-lightweight")))((("bloom filters", "lightweight clients and", id="bloom-lightweight")))((("lightweight clients", "bloom filters and", id="lightweight-bloom")))are used to filter the transactions (and blocks containing
|
||||
them) that a lightweight client receives from its peers, selecting only
|
||||
@ -1170,8 +1170,6 @@ As a way to increase the privacy and security of the Bitcoin P2P
|
||||
network, there is a solution that provides encryption of the
|
||||
communications: _Tor transport_.
|
||||
|
||||
==== Tor Transport
|
||||
|
||||
Tor, which
|
||||
stands for _The Onion Routing network_, is a software project and
|
||||
network that offers encryption and encapsulation of data through
|
||||
|
||||
@ -6,7 +6,7 @@ It's what allows every full node to independently determine what keys and
|
||||
scripts control which bitcoins. In this chapter, we'll look at the
|
||||
structure of the blockchain and see how it uses cryptographic
|
||||
commitments and other clever tricks to make every part of it easy for
|
||||
full nodes (and sometimes light clients) to validate.
|
||||
full nodes (and sometimes lightweight clients) to validate.
|
||||
|
||||
The blockchain data structure is
|
||||
an ordered, back-linked list of blocks of transactions. The blockchain
|
||||
@ -382,7 +382,7 @@ Bitcoin's merkle trees is SHA256 applied twice, also known as
|
||||
double-SHA256.
|
||||
|
||||
When N data elements are hashed and summarized in a merkle tree, you can
|
||||
check to see if any one data element is included in the tree with at
|
||||
check to see if any one data element is included in the tree with
|
||||
about +log~2~(N)+ calculations, making this a very efficient data
|
||||
structure.
|
||||
|
||||
@ -812,7 +812,7 @@ $ bitcoin-cli -regtest generatetoaddress 500 \
|
||||
|
||||
It will only take a few seconds to mine all these blocks, which
|
||||
certainly makes it easy for testing. If you check your wallet balance,
|
||||
you will see that you earned a reward for the first 400 blocks (coinbase
|
||||
you will see that you earned the rewards for the first 400 blocks (coinbase
|
||||
rewards must be 100 blocks deep before you can ((("blockchain", "test blockchains", "regtest", startref="blockchain-test-regtest")))((("test blockchains", "regtest", startref="test-block-regtest")))((("regtest", startref="regtest")))spend them):
|
||||
|
||||
----
|
||||
@ -826,7 +826,7 @@ Bitcoin's ((("blockchain", "test blockchains", "development usage")))((("test bl
|
||||
blockchains (regtest, signet, testnet3, mainnet) offer a range
|
||||
of testing environments for bitcoin development. Use the test
|
||||
blockchains whether you are developing for Bitcoin Core or another
|
||||
full-node consensus client (an application such as a wallet, exchange,
|
||||
full-node consensus client; an application such as a wallet, exchange,
|
||||
ecommerce site; or even developing novel smart contracts and complex
|
||||
scripts).
|
||||
|
||||
|
||||
@ -167,8 +167,7 @@ The most ((("deflation", id="deflation")))((("inflation", id="inflation")))impor
|
||||
fixed and diminishing monetary issuance is that the currency tends to be
|
||||
inherently _deflationary_. Deflation is the phenomenon of appreciation
|
||||
of value due to a mismatch in supply and demand that drives up the value
|
||||
(and exchange rate) of a currency. The opposite of inflation, price
|
||||
deflation, means that the money has more purchasing power over time.
|
||||
(and exchange rate) of a currency. Price deflation is the opposite of inflation; it means that the money has more purchasing power over time.
|
||||
|
||||
Many economists argue that a deflationary economy is a disaster that
|
||||
should be avoided at all costs. That is because in a period of rapid
|
||||
@ -947,7 +946,7 @@ New Target = Old Target * (20,160 minutes / Actual Time of Last 2015 Blocks)
|
||||
[NOTE]
|
||||
====
|
||||
While the target calibration happens every 2,016 blocks, because of an
|
||||
off-by-one error in the original Bitcoin software it is based on the
|
||||
off-by-one error in the original Bitcoin software, it is based on the
|
||||
total time of the previous 2,015 blocks (not 2,016 as it should be),
|
||||
resulting in a retargeting bias toward higher difficulty by 0.05%.
|
||||
====
|
||||
@ -1397,8 +1396,7 @@ eight-or-less wasn't winning, it was a fair way to measure dice throws
|
||||
for the players, and it occasionally produces a less-than-four throw.
|
||||
|
||||
Similarly, a mining pool will set a (higher and easier) pool target that
|
||||
will ensure that an individual pool miner can find block header hashes
|
||||
that are less than the pool target often, earning shares. Every now and
|
||||
will ensure that an individual pool miner frequently earns shares by finding block header hashes that are less than the pool target. Every now and
|
||||
then, one of these attempts will produce a block header hash that is
|
||||
less than the Bitcoin network target, making it a valid block and the
|
||||
whole pool wins.
|
||||
@ -2015,7 +2013,7 @@ a different bit, renewing the activation period.
|
||||
Furthermore, after the +TIMEOUT+ has passed and a feature has been
|
||||
activated or rejected, the signaling bit can be reused for another
|
||||
feature without confusion. Therefore, up to 29 changes can be signaled
|
||||
in parallel and after +TIMEOUT+, the bits can be "recycled" to propose
|
||||
in parallel. After +TIMEOUT+, the bits can be "recycled" to propose
|
||||
new changes.
|
||||
|
||||
[NOTE]
|
||||
|
||||
@ -145,7 +145,7 @@ intrinsic to the blockchain.
|
||||
|
||||
Colored coins are used to track digital
|
||||
assets as well as physical assets held by third parties and traded
|
||||
through colored coins certificates of ownership. Digital asset colored
|
||||
through certificates of ownership associated with colored coins. Digital asset colored
|
||||
coins can represent intangible assets such as a stock certificate,
|
||||
license, virtual property (game items), or most any form of licensed
|
||||
intellectual property (trademarks, copyrights, etc.). Tangible asset
|
||||
@ -340,7 +340,7 @@ Translated forwarding::
|
||||
support forwarding bitcoin [.keep-together]#payments.#
|
||||
|
||||
Native forwarding is conceptually simpler but essentially requires a
|
||||
separate LN for every asset. Translated forwarding
|
||||
separate Lightning-type network for every asset. Translated forwarding
|
||||
allows building on the economies of scale of the Bitcoin LN, but it may be vulnerable to a problem called((("free American call option"))) the _free American
|
||||
call option_, where a receiver may selectively accept or reject certain
|
||||
payments depending on recent changes to the exchange rate in order to
|
||||
@ -1038,7 +1038,7 @@ efficient route.
|
||||
|
||||
Alice's node then constructs an HTLC, payable to the hash +H+, with a
|
||||
10-block refund timeout (current block + 10), for an amount of 1.003
|
||||
bitcoins (see <<ln_payment_process>> step 2). The extra 0.003 will be
|
||||
bitcoins (see <<ln_payment_process>>, step 2). The extra 0.003 will be
|
||||
used to compensate the intermediate nodes for their participation in
|
||||
this payment route. Alice offers this HTLC to Bob, deducting 1.003
|
||||
bitcoins from her channel balance with Bob and committing it to the HTLC.
|
||||
@ -1068,7 +1068,7 @@ Carol now has a commitment that if she gets +R+ within the next nine
|
||||
blocks, she can claim 1.002 bitcoins locked by Bob. Now she can make an
|
||||
HTLC commitment on her channel with Diana. She commits an HTLC of 1.001
|
||||
bitcoins to hash +H+, for eight blocks, which Diana can redeem if she has
|
||||
secret +R+ (see <<ln_payment_process>> step 4). From Carol's
|
||||
secret +R+ (see <<ln_payment_process>>, step 4). From Carol's
|
||||
perspective, if this works she is 0.001 bitcoins better off and if it
|
||||
doesn't she loses nothing. Her HTLC to Diana is only viable if +R+ is
|
||||
revealed, at which point she can claim the HTLC from Bob. The channel
|
||||
@ -1076,27 +1076,27 @@ balance between Carol and Diana is now: 2 to Diana, 0.999 to Carol,
|
||||
1.001 committed by Carol to the HTLC.
|
||||
|
||||
Finally, Diana can offer an HTLC to Eric, committing 1 bitcoin for seven
|
||||
blocks to hash +H+ (see <<ln_payment_process>> step 5). The channel
|
||||
blocks to hash +H+ (see <<ln_payment_process>>, step 5). The channel
|
||||
balance between Diana and Eric is now: 2 to Eric, 1 to Diana, 1
|
||||
committed by Diana to the HTLC.
|
||||
|
||||
However, at this hop in the route, Eric _has_ secret +R+. He can
|
||||
therefore claim the HTLC offered by Diana. He sends +R+ to Diana and
|
||||
claims the 1 bitcoin, adding it to his channel balance (see
|
||||
<<ln_payment_process>> step 6). The channel balance is now: 1 to Diana,
|
||||
<<ln_payment_process>>, step 6). The channel balance is now: 1 to Diana,
|
||||
3 to Eric.
|
||||
|
||||
Now, Diana has secret +R+. Therefore, she can now claim the HTLC from
|
||||
Carol. Diana transmits +R+ to Carol and adds the 1.001 bitcoins to her
|
||||
channel balance (see <<ln_payment_process>> step 7). Now the channel
|
||||
channel balance (see <<ln_payment_process>>, step 7). Now the channel
|
||||
balance between Carol and Diana is: 0.999 to Carol, 3.001 to Diana.
|
||||
Diana has "earned" 0.001 for participating in this payment route.
|
||||
|
||||
Flowing back through the route, the secret +R+ allows each participant
|
||||
to claim the outstanding HTLCs. Carol claims 1.002 from Bob, setting the
|
||||
balance on their channel to: 0.998 to Bob, 3.002 to Carol (see
|
||||
<<ln_payment_process>> step 8). Finally, Bob claims the HTLC from Alice
|
||||
(see <<ln_payment_process>> step 9). Their channel balance is updated
|
||||
<<ln_payment_process>>, step 8). Finally, Bob claims the HTLC from Alice
|
||||
(see <<ln_payment_process>>, step 9). Their channel balance is updated
|
||||
as: 0.997 to Alice, 3.003 to Bob.
|
||||
|
||||
Alice has paid Eric 1 bitcoin without opening a channel to Eric. None of
|
||||
|
||||
@ -10,5 +10,5 @@
|
||||
|
||||
<p>Many of the animals on O'Reilly covers are endangered; all of them are important to the world. To learn more about how you can help, go to <a class="orm:hideurl" href="https://animals.oreilly.com"><em>animals.oreilly.com</em></a>.</p>
|
||||
|
||||
<p>The cover image is from <em>Insects Abroad</em>. The cover fonts are URW Typewriter and Guardian Sans. The text font is Adobe Minion Pro; the heading font is Adobe Myriad Condensed; and the code font is Dalton Maag's Ubuntu Mono.</p>
|
||||
<p>The cover illustration is by Karen Montgomery, based on an image from <em>Insects Abroad</em>. The cover fonts are Gilroy Semibold and Guardian Sans. The text font is Adobe Minion Pro; the heading font is Adobe Myriad Condensed; and the code font is Dalton Maag's Ubuntu Mono.</p>
|
||||
</section>
|
||||
|
||||
@ -12,7 +12,7 @@ development in 2023 have been added.
|
||||
Old Chapters 6 and 7::
|
||||
Text from previous versions of Chapter 6, "Transactions," and Chapter 7,
|
||||
"Advanced Transactions," has been rearranged and expanded across four
|
||||
new chapters: pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#c_transactions">#c_transactions</a>] (the structure of txes), pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#c_authorization_authentication">#c_authorization_authentication</a>], pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#c_signatures">#c_signatures</a>], and
|
||||
new chapters: pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#c_transactions">#c_transactions</a>] (the structure of transactions), pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#c_authorization_authentication">#c_authorization_authentication</a>], pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#c_signatures">#c_signatures</a>], and
|
||||
pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#tx_fees">#tx_fees</a>].
|
||||
|
||||
<<c_transactions>>::
|
||||
|
||||
@ -169,7 +169,7 @@ During the development of the book, I made early drafts available on GitHub and
|
||||
|
||||
Once the book was drafted, it went through several rounds of technical review. Thanks to Cricket Liu and Lorne Lantz for their thorough review, comments, and support.
|
||||
|
||||
Several Bitcoin developers contributed code samples, reviews, comments, and encouragement. Thanks to Amir Taaki and Eric Voskuil for example code snippets and many great comments; Chris Kleeschulte for contributing the Bitcore appendix; Vitalik Buterin and Richard Kiss for help with elliptic curve math and code contributions; Gavin Andresen for corrections, comments, and encouragement; Michalis Kargakis for comments, contributions, and btcd writeup; and Robin Inge for errata submissions improving the second print. In the second edition, I again received a lot of help from many Bitcoin Core developers, including Eric Lombrozo who demystified segregated witness, Luke Dashjr who helped improve the chapter on transactions, Johnson Lau who reviewed segregated witness and other chapters, and many others. I owe thanks to Joseph Poon, Tadge Dryja, and Olaoluwa Osuntokun who explained Lightning Network, reviewed my writing, and answered questions when I got stuck.
|
||||
Several Bitcoin developers contributed code samples, reviews, comments, and encouragement. Thanks to Amir Taaki and Eric Voskuil for example code snippets and many great comments; Chris Kleeschulte for contributing information about Bitcore; Vitalik Buterin and Richard Kiss for help with elliptic curve math and code contributions; Gavin Andresen for corrections, comments, and encouragement; Michalis Kargakis for comments, contributions, and btcd writeup; and Robin Inge for errata submissions improving the second print. In the second edition, I again received a lot of help from many Bitcoin Core developers, including Eric Lombrozo who demystified segregated witness, Luke Dashjr who helped improve the chapter on transactions, Johnson Lau who reviewed segregated witness and other chapters, and many others. I owe thanks to Joseph Poon, Tadge Dryja, and Olaoluwa Osuntokun who explained Lightning Network, reviewed my writing, and answered questions when I got stuck.
|
||||
|
||||
I owe my love of words and books to my mother, Theresa, who raised me in a house with books lining every wall. My mother also bought me my first computer in 1982, despite being a self-described technophobe. My father, Menelaos, a civil engineer who just published his first book at 80 years old, was the one who taught me logical and analytical thinking and a love of science and engineering.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user