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).
<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>
@ -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
@ -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.
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
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
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.
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):
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
<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 <aclass="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>
@ -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
@ -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.
Clare Laylock
6 months ago