@ -19,7 +19,7 @@ witnessed, but proof that it came from the largest pool of CPU power."
____
* *Implementation detail:* If each link in the chain (called "blocks"
in Bitcoin) was built using the same amount of proof of work (PoW), the
in Bitcoin) was built using the same amount of _proof of work_ (PoW), the
longest chain would be the one backed by the largest pool of
computational power. However, Bitcoin was implemented in such a way that
the amount of PoW can vary between blocks, so it became important not to
@ -37,7 +37,7 @@ occurred in July 2010, long after Bitcoin’s initial release:
+ if (pindexNew->bnChainWork > bnBestChainWork)
----
* *Terminology change:* General CPUs were used to generate the POW for
the earliest Bitcoin blocks but POW generation today is mostly performed
the earliest Bitcoin blocks, but POW generation today is mostly performed
by specialist Application Specific Integrated Circuits (ASICs), so
instead of saying "CPU power" it is perhaps more correct to say
"computational power" or, simply, "hash rate" for the hashing used
@ -56,7 +56,7 @@ called "miners" based on Nakamoto’s analogy to gold miners in section
6 of the paper. Nakamoto expected all miners to be nodes but the
software he released did not require all nodes to be miners. In the
original software, a simple menu item in the node GUI allowed toggling
the mining function or or off.
the mining function on or off.
+
Today it is the case that the overwhelming number of nodes are not
miners and that many individuals who own mining hardware do not use it
@ -77,7 +77,7 @@ known as the _selfish mining attack_ to allow an attacker with around
30% of total network hash rate to make other miners less profitable,
perhaps driving them into following the attacking miner’s policy. So
instead of saying "a majority of CPU power is controlled by nodes that
are not cooperating to attack the network" it is perhaps more correct
are not cooperating to attack the network," it is perhaps more correct
to say "as long as nodes cooperating to attack the network control less
than about 30% of the network."
@ -94,11 +94,11 @@ ____
this system where digital signatures are not used directly but rather a
"deterministic expression" is used instead. Just as a signature that
matches a known public key can be used to enable a payment, the data
that satisfies an known expression can also enable a payment.
that satisfies a known expression can also enable a payment.
Generically, the expression that must be satisfied in Bitcoin in order
to spend a coin is known as an "encumbrance." Almost all encumbrances
in Bitcoin to date require providing at least one signature. So instead
of saying "a chain of digital signatures" it is more correct to say
of saying "a chain of digital signatures," it is more correct to say
"a chain of encumbrances." Given that transactions often have more
than one input and more than one output, the structure is not very
chain-like; it’s more accurately described as a directed acyclic ((("transactions", "errata in Bitcoin whitepaper", startref="transaction-errata")))graph
@ -185,7 +185,7 @@ the past.
____
"Some linking((("privacy", "errata in Bitcoin whitepaper"))) is still unavoidable with multi-input transactions, which
necessarily reveal that their inputs were owned by the same owner"
necessarily reveal that their inputs were owned by the same owner."
____
* *Post-publication invention:* It isn't clear that different inputs
@ -197,7 +197,7 @@ toward paying Charlie and Dan than there is between just Alice
contributing two of her inputs toward paying Charlie and Dan.
+
This technique is known today as
https://oreil.ly/UBEJX[CoinJoin] and software implementing
https://oreil.ly/UBEJX[CoinJoin], and software implementing
@ -7,8 +7,8 @@ Bitcoin Improvement Proposals are design documents providing information to the
As per BIP1 _BIP Purpose and Guidelines_, there are three((("Bitcoin Improvement Proposals (BIPs)", "types of"))) kinds of BIPs:
_Standard_ BIP:: Describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin.
_Informational_ BIP:: Describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors may ignore informational BIPs or follow their advice.
_Process_ BIP:: Describes a Bitcoin process, or proposes a change to (or an event in) a process. Process BIPs are like standard BIPs but apply to areas other than the Bitcoin protocol itself. They might propose an implementation, but not to Bitcoin's codebase; they often require community consensus; and unlike informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a process BIP.
_Informational_ BIP:: Describes a Bitcoin design issue or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors may ignore informational BIPs or follow their advice.
_Process_ BIP:: Describes a Bitcoin process or proposes a change to (or an event in) a process. Process BIPs are like standard BIPs but apply to areas other than the Bitcoin protocol itself. They might propose an implementation but not to Bitcoin's codebase; they often require community consensus. Unlike informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a process BIP.
BIPs are recorded in a https://oreil.ly/jjO0R[versioned repository on GitHub].
An MIT-licensed document from the open source Bitcoin Core project,
@ -18,7 +18,7 @@ significantly changed.
BIPs that are ((("Bitcoin Improvement Proposals (BIPs)", "implemented by Bitcoin Core", id="bips-implement")))((("Bitcoin Core", "BIPs implemented by", id="bitcoin-core-bips")))implemented by Bitcoin Core:
- BIP9: The changes allowing multiple soft-forks to be deployed in parallel have been implemented since v0.12.1 (PR #7575)
- BIP9: The changes allowing multiple soft-forks to be deployed in parallel have been implemented since v0.12.1 (PR #7575).
- BIP11: Multisig outputs are standard since v0.6.0 (PR #669).
- BIP13: The address format for P2SH addresses has been implemented since v0.6.0 (PR #669).
- BIP14: The subversion string is being used as User Agent since v0.6.0 (PR #669).
@ -44,7 +44,7 @@ BIPs that are ((("Bitcoin Improvement Proposals (BIPs)", "implemented by Bitcoin
- 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).
- 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.
<p>Andreas grew up with the internet, starting his first company, an early BBS and proto-ISP, as a teenager in his home in Greece. He earned degrees in computer science, data communications, and distributed systems from University College London (UCL)—recently ranked among the world’s top 10 universities. After moving to the United States, Andreas cofounded and managed a successful technology research company, and in that role advised dozens of Fortune 500 company executives on networking, security, data centers, and cloud computing. More than 200 of his articles on security, cloud computing, and data centers have been published in print and syndicated worldwide. He holds two patents in networking and security.</p>
<p>In 1990, Andreas started teaching various IT topics in private, professional, and academic environments. He honed his speaking skills in front of audiences ranging in size from five executives in a boardroom to thousands of people in large conferences. With more than 400 speaking engagements under his belt he is considered a world-class and charismatic public speaker and teacher. In 2014, he was appointed as a teaching fellow with the University of Nicosia, the first university in the world to offer a masters degree in digital currency. In this role, he helped develop the curriculum and cotaught the Introduction to Digital Currencies course, offered as a massive open online course (MOOC) through the university.</p>
<p>In 1990, Andreas started teaching various IT topics in private, professional, and academic environments. He honed his speaking skills in front of audiences ranging in size from five executives in a boardroom to thousands of people in large conferences. With more than 400 speaking engagements under his belt, he is considered a world-class and charismatic public speaker and teacher. In 2014, he was appointed as a teaching fellow with the University of Nicosia, the first university in the world to offer a masters degree in digital currency. In this role, he helped develop the curriculum and cotaught the Introduction to Digital Currencies course, offered as a massive open online course (MOOC) through the university.</p>
<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>
@ -83,9 +83,9 @@ In this chapter we'll get started by explaining some of the main concepts and te
The ((("digital currencies, history of")))((("history", "of digital currencies", secondary-sortas="digital currencies")))((("cryptography")))emergence of viable digital money is closely linked to developments in cryptography. This is not surprising when one considers the fundamental challenges involved with using bits to represent value that can be exchanged for goods and services. Three basic questions for anyone accepting digital money are:
1. Can I trust that the money is authentic and not counterfeit?
2. Can I trust that the digital money can only be spent once (known as the “double-spend” problem)?
3. Can I be sure that no one else can claim this money belongs to them and not me?
* Can I trust that the money is authentic and not counterfeit?
* Can I trust that the digital money can only be spent once (known as the “double-spend” problem)?
* Can I be sure that no one else can claim this money belongs to them and not me?
Issuers of paper money are constantly battling the counterfeiting problem by using increasingly sophisticated papers and printing technology. Physical money addresses the double-spend issue easily because the same paper note cannot be in two places at once. Of course, conventional money is also often stored and transmitted digitally. In these cases, the counterfeiting and double-spend issues are handled by clearing all electronic transactions through central authorities that have a global view of the currency in circulation. For digital money, which cannot take advantage of esoteric inks or holographic strips, cryptography provides the basis for trusting the legitimacy of a user’s claim to value. Specifically, cryptographic digital signatures enable a user to sign a digital asset or transaction proving the ownership of that asset. With the appropriate architecture, digital signatures also can be used to address the double-spend issue.
@ -99,7 +99,7 @@ Although these earlier digital currencies worked, they were centralized and, as
Bitcoin was((("Bitcoin", "history of")))((("history", "of Bitcoin", secondary-sortas="Bitcoin")))((("Nakamoto, Satoshi"))) first described in 2008 with the publication of a
paper titled "Bitcoin: A Peer-to-Peer Electronic Cash
System,"footnote:[https://oreil.ly/KUaBM["Bitcoin: A Peer-to-Peer Electronic Cash System,"]
System,"footnote:[https://oreil.ly/KUaBM["Bitcoin: A Peer-to-Peer Electronic Cash System"],
Satoshi Nakamoto.] written under the
alias of Satoshi Nakamoto (see <<satoshi_whitepaper>>). Nakamoto
combined several prior inventions such as digital signatures and Hashcash to create
@ -153,12 +153,12 @@ derived from the original implementation written by Satoshi Nakamoto.
==== Choosing a Bitcoin Wallet
Bitcoin wallets ((("wallets", "choosing")))((("selecting", "wallets")))((("choosing", see="selecting")))are one of the most actively developed applications in the Bitcoin ecosystem. There is intense competition, and while a new wallet is probably being developed right now, several wallets from last year are no longer actively maintained. Many wallets focus on specific platforms or specific uses and some are more suitable for beginners while others are filled with features for advanced users. Choosing a wallet is highly subjective and depends on the use and user expertise. Therefore it would be pointless to recommend a specific brand or wallet. However, we can categorize Bitcoin wallets according to their platform and function and provide some clarity about all the different types of wallets that exist. It is worth trying out several different wallets until you find one that fits your needs.
Bitcoin wallets ((("wallets", "choosing")))((("selecting", "wallets")))((("choosing", see="selecting")))are one of the most actively developed applications in the Bitcoin ecosystem. There is intense competition, and while a new wallet is probably being developed right now, several wallets from last year are no longer actively maintained. Many wallets focus on specific platforms or specific uses and some are more suitable for beginners while others are filled with features for advanced users. Choosing a wallet is highly subjective and depends on the use and user expertise. Therefore, it would be pointless to recommend a specific brand or wallet. However, we can categorize Bitcoin wallets according to their platform and function and provide some clarity about all the different types of wallets that exist. It is worth trying out several different wallets until you find one that fits your needs.
===== Types of Bitcoin wallets
Bitcoin wallets ((("wallets", "types of", id="wallet-type")))can be categorized as follows, according to the platform:
Desktop wallet:: A ((("desktop wallets")))desktop wallet was the first type of Bitcoin wallet created as a reference implementation and many users run desktop wallets for the features, autonomy, and control they offer. Running on general-use operating systems such as Windows and macOS has certain security disadvantages, however, as these platforms are often insecure and poorly configured.
Desktop wallet:: A ((("desktop wallets")))desktop wallet was the first type of Bitcoin wallet created as a reference implementation. Many users run desktop wallets for the features, autonomy, and control they offer. Running on general-use operating systems such as Windows and macOS has certain security disadvantages, however, as these platforms are often insecure and poorly configured.
Mobile wallet:: A ((("mobile wallets")))mobile wallet is the most common type of Bitcoin
wallet. Running on smart-phone operating systems such as Apple iOS and
@ -212,7 +212,7 @@ creates outgoing transactions.
Third-party API client:: A third-party
API client ((("third-party API clients")))is one that interacts with Bitcoin through a third-party
system of APIs, rather than by
system of APIs rather than by
connecting to the Bitcoin network directly. The wallet may be stored by
the user or by third-party servers, but the client trusts the remote
server to provide it with accurate information and protect its ((("wallets", "types of", startref="wallet-type")))privacy.
@ -242,9 +242,7 @@ ultimately controls your funds on your behalf. Key management software falls int
important categories based on control: _wallets_, where you
control the keys, and the funds and accounts with custodians where some
third-party controls the keys. To emphasize this point, I (Andreas)
coined the phrase:
_Your keys, your coins. Not your keys, not your coins_.
coined the phrase: _Your keys, your coins. Not your keys, not your coins_.
Combining these categorizations, many Bitcoin wallets fall into a few
groups, with the three most common being desktop full node
@ -275,8 +273,8 @@ to restore her wallet.
[[recovery_code_intro]]
==== Recovery Codes
Most ((("wallets", "recovery codes", id="wallet-recovery")))((("recovery codes", id="recovery-code")))((("backing up", "recovery codes", see="recovery codes")))modern noncustodial Bitcoin wallets will provide a _recovery
code_ for their user
Most ((("wallets", "recovery codes", id="wallet-recovery")))((("recovery codes", id="recovery-code")))((("backing up", "recovery codes", see="recovery codes")))modern noncustodial Bitcoin wallets will provide a recovery
code for their user
to back up. The recovery code usually consists of numbers, letters, or words
selected randomly by the software, and is used as the basis for the keys
that are generated by the wallet. See <<recovery_code_sample>> for
@ -384,7 +382,7 @@ payment.
Alice((("bitcoins", "receiving")))((("receiving bitcoins"))) uses the _Receive_ button, which displays a QR code, shown in <<wallet_receive>>.
[[wallet_receive]]
.Alice uses the Receive screen on her mobile Bitcoin wallet, and displays her address in a QR code format
.Alice uses the Receive screen on her mobile Bitcoin wallet and displays her address in a QR code format
image::images/mbc3_0101.png["Wallet receive screen with QR code displayed. Image derived from Bitcoin Design Guide CC-BY"]
The QR code is the square with a pattern of black and white dots, serving as a form of barcode that contains the same information in a format that can be scanned by Joe's smartphone camera.
@ -429,7 +427,7 @@ many users choose to maintain dedicated exchange accounts independent from
their ((("bitcoins", "currency exchanges", startref="bitcoin-exchange")))((("currency exchanges", startref="currency-exchange")))wallets.
====
Alice was introduced to Bitcoin by a friend so she has an easy way to acquire her first bitcoins. Next, we will look at how she buys bitcoins from her friend Joe and how Joe sends the bitcoins to her ((("bitcoins", "acquiring", startref="bitcoin-acquire")))((("acquiring bitcoins", startref="acquire-bitcoin")))wallet.
Alice was introduced to Bitcoin by a friend, so she has an easy way to acquire her first bitcoins. Next, we will look at how she buys bitcoins from her friend Joe and how Joe sends the bitcoins to her ((("bitcoins", "acquiring", startref="bitcoin-acquire")))((("acquiring bitcoins", startref="acquire-bitcoin")))wallet.
[[bitcoin_price]]
==== Finding the Current Price of Bitcoin
@ -441,11 +439,11 @@ Bitcoin, like most other currencies, has a _floating exchange rate_. That means
There are hundreds of applications and websites that can provide the current market rate. Here are some of the most popular:
https://bitcoinaverage.com[Bitcoin Average]:: A site that provides a simple view of the volume-weighted-average for each currency.
https://bitcoinaverage.com[Bitcoin Average]:: A site that provides a simple view of the volume-weightedaverage for each currency.
https://coincap.io[CoinCap]:: A service listing the market capitalization and exchange rates of hundreds of cryptocurrencies, including bitcoins.
https://oreil.ly/ACieC[Chicago Mercantile Exchange Bitcoin Reference Rate]:: A reference rate that can be used for institutional and contractual reference, provided as part of investment data feeds by the CME.
In addition to these various sites and applications, some bitcoin
In addition to these various sites and applications, some Bitcoin
wallets will automatically convert amounts between bitcoin and other((("bitcoins", "exchange rate", startref="bitcoin-exchange-rate")))((("exchange rate", startref="exchange-rate")))((("current price of bitcoins", startref="current-price")))
currencies.
@ -484,7 +482,7 @@ amount, because he is about to transmit money and mistakes will soon become
irreversible. After double-checking the address and amount, he presses
Send to transmit the transaction. Joe's mobile Bitcoin wallet constructs
a transaction that assigns 0.001 BTC to the address provided by Alice,
sourcing the funds from Joe's wallet and signing the transaction with
sourcing the funds from Joe's wallet, and signing the transaction with
Joe's private keys. This tells the Bitcoin network that Joe has
authorized a transfer of value to Alice's new address. As the
transaction is transmitted via the peer-to-peer protocol, it quickly
acquired her first bitcoins. In <<getting_first_bitcoin>>, Alice met with
her friend Joe to exchange some cash for bitcoins. Since then, Alice has
bought additional bitcoins. Now Alice will make
her first spending transaction, buying access to a premium podcast episode from Bob's online store.
her first spending transaction: buying access to a premium podcast episode from Bob's online store.
Bob's web store recently started accepting bitcoin payments by adding a
Bitcoin option to its website. The prices at Bob's store are listed in
@ -75,7 +75,7 @@ the local currency (US dollars), but at checkout, customers have the
option of paying in either dollars or bitcoin.
Alice finds the podcast episode she wants to buy and proceeds to the checkout page. At checkout,
Alice is offered the option to pay with bitcoin, in addition to the
Alice is offered the option to pay with bitcoin in addition to the
usual options. The checkout cart displays the price in US dollars and
also in bitcoin (BTC), at Bitcoin's prevailing exchange rate.
@ -139,16 +139,7 @@ rules also apply to other bitcoin bookkeeping units, such as
millibitcoins and satoshis.
====
You can examine Alice's transaction to Bob's Store on the blockchain
using((("transactions", "spending bitcoins", startref="transaction-spend")))((("bitcoins", "spending", startref="bitcoin-spend")))((("spending bitcoins", startref="spend-bitcoin"))) a block explorer site (<<view_alice_transaction>>).
[[view_alice_transaction]]
.View Alice's transaction on https://blockstream.info/tx/674616f1fbc6cc748213648754724eebff0fc04506f2c81efb1349d1ebc8a2ef[Blockstream Explorer]
You can use a block explorer to examine blockchain data, such as the payment made to Bob in Alice's((("transactions", "spending bitcoins", startref="transaction-spend")))((("bitcoins", "spending", startref="bitcoin-spend")))((("spending bitcoins", startref="spend-bitcoin"))) https://oreil.ly/hAeyh[transaction].
In the following sections, we will examine this transaction in more
detail. We'll see how Alice's wallet constructed it, how it was
@ -264,7 +255,7 @@ change output (and the address it pays, called a _change address_) and a
payment output.
Importantly, the change address does not have to be the
same address as that of the input and for privacy reasons is often a new
same address as that of the input and, for privacy reasons, is often a new
address from the owner's wallet. In ideal circumstances, the two
different uses of outputs both use never-before-seen addresses and
otherwise look identical, preventing any third party from determining
@ -273,17 +264,17 @@ illustration purposes, we've added shading to the change outputs in
<<transaction-chain>>.
Not every transaction has a change output. Those that don't are ((("changeless transactions")))((("transactions", "changeless")))called
_changeless transactions_ and they can have only a single output.
_changeless transactions_, and they can have only a single output.
Changeless transactions are only a practical option if the amount being
spent is roughly the same as the amount available in the transaction
inputs minus the anticipated transaction fee. In <<transaction-chain>>
inputs minus the anticipated transaction fee. In <<transaction-chain>>,
we see Bob creating Tx3 as a changeless transaction that spends the
output he ((("transactions", "change output", startref="transaction-change-output")))((("change output", startref="change-output")))((("outputs", "change output", startref="output-change")))received in Tx2.
==== Coin Selection
Different wallets((("transactions", "coin selection")))((("coin selection in transactions")))((("selecting", "coins in transactions"))) use different strategies when choosing which
inputs to se in a payment, called _coin selection_.
inputs to use in a payment, called _coin selection_.
They might aggregate many small
inputs, or use one that is equal to or larger than the desired payment.
@ -348,9 +339,9 @@ wants to send to Bob. Most wallets keep track of all the available
outputs belonging to addresses in the wallet. Therefore, Alice's wallet
would contain a copy of the transaction output from Joe's transaction,
which was created in exchange for cash (see <<getting_first_bitcoin>>).
A bitcoin wallet application that runs on a full node actually
A Bitcoin wallet application that runs on a full node actually
contains a copy of every confirmed transaction's ((("UTXOs (unspent transaction outputs)")))unspent outputs, called
_Unspent Transaction Outputs_ (UTXOs).
_unspent transaction outputs_ (UTXOs).
However, because full nodes use more resources, many
user wallets run lightweight clients that track only the user's own
UTXOs.
@ -358,7 +349,7 @@ UTXOs.
In this case, this single
UTXO is sufficient to pay for the podcast. Had this not been the case,
Alice's wallet application might have to combine several
smaller UTXOs, like picking coins from a purse until it could
smaller UTXOs, like picking coins from a purse, until it could
find enough to pay for the podcast. In both cases, there might be a need
to get some change back, which we will see in the next section, as the
wallet application creates the transaction outputs (payments).
@ -375,7 +366,7 @@ address, only Bob's wallet can present such a signature to later spend this
output. Alice will therefore _encumber_ the output value with a demand
for a signature from Bob.
This transaction will also include a second output, ((("change output")))because Alice's
This transaction will also include a second output ((("change output")))because Alice's
funds contain more money than the cost of the
podcast. Alice's change
output is created in the very same
@ -386,7 +377,7 @@ then spend the change output in a subsequent transaction.
Finally, for the transaction to be processed by the network in a((("transaction fees"))) timely
fashion, Alice's wallet application will add a small fee. The fee is not
explicitly stated in the transaction; it is implied by the difference in value between
inputs and outputs. This _transaction fee_ is collected by the
inputs and outputs. This transaction fee is collected by the
miner as a fee for including the transaction in a block
that gets recorded on the blockchain.
@ -501,7 +492,7 @@ Bitcoin users will accept the block with its transactions as a
valid block. If the output doesn't match the template, the miner makes
a small change to their candidate block and tries again. As of this
writing, the number of candidate blocks miners need to try before finding
a winning combination is about 168 billion trillions. That's also how
a winning combination is about 168 billion trillion. That's also how
many times the hash function needs to be run.
However, once a winning combination has been found, anyone can verify
@ -628,8 +619,8 @@ look like <<block-alice2>>.
image::images/mbc3_0209.png["Alice's transaction as part of a transaction chain"]
In this chapter, we((("transactions", "spending bitcoins", startref="transaction-spend2")))((("bitcoins", "spending", startref="bitcoin-spend2")))((("spending bitcoins", startref="spend-bitcoin2"))) saw how transactions build a chain that moves value
from owner to owner. We also tracked Alice's transaction, from the
moment it was created in her wallet, through the Bitcoin network and to
from owner to owner. We also tracked Alice's transaction from the
moment it was created in her wallet, through the Bitcoin network, and to
the miners who recorded it on the blockchain. In the rest of this book,
we will examine the specific technologies behind wallets, addresses,
signatures, transactions, the network, and finally, mining.
@ -268,7 +268,7 @@ interest to points on the curve with two integer coordinates!
In some cases (i.e., if P~1~ and P~2~ have the same x values but
different y values), the tangent line will be exactly vertical, in which
case P3 = "point at infinity."
case P~3~ = "point at infinity."
If P~1~ is the "point at infinity," then P~1~ + P~2~ = P~2~. Similarly,
if P~2~ is the point at infinity, then P~1~ + P~2~ = P~1~. This shows
@ -292,7 +292,7 @@ irreversible: _K_ = _k_ * _G_, where _k_ is the private key, _G_ is a
constant point called the _generator point_, and _K_ is the resulting
public key. The reverse operation, known as "finding the discrete
logarithm"—calculating _k_ if you know __K__—is as difficult as trying
all possible values of _k_, i.e., a brute-force search. Before we
all possible values of _k_ (i.e., a brute-force search). Before we
demonstrate how to generate a public key from a private key, let's look
at elliptic curve cryptography in a bit more detail.
@ -325,9 +325,9 @@ bitcoin:
where _k_ is the private key, _G_ is the generator point, and _K_ is the
resulting public key, a point on the curve. Because the generator point
is always the same for all bitcoin users, a private key _k_ multiplied
is always the same for all Bitcoin users, a private key _k_ multiplied
with _G_ will always result in the same public key _K_. The relationship
between _k_ and _K_ is fixed, but can only be calculated in one
between _k_ and _K_ is fixed but can only be calculated in one
direction, from _k_ to _K_. That's why a Bitcoin public key can be
shared with anyone and does not reveal the user's private key (_k_).
@ -339,7 +339,7 @@ one way.
====
Implementing the elliptic curve multiplication, we take the private key
_k_ generated previously and multiply it with the generator point G to
_k_ generated previously and multiply it with the generator point _G_ to
find the public key _K_:
[source, python]
@ -533,11 +533,11 @@ was the exact same key that was used to create that earlier commitment.
The SHA256 hash function is considered to be very secure and produces
256 bits (32 bytes) of output, less than half the size of original
Bitcoin public keys. However, there are other slightly less secure hash
functions that produce smaller output, such as the ((("RIPEMD160 hash function")))RIPEMD160 hash
functions that produce smaller output, such as the ((("RIPEMD-160 hash function")))RIPEMD-160 hash
function whose output is 160 bits (20 bytes). For reasons Satoshi
Nakamoto never stated, the original version of Bitcoin made commitments
to public keys by first hashing the key with SHA256 and then hashing
that output with RIPEMD160; this produced a 20-byte commitment to the
that output with RIPEMD-160; this produced a 20-byte commitment to the
public key.
We can look at that algorithmically.
@ -754,15 +754,14 @@ When ((("public key cryptography", "compressed public keys", id="pub-key-compres
alternative encoding for public keys that used only 33 bytes and which
was backward compatible with all Bitcoin full nodes at the time,
so there was no need to change the Bitcoin protocol. Those 33-byte
public keys are known as _compressed public keys_ and the original 65
byte keys are known as _uncompressed public keys_. Using smaller public keys
public keys are known as _compressed public keys_, and the original 65-byte keys are known as _uncompressed public keys_. Using smaller public keys
results in smaller transactions, allowing more payments to be made in the same
block.
As we saw in the section <<public_key_derivation>>, a public key is a point (x,y) on an
elliptic curve. Because the curve expresses a mathematical function, a
point on the curve represents a solution to the equation and, therefore,
if we know the _x_ coordinate we can calculate the _y_ coordinate by
if we know the _x_ coordinate, we can calculate the _y_ coordinate by
solving the equation y^2^ mod p = (x^3^ + 7) mod p. That allows us to
store only the _x_ coordinate of the public key point, omitting the _y_
coordinate and reducing the size of the key and the space required to
@ -796,8 +795,8 @@ positive or negative value. Visually, this means that the resulting _y_
coordinate can be above or below the x-axis. As you can see from the
graph of the elliptic curve in <<ecc-curve>>, the curve is symmetric,
meaning it is reflected like a mirror by the x-axis. So, while we can
omit the _y_ coordinate we have to store the _sign_ of _y_ (positive or
negative); or in other words, we have to remember if it was above or
omit the _y_ coordinate, we have to store the _sign_ of _y_ (positive or
negative); in other words, we have to remember if it was above or
below the x-axis because each of those options represents a different
point and a different public key. When calculating the elliptic curve in
binary arithmetic on the finite field of prime order p, the _y_
@ -821,9 +820,9 @@ This compressed public key corresponds to the same private key, meaning
it is generated from the same private key. However, it looks different
from the uncompressed public key. More importantly, if we convert this
compressed public key to a commitment using the HASH160
function (+RIPEMD160(SHA256(K))+) it will produce a _different_
function (+RIPEMD160(SHA256(K))+), it will produce a _different_
commitment than the uncompressed public key, leading to a different
address. This can be confusing, because it means that a single private
address. This can be confusing because it means that a single private
key can produce a public key expressed in two different formats
(compressed and uncompressed) that produce two different Bitcoin
addresses. However, the private key is identical for both Bitcoin
@ -835,7 +834,7 @@ addresses.
image::images/mbc3_0408.png["pubkey_compression"]
Compressed public keys are now the default in almost all Bitcoin
software, and were made required when using certain new features added
software and were required when using certain new features added
in later protocol upgrades.
However, some software still needs to support uncompressed public keys,
@ -847,7 +846,7 @@ to scan for the correct type can lead to the user not being able to
spend their full balance. To resolve this issue, when private keys are
exported from a wallet, the WIF that is used to
represent them is implemented slightly differently in newer Bitcoin
wallets, to indicate that these private keys have been used to produce((("public key cryptography", "compressed public keys", startref="pub-key-compress")))((("compressed public keys", startref="compress-pub-key")))((("uncompressed public keys", startref="uncompress-pub-key")))
wallets to indicate that these private keys have been used to produce((("public key cryptography", "compressed public keys", startref="pub-key-compress")))((("compressed public keys", startref="compress-pub-key")))((("uncompressed public keys", startref="uncompress-pub-key")))
compressed public keys.
[[addresses_for_p2sh]]
@ -962,7 +961,7 @@ the HASH160 algorithm. This is((("second preimage attacks"))) a _second preimag
However, this changes when an attacker is able to influence the original input
value. For example, an attacker participates in the creation of a
multisignature script where tthey don't need to submit their public key until after they learn all of the other partys' public keys.
multisignature script where they don't need to submit their public key until after they learn all of the other partys' public keys.
In that case, the strength of hash algorithm is reduced to its square
root. For HASH160, the probability becomes 1-in-2^80^. This is a
_collision attack_.
@ -985,9 +984,9 @@ processes involving multiple parties, which could make the attack
profitable.
There are well-established cryptographic protocols for preventing
collision attacks but a simple solution that doesn't require any
collision attacks, but a simple solution that doesn't require any
special knowledge on the part of wallet developers is to simply use
a stronger hash function. Later upgrades to Bitcoin made that possible
a stronger hash function. Later upgrades to Bitcoin made that possible,
and newer Bitcoin addresses provide at least 128 bits of collision
resistance. To perform 2^128^ hash operations would take all current
The version of bech32 with a single different constant is known as
Bech32 Modified (bech32m). All of the characters in bech32 and bech32m
bech32 modified (bech32m). All of the characters in bech32 and bech32m
addresses for the same underlying data will be identical except for the
last six (the checksum). That means a wallet will need to know which
version is in use in order to validate the checksum, but both address
types contain an internal version byte that makes determining that easy.
===== Encoding and Decoding bech32m addresses
In this((("encoding", "bech32m addresses", id="encode-bech32m")))((("decoding", "bech32m addresses", id="decode-bech32m"))) section, we'll look at the encoding and parsing rules for
To work with both bech32 and((("encoding", "bech32m addresses", id="encode-bech32m")))((("decoding", "bech32m addresses", id="decode-bech32m"))) bech32m, we'll look at the encoding and parsing rules for
bech32m Bitcoin addresses since they encompass the ability to parse
bech32 addresses and are the current recommended address format for
Bitcoin wallets.
Bech32m addresses start with a Human Readable Part (HRP). There are
Bech32m addresses start with a human readable part (HRP). There are
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>>.
@ -1284,19 +1283,19 @@ scripts are listed in <<scripts_for_diff_segwit_outputs>>.
@ -1523,7 +1523,7 @@ can easily be converted to any other((("private keys", "formats", startref="priv
==== Compressed Private Keys
The commonly((("private keys", "compressed", id="private-key-compress")))((("compressed private keys", id="compress-private-key"))) used term "compressed private key" is a misnomer, because when a private
key is exported as WIF-compressed it is actually one byte _longer_ than
key is exported as WIF-compressed, it is actually one byte _longer_ than
an "uncompressed" private key. That is because the private key has an
added one-byte suffix (shown as 01 in hex in <<table_4-4>>), which
signifies that the private key is from a newer wallet and should only be
@ -1596,8 +1596,8 @@ addresses and those will be used in transactions. When exporting private
keys from a new wallet that implements compressed public keys, the WIF
is modified, with the addition of a one-byte suffix +01+ to the private
key. The resulting base58check-encoded private key is called a
"compressed WIF" and starts with the letter _K_ or _L_, instead of
starting with "5" as is the case with WIF-encoded (uncompressed) keys
"compressed WIF" and starts with the letter _K_ or _L_ instead of
starting with "5," as is the case with WIF-encoded (uncompressed) keys
In a ((("wallets", "key generation", "backing up derivation paths", id="wallet-keygen-backups")))((("key generation", "backing up derivation paths", id="keygen-backups")))((("backing up", "key derivation paths", id="backup-key-derive")))BIP32 tree of keys, there are approximately four billion first-level
keys and each of those keys can have its own four billion children, with
keys; each of those keys can have its own four billion children, with
those children each potentially having four billion children of their
own, and so on. It's not possible for a wallet application to generate
even a small fraction of every possible key in a BIP32 tree, which means
@ -611,7 +611,7 @@ included directly. Their disadvantage is that they require users to back
up additional information along with their recovery code. The
additional information usually can't compromise a user's security, so it
doesn't require as much protection as the recovery code, although it can
reduce their privacy and so does require some protection.
reduce their privacy and does require some protection.
Almost all wallet applications that use explicit paths as of this
writing use the _output script descriptors_ standard (called
@ -660,14 +660,14 @@ Developers of modern wallets can choose from a variety of different
technologies to help users create and use backups--and new solutions
appear every year. Instead of going into detail about each of the
options we described earlier in this chapter, we'll focus the rest of
this chapter on the stack of technologies that we think is most widely
this chapter on the stack of technologies we think is most widely
@ -966,7 +966,7 @@ greater the entropy, the harder it will be for them to figure out part
of the code they didn't see. For example, if an attacker sees half of a
128-bit code (64 bits), it's plausible that they'll be able to brute
force the remaining 64 bits. If they see half of a 256-bit code (128
bits), it's not plausible that they can brute force the other half. We
bits), it's not plausible they can brute force the other half. We
don't recommend relying on this defense--either keep your recovery codes
very safe or use a method like SLIP39 that lets you distribute your
recovery code across multiple locations without relying on the safety of
@ -1026,7 +1026,7 @@ her family to recover the cryptocurrency((("wallets", "recovery codes", startref
HD wallets ((("wallets", "key generation", "HD (hierarchical deterministic)", id="wallet-keygen-hd")))((("key generation", "HD (hierarchical deterministic)", id="keygen-hd")))((("HD (hierarchical deterministic) key generation", id="hd-keygen")))((("BIP32 HD (hierarchical deterministic) key generation", id="bip32")))((("seeds", "HD wallet creation", id="seed-hdwallet")))are created from a ((("root seeds")))single _root seed_, which is a
128-, 256-, or 512-bit random number. Most commonly, this seed is
generated by or decrypted from a _recovery code_ as detailed in the previous section.
generated by or decrypted from a recovery code as detailed in the previous section.
Every key in the HD wallet is deterministically derived from this root
seed, which makes it possible to re-create the entire HD wallet from
@ -1068,7 +1068,7 @@ that combines:
The chain code is used to introduce deterministic random data to the
process, so that knowing the index and a child key is not sufficient to
derive other child keys. Knowing a child key does not make it possible
to find its siblings, unless you also have the chain code. The initial
to find its siblings unless you also have the chain code. The initial
chain code seed (at the root of the tree) is made from the seed, while
subsequent child chain codes are derived from each parent chain code.
Bitcoin Core's serialization format is special because it's the format
used to make commitments to transactions and to relay them across
Bitcoin's peer-to-peer (P2P) network, but otherwise programs can use
Bitcoin's P2P network, but otherwise programs can use
a different format as long as they transmit all of the
same data. However, Bitcoin Core's format is reasonably compact for the
data it transmits and simple to parse, so many other Bitcoin programs
@ -62,12 +62,12 @@ use this format.
[TIP]
====
The only ((("partially signed bitcoin transaction (PSBT) format")))((("PSBT (partially signed bitcoin transaction) format")))other widely used transaction serialization format of that
The only ((("partially signed bitcoin transaction (PSBT) format")))((("PSBT (partially signed bitcoin transaction) format")))other widely used transaction serialization format that
we're aware of is the partially signed bitcoin transaction (PSBT) format
documented in BIPs 174 and 370 (with extensions documented in other
BIPs). PSBT allows an untrusted program to produce a transaction
template that can be verified and updated by trusted programs (such as
hardware signing devices) that possesses the necessary private keys or
hardware signing devices) that have the necessary private keys or
other sensitive data to fill in the template. To accomplish this, PSBT
allows storing a significant amount of metadata about a transaction,
making it much less compact than the standard serialization format.
@ -135,7 +135,7 @@ If you implement a protocol that uses presigned transactions, ensure
that it doesn't use any features that are reserved for future upgrades.
Bitcoin Core's default transaction relay policy does not allow the use
of reserved features. You can test whether a transaction complies with
that policy by using the Bitcoin Core RPC +testmempoolaccept+ on ((("transactions", "presigned", startref="transaction-presign")))((("presigned transactions", startref="presign-transaction")))Bitcoin
that policy by using Bitcoin Core's +testmempoolaccept+ RPC on ((("transactions", "presigned", startref="transaction-presign")))((("presigned transactions", startref="presign-transaction")))Bitcoin
mainnet.
****
@ -143,8 +143,8 @@ As of this writing, a proposal to begin using version 3 transactions is
being widely considered. That proposal does not seek to change the
consensus rules but only the policy that Bitcoin full nodes use to relay
transactions. Under the proposal, version 3 transactions would be
subject to additional constraints in order to prevent certain Denial of
Service (DoS) attacks that we'll discuss((("transactions", "version of", startref="transactions-version")))((("version (of transactions)", startref="version-transactions"))) further in <<transaction_pinning>>.
subject to additional constraints in order to prevent certain denial of
service (DoS) attacks that we'll discuss((("transactions", "version of", startref="transactions-version")))((("version (of transactions)", startref="version-transactions"))) further in <<transaction_pinning>>.
=== Extended Marker and Flag
@ -262,7 +262,7 @@ Each input in a transaction must contain three fields:
We'll look at each of those fields in the following sections. Some
inputs also include a witness stack, but this is serialized at the end of a
transaction and so we'll ((("transactions", "inputs", "length of list", startref="transaction-input-length")))((("inputs", "length of list", startref="input-transaction-length")))examine it later.
transaction so we'll ((("transactions", "inputs", "length of list", startref="transaction-input-length")))((("inputs", "length of list", startref="input-transaction-length")))examine it later.
[[outpoints]]
@ -347,7 +347,7 @@ txid from the outpoint in our example transaction:
If we try using that that txid to retrieve that transaction using
If we try using that txid to retrieve that transaction using
Bitcoin Core, we get an error and must reverse its byte order:
----
@ -371,7 +371,7 @@ This odd behavior is probably an unintentional consequence of a
https://oreil.ly/01JH2[design
decision in early Bitcoin software]. As a practical matter, it means
developers of Bitcoin software need to remember to reverse the order of
bytes in transaction and block identifiers that they show to users.
bytes in transaction and block identifiers they show to users.
In this book, we use the term _internal byte order_ for the data that
appears within transactions and blocks. We use _display byte order_ for
@ -486,7 +486,7 @@ isn't a very effective protocol.
The third problem was that it was possible to replace one version of a
transaction with a different version an unlimited number of
times. Each replacement would consume the bandwidth of all the relaying full nodes
on the network. For example, as of this writing there are about 50,000
on the network. For example, as of this writing, there are about 50,000
relaying full nodes; an attacker creating 1,000 replacement transactions
per minute at 200 bytes each would use about 20 kilobytes of their
personal bandwidth but about 10 gigabytes of full node network bandwidth
@ -546,7 +546,7 @@ Since sequence is a per-input field, a transaction may contain any
number of timelocked inputs, all of which must have sufficiently aged
for the transaction to be valid. A disable flag allows a transaction to
include both inputs with a relative timelock (sequence < 2^31^) and
inputs without a relative timelock (sequence >= 2^31^).
inputs without a relative timelock (sequence ≥ 2^31^).
The sequence value is specified in either blocks or seconds.
A type-flag
@ -573,7 +573,7 @@ as defined by BIP68.
.BIP68 definition of sequence encoding (Source: BIP68)
image::images/mbc3_0603.png["BIP68 definition of sequence encoding"]
Note that any transaction which sets a relative timelock using sequence
Note that any transaction that sets a relative timelock using sequence
also sends the signal for opt-in replace by fee ((("transactions", "inputs", startref="transaction-input")))((("inputs", startref="input-transaction")))((("transactions", "inputs", "sequence field", startref="transaction-input-sequence")))((("inputs", "sequence field", startref="input-transaction-sequence")))((("sequence field (transaction inputs)", startref="sequence-field")))((("relative timelocks", startref="relative-timelock")))as described in
<<sequence-bip125>>.
@ -626,7 +626,7 @@ contribute any value to a transaction spending it even if the
transaction's fee rate was zero. However, many other outputs with low
values can be uneconomical as well, even unintentionally. For example,
at a typical fee rate on the network today, an output might add more
value to a transaction than it costs to spend--but, tomorrow, fee rates
value to a transaction than it costs to spend--but tomorrow, fee rates
might rise and make the output uneconomical.
The need for full nodes to keep track of all unspent transaction outputs
The ((("transactions", "outputs", "output scripts", id="transaction-output-script")))((("outputs", "output scripts", id="output-transaction-script")))((("output scripts", id="output-script2")))output amount is followed by a compactSize integer indicating the
length of the _output script_, the script that contains the
conditions which will need to be fulfilled in order to spend the
conditions that will need to be fulfilled in order to spend the
bitcoins. According to Bitcoin's
consensus rules, the minimum size of an output script is zero.
@ -703,7 +703,7 @@ the block containing it.
An output script with zero length can be spent by an input script containing
++OP_TRUE++. Anyone can create that input script, which means anyone
can spend an empty output script. There are an essentially unlimited
number of scripts that anyone can spend and they are known to Bitcoin
number of scripts that anyone can spend, and they are known to Bitcoin
protocol developers as _anyone can spends_. Upgrades to Bitcoin's
script language often take an existing anyone-can-spend script and add
new constraints to it, making it only spendable under the new
@ -719,7 +719,7 @@ transaction outputs_. This was originally implemented after the
discovery of several early bugs in Bitcoin related to the Script
language and is retained in modern Bitcoin Core to support
anyone-can-spend upgrades and to encourage the best practice of placing
script conditions in P2SH redeem script, segwit v0 witness scripts, and
script conditions in P2SH redeem scripts, segwit v0 witness scripts, and
segwit v1 (taproot) leaf scripts.
We'll look at each of the current standard transaction templates and
@ -736,7 +736,7 @@ accept evidence from those who are reliable.
Imagine what a witness would look like for a math problem. For example,
if the important problem was _x + 2 == 4_ and someone claimed they
witnessed the solution, what would we ask them? We'd want a
mathematical proof that showed a value which could be summed with two to
mathematical proof that showed a value that could be summed with two to
equal four. We could even omit the need for a person and just use the
proposed value for _x_ as our witness. If we were told that the witness
was _two_, then we could fill in the equation, check that it was correct, and
@ -757,7 +757,7 @@ protected by the following script:
Obviously, allowing your bitcoins to be spent by anyone who can solve a
simple equation wouldn't be secure. As we'll see in <<c_signatures>>, an
unforgeable digital signature scheme uses an equation that can only be
solved by someone in possession of certain data that they're able to
solved by someone in possession of certain data they're able to
keep secret. They're able to reference that secret data using a public
identifier. That public identifier is ((("public keys")))((("digital signatures")))((("signatures", see="digital signatures")))called a _public key_ and a
solution to the equation is called a _signature_.
@ -797,7 +797,7 @@ transactions out of order:
- If Alice and Bob sign Tx~1~ before they sign Tx~0~, then they're both
guaranteed to be able to get a refund at any time. The protocol
doesn't require either of them trust the other, making ((("trustless protocols")))it a _trustless
doesn't require either of them to trust the other, making ((("trustless protocols")))it a _trustless
protocol_.
A problem with this construction in the legacy transaction format is
@ -882,7 +882,7 @@ developers worked on proposals to minimize third-party malleability,
such as BIP62. However, even if they were able to entirely eliminate
third-party malleability, users of contract protocols faced another problem:
if they required a signature from someone else involved in the protocol,
that person could generate alternative signatures and so change the txid.
that person could generate alternative signatures and change the txid.
For example, Alice and Bob have deposited their money into a script
requiring a signature from both of them to spend. They've also created
@ -1030,7 +1030,7 @@ items_. We'll explore them in detail in
each witness item is prefixed by a compactSize integer indicating its
size.
Legacy inputs don't contain any witness items so their witness stack
Legacy inputs don't contain any witness items, so their witness stack
consists entirely of a count of zero (0x00).
Alice's transaction contains one input and one ((("transactions", "witnesses", startref="transaction-witness")))((("witnesses", startref="witness")))((("transactions", "witnesses", "count", startref="transaction-witness-count")))((("witnesses", "count", startref="witness-count")))witness item.
@ -1039,7 +1039,7 @@ Alice's transaction contains one input and one ((("transactions", "witnesses", s
=== Lock Time
The ((("transactions", "lock time")))((("lock time")))final field in a serialized transaction is its lock time. This
field was part of Bitcoin's original serialization format but it was
field was part of Bitcoin's original serialization format, but it was
initially only enforced by Bitcoin's policy for choosing which
transactions to mine. Bitcoin's earliest known soft fork added a rule
that, starting at block height 31,000, forbid the inclusion of a
@ -7,7 +7,7 @@ nodes will distinguish the authorized spenders from everyone else,
called _authentication_. Your authorization instructions and the
spender proof of authentication will be checked by thousands of
independent full nodes, which all need to come to the same conclusion
that a spend was authorized and authentic in order for the transaction
that a spend was authorized and authenticated in order for the transaction
containing it to be valid.
The original description of Bitcoin used a public key for authorization.
@ -51,7 +51,7 @@ conditions for spending and how those conditions can be satisfied.
[TIP]
====
Bitcoin transaction validation((("transactions", "validating")))((("validating", "transactions"))) is not based on
a static pattern, but instead is achieved through the execution of a
a static pattern but instead is achieved through the execution of a
scripting language. This language allows for a nearly infinite variety
of conditions to be expressed.
====
@ -75,7 +75,7 @@ validation mechanism from being used as a vulnerability.
==== Stateless Verification
The ((("scripts", "stateless verification")))((("stateless script verification")))((("verifying", "scripts")))Bitcoin transaction script language is
stateless, in that there is no state prior to execution of the script,
stateless, in that there is no state prior to execution of the script
or state saved after execution of the script. All the
information needed to execute a script is contained within the script
and the transaction executing the script. A
@ -112,7 +112,7 @@ validation software will copy the input script, retrieve the UTXO
referenced by the input, and copy the output script from that UTXO. The
input and output scripts are then executed together. The input is
valid if the input script satisfies the output script's conditions
(see <<script_exec>>). All the inputs are validated independently, as
(see <<script_exec>>). All the inputs are validated independently as
part of the overall validation of the transaction.
Note that the preceding steps involve making copies of all data. The
@ -150,8 +150,8 @@ the stack.
Conditional operators evaluate a condition, producing a boolean result
of +TRUE+ or +FALSE+. For example, +OP_EQUAL+ pops two items from the stack
and pushes +TRUE+ (+TRUE+ is represented by the number 1) if they are equal
or +FALSE+ (represented by zero) if they are not equal. Bitcoin
transaction scripts usually contain a conditional operator, so that they
or +FALSE+ (represented by 0) if they are not equal. Bitcoin
transaction scripts usually contain a conditional operator so that they
can produce the +TRUE+ result that signifies a valid ((("scripts", "stack", startref="script-stack")))((("stack", startref="stack")))transaction.
===== A simple script
@ -363,7 +363,7 @@ the input script has
two valid signatures from private keys that correspond to two of
the three public keys set as an encumbrance.
At this time, Bitcoin Core's transaction relay policy limits multisignature output scripts to at most three
At this time, Bitcoin Core's transaction relay policy limits multisignature output scripts to, at most, three
listed public keys, meaning you can do anything from a 1-of-1 to a
3-of-3 multisignature or any combination within that range.
You may want to check the +IsStandard()+ function to see what is currently
@ -400,13 +400,12 @@ point, +OP_CHECKMULTISIG+ should pop the final +t+ items, which are the
signatures, and see if they are valid. However, unfortunately, an oddity in
the implementation causes +OP_CHECKMULTISIG+ to pop one more item (t+1
total) than it should. The extra item is called((("dummy stack element"))) the _dummy stack
element_ and it is disregarded when checking the
element_, and it is disregarded when checking the
signatures so it has no direct effect on +OP_CHECKMULTISIG+ itself.
However, the dummy element must be present because, if it isn't present,
However, the dummy element must be present because, if it isn't present
when +OP_CHECKMULTISIG+ attempts to pop on an empty stack, it will cause a
stack error and script failure (marking the transaction as invalid).
Because the dummy element is disregarded it can be anything, but
it became the custom early on to use +OP_0+, which later became a
Because the dummy element is disregarded, it can be anything. It became the custom early on to use +OP_0+, which later became a
relay policy rule and eventually a consensus rule (with the enforcement of BIP147).
Because popping the dummy element is part of the consensus rules, it must now be
@ -448,9 +447,9 @@ indicating which provided signature corresponds to which public key,
allowing the +OP_CHECKMULTISIG+ operation to only perform exactly +t+
signature-checking operations. It's possible that Bitcoin's original
developer added the extra element (which we now call the dummy stack
element) in the original version of Bitcoin so that they could add the
element) in the original version of Bitcoin so they could add the
feature for allowing a map to be passed in a later soft fork. However,
that feature was never implemented and the BIP147 update to the
that feature was never implemented, and the BIP147 update to the
consensus rules in 2017 makes it impossible to add that feature in the
future.
@ -552,10 +551,10 @@ with P2SH.
</table>
++++
As you can see from the tables, with P2SH the complex script that
As you can see from the tables, with P2SH, the complex script that
details the conditions for spending the output (redeem script) is not
presented in the output script. Instead, only a hash of it is in the
output script and the redeem script itself is presented later, as part
output script, and the redeem script itself is presented later as part
of the input script when the output is spent. This shifts the burden
in fees and complexity from the spender to the receiver of the
transaction.
@ -572,7 +571,7 @@ incoming payments from customers:
----
This entire script can instead be represented by a 20-byte cryptographic
hash, by first applying the SHA256 hashing algorithm and then applying
hash by first applying the SHA256 hashing algorithm and then applying
the RIPEMD-160 algorithm on the result. For example, starting with the
hash of Mohammed's redeem script:
@ -625,14 +624,14 @@ base58check-encoded addresses that start with a "3."
For example, Mohammed's complex script, hashed and base58check-encoded
as a P2SH address, becomes +39RF6JqABiHdYHkfChV6USGMe6Nsr66Gzw+.
Now, Mohammed can give this "address" to his customers and they can use
almost any Bitcoin wallet to make a simple payment, like any other
Now, Mohammed can give this "address" to his customers, and they can use
almost any Bitcoin wallet to make a simple payment like any other
Bitcoin address. The 3 prefix gives them a hint that this is a special
type of address, one corresponding to a script instead of a public key,
but otherwise it works in exactly the same way as a payment to any other Bitcoin
address.
P2SH addresses hide all of the complexity so that the person making a
P2SH addresses hide all of the complexity so the person making a
payment does not see the script.
==== Benefits of P2SH
@ -657,7 +656,7 @@ scripts in outputs:
==== Redeem Script and Validation
You are((("redeem scripts", "validating")))((("validating", "redeem scripts"))) not able to put a P2SH inside a P2SH redeem script, because the
You are((("redeem scripts", "validating")))((("validating", "redeem scripts"))) not able to put a P2SH inside a P2SH redeem script because the
P2SH specification is not recursive. Also, while it is technically
possible to include +OP_RETURN+ (see <<op_return>>) in a redeem script, as
nothing in the rules prevents you from doing so, it is of no practical
@ -669,7 +668,7 @@ until you attempt to spend a P2SH output, if you create an output with the
hash of an invalid redeem script, you will not be able to spend
it. The spending transaction, which includes the redeem script,
will not be accepted because it is an invalid script. This creates a
risk, because you can send bitcoin to a P2SH address that cannot be spent later.
risk because you can send bitcoin to a P2SH address that cannot be spent later.
[WARNING]
====
@ -742,7 +741,7 @@ Keep in mind that there is no input script that corresponds to
whole point of an +OP_RETURN+ output is that you can't spend the money locked in that
output, and therefore it does not need to be held in the UTXO set as
potentially spendable: +OP_RETURN+ outputs are _provably unspendable_. +OP_RETURN+ outputs
usually have a zero amount, because any bitcoins
usually have a zero amount because any bitcoins
assigned to such an output are effectively lost forever. If an +OP_RETURN+ output is
referenced as an input in a transaction, the script validation engine
will halt the execution of the validation script and mark the
@ -759,7 +758,7 @@ being included in a block until a specific block height, but it does not
prevent spending the funds in another transaction earlier than that.
Let's explain that with the following example.
Alice signs a transaction spending one of her outputs to Bob's address, and sets the transaction lock time to 3 months in the future. Alice sends that transaction to Bob to hold. With this transaction Alice and Bob know that:
Alice signs a transaction spending one of her outputs to Bob's address and sets the transaction lock time to 3 months in the future. Alice sends that transaction to Bob to hold. With this transaction Alice and Bob know that:
* Bob cannot transmit the transaction to redeem the funds until 3 months have elapsed.
* Bob may transmit the transaction after 3 months.
@ -777,7 +776,7 @@ In ((("transactions", "timelocks", "verifying", id="transaction-timelock-op-cltv
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_CLTV+ is a per-output timelock, rather than a per-transaction timelock
+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.
@ -808,7 +807,7 @@ To lock it to a time, say 3 months from now, his P2SH script would
Digital signatures((("digital signatures", "SIGHASH flags", id="digital-signature-sighash")))((("SIGHASH flags", id="sighash"))) apply to messages,
which in the case of Bitcoin, are the transactions themselves. The
signature prove a _commitment_ by the signer to specific transaction
signature proves a _commitment_ by the signer to specific transaction
data. In the simplest form, the signature applies to almost the entire
transaction, thereby committing to all the inputs, outputs, and other
transaction fields. However, a signature can commit to only a subset of
@ -103,7 +103,7 @@ Bitcoin signatures have a way of indicating which
part of a transaction's data is included in the hash signed by the
private key using a +SIGHASH+ flag. The +SIGHASH+ flag is a single byte
that is appended to the signature. Every signature has either an
explicit or implicit +SIGHASH+ flag
explicit or implicit +SIGHASH+ flag,
and the flag can be different from input to input. A transaction with
three signed inputs may have three signatures with different +SIGHASH+
flags, each signature signing (committing) to different parts of the
@ -217,7 +217,7 @@ in practice:
funds can construct a transaction with a single output. The single
output pays the "goal" amount to the fundraiser. Such a transaction is
obviously not valid, as it has no inputs. However, others can now amend
it by adding an input of their own, as a donation. They sign their own
it by adding an input of their own as a donation. They sign their own
input with +ALL|ANYONECANPAY+. Unless enough inputs are gathered to
reach the value of the output, the transaction is invalid. Each donation
is a "pledge," which cannot be collected by the fundraiser until the
@ -227,7 +227,7 @@ someone who lends them funds), allowing them to collect the donations
even if they haven't reached the specified value.
+NONE+ :: This construction can be used to create a "bearer check" or
"blank check" of a specific amount. It commits to all inputs, but allows
"blank check" of a specific amount. It commits to all inputs but allows
the outputs to be changed. Anyone can write their own
Bitcoin address into the output script.
By itself, this allows any miner to change
@ -394,7 +394,7 @@ generator +G=5+ to get her public key +xG=15+. She gives Bob +15+.
4. Bob derives +sG = 200 = 40 * 5+ and +exG = 165 = 11 * 15+. He then
verifies that +200 == 35 + 165+. Note that this is the same operation
that Alice performed but all of the values have been scaled up by +5+
that Alice performed, but all of the values have been scaled up by +5+
(the value of +G+).
Of course, this is an oversimplified example. When working with simple
@ -549,8 +549,7 @@ she's ready to spend, she begins generating her signature:
==== Serialization of Schnorr Signatures
A schnorr signature ((("digital signatures", "schnorr signature algorithm", "serialization")))((("schnorr signature algorithm", "serialization")))((("serialization", "of schnorr signature algorithm", secondary-sortas="schnorr")))consists of two values, +kG+ and +s+. The value
+kG+ is a point on Bitcoin's elliptic curve (called secp256k1) and so
would normally be represented by two 32-byte coordinates, e.g., +(x,y)+.
+kG+ is a point on Bitcoin's elliptic curve (called secp256k1) and would normally be represented by two 32-byte coordinates, e.g., +(x,y)+.
However, only the _x_ coordinate is needed, so only that value is
included. When you see +kG+ in schnorr signatures for Bitcoin, note that it's only that point's _x_
coordinate.
@ -560,7 +559,7 @@ Bitcoin's secp256k1 curve, it can never be more than 32 bytes long.
Although both +kG+ and +s+ can sometimes be values that can be
represented with fewer than 32 bytes, it's improbable that they'd be
much smaller than 32 bytes, and so they're serialized as two 32-byte
much smaller than 32 bytes, so they're serialized as two 32-byte
values (i.e., values smaller than 32 bytes have leading zeros).
They're serialized in the order of +kG+ and then +s+, producing exactly
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
else. The protocol can be extended to any number of participants; e.g.,
else. The protocol can be extended to any number of participants (e.g.,
a million people could prove they knew the sum of their million
different keys.
different keys).
The preceding protocol has several security problems. Most notable is that one
party might learn the public keys of the other parties before committing
@ -631,7 +630,7 @@ to their own public key. For example, Alice generates her public key
+yG+ honestly and shares it with Bob. Bob generates his public key
using +zG - yG+. When their two keys are combined (+yG + zG - yG+), the
positive and negative +yG+ terms cancel out so the public key only represents
the private key for +z+, i.e., Bob's private key. Now Bob can create a
the private key for +z+ (i.e., Bob's private key). Now Bob can create a
valid signature without any assistance from Alice. This is ((("key cancellation attacks")))called a
_key cancellation attack_.
@ -790,9 +789,9 @@ work together to reconstruct Alice's partial private key. Now Bob has
his own partial private key plus the keys of Alice and Carol, allowing
him to spend the funds himself without their involvement. This attack can
be addressed if all of the participants agree to only communicate using a
scheme that allows any one of them to see all of the other's messages;
e.g., if Bob tells Alice that Carol is unavailable, Carol is able to see
that message before she begins working with Bob. Other solutions,
scheme that allows any one of them to see all of the other's messages
(e.g., if Bob tells Alice that Carol is unavailable, Carol is able to see
that message before she begins working with Bob). Other solutions,
possibly more robust solutions, to this problem were being researched at
the time of writing.
@ -841,7 +840,7 @@ Less provable security::
Nonlinear::
ECDSA signatures cannot be easily combined to create scriptless
multisignatures or used in related advanced applications such as
multisignatures or used in related advanced applications, such as
multiparty signature adaptors. There are workarounds for this
problem, but they involve additional extra complexity that
significantly slows down operations and which, in some cases, has
@ -923,7 +922,7 @@ as follows:
=== The Importance of Randomness in Signatures
As we((("digital signatures", "randomness, importance of", id="digital-signature-random")))((("randomness, importance in digital signatures", id="random-digital-signature"))) saw in <<schnorr_signatures>> and <<ecdsa_signatures>>,
the signature generation algorithm uses a random number _k_, as the basis
the signature generation algorithm uses a random number _k_ as the basis
for a private/public nonce pair. The value of _k_ is not
important, _as long as it is random_. If signatures from the same
private key use the private nonce _k_ with different messages
@ -17,7 +17,7 @@ blockchain to a sufficient depth before he considers the money he
received as his to spend (see <<confirmations>>).
For Alice's transaction to be included in the
blockchain, it must be included in a _block_ of transactions. There are
a limited number of((("blocks", "transactions in")))((("transactions", "in blocks", secondary-sortas="blocks"))) blocks produced in a given amount of time and each
a limited number of((("blocks", "transactions in")))((("transactions", "in blocks", secondary-sortas="blocks"))) blocks produced in a given amount of time, and each
block only has a limited amount of space. Only the miner who creates
that block gets to choose which transactions to include. Miners may
select transactions by any criteria they want, including refusing to
@ -84,7 +84,7 @@ a payment typically have an interest in having it confirming quickly, so
normally allowing only spenders to choose fees can sometimes be a
problem; we'll look at a solution to that problem in <<cpfp>>. However,
in many common payment flows, the parties with the highest desire to see a
transaction confirm quickly--that is, the parties who'd be the most
transaction confirm quickly--that is, the parties who would be the most
willing to pay higher fees--are the spenders.
For those reasons, both technical and practical, it is customary in
@ -230,11 +230,11 @@ Full RBF::
****
The reason for the two different versions of RBF is that full RBF has
been controversial. Early versions of Bitcoin allowed transaction
replacement but this behavior was disabled for several releases. During
replacement, but this behavior was disabled for several releases. During
that time, a miner or full node using the software now called Bitcoin
Core would not replace the first version of an unconfirmed transaction
they received with any different version. Some merchants came to expect
this behavior: they assumed that any valid unconfirmed transaction which
this behavior: they assumed that any valid unconfirmed transaction that
paid an appropriate fee rate would eventually become a confirmed
transaction, so they provided their goods or services shortly after
receiving such an unconfirmed transaction.
@ -292,7 +292,7 @@ having "Sending support" on
https://oreil.ly/IhMzx.
As a developer, if you plan to implement RBF fee bumping, you will first
need to decided whether to perform opt-in RBF or full RBF. At the time
need to decide whether to perform opt-in RBF or full RBF. At the time
of writing, opt-in RBF is the only method that's sure to work. Even if
full RBF becomes reliable, there will likely be several years where
replacements of opt-in transactions get confirmed slightly faster than
@ -432,7 +432,7 @@ The solution to this problem is the ability to relay transactions as a
package, called _package relay_, allowing the receiving node to evaluate
the fee rate of the entire package before operating on any individual
transaction. As of this writing, developers working on Bitcoin Core
have made significant progress on implementing package relay and a
have made significant progress on implementing package relay, and a
limited early version of it may be available by the time this book is
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 reward for the first 400 blocks (coinbase
you will see that you earned a reward 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):
@ -440,7 +440,7 @@ fees (+nFees+), and the sum is returned.
If Jing's mining node writes the coinbase transaction, what stops Jing
from "rewarding" himself 100 or 1,000 bitcoin? The answer is that an
inflated reward would result in the block being deemed invalid by
everyone else, wasting Jing's electricity used for Proof-of-Work. Jing
everyone else, wasting Jing's electricity used for PoW. Jing
only gets to spend the reward if the block is accepted by ((("rewards", startref="reward-coinbase")))((("transaction fees", "in coinbase transactions", secondary-sortas="coinbase transactions", startref="transaction-fee-coinbase")))everyone.
====
@ -524,7 +524,7 @@ structure of the((("inputs", "coinbase versus regular transactions"))) coinbase
<tr>
<td><p>Variable</p></td>
<td><p>Coinbase Data</p></td>
<td><p>Arbitrary data used for extra nonce and mining tags. In v2 blocks; must begin with block height</p></td>
<td><p>Arbitrary data used for extra nonce and mining tags; in v2 blocks, must begin with block height</p></td>
</tr>
<tr>
<td><p>4 bytes</p></td>
@ -554,7 +554,7 @@ be used by miners in any way they want; it is arbitrary data.
In the genesis block, for
example, Satoshi Nakamoto added the text "The Times 03/Jan/2009
Chancellor on brink of second bailout for banks" in the coinbase data,
using it as a proof of the earliest date this block chould have been
using it as a proof of the earliest date this block could have been
created and to convey a message. Currently,
miners often use the coinbase data to include extra nonce values and strings
identifying the mining pool.
@ -604,12 +604,12 @@ as listed in <<block_header_structure_ch10>>.
<tr>
<td><p>4 bytes</p></td>
<td><p>Target</p></td>
<td><p>The Proof-of-Work algorithm target for this block</p></td>
<td><p>The proof-of-work algorithm target for this block</p></td>
</tr>
<tr>
<td><p>4 bytes</p></td>
<td><p>Nonce</p></td>
<td><p>A counter used for the Proof-of-Work algorithm</p></td>
<td><p>A counter used for the proof-of-work algorithm</p></td>
</tr>
</tbody>
</table>
@ -662,11 +662,11 @@ transactions into a single 32-byte value, which is the _witness root
hash_.
The witness root hash is added to an output of the coinbase transaction.
This step may be skipped if none of the transactions in the blook are
This step may be skipped if none of the transactions in the block are
required to contain a witness structure. Each transaction (including
the coinbase transaction) is then listed using its transaction
identifier (_txid_) and used to build a second merkle tree, the root of
which becomes the merkle root to which the block header commits.
which becomes the merkle root, to which the block header commits.
Jing's mining node will then add a 4-byte timestamp, encoded as a Unix
"epoch" timestamp, which is based on the number of seconds elapsed from
@ -674,7 +674,7 @@ January 1, 1970, midnight UTC/GMT.
Jing's node then fills in the nBits target, which must be set to a
compact representation of the required
Proof-of-Work to make this a valid block. The target is stored in the
PoW to make this a valid block. The target is stored in the
block as a "target bits" metric, which is a mantissa-exponent encoding
of the target. The encoding has a 1-byte exponent, followed by a 3-byte
mantissa (coefficient). In block 277,316, for example, the target bits
@ -696,7 +696,7 @@ the header before a version is found that satisfies the((("bitcoins", "mining",
Now
that((("candidate blocks", "mining", id="candidate-mine")))((("blocks", "candidate blocks", "mining", id="block-candidate-mine")))((("mining", "candidate blocks", id="mining-candidate")))((("bitcoins", "mining", "candidate blocks", id="bitcoin-mining-candidate"))) a candidate block has been constructed by Jing's node, it is time
for Jing's hardware mining rig to "mine" the block, to find a solution
to the Proof-of-Work algorithm that makes the block valid. Throughout
to the proof-of-work algorithm that makes the block valid. Throughout
this book we have studied cryptographic hash functions as used in
various aspects of the Bitcoin system. The hash function SHA256 is the
Block headers ((("bitcoins", "mining", "target representation", id="bitcoin-mining-target")))((("mining", "target representation", id="mining-target")))((("targets", "representation of", id="target-represent")))((("Proof-of-Work algorithm", "target representation", id="proof-target")))contain the target in a notation called "target
bits" or just "bits," which in block 277,316 has the value of
+0x1903a30c+. This notation expresses the Proof-of-Work target as a
+0x1903a30c+. This notation expresses the proof-of-work target as a
coefficient/exponent format, with the first two hexadecimal digits for
the exponent and the next six hex digits as the coefficient. In this
block, therefore, the exponent is +0x19+ and the coefficient is
@ -886,7 +886,7 @@ switching back to hexadecimal:
++++
This means that a valid block for height 277,316 is one that has a block
header hash that is less than the target. In binary that number must
header hash less than the target. In binary that number must
have more than 60 leading bits set to zero. With this level of
difficulty, a single miner processing 1 trillion hashes per second (1
terahash per second or 1 TH/sec) would only find a solution once every
@ -897,7 +897,7 @@ terahash per second or 1 TH/sec) would only find a solution once every
As we saw, ((("bitcoins", "mining", "adjusting difficulty", id="bitcoin-mining-difficulty")))((("mining", "adjusting difficulty", id="mining-difficulty")))((("targets", "adjusting difficulty", id="target-difficulty")))((("Proof-of-Work algorithm", "adjusting difficulty", id="proof-difficulty")))((("difficulty", "adjusting", id="difficulty-adjust")))the target determines the difficulty and
therefore affects how long it takes to find a solution to the
Proof-of-Work algorithm. This leads to the obvious questions: Why is the
proof-of-work algorithm. This leads to the obvious questions: Why is the
difficulty adjustable, who adjusts it, and how?
Bitcoin's blocks are generated every 10 minutes, on average. This is
@ -908,14 +908,14 @@ it is expected that computer power will continue to increase at a rapid
pace. Furthermore, the number of participants in mining and the
computers they use will also constantly change. To keep the block
generation time at 10 minutes, the difficulty of mining must be adjusted
to account for these changes. In fact, the Proof-of-Work target is a
to account for these changes. In fact, the proof-of-work target is a
dynamic parameter that is periodically adjusted to meet a 10-minute
block interval goal. In simple terms, the target is set so that the
current mining power will result in a 10-minute block interval.
How, then, is such an adjustment made in a completely decentralized
network? Retargeting occurs automatically and on every node
independently. Every 2,016 blocks, all nodes retarget the Proof-of-Work.
independently. Every 2,016 blocks, all nodes retarget the PoW.
The ratio between the actual time span and desired time span of 10
minutes per block is calculated and a
proportionate adjustment (up or down) is made to the target. In simple
@ -940,7 +940,7 @@ resulting in a retargeting bias toward higher difficulty by 0.05%.
<<retarget_code>> shows the code used in the Bitcoin Core client.
[[retarget_code]]
.Retargeting the Proof-of-Work—[.plain]#++CalculateNextWorkRequired()++# in pow.cpp
.Retargeting the proof of work—[.plain]#++CalculateNextWorkRequired()++# in pow.cpp
====
[source,cpp]
----
@ -997,7 +997,7 @@ electricity. High-performance mining systems are about as efficient as
possible with the current generation of silicon fabrication, converting
electricity into hashing computation at the highest rate possible. The
primary influence on the mining market is the price of one kilowatt-hour
of electricity in bitcoin, because that determines the profitability of
of electricity in bitcoin because that determines the profitability of
mining and therefore the incentives to enter or exit the ((("bitcoins", "mining", "adjusting difficulty", startref="bitcoin-mining-difficulty")))((("mining", "adjusting difficulty", startref="mining-difficulty")))((("targets", "adjusting difficulty", startref="target-difficulty")))((("Proof-of-Work algorithm", "adjusting difficulty", startref="proof-difficulty")))((("difficulty", "adjusting", startref="difficulty-adjust")))mining
market.
@ -1101,7 +1101,7 @@ The independent validation also ensures that only blocks that follow the
consensus rules are incorporated in the blockchain, thus earning
their miners the reward. Blocks that violate the rules are rejected
and not only lose their miners the reward, but also waste the effort expended to find
a Proof-of-Work solution, thus incurring upon those miners all of the costs of creating a
a proof-of-work solution, thus incurring upon those miners all of the costs of creating a
block but giving them none of the rewards.
When a node receives a new block, it will validate the block by checking
@ -1109,20 +1109,20 @@ it against a long list of criteria that must all be met; otherwise, the
block is rejected. These criteria can be seen in the Bitcoin Core client
in the functions +CheckBlock+ and +CheckBlockHeader+ and include:
- The block data structure is syntactically valid
- The block data structure is syntactically valid.
- The block header hash is less than the target (enforces the
Proof-of-Work)
proof of work).
- The block timestamp is between the MTP and two
hours in the future (allowing for time errors)
hours in the future (allowing for time errors).
- The block weight is within acceptable limits
- The block weight is within acceptable limits.
- The first transaction (and only the first) is a coinbase transaction
- The first transaction (and only the first) is a coinbase transaction.
- All transactions within the block are valid using the transaction
checklist discussed in <<tx_verification>>
checklist discussed in <<tx_verification>>.
The independent validation of each new block by every node on the
network ensures that the miners cannot cheat. In previous sections we
@ -1135,7 +1135,7 @@ the entire block invalid, which would result in the block being rejected
and, therefore, that transaction would never become part of the blockchain.
The miners have to construct a block, based on the shared rules
that all nodes follow, and mine it with a correct solution to the
Proof-of-Work. To do so, they expend a lot of electricity in mining, and
PoW. To do so, they expend a lot of electricity in mining, and
if they cheat, all the electricity and effort is wasted. This is why
independent validation is a key component of ((("bitcoins", "mining", "validating blocks", startref="bitcoin-mining-validate")))((("mining", "validating blocks", startref="mining-validate")))((("blocks", "validating", startref="block-validate")))((("validating", "blocks", startref="validate-block")))((("decentralized consensus", "validating blocks", startref="decentral-consensus-validate")))((("nodes", "validating blocks", startref="nodes-validate")))decentralized consensus.
@ -1146,14 +1146,14 @@ independent validation is a key component of ((("bitcoins", "mining", "validatin
The final ((("bitcoins", "mining", "assembling blockchain", id="bitcoin-mining-assemble")))((("mining", "assembling blockchain", id="mining-assemble")))((("blockchain", "assembling", id="blockchain-assemble")))((("decentralized consensus", "assembling blockchain", id="decentral-consensus-assemble")))part in Bitcoin's decentralized
consensus mechanism is the assembly of blocks into chains and the
selection of the chain with the most Proof-of-Work.
selection of the chain with the most proof of work.
A _best blockchain_ is whichever valid chain of blocks has
the most cumulative Proof-of-Work associated with it.
the most cumulative PoW associated with it.
The
best chain may also have branches with blocks that are "siblings" to
the blocks on the best chain. These blocks are valid but not part of the
best chain. They are kept for future reference, in case one of those
best chain. They are kept for future reference in case one of those
secondary chains later becomes primary. When sibling blocks occur,
they're usually the result of an
almost simultaneous mining of different blocks at the same height.
@ -1234,7 +1234,7 @@ deliver more mining power in a single box than the entire Bitcoin
network in 2010.
At the time of writing, it is believed that there are no more giant
leaps left in Bitcoin mining equipment,
leaps left in Bitcoin mining equipment
because the industry has reached the forefront of((("Moore's Law"))) Moore's Law, which
stipulates that computing density will double approximately every 18
months. Still, the mining power of the network continues to advance at
@ -1268,7 +1268,7 @@ extra nonce space, allowing them to explore a much larger range of block
header values to find valid blocks. The coinbase transaction is included
in the merkle tree, which means that any change in the coinbase script
causes the merkle root to change. Eight bytes of extra nonce, plus the 4
bytes of "standard" nonce allow miners to explore a total 2^96^ (8
bytes of "standard" nonce, allow miners to explore a total 2^96^ (8
followed by 28 zeros) possibilities _per second_ without having to
modify the timestamp.
@ -1318,9 +1318,9 @@ server while mining, synchronizing their efforts with the other miners.
Thus, the pool miners share the effort to mine a block and then share in
the rewards.
Successful blocks pay the reward to a pool Bitcoin address, rather than
Successful blocks pay the reward to a pool Bitcoin address rather than to
individual miners. The pool server will periodically make payments to
the miners' Bitcoin addresses, once their share of the rewards has
the miners' Bitcoin addresses once their share of the rewards has
reached a certain threshold. Typically, the pool server charges a
percentage fee of the rewards for providing the pool-mining service.
@ -1340,14 +1340,14 @@ will be mining with a few tens of a kilowatt of electricity, others will
be running a data center consuming megawatts of power. How does a
mining pool measure the individual contributions, so as to fairly
distribute the rewards, without the possibility of cheating? The answer
is to use Bitcoin's Proof-of-Work algorithm to measure each pool miner's
is to use Bitcoin's proof-of-work algorithm to measure each pool miner's
contribution, but set at a lower difficulty so that even the smallest
pool miners win a share frequently enough to make it worthwhile to
contribute to the pool. By setting a lower difficulty for earning
shares, the pool measures the amount of work done by each miner. Each
time a pool miner finds a block header hash that is less than the pool
target, they prove they have done the hashing work to find that result.
That header ultimately commits to the coinbase transaction and so it can
That header ultimately commits to the coinbase transaction and can
be used to prove the miner used a coinbase transaction that would have
paid the block reward to the pool. Each pool miner is given a
slightly different coinbase transaction template so each of them hashes
@ -1503,7 +1503,7 @@ product without paying for it.
Let's examine a practical example of a 51% attack. In the first chapter,
we looked at a transaction between Alice and Bob. Bob, the seller, is
willing to accept payment without waiting for
confirmation (mining in a block), because the risk of a double-spend on
confirmation (mining in a block) because the risk of a double-spend on
a small item is low in comparison to the convenience of rapid
customer service. This is similar to the practice of coffee shops that
accept credit card payments without a signature for amounts below $25,
@ -1531,7 +1531,7 @@ Mallory's transaction is included in a block. Paul directs the mining
pool to remine the same block height as the block containing Mallory's
transaction, replacing Mallory's payment to Carol with a transaction
that double-spends the same input as Mallory's payment. The double-spend
transaction consumes the same UTXO and pays it back to Mallory's wallet,
transaction consumes the same UTXO and pays it back to Mallory's wallet
instead of paying it to Carol, essentially allowing Mallory to keep the
bitcoins. Paul then directs the mining pool to mine an additional block,
so as to make the chain containing the double-spend transaction longer
@ -1541,7 +1541,7 @@ the new (longer) chain, the double-spent transaction replaces the
original payment to Carol. Carol is now missing the three paintings and
also has no payment. Throughout all this activity, Paul's mining
pool participants might remain blissfully unaware of the double-spend
attempt, because they mine with automated miners and cannot monitor
attempt because they mine with automated miners and cannot monitor
every transaction or block.
To protect against this
@ -1572,9 +1572,9 @@ Despite its ((("majority attacks", startref="majority-attack")))((("51% attacks"
of the hashing power. In fact, such an attack can be attempted with a
smaller percentage of the hashing power. The 51% threshold is simply the
level at which such an attack is almost guaranteed to succeed. A
hashrate attack is essentially a tug-of-war for the next block and the
hashrate attack is essentially a tug-of-war for the next block, and the
"stronger" group is more likely to win. With less hashing power, the
probability of success is reduced, because other miners control the
probability of success is reduced because other miners control the
generation of some blocks with their "honest" mining power. One way to
look at it is that the more hashing power an attacker has, the longer
the fork he can deliberately create, the more blocks in the recent past
@ -1596,7 +1596,7 @@ Not all attackers will be motivated by profit, however. One potential
attack scenario is where an attacker intends to disrupt the Bitcoin
network without the possibility of profiting from such disruption. A
malicious attack aimed at crippling Bitcoin would require enormous
investment and covert planning, but could conceivably be launched by a
investment and covert planning but could conceivably be launched by a
well-funded, most likely state-sponsored, attacker. Alternatively, a
well-funded attacker could attack Bitcoin by simultaneously
amassing mining hardware, compromising pool operators, and attacking
@ -1638,7 +1638,7 @@ after one or more blocks are mined.
There is another scenario in which the network may diverge into
following two chains: a change in the consensus rules. This type of fork
is called a _hard fork_, because after the fork the network may not
is called a _hard fork_, because after the fork, the network may not
converge onto a single chain. Instead, the two chains can evolve
independently. Hard forks occur when part of the network is operating
under a different set of consensus rules than the rest of the network.
@ -1676,7 +1676,7 @@ containing this transaction.
Any node or miner that has not upgraded the software to validate foocoin
is now unable to process block 7b. From their perspective,
both the transaction that contained a foocoin and block 7b that
contained that transaction are invalid, because they are evaluating them
contained that transaction are invalid because they are evaluating them
based upon the old consensus rules. These nodes will reject the
transaction and the block and will not propagate them. Any miners that
are using the old rules will not accept block 7b and will continue to
@ -1810,7 +1810,7 @@ that do not have near-unanimous support are considered too contentious
to attempt without risking a partition of the system.
Already we have seen the emergence of new methodologies to address the
risks of hard forks. In the next section, we will look at soft forks,
risks of hard forks. In the next section, we will look at soft forks
and the methods for signaling and activation of
consensus modifications.
@ -1872,7 +1872,7 @@ to increasing the future cost of code maintenance because of design
trade-offs made in the past. Code complexity in turn increases the
likelihood of bugs and security vulnerabilities.
Validation relaxation:: Unmodified clients see transactions as valid,
Validation relaxation:: Unmodified clients see transactions as valid
without evaluating the modified consensus rules. In effect, the
unmodified clients are not validating using the full range of consensus
rules, as they are blind to the new rules. This applies to NOP-based
@ -1919,7 +1919,7 @@ version to "2," instead of "1." This did not immediately make version
invalid and all version "2" blocks would be required to contain the
block height in the coinbase to be valid.
BIP34 defined a two-step activation mechanism, based on a rolling
BIP34 defined a two-step activation mechanism based on a rolling
window of 1,000 blocks. A miner would signal their individual
readiness for BIP34 by constructing blocks with "2" as the version
number. Strictly speaking, these blocks did not yet have to comply with
@ -1993,7 +1993,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 and after +TIMEOUT+, the bits can be "recycled" to propose
new changes.
[NOTE]
@ -2014,7 +2014,7 @@ number.
bit:: 0 through 28, the bit in the block version that miners use to
signal approval for this proposal.
starttime:: The time (based on median time past, or MTP) that signaling
starttime:: The time (based on MTP) that signaling
starts after which the bit's value is interpreted as signaling readiness
for the proposal.
@ -2030,7 +2030,7 @@ later.
BIP9 offers a proposal state diagram to illustrate the various stages
and transitions for a proposal, as shown in <<bip9states>>.
Proposals start in the +DEFINED+ state, once their parameters are known
Proposals start in the +DEFINED+ state once their parameters are known
(defined) in the Bitcoin software. For blocks with MTP after the start
time, the proposal state transitions to +STARTED+. If the voting
threshold is exceeded within a retarget period and the timeout has not
@ -2100,7 +2100,7 @@ Software was published that used BIP8 to attempt to activate the
taproot proposal in 2021, and there was evidence that at least a
small number of users ran that software. Some of those users also claim
that their willingness to use BIP8 to force miners to activate taproot
was the reason it did eventually activate. They claim that, if taproot
was the reason it did eventually activate. They claim that if taproot
had not been activated quickly, other users would have also begun
running BIP8. Unfortunately, there's no way to prove what would have
happened, and so we can't say for sure how much BIP8 contributed to the
@ -2136,7 +2136,7 @@ future attempt to activate a ((("consensus rules", "soft forks", "speedy trial a
=== Consensus Software Development
Consensus software((("consensus rules", "software development")))((("software development for consensus rules")))((("forks", "consensus rule software development"))) continues to evolve and there is much
Consensus software((("consensus rules", "software development")))((("software development for consensus rules")))((("forks", "consensus rule software development"))) continues to evolve, and there is much
discussion on the various mechanisms for changing the consensus rules.
By its very nature, Bitcoin sets a very high bar on coordination and
consensus for changes. As a decentralized system, it has no "authority"
A transaction on the blockchain can commit to a value,
proving that a piece of data existed at the time
it was recorded (Timestamp). The commitment cannot be modified ex-post-facto
(Immutability) and the proof will be stored permanently (Durability).
(Immutability), and the proof will be stored permanently (Durability).
Kickstarter (Lighthouse):: Consistency + Atomicity + Integrity. If you
sign one input and the output (Integrity) of a fundraiser transaction,
@ -231,14 +231,14 @@ validation. That brings ((("colored coins application", "P2C (pay to contract)"
==== Client-Side Validation
Bob had ((("colored coins application", "client-side validation")))((("client-side validation")))((("validating", "with client-side validation", secondary-sortas="client-side validation")))some colored coins associated with a UTXO. He spent that UTXO
in a way that committed to a contract which indicated how the next
in a way that committed to a contract that indicated how the next
receiver (or receivers) of the colored coins will prove their ownership
over the coins in order to further spend them.
In practice, Bob's P2C contract likely simply committed to one or more
unique identifiers for the UTXOs that will be used as single-use seals
for deciding when the colored coins are next spent. For example, Bob's
contract may have indicated that the UTXO that Alice received to her P2C
contract may have indicated that the UTXO Alice received to her P2C
tweaked public key now controls half of his colored coins, with the
other half of his colored coins now being assigned to a different UTXO
that may have nothing to do with the transaction between Alice and Bob.
@ -341,7 +341,7 @@ Translated forwarding::
Native forwarding is conceptually simpler but essentially requires a
separate Lightning Network for every asset. Translated forwarding
allows building on the economies of scale of the Bitcoin Lightning
Network but it may be vulnerable to a problem called((("free American call option"))) the _free American
Network, 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
siphon money from the hop next to them. Although there's no known
@ -361,7 +361,7 @@ working on BIPs that may be available after this book goes((("Bitcoin", "as appl
transactions between two parties, outside of the Bitcoin blockchain.
transactions between two parties outside of the Bitcoin blockchain.
These transactions, which would be valid if settled on the Bitcoin
blockchain, are held offchain instead, waiting for
eventual batch settlement. Because the transactions are not settled,
@ -370,15 +370,15 @@ extremely high transaction throughput, low latency, and
fine granularity.
Actually, the term _channel_ is a metaphor. State channels are virtual
constructs represented by the exchange of state between two parties,
outside of the blockchain. There are no "channels" per se and the
constructs represented by the exchange of state between two parties
outside of the blockchain. There are no "channels" per se, and the
underlying data transport mechanism is not the channel. We use the term
channel to represent the relationship and shared state between two
parties, outside of the blockchain.
_channel_ to represent the relationship and shared state between two
parties outside of the blockchain.
To further explain this
concept, think of a TCP stream. From the perspective of higher-level
protocols it is a "socket" connecting two applications across the
protocols, it is a "socket" connecting two applications across the
internet. But if you look at the network traffic, a TCP stream is just a
virtual channel over IP packets. Each endpoint of the TCP stream
sequences and assembles IP packets to create the illusion of a stream of
@ -404,7 +404,7 @@ the state being altered is the balance of a virtual currency.
==== State Channels—Basic Concepts and Terminology
A state channel((("payment channels", "state channels", id="payment-channel-state")))((("state channels", id="state-channel-terminology")))((("transactions", "state channels", id="transaction-state"))) is
established between two parties, through a transaction that locks a
established between two parties through a transaction that locks a
shared state on the blockchain. This is called ((("funding transactions")))the _funding transaction_.
This single transaction must be transmitted to
the network and mined to establish the channel. In the example of a
@ -438,7 +438,7 @@ In the entire lifetime of the channel, only two transactions need to be
submitted for mining on the blockchain: the funding and settlement
transactions. In between these two states, the two parties can exchange
any number of commitment transactions that are never seen by anyone
else,nor submitted to the blockchain.
else or submitted to the blockchain.
<<payment_channel>> illustrates a payment channel between Bob and Alice,
showing the funding, commitment, and settlement ((("payment channels", "state channels", startref="payment-channel-state")))((("state channels", startref="state-channel-terminology")))((("transactions", "state channels", startref="transaction-state")))transactions.
@ -453,7 +453,7 @@ To
explain ((("payment channels", "example of", id="payment-channel-example")))state channels, we start with a very simple example. We
demonstrate a one-way channel, meaning that value is flowing in one
direction only. We will also start with the naive assumption that no one
is trying to cheat, to keep things simple. Once we have the basic
is trying to cheat to keep things simple. Once we have the basic
channel idea explained, we will then look at what it takes to make it
trustless so that neither party _can_ cheat, even if they are trying to.
@ -525,7 +525,7 @@ second commitment transaction, together with another second of video.
In this way, Emma's software continues to send commitment transactions
to Fabian's server in exchange for streaming video. The balance of the
channel gradually accumulates in favor of Fabian, as Emma consumes more
channel gradually accumulates in favor of Fabian as Emma consumes more
seconds of video. Let's say Emma watches 600 seconds (10 minutes) of
video, creating and signing 600 commitment transactions. The last
commitment transaction (#600) will have two outputs, splitting the
@ -564,7 +564,7 @@ to fix those:
- While the channel is running, Emma can take any of the commitment
transactions Fabian has countersigned and transmit one to the
blockchain. Why pay for 600 seconds of video, if she can transmit
blockchain. Why pay for 600 seconds of video if she can transmit
commitment transaction #1 and only pay for 1 second of video? The
channel fails because Emma can cheat by broadcasting a prior
commitment that is in her favor.
@ -578,11 +578,11 @@ transaction at the same time. She signs the funding transaction but
doesn't transmit it to anyone. Emma transmits only the refund
transaction to Fabian and obtains his signature.
The refund transaction acts as the first commitment transaction and its
The refund transaction acts as the first commitment transaction, and its
timelock establishes the upper bound for the channel's life. In this
case, Emma could set the lock time to 30 days or 4,320 blocks into the
future. All subsequent commitment transactions must have a shorter
timelock, so that they can be redeemed before the refund transaction.
timelock so they can be redeemed before the refund transaction.
Now that Emma has a fully signed refund transaction, she can confidently
transmit the signed funding transaction knowing that she can eventually,
@ -591,7 +591,7 @@ disappears.
Every commitment transaction the parties exchange during the life of the
channel will be timelocked into the future. But the delay will be
slightly shorter for each commitment so the most recent commitment can
slightly shorter for each commitment, so the most recent commitment can
be redeemed before the prior commitment it invalidates. Because of the
lock time, neither party can successfully propagate any of the
commitment transactions until their timelock expires. If all goes well,
@ -637,14 +637,14 @@ construct more flexible, useful, and sophisticated state channels.
Timelocks are not the only way to invalidate prior commitment
transactions. In the next sections we will see how a revocation key can
be used to achieve the same result. Timelocks are effective but they
be used to achieve the same result. Timelocks are effective, but they
have two distinct disadvantages. By establishing a maximum timelock when
the channel is first opened, they limit the lifetime of the channel.
Worse, they force channel implementations to strike a balance between
allowing long-lived channels and forcing one of the participants to wait
a very long time for a refund in case of premature closure. For example,
if you allow the channel to remain open for 30 days, by setting the
refund timelock to 30 days, if one of the parties disappears immediately
if you allow the channel to remain open for 30 days by setting the
refund timelock to 30 days, if one of the parties disappears immediately,
the other party must wait 30 days for a refund. The more distant the
endpoint, the more distant the refund.
@ -689,10 +689,10 @@ transaction and builds a settlement transaction that is identical in
every way except that it omits the timelock. Both parties can sign this
settlement transaction knowing there is no way to cheat and get a more
favorable balance. By cooperatively signing and transmitting the
settlement transaction they can close the channel and redeem their
settlement transaction, they can close the channel and redeem their
balance immediately. Worst case, one of the parties can be petty, refuse
to cooperate, and force the other party to do a unilateral close with
the most recent commitment transaction. But if they do that, they have
the most recent commitment transaction. If they do that, they have
to wait for their funds ((("payment channels", "trustless channels", startref="payment-channel-trustless")))((("trustless channels", startref="trustless-channel")))((("timelocks", "trustless channels", startref="timelock-trustless")))((("commitment transactions", "trustless channels", startref="commit-trustless")))too.
==== Asymmetric Revocable Commitments
@ -825,7 +825,7 @@ redemption script for that output allows one party to redeem it after
key, penalizing transmission of a revoked commitment.
So when Hitesh creates a commitment transaction for Irene to sign, he
makes the second output payable to himself after 1,000 blocks, or to the
makes the second output payable to himself after 1,000 blocks or to the
revocation public key (of which he only knows half the secret). Hitesh
constructs this transaction. He will only reveal his half of the
revocation secret to Irene when he is ready to move to a new channel
@ -850,8 +850,8 @@ ENDIF
CHECKSIG
----
Irene can confidently sign this transaction, since if transmitted it
will immediately pay her what she is owed. Hitesh holds the transaction,
Irene can confidently sign this transaction since if transmitted, it
will immediately pay her what she is owed. Hitesh holds the transaction
but knows that if he transmits it in a unilateral channel closing, he
will have to wait 1,000 blocks to get paid.
@ -872,7 +872,7 @@ The revocation protocol is bilateral, meaning that in each round, as the
channel state is advanced, the two parties exchange new commitments,
exchange revocation secrets for the previous commitments, and sign each
other's new commitment transactions. After they accept a new state, they
make the prior state impossible to use, by giving each other the
make the prior state impossible to use by giving each other the
necessary revocation secrets to punish any cheating.
Let's look at an example of how it works. One of Irene's customers wants
@ -883,7 +883,7 @@ reflect the new balance. They will commit to a new state (state number
bitcoins to Irene. To advance the state of the channel, they will each
create new commitment transactions reflecting the new channel balance.
As before, these commitment transactions are asymmetric so that the
As before, these commitment transactions are asymmetric so the
commitment transaction each party holds forces them to wait if they
redeem it. Crucially, before signing new commitment transactions, they
must first exchange revocation keys to invalidate any outdated commitments.
@ -891,7 +891,7 @@ In this particular case, Hitesh's interests are aligned with the real
state of the channel and therefore he has no reason to broadcast a prior
state. However, for Irene, state number 1 leaves her with a higher
balance than state 2. When Irene gives Hitesh the revocation key for her
prior commitment transaction (state number 1) she is effectively
prior commitment transaction (state number 1), she is effectively
revoking her ability to profit from regressing the channel to a prior
state because with the revocation key, Hitesh can redeem both outputs of
the prior commitment transaction without delay. Meaning if Irene
@ -919,7 +919,7 @@ channel.
Payment channels ((("payment channels", "HTLC (Hash Time Lock Contract)", id="payment-channel-htlc")))((("HTLC (Hash Time Lock Contract)", id="htlc")))can be further
extended with a special type of smart contract that allows the
participants to commit funds to a redeemable secret, with an expiration
time. This feature is called a _Hash Time Lock Contract_, or _HTLC_, and
time. This feature is called a _hash time lock contract_, or _HTLC_, and
is used in both bidirectional and routed payment channels.
Let's first explain the "hash" part of the HTLC. To create an HTLC, the
@ -957,8 +957,8 @@ ENDIF
Anyone who knows the secret +R+, which when hashed equals to +H+, can
redeem this output by exercising the first clause of the +IF+ flow.
If the secret is not revealed and the HTLC claimed, after a certain
number of blocks the payer can claim a refund using the second clause in
If the secret is not revealed and the HTLC claimed after a certain
number of blocks, the payer can claim a refund using the second clause in
the +IF+ flow.
This is a basic implementation of an HTLC. This type of HTLC can be
@ -1008,7 +1008,7 @@ Alice wants to pay Eric 1 bitcoin. However, Alice is not connected to
Eric by a payment channel. Creating a payment channel requires a funding
transaction, which must be committed to the Bitcoin blockchain. Alice
does not want to open a new payment channel and commit more of her
funds. Is there a way to pay Eric, indirectly?
funds. Is there a way to pay Eric indirectly?
<<ln_payment_process>> shows the step-by-step process of routing a
payment from Alice to Eric, through a series of HTLC commitments on the
@ -1113,17 +1113,17 @@ construct a _path_ through the network by connecting payment channels
with sufficient capacity. Nodes advertise routing information, including
what channels they have open, how much capacity each channel has, and
what fees they charge to route payments. The routing information can be
shared in a variety of ways and different pathfinding protocols have
shared in a variety of ways, and different pathfinding protocols have
emerged as Lightning Network technology has advanced.
Current implementations of
route discovery use a P2P model where nodes propagate channel
announcements to their peers, in a "flooding" model, similar to how
announcements to their peers in a "flooding" model, similar to how
Bitcoin propagates transactions.
In our previous example, Alice's node uses one of these route discovery
mechanisms to find one or more paths connecting her node to Eric's node.
Once Alice's node has constructed a path, she will initialize that path
through the network, by propagating a series of encrypted and nested
through the network by propagating a series of encrypted and nested
instructions to connect each of the adjacent payment channels.
Importantly, this path is only known to Alice's node. All other
@ -1132,10 +1132,10 @@ Carol's perspective, this looks like a payment from Bob to Diana. Carol
does not know that Bob is actually relaying a payment from Alice. She
also doesn't know that Diana will be relaying a payment to Eric.
This is a critical feature of the Lightning Network, because it ensures
This is a critical feature of the Lightning Network because it ensures
privacy of payments and makes it difficult to apply surveillance,
censorship, or blacklists. But how does Alice establish this payment
path, without revealing anything to the intermediary nodes?
path without revealing anything to the intermediary nodes?
The Lightning Network implements an onion-routed protocol based on a
scheme called https://oreil.ly/fuCiK[Sphinx]. This routing protocol
@ -1148,7 +1148,7 @@ through the Lightning Network such that:
- Other than the previous and next hops, they cannot learn about any
other nodes that are part of the path.
- They cannot identify the length of the payment path, or their own
- They cannot identify the length of the payment path or their own
position in that path.
- Each part of the path is encrypted in such a way that a network-level
@ -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 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
@ -61,7 +61,7 @@ All the code snippets use real values and calculations where possible, so that y
This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.
We appreciate, but do not require, attribution. An attribution usually includes [.keep-together]#the title,# author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by [.keep-together]#Andreas M.# Antonopoulos and David A. Harding (O’Reilly). Copyright 2024, ISBN 978-1-491-95438-6.”
We appreciate, but do not require, attribution. An attribution usually includes [.keep-together]#the title,# author, publisher, and ISBN. For example: “_Mastering Bitcoin_, 3rd ed., by [.keep-together]#Andreas M.# Antonopoulos and David A. Harding (O’Reilly). Copyright 2024, ISBN 978-1-098-15009-9.”
Some editions of this book are offered under an open source license, such as https://oreil.ly/RzUHE[CC-BY-NC], in which case the terms of that license apply.
The Bitcoin addresses, transactions, keys, QR codes, and blockchain data used in this book are, for the most part, real. That means you can browse the blockchain, look at the transactions offered as examples, retrieve them with your own scripts or programs, etc.
However, note that the private keys used to construct addresses are either printed in this book, or have been "burned." That means that if you send money to any of these addresses, the money will either be lost forever, or in some cases everyone who can read the book can take it using the private keys printed in here.
However, note that the private keys used to construct addresses are either printed in this book or have been "burned." That means if you send money to any of these addresses, the money will either be lost forever, or in some cases everyone who can read the book can take it using the private keys printed in here.
[WARNING]
====
DO NOT SEND MONEY TO ANY OF THE ADDRESSES IN THIS BOOK. Your money will be taken by another reader, or lost forever.
DO NOT SEND MONEY TO ANY OF THE ADDRESSES IN THIS BOOK. Your money will be taken by another reader or lost forever.
====
=== O'Reilly Online Learning
@ -126,25 +126,25 @@ Watch us on YouTube: link:$$https://youtube.com/oreillymedia$$[].
=== Contacting the Authors
You can contact Andreas M. Antonopoulos on his personal site:
Many thanks to all of Andreas's patrons who support his work through monthly donations. You can follow his Patreon page here:
link:$$https://patreon.com/aantonop$$[]
link:$$https://patreon.com/aantonop$$[].
Information about _Mastering Bitcoin_ as well as Andreas's Open Edition and translations are available on:
link:$$https://bitcoinbook.info/$$[]
Information about _Mastering Bitcoin_ as well as Andreas's Open Edition and translations is available on:
link:$$https://bitcoinbook.info$$[].
You can contact David A. Harding on his personal site:
link:$$https://dtrt.org/$$[]
link:$$https://dtrt.org$$[].
=== Acknowledgments for the First and Second Editions
@ -156,11 +156,11 @@ It is impossible to make a distinction between the Bitcoin technology and the Bi
The journey to becoming an author starts long before the first book, of course. My first language (and schooling) was Greek, so I had to take a remedial English writing course in my first year of university. I owe thanks to Diana Kordas, my English writing teacher, who helped me build confidence and skills that year. Later, as a professional, I developed my technical writing skills on the topic of data centers, writing for _Network World_ magazine. I owe thanks to John Dix and John Gallant, who gave me my first writing job as a columnist at _Network World_ and to my editor Michael Cooney and my colleague Johna Till Johnson who edited my columns and made them fit for publication. Writing 500 words a week for four years gave me enough experience to eventually consider becoming an author.
Thanks also to those who supported me when I submitted my book proposal to O'Reilly, by providing references and reviewing the proposal. Specifically, thanks to John Gallant, Gregory Ness, Richard Stiennon, Joel Snyder, Adam B. Levine, Sandra Gittlen, John Dix, Johna Till Johnson, Roger Ver, and Jon Matonis. Special thanks to Richard Kagan and Tymon Mattoszko, who reviewed early versions of the proposal and Matthew Taylor, who copyedited the proposal.
Thanks also to those who supported me when I submitted my book proposal to O'Reilly by providing references and reviewing the proposal. Specifically, thanks to John Gallant, Gregory Ness, Richard Stiennon, Joel Snyder, Adam B. Levine, Sandra Gittlen, John Dix, Johna Till Johnson, Roger Ver, and Jon Matonis. Special thanks to Richard Kagan and Tymon Mattoszko, who reviewed early versions of the proposal and Matthew Taylor, who copyedited the proposal.
Thanks to Cricket Liu, author of the O'Reilly title _DNS and BIND_, who introduced me to O'Reilly. Thanks also to Michael Loukides and Allyson MacDonald at O'Reilly, who worked for months to help make this book happen. Allyson was especially patient when deadlines were missed and deliverables delayed as life intervened in our planned schedule. For the second edition, I thank Timothy McGovern for guiding the process, Kim Cofer for patiently editing, and Rebecca Panzer for illustrating many new diagrams.
The first few drafts of the first few chapters were the hardest, because Bitcoin is a difficult subject to unravel. Every time I pulled on one thread of the Bitcoin technology, I had to pull on the whole thing. I repeatedly got stuck and a bit despondent as I struggled to make the topic easy to understand and create a narrative around such a dense technical subject. Eventually, I decided to tell the story of Bitcoin through the stories of the people using Bitcoin and the whole book became a lot easier to write. I owe thanks to my friend and mentor, Richard Kagan, who helped me unravel the story and get past the moments of writer's block. I thank Pamela Morgan, who reviewed early drafts of each chapter in the first and second edition of the book, and asked the hard questions to make them better. Also, thanks to the developers of the San Francisco Bitcoin Developers Meetup group as well as Taariq Lewis and Denise Terry for helping test the early material. Thanks also to Andrew Naugler for infographic design.
The first few drafts of the first few chapters were the hardest, because Bitcoin is a difficult subject to unravel. Every time I pulled on one thread of the Bitcoin technology, I had to pull on the whole thing. I repeatedly got stuck and a bit despondent as I struggled to make the topic easy to understand and create a narrative around such a dense technical subject. Eventually, I decided to tell the story of Bitcoin through the stories of the people using Bitcoin and the whole book became a lot easier to write. I owe thanks to my friend and mentor, Richard Kagan, who helped me unravel the story and get past the moments of writer's block. I thank Pamela Morgan, who reviewed early drafts of each chapter in the first and second edition of the book and asked the hard questions to make them better. Also, thanks to the developers of the San Francisco Bitcoin Developers Meetup group as well as Taariq Lewis and Denise Terry for helping test the early material. Thanks also to Andrew Naugler for infographic design.
During the development of the book, I made early drafts available on GitHub and invited public comments. More than a hundred comments, suggestions, corrections, and contributions were submitted in response. Those contributions are explicitly acknowledged, with my thanks, in <<github_contrib>>. Most of all, my sincere thanks to my volunteer GitHub editors Ming T. Nguyen (1st edition) and Will Binns (2nd edition), who worked tirelessly to curate, manage, and resolve pull requests, issue reports, and perform bug fixes on GitHub.
Clare Laylock
6 months ago