mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-11-13 11:28:57 +00:00
PR and QC1
This commit is contained in:
Clare Laylock
parent
ebbf5c9865
commit
74355b72a3
@ -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
|
||||
it has been in use since 2015.
|
||||
|
||||
=== Calculations
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
|
||||
<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-weighted average 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
|
||||
|
||||
@ -26,7 +26,7 @@ interactions between several users by sending
|
||||
funds from one wallet to another. While tracking a transaction through
|
||||
the Bitcoin network to the blockchain, we will use a _blockchain
|
||||
explorer_ site to visualize each step. A blockchain explorer is a web
|
||||
application that operates as a bitcoin search engine, in that it allows
|
||||
application that operates as a Bitcoin search engine, in that it allows
|
||||
you to search for addresses, transactions, and blocks and see the
|
||||
relationships and flows between them.
|
||||
|
||||
@ -67,7 +67,7 @@ Alice, ((("transactions", "spending bitcoins", id="transaction-spend")))((("bitc
|
||||
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]
|
||||
====
|
||||
----
|
||||
https://blockstream.info/tx/674616f1fbc6cc748213648754724eebff0fc04506f2c81efb1349d1ebc8a2ef
|
||||
----
|
||||
====
|
||||
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.
|
||||
|
||||
@ -36,8 +36,8 @@ full time and several dozen more on a part-time basis. Anyone can
|
||||
contribute to the code—including you!
|
||||
|
||||
When Bitcoin was created by Satoshi Nakamoto, the
|
||||
software was mostly completed before publication of the whitepaper reproduced in
|
||||
<<satoshi_whitepaper>>. Satoshi wanted to make sure the
|
||||
software was mostly completed before publication of the whitepaper (reproduced in
|
||||
<<satoshi_whitepaper>>). Satoshi wanted to make sure the
|
||||
implementation worked before publishing a paper about it. That first implementation, then simply
|
||||
known as "Bitcoin," has been heavily modified and
|
||||
improved. It has evolved into what is known as _Bitcoin Core_, to
|
||||
@ -83,17 +83,17 @@ source repository from GitHub. On the https://oreil.ly/hN9g1[Bitcoin Core downl
|
||||
page], select the most recent version and download the compressed
|
||||
archive of the source code. Alternatively, use the Git command line to create a
|
||||
local copy of the source code from the
|
||||
https://oreil.ly/BdOwl[GitHub bitcoin page].
|
||||
https://oreil.ly/BdOwl[GitHub Bitcoin page].
|
||||
|
||||
[TIP]
|
||||
====
|
||||
In
|
||||
many of the ((("command prompts")))((("shell command prompts")))examples in this chapter we will be using the operating
|
||||
many of the ((("command prompts")))((("shell command prompts")))examples in this chapter, we will be using the operating
|
||||
system's command-line interface (also known as a "shell"), accessed via
|
||||
a "terminal" application. The shell will display a prompt, you type a
|
||||
command, and the shell responds with some text and a new prompt for your
|
||||
next command. The prompt may look different on your system, but in the
|
||||
following examples it is denoted by a +$+ symbol. In the examples, when
|
||||
following examples, it is denoted by a +$+ symbol. In the examples, when
|
||||
you see text after a +$+ symbol, don't type the +$+ symbol but type the
|
||||
command immediately following it, then press Enter to execute the
|
||||
command. In the examples, the lines below each command are the operating
|
||||
@ -318,7 +318,7 @@ cores if they are available. If all goes well, Bitcoin Core is now
|
||||
compiled. You should run the unit test suite with +make check+ to ensure
|
||||
the linked libraries are not broken in obvious ways. The final step is
|
||||
to install the various executables on your system using the +make
|
||||
install+ command. You may be prompted for your user password, because
|
||||
install+ command. You may be prompted for your user password because
|
||||
this step requires administrative privileges:
|
||||
|
||||
----
|
||||
@ -487,10 +487,10 @@ inside the configuration file it refers to.
|
||||
++datadir++:: Select((("datadir option (bitcoind command)"))) the directory and filesystem in which to put all the
|
||||
blockchain data. By default this is the _.bitcoin_ subdirectory of your
|
||||
home directory. Depending on your configuration, this can use from about 10
|
||||
gigabytes to almost 1 terabyte as of this writing, with the maximum size
|
||||
GB to almost 1 TB as of this writing, with the maximum size
|
||||
expected to increase by several hundred gigabytes per year.
|
||||
|
||||
++prune++:: Reduce the((("prune option (bitcoind command)"))) blockchain disk space requirements to this many megabytes, by
|
||||
++prune++:: Reduce the((("prune option (bitcoind command)"))) blockchain disk space requirements to this many megabytes by
|
||||
deleting old blocks. Use this on a resource-constrained node that can't
|
||||
fit the full blockchain. Other parts of the system will use other disk
|
||||
space that can't currently be pruned, so you will still need at least
|
||||
@ -500,7 +500,7 @@ the minimum amount of space mentioned in the +datadir+ option.
|
||||
programmatically retrieve any transaction by its ID provided that the
|
||||
block containing that transaction hasn't been pruned.
|
||||
|
||||
++dbcache++:: The size((("dbcache option (bitcoind command)"))) of the UTXO cache. The default is 450 MiB. Increase
|
||||
++dbcache++:: The size((("dbcache option (bitcoind command)"))) of the UTXO cache. The default is 450 mebibytes (MiB). Increase
|
||||
this size on high-end hardware to read and write from your disk less
|
||||
often, or reduce the size on low-end hardware to save memory at the
|
||||
expense of using your disk more frequently.
|
||||
@ -527,7 +527,7 @@ indexing, you need to
|
||||
wait for it to rebuild the index.
|
||||
****
|
||||
|
||||
<<full_index_node>> shows how you might combine the preceding options,
|
||||
<<full_index_node>> shows how you might combine the preceding options
|
||||
with a fully indexed node, running as an API backend for a bitcoin
|
||||
application.
|
||||
|
||||
@ -582,7 +582,7 @@ $ bitcoind -printtoconsole
|
||||
2023-01-28T03:43:39Z scheduler thread start
|
||||
2023-01-28T03:43:39Z [http] creating work queue of depth 16
|
||||
2023-01-28T03:43:39Z Using random cookie authentication.
|
||||
2023-01-28T03:43:39Z Generated RPC authentication cookie /lotsofspace/bitcoin/.cookie
|
||||
2023-01-28T03:43:39Z Generated RPC cookie /lotsofspace/bitcoin/.cookie
|
||||
2023-01-28T03:43:39Z [http] starting 4 worker threads
|
||||
2023-01-28T03:43:39Z Using wallet directory /lotsofspace/bitcoin/wallets
|
||||
2023-01-28T03:43:39Z init message: Verifying wallet(s)…
|
||||
@ -681,8 +681,8 @@ Result:
|
||||
Examples:
|
||||
> bitcoin-cli getblockhash 1000
|
||||
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest",
|
||||
"method": "getblockhash",
|
||||
"params": [1000]}' -H 'content-type: text/plain;' http://127.0.0.1:8332/
|
||||
"method": "getblockhash",
|
||||
"params": [1000]}' -H 'content-type: text/plain;' http://127.0.0.1:8332/
|
||||
----
|
||||
|
||||
At the end of the help information you will see two examples of the RPC
|
||||
@ -774,7 +774,7 @@ on how many blocks your ((("Bitcoin Core", "command-line interface", "status inf
|
||||
In <<spending_bitcoin>>, Alice ((("Bitcoin Core", "command-line interface", "exploring/decoding transactions", id="bitcoin-core-command-transaction")))((("command-line interface (Bitcoin Core)", "exploring/decoding transactions", id="command-transaction")))((("transactions", "exploring/decoding", id="transactions-explore-decode")))((("exploring", "transactions", id="explore-transaction")))((("decoding", "transactions", id="decode-transaction")))made a purchase from Bob's store. Her
|
||||
transaction was recorded on the blockchain.
|
||||
Let's use the API to retrieve and examine that transaction by passing
|
||||
the txid as a parameter:
|
||||
the transaction ID (txid) as a parameter:
|
||||
|
||||
[[alice_tx_serialized]]
|
||||
.Alice's serialized transaction
|
||||
@ -882,7 +882,7 @@ Bob and the change back to Alice.
|
||||
We can further explore the blockchain by examining the previous
|
||||
transaction referenced by its +txid+ in this transaction using the same
|
||||
commands (e.g., +getrawtransaction+). Jumping from transaction to
|
||||
transaction we can follow a chain of transactions back as the coins are
|
||||
transaction, we can follow a chain of transactions back as the coins are
|
||||
transmitted from one owner to the((("Bitcoin Core", "command-line interface", "exploring/decoding transactions", startref="bitcoin-core-command-transaction")))((("command-line interface (Bitcoin Core)", "exploring/decoding transactions", startref="command-transaction")))((("transactions", "exploring/decoding", startref="transactions-explore-decode")))((("exploring", "transactions", startref="explore-transaction")))((("decoding", "transactions", startref="decode-transaction"))) next.
|
||||
|
||||
==== Exploring Blocks
|
||||
@ -928,7 +928,7 @@ f6cd83c3ca
|
||||
"difficulty": 157416.4018436489,
|
||||
"chainwork": "[...]00000000000000000000000000000000000000541788211ac227bc",
|
||||
"nTx": 13,
|
||||
"previousblockhash": "[...]000b60bc96a44724fd72daf9b92cf8ad00510b5224c6253ac40095",
|
||||
"previousblockhash": "[...]0b60bc96a44724fd72daf9b92cf8ad00510b5224c6253ac40095",
|
||||
"nextblockhash": "[...]00129f5f02be247070bf7334d3753e4ddee502780c2acaecec6d66",
|
||||
"strippedsize": 4179,
|
||||
"size": 4179,
|
||||
@ -968,8 +968,7 @@ we'll examine those ((("Bitcoin Core", "command-line interface", "exploring bloc
|
||||
|
||||
The
|
||||
+bitcoin-cli+ helper is ((("Bitcoin Core", "command-line interface", "API access", id="bitcoin-core-command-api")))((("command-line interface (Bitcoin Core)", "API access", id="command-api")))((("API access", id="api")))very useful for exploring the Bitcoin Core API
|
||||
and testing functions. But the whole point of an application programming
|
||||
interface is to access functions programmatically. In this section we
|
||||
and testing functions. But the whole point of an API is to access functions programmatically. In this section we
|
||||
will demonstrate accessing Bitcoin Core from another program.
|
||||
|
||||
Bitcoin Core's API is a JSON-RPC interface. JSON stands for JavaScript
|
||||
@ -985,8 +984,8 @@ client to construct one of these JSON-RPC calls:
|
||||
|
||||
----
|
||||
$ curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest",
|
||||
"method": "getblockchaininfo",
|
||||
"params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
|
||||
"method": "getblockchaininfo",
|
||||
"params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
|
||||
----
|
||||
|
||||
This command shows that +curl+ submits an HTTP request to the local host
|
||||
@ -1006,13 +1005,13 @@ any higher-level Bitcoin Core RPC wrappers), ((("Bitcoin Core", "authentication"
|
||||
====
|
||||
----
|
||||
$ cat .bitcoin/.cookie
|
||||
__cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0
|
||||
__cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0
|
||||
|
||||
$ curl
|
||||
--user __cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0
|
||||
--data-binary '{"jsonrpc": "1.0", "id":"curltest",
|
||||
"method": "getblockchaininfo",
|
||||
"params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
|
||||
--user __cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031b17b19cd0
|
||||
--data-binary '{"jsonrpc": "1.0", "id":"curltest",
|
||||
"method": "getblockchaininfo",
|
||||
"params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/
|
||||
|
||||
{"result":{"chain":"main","blocks":799278,"headers":799278,
|
||||
"bestblockhash":"000000000000000000018387c50988ec705a95d6f765b206b6629971e6978879",
|
||||
@ -1150,7 +1149,7 @@ https://oreil.ly/xn_rg[python-bitcoinlib]:: A ((("Python toolkits")))((("python
|
||||
https://oreil.ly/wcpXP[pycoin]:: A Python bitcoin library by Richard Kiss
|
||||
|
||||
==== Go
|
||||
https://oreil.ly/h5MEI[btcd]:: A ((("Go toolkits")))((("btcd")))Go language full-node Bitcoin client
|
||||
https://oreil.ly/h5MEI[btcd]:: A ((("Go toolkits")))((("btcd")))Go language, full-node Bitcoin client
|
||||
|
||||
==== Rust
|
||||
https://oreil.ly/me6gf[rust-bitcoin]:: Rust ((("Rust toolkits")))((("rust-bitcoin")))bitcoin library for serialization, parsing, and API calls
|
||||
@ -1161,7 +1160,7 @@ https://bitcoin-s.org[bitcoin-s]:: A ((("Scala toolkits")))((("bitcoin-s")))Bitc
|
||||
==== C#
|
||||
https://oreil.ly/Qfjgq[NBitcoin]:: Comprehensive((("C# toolkits")))((("NBitcoin"))) bitcoin library for the .NET framework
|
||||
|
||||
Many more libraries exist in a variety of other programming languages
|
||||
Many more libraries exist in a variety of other programming languages,
|
||||
and more are created all the time.
|
||||
|
||||
If you followed the instructions in this chapter, you now have Bitcoin
|
||||
|
||||
@ -13,7 +13,7 @@ The original Bitcoin paper describes a very simple scheme for achieving
|
||||
those goals, shown in <<pay-to-pure-pubkey>>. A receiver like Bob
|
||||
accepts bitcoins to a public key in a transaction that is signed by the
|
||||
spender (like Alice). The bitcoins that Alice is spending had been
|
||||
previously received to one her public keys, and she uses the
|
||||
previously received to one of her public keys, and she uses the
|
||||
corresponding private key to generate her signature. Full nodes can
|
||||
verify that Alice's signature commits to the output of a hash function
|
||||
that itself commits to Bob's public key and other transaction details.
|
||||
@ -93,10 +93,10 @@ over the private key is the root of user control over all funds
|
||||
associated with the corresponding Bitcoin public key. The private key is
|
||||
used to create signatures that are used to spend bitcoins by proving
|
||||
control of funds used in a transaction. The private key must remain
|
||||
secret at all times, because revealing it to third parties is equivalent
|
||||
secret at all times because revealing it to third parties is equivalent
|
||||
to giving them control over the bitcoins secured by that key. The private
|
||||
key must also be backed up and protected from accidental loss, because
|
||||
if it's lost it cannot be recovered and the funds secured by it are
|
||||
key must also be backed up and protected from accidental loss because
|
||||
if it's lost, it cannot be recovered and the funds secured by it are
|
||||
forever lost too.
|
||||
|
||||
[TIP]
|
||||
@ -119,7 +119,7 @@ number generators to produce 256 bits of entropy.
|
||||
|
||||
More precisely, the private key can be any number between +0+ and +n -
|
||||
1+ inclusive, where n is a constant (n = 1.1578 * 10^77^, slightly less
|
||||
than 2^256^) defined as the order of the elliptic curve used in bitcoin
|
||||
than 2^256^) defined as the order of the elliptic curve used in Bitcoin
|
||||
(see <<elliptic_curve>>). To create such a key, we randomly pick a
|
||||
256-bit number and check that it is less than +n+. In programming terms,
|
||||
this is usually achieved by feeding a larger string of random bits,
|
||||
@ -150,7 +150,7 @@ bits):
|
||||
|
||||
[TIP]
|
||||
====
|
||||
The size of Bitcoin's private key space, (2^256^) is an unfathomably
|
||||
The size of Bitcoin's private key space (2^256^) is an unfathomably
|
||||
large number. It is approximately 10^77^ in decimal. For comparison, the
|
||||
visible universe is estimated to((("private keys", "generating", startref="private-key-generate"))) contain 10^80^ atoms.
|
||||
====
|
||||
@ -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
|
||||
Bitcoin miners about 32 billion years.
|
||||
@ -1028,7 +1027,7 @@ identified several problems((("public key cryptography", "base58check encoding")
|
||||
- Its mixed-case presentation made it inconvenient to read aloud or
|
||||
transcribe. Try reading one of the legacy addresses in this chapter
|
||||
to a friend who you have transcribe it. Notice how you have to prefix
|
||||
every letter with the words "uppercase" and "lowercase." Also note
|
||||
every letter with the words "uppercase" and "lowercase." Also, note
|
||||
when you review their writing that the uppercase and lowercase
|
||||
versions of some letters can look similar in many people's
|
||||
handwriting.
|
||||
@ -1173,20 +1172,20 @@ time in a billion.
|
||||
//https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb
|
||||
|
||||
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>>.
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>P2WPKH</p></td>
|
||||
<td><p>OP_0 2b626ed108ad00a944bb2922a309844611d25468</p></td>
|
||||
<td><p><code>OP_0 2b626ed108ad00a944bb2922a309844611d25468</code></p></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><p>P2WSH</p></td>
|
||||
<td><p>OP_0 648a32e50b6fb7c5233b228f60a6a2ca4158400268844c4bc295ed5e8c3d626f</p></td>
|
||||
<td><p><code>OP_0 648a32e50b6fb7c5233b228f60a6a2ca4158400268844c4bc295ed5e8c3d626f</code></p></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><p>P2TR</p></td>
|
||||
<td><p>OP_1 2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311</p></td>
|
||||
<td><p><code>OP_1 2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311</code></p></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><p>Future Example</p></td>
|
||||
<td><p>OP_16 0000</p></td>
|
||||
<td><p><code>OP_16 0000</code></p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@ -1314,7 +1313,7 @@ the script, pass it into a SHA256 hash function, and use the 32-byte
|
||||
digest of that function in the witness program. For P2SH, the SHA256
|
||||
digest was hashed again with RIPEMD-160, but that may not be secure in
|
||||
some cases; for details, see <<p2sh_collision_attacks>>. A result of
|
||||
using SHA256 without RIPEMD160 is that P2WSH commitments are 32 bytes
|
||||
using SHA256 without RIPEMD-160 is that P2WSH commitments are 32 bytes
|
||||
(256 bits) instead 20 bytes (160 bits).
|
||||
|
||||
For the pay-to-taproot (P2TR) output, the witness program is a point on
|
||||
@ -1328,12 +1327,12 @@ program (2 bytes) with a null value.
|
||||
|
||||
Now that we know the version number and the witness program, we can
|
||||
convert each of them into a bech32 address. Let's use the bech32m reference
|
||||
library for Python to quickly generate those addresses, and then take a
|
||||
library for Python to quickly generate those addresses and then take a
|
||||
deeper look at what's happening:
|
||||
|
||||
----
|
||||
$ github="https://raw.githubusercontent.com"
|
||||
$ wget $github//sipa/bech32/master/ref/python/segwit_addr.py
|
||||
$ wget $github/sipa/bech32/master/ref/python/segwit_addr.py
|
||||
|
||||
$ python
|
||||
>>> from segwit_addr import *
|
||||
@ -1385,7 +1384,8 @@ decode(hrp, addr)
|
||||
>>> _ = decode("bc", "bc1q9d3xa5gg45q2j39m9y32xzvygcgay4rgc6aaee")
|
||||
>>> _[0], bytes(_[1]).hex()
|
||||
(0, '2b626ed108ad00a944bb2922a309844611d25468')
|
||||
>>> _ = decode("bc", "bc1p9nh05ha8wrljf7ru236awm4t2x0d5ctkkywmu9sclnm4t0av2vgs4k3au7")
|
||||
>>> _ = decode("bc",
|
||||
"bc1p9nh05ha8wrljf7ru236awm4t2x0d5ctkkywmu9sclnm4t0av2vgs4k3au7")
|
||||
>>> _[0], bytes(_[1]).hex()
|
||||
(1, '2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311')
|
||||
----
|
||||
@ -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
|
||||
from((("private keys", "compressed", startref="private-key-compress")))((("compressed private keys", startref="compress-private-key"))) older wallets.
|
||||
|
||||
=== Advanced Keys and Addresses
|
||||
@ -1613,7 +1613,7 @@ addresses that contain human-readable messages. For example,
|
||||
+1LoveBPzzD72PUXLzCkYAtGFYmK5vYNR33+ is a valid address that contains
|
||||
the letters forming the word "Love" as the first four base58 letters.
|
||||
Vanity addresses require generating and testing billions of candidate
|
||||
private keys, until a Bitcoin address with the desired pattern is found.
|
||||
private keys until a Bitcoin address with the desired pattern is found.
|
||||
Although there are some optimizations in the vanity generation
|
||||
algorithm, the process essentially involves picking a private key at
|
||||
random, deriving the public key, deriving the Bitcoin address, and
|
||||
@ -1767,7 +1767,7 @@ As you can see, Eugenia won't be creating the vanity address
|
||||
computers. Each additional character increases the difficulty by a
|
||||
factor of 58. Patterns with more than seven characters are usually found
|
||||
by specialized hardware, such as custom-built desktops with multiple
|
||||
GPUs.
|
||||
graphics processing units (GPUs).
|
||||
Vanity searches on GPU systems are many orders of magnitude
|
||||
faster than on a general-purpose CPU.
|
||||
|
||||
@ -1842,7 +1842,7 @@ image::images/mbc3_0410.png[]
|
||||
Some are intended to be given as gifts and have seasonal themes, such as
|
||||
Christmas and New Year's. Others are designed for storage in a
|
||||
bank vault or safe with the private key hidden in some way, either with
|
||||
opaque scratch-off stickers, or folded and sealed with tamper-proof
|
||||
opaque scratch-off stickers or folded and sealed with tamper-proof
|
||||
adhesive foil. Other designs feature additional copies of the key and
|
||||
address, in the form of detachable stubs similar to ticket stubs,
|
||||
allowing you to store multiple copies to protect against fire, flood, or
|
||||
|
||||
@ -72,7 +72,7 @@ be able to predict the new output--not even if they know the new input.
|
||||
|
||||
This allows us to take one random value and transform it into a
|
||||
practically unlimited number of seemingly random values. Even more
|
||||
usefully, later using the same hash function with the same ((("seeds")))input
|
||||
useful, later using the same hash function with the same ((("seeds")))input
|
||||
(called a _seed_) will produce the same seemingly random values:
|
||||
|
||||
----
|
||||
@ -160,7 +160,7 @@ that corresponds to the public child key Bob created.
|
||||
In other words, it's possible to create child public keys even if you
|
||||
don't know anything about the parent private key. The value added to a
|
||||
public key is ((("key tweaks")))known as a _key tweak._ If a deterministic algorithm is
|
||||
used for generating the key tweaks, then it's possible to for someone
|
||||
used for generating the key tweaks, then it's possible for someone
|
||||
who doesn't know the private key to create an essentially unlimited
|
||||
sequence of public child keys from a single public parent key. The
|
||||
person who controls the private parent key can then use the same key
|
||||
@ -179,7 +179,7 @@ transactions to the less-secure frontend for broadcast to the Bitcoin
|
||||
network.
|
||||
|
||||
Public child key derivation can produce a linear sequence of keys
|
||||
similar to the previously seen <<Type1_wallet>>, but modern wallets
|
||||
similar to the previously seen <<Type1_wallet>>, but modern wallet
|
||||
applications use one more trick to provide a tree of keys instead a
|
||||
single sequence, as described in the((("wallets", "key generation", "public child key derivation", startref="wallet-keygen-public-child")))((("key generation", "public child key derivation", startref="keygen-public-child")))((("public child key derivation", startref="public-child-derive")))((("child key pair derivation", startref="child-key-pair"))) following section.
|
||||
|
||||
@ -278,7 +278,7 @@ BIP39::
|
||||
adding a checksum to it, and encoding the data into a series of 12 to
|
||||
24 words (which may be localized to a user's native language). The
|
||||
words (plus an optional passphrase) are run through a _key-stretching
|
||||
function_ and the output is used as a seed. BIP39 recovery codes have
|
||||
function_, and the output is used as a seed. BIP39 recovery codes have
|
||||
several shortcomings, which later schemes attempt to address.
|
||||
|
||||
Electrum v2::
|
||||
@ -299,7 +299,7 @@ Aezeed::
|
||||
cryptographic properties of the recovery code.
|
||||
It also includes a _wallet birthday_
|
||||
in the recovery code, a reference to the date when the user created
|
||||
the wallet database; this allows a restoration process to find all of
|
||||
the wallet database. This allows a restoration process to find all of
|
||||
the funds associated with a wallet without scanning the entire
|
||||
blockchain, which is especially useful for privacy-focused lightweight clients.
|
||||
It includes support for changing the passphrase or changing other
|
||||
@ -318,7 +318,7 @@ Muun::
|
||||
Although this is unwieldy compared to the BIP39, Electrum v2, and
|
||||
Aezeed recovery codes, it provides support for new technologies and
|
||||
standards that are becoming more common in new wallets, such as
|
||||
Lightning Network support, output script descriptors, and miniscript.
|
||||
Lightning Network (LN) support, output script descriptors, and miniscript.
|
||||
|
||||
SLIP39::
|
||||
A successor ((("SLIP39 recovery codes")))to BIP39 with some of the same authors, SLIP39 allows
|
||||
@ -467,12 +467,12 @@ amount of every transaction listed but a blank entry for the
|
||||
Wallets should provide their users with a convenient way to back up
|
||||
label data. That seems obvious, but there are a number of
|
||||
widely used wallet applications that make it easy to create and use
|
||||
recovery codes but which provide no way to back up or restore label
|
||||
recovery codes but that provide no way to back up or restore label
|
||||
data.
|
||||
|
||||
Additionally, it may be useful for wallet applications to provide a
|
||||
standardized format to export labels so that they can be used in other
|
||||
applications, e.g., accounting software. A standard for that ((("labels, backing up", startref="label-backup")))format is
|
||||
applications (e.g., accounting software). A standard for that ((("labels, backing up", startref="label-backup")))format is
|
||||
proposed in BIP329.
|
||||
|
||||
Wallet applications implementing additional protocols beyond basic
|
||||
@ -507,7 +507,7 @@ and additional ((("wallets", "nonkey data, backing up", startref="wallet-nonkey-
|
||||
==== Backing Up Key Derivation Paths
|
||||
|
||||
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
|
||||
used in wallets as of early 2023:
|
||||
|
||||
- BIP39 recovery codes
|
||||
- BIP32 hierarchical deterministic (HD) key derivation
|
||||
- BIP32 HD key derivation
|
||||
- BIP44-style implicit paths
|
||||
|
||||
All of these standards have been around since 2014 or earlier and
|
||||
All of these standards have been around since 2014 or earlier, and
|
||||
you'll have no problem finding additional resources for using them.
|
||||
However, if you're feeling bold, we do encourage you to investigate more
|
||||
modern standards that may provide additional features or safety.
|
||||
@ -678,7 +678,7 @@ modern standards that may provide additional features or safety.
|
||||
BIP39 ((("wallets", "recovery codes", id="wallet-recovery-bip39")))((("recovery codes", id="recovery-code-bip39")))((("BIP39 recovery codes", id="bip39-recovery")))recovery codes are word
|
||||
sequences that represent (encode) a random number used as a seed to
|
||||
derive a deterministic wallet. The sequence of words is sufficient to
|
||||
re-create the seed and from there re-create all the
|
||||
re-create the seed and from there, re-create all the
|
||||
derived keys. A wallet application that implements deterministic wallets
|
||||
with a BIP39 recovery code will show the user a sequence of 12 to 24 words when
|
||||
first creating a wallet. That sequence of words is the wallet backup and
|
||||
@ -693,7 +693,7 @@ Recovery codes((("brainwallets"))) are often confused with
|
||||
"brainwallets." They are not the same. The primary difference is that a
|
||||
brainwallet consists of words chosen by the user, whereas recovery codes
|
||||
are created randomly by the wallet and presented to the user. This
|
||||
important difference makes recovery codes much more secure, because
|
||||
important difference makes recovery codes much more secure because
|
||||
humans are very poor sources of randomness.
|
||||
====
|
||||
|
||||
@ -902,7 +902,7 @@ some examples of recovery codes and the seeds ((("key-stretching functions", sta
|
||||
</tbody>
|
||||
</table>
|
||||
<table id="bip39_256_no_pass">
|
||||
<caption><span class="label">Table 5-7. </span>256-bit entropy BIP39 recovery code, no passphrase, resulting seed</caption>
|
||||
<caption>256-bit entropy BIP39 recovery code, no passphrase, resulting seed</caption>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p><strong>Entropy input (256 bits)</strong></p></td>
|
||||
@ -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.
|
||||
|
||||
@ -1089,7 +1089,7 @@ parent.
|
||||
image::images/mbc3_0507.png["ChildPrivateDerivation"]
|
||||
|
||||
Changing the index allows us to extend the parent and create the other
|
||||
children in the sequence, e.g., Child 0, Child 1, Child 2, etc. Each
|
||||
children in the sequence (e.g., Child 0, Child 1, Child 2, etc.). Each
|
||||
parent key can have 2,147,483,647 (2^31^) children (2^31^ is half of the
|
||||
entire 2^32^ range available because the other half is reserved for a
|
||||
special type of derivation we will talk about later in this chapter).
|
||||
@ -1177,9 +1177,9 @@ LrtJunSDMstweyLXhRgPxdp14sk9tJPW9
|
||||
|
||||
As
|
||||
mentioned previously, ((("key generation", "HD (hierarchical deterministic)", "public child key derivation", id="keygen-hd-public-child")))((("HD (hierarchical deterministic) key generation", "public child key derivation", id="hd-keygen-public-child")))((("public child key derivation", id="public-child")))((("child key pair derivation", "public keys", id="child-key-pair-public")))a very useful characteristic of HD wallets is the
|
||||
ability to derive public child keys from public parent keys, _without_
|
||||
ability to derive public child keys from public parent keys _without_
|
||||
having the private keys. This gives us two ways to derive a child public
|
||||
key: either from the child private key, or directly from the parent
|
||||
key: either from the child private key or directly from the parent
|
||||
public key.
|
||||
|
||||
An extended public key can be used, therefore, to derive all of the
|
||||
@ -1189,7 +1189,7 @@ structure.
|
||||
This shortcut can be used to create public key–only
|
||||
deployments where a server or application has a copy of an extended
|
||||
public key and no private keys whatsoever. That kind of deployment can
|
||||
produce an infinite number of public keys and Bitcoin addresses, but
|
||||
produce an infinite number of public keys and Bitcoin addresses but
|
||||
cannot spend any of the money sent to those addresses. Meanwhile, on
|
||||
another, more secure server, the extended private key can derive all the
|
||||
corresponding private keys to sign transactions and spend the money.
|
||||
@ -1359,9 +1359,9 @@ a "gap" in the tree above the level where extended public keys are used.
|
||||
|
||||
In simple terms, if you want to use the convenience of an xpub to derive
|
||||
branches of public keys, without exposing yourself to the risk of a
|
||||
leaked chain code, you should derive it from a hardened parent, rather
|
||||
leaked chain code, you should derive it from a hardened parent rather
|
||||
than a normal parent. As a best practice, the level-1 children of the
|
||||
master keys are always derived through the hardened derivation, to
|
||||
master keys are always derived through the hardened derivation to
|
||||
prevent compromise of the master keys.
|
||||
|
||||
===== Index numbers for normal and hardened derivation
|
||||
@ -1445,7 +1445,7 @@ extended key can have 4 billion children: 2 billion normal children and
|
||||
billion children, and so on. The tree can be as deep as you want, with
|
||||
an infinite number of generations. With all that flexibility, however,
|
||||
it becomes quite difficult to navigate this infinite tree. It is
|
||||
especially difficult to transfer HD wallets between implementations,
|
||||
especially difficult to transfer HD wallets between implementations
|
||||
because the possibilities for internal organization into branches and
|
||||
subbranches are endless.
|
||||
|
||||
@ -1456,7 +1456,7 @@ the "purpose" of the tree structure. Based on BIP43, an HD wallet
|
||||
should use only one level-1 branch of the tree, with the index number
|
||||
identifying the structure and namespace of the rest of the tree by
|
||||
defining its purpose. For example, an HD wallet using only branch
|
||||
m/i++'++/ is intended to signify a specific purpose and that
|
||||
m/i++'++/ is intended to signify a specific purpose, and that
|
||||
purpose is identified by index number "i."
|
||||
|
||||
Extending that specification, ((("BIP44 HD wallet tree structure", id="bip44")))BIP44 proposes a multiaccount structure
|
||||
@ -1474,10 +1474,10 @@ The first-level "purpose" is always set to +44'+. The second-level
|
||||
"coin_type" specifies the type of cryptocurrency coin, allowing for
|
||||
multicurrency HD wallets where each currency has its own subtree under
|
||||
the second level. Bitcoin is
|
||||
m/44'/0' and Bitcoin Testnet is m/44++'++/1++'++.
|
||||
m/44'/0' and Bitcoin Testnet is m/44++'++/1++'++.
|
||||
|
||||
The third level of the tree is "account," which allows users to
|
||||
subdivide their wallets into separate logical subaccounts, for
|
||||
subdivide their wallets into separate logical subaccounts for
|
||||
accounting or organizational purposes. For example, an HD wallet might
|
||||
contain two Bitcoin "accounts": m/44++'++/0++'++/0++'++
|
||||
and m/44++'++/0++'++/1++'++. Each account is the root of
|
||||
|
||||
@ -54,7 +54,7 @@ e739df2f899c49dc267c0ad280aca6dab0d2fa2b42a45182fc83e81713010000
|
||||
|
||||
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:
|
||||
eb3ae38f27191aa5f3850dc9cad00492b88b72404f9da135698679268041c54a
|
||||
----
|
||||
|
||||
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
|
||||
@ -685,7 +685,7 @@ satoshis aren't being ((("transactions", "outputs", "amount field", startref="tr
|
||||
|
||||
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
|
||||
instead be:
|
||||
|
||||
----
|
||||
<Bob's pubkey> OP_CHECKSIGVERIFY <now + 3 months> OP_CHECKLOCKTIMEVERIFYG
|
||||
<Bob's pubkey> OP_CHECKSIGVERIFY <now + 3 months> OP_CHECKLOCKTIMEVERIFY
|
||||
----
|
||||
|
||||
where +<now {plus} 3 months>+ is a block height or time value estimated
|
||||
@ -823,7 +822,7 @@ to be equal or greater to the timelock in the +OP_CHECKLOCKTIMEVERIFY+
|
||||
Alice set. Bob then broadcasts the transaction on the Bitcoin network.
|
||||
|
||||
Bob's transaction is evaluated as follows. If the +OP_CHECKLOCKTIMEVERIFY+
|
||||
parameter Alice set is less than or equal the spending transaction's
|
||||
parameter Alice set is less than or equal to the spending transaction's
|
||||
lock time, script execution continues (acts as if a _no
|
||||
operation_ or +OP_NOP+ opcode was executed). Otherwise, script
|
||||
execution halts and the transaction is deemed invalid.
|
||||
@ -911,7 +910,7 @@ the +OP_CHECKSEQUENCEVERIFY+ (+OP_CSV+) opcode.
|
||||
Relative timelocks are
|
||||
implemented according to the specifications in
|
||||
https://oreil.ly/ZuANb[BIP68,
|
||||
Relative lock-time using consensus-enforced sequence numbers] and
|
||||
relative lock-time using consensus-enforced sequence numbers] and
|
||||
https://oreil.ly/dLA2r[BIP112,
|
||||
+OP_CHECKSEQUENCEVERIFY+].
|
||||
|
||||
@ -947,7 +946,7 @@ of interaction across inputs that occurs with +OP_CLTV+ doesn't affect +OP_CSV+.
|
||||
====
|
||||
|
||||
Relative timelocks with +OP_CSV+ are especially useful when several
|
||||
(chained) transactions are created and signed, but not propagated--that
|
||||
(chained) transactions are created and signed but not propagated--that
|
||||
is, they're kept off the blockchain (_offchain_). A child transaction cannot be used until the
|
||||
parent transaction has been propagated, mined, and aged by the time
|
||||
specified in the relative timelock. One application of this use case is shown in <<state_channels>> and <<lightning_network>>.
|
||||
@ -962,7 +961,7 @@ One of((("scripts", "flow control", id="script-flow")))((("flow control in scrip
|
||||
powerful features of Bitcoin Script is flow control, also known as
|
||||
conditional clauses. You are probably familiar with flow control in
|
||||
various programming languages that use the construct +IF...THEN...ELSE+.
|
||||
Bitcoin conditional clauses look a bit different, but are essentially
|
||||
Bitcoin conditional clauses look a bit different but are essentially
|
||||
the same construct.
|
||||
|
||||
At a basic level, Bitcoin conditional opcodes allow us to construct a
|
||||
@ -1082,7 +1081,7 @@ A very common use for flow control in Bitcoin Script is to construct a
|
||||
script that offers multiple execution paths, each a different way
|
||||
of redeeming the UTXO.
|
||||
|
||||
Let's look at a simple example, where
|
||||
Let's look at a simple example where
|
||||
we have two signers, Alice and Bob, and either one is able to redeem.
|
||||
With multisig, this would be expressed as a 1-of-2 multisig script. For
|
||||
the sake of demonstration, we will do the same thing with an +OP_IF+
|
||||
@ -1146,7 +1145,7 @@ In this scenario, there are three execution paths (+subscript A+, +subscript
|
||||
B+, and +subscript C+). The input script provides a path in the form of
|
||||
a sequence of +TRUE+ or +FALSE+ values. To select path +subscript B+, for
|
||||
example, the input script must end in +OP_1 OP_0+ (+TRUE+, +FALSE+). These
|
||||
values will be pushed onto the stack, so that the second value (+FALSE+)
|
||||
values will be pushed onto the stack so that the second value (+FALSE+)
|
||||
ends up at the top of the stack. The outer +OP_IF+ clause pops the +FALSE+
|
||||
value and executes the first +OP_ELSE+ clause. Then the +TRUE+ value moves
|
||||
to the top of the stack and is evaluated by the inner (nested) +OP_IF+,
|
||||
@ -1163,7 +1162,7 @@ at each flow control((("scripts", "flow control", startref="script-flow")))((("f
|
||||
In this((("scripts", "examples of", id="script-example-complex"))) section we combine many of
|
||||
the concepts from this chapter into a single example.
|
||||
|
||||
Mohammed is company owner in Dubai who is operating an import/export
|
||||
Mohammed, a company owner in Dubai, operates an import/export
|
||||
business; he
|
||||
wishes to construct a company capital account with flexible rules. The
|
||||
scheme he creates requires different levels of authorization depending
|
||||
@ -1239,7 +1238,7 @@ OP_0 <Saeed's Sig> <Lawer's Sig> OP_FALSE OP_TRUE
|
||||
[TIP]
|
||||
====
|
||||
Why +OP_FALSE OP_TRUE+? Isn't that backward? +FALSE+ is pushed onto the
|
||||
stack and +TRUE+ is pushed on top of it.
|
||||
stack, and +TRUE+ is pushed on top of it.
|
||||
+TRUE+ is therefore popped _first_ by the first +OP_IF+ opcode.
|
||||
====
|
||||
|
||||
@ -1480,14 +1479,14 @@ Alice and Bob can use legacy non-segwit outputs. But Bob would
|
||||
likely want to use segwit to reduce transaction fees, taking advantage
|
||||
of the reduced cost of witness structure.
|
||||
|
||||
In this case Bob's wallet can construct a P2SH address that contains a
|
||||
In this case, Bob's wallet can construct a P2SH address that contains a
|
||||
segwit script inside it. Alice's wallet can make payments to it without
|
||||
any knowledge of segwit.
|
||||
Bob's wallet can then spend this payment with a segwit transaction,
|
||||
taking advantage of segwit and reducing transaction fees.
|
||||
|
||||
Both forms of witness scripts, P2WPKH and P2WSH, can be embedded in a
|
||||
P2SH address. The first is noted as nested P2WPKH and the second is noted
|
||||
P2SH address. The first is noted as nested P2WPKH, and the second is noted
|
||||
as nested P2WSH.
|
||||
|
||||
===== Nested pay to witness public key hash
|
||||
@ -1632,7 +1631,7 @@ image::images/mbc3_0705.png["A MAST with three sub-scripts"]
|
||||
We can now create a compact membership proof that proves a particular
|
||||
authorization condition is a member of the merkle tree without
|
||||
disclosing any details about the other members of the merkle tree. See
|
||||
<<diagram_mast2>>, and note that the nodes with diagonal corners can be
|
||||
<<diagram_mast2>>, and note that the shaded nodes can be
|
||||
computed from other data provided by the user, so they don't need to be
|
||||
specified at spend time.
|
||||
|
||||
@ -1641,7 +1640,7 @@ specified at spend time.
|
||||
image::images/mbc3_0706.png["A MAST membership proof for one of the sub-scripts"]
|
||||
|
||||
The hash digests used to create the commitments are each 32 bytes, so
|
||||
proving a spend of <<diagram_mast2>> is authorized (using a merkle tree and the
|
||||
proving that a spend of <<diagram_mast2>> is authorized (using a merkle tree and the
|
||||
particular conditions) and authenticated (using signatures) uses 383
|
||||
bytes. By comparison, the same spend without a merkle tree (i.e., providing all possible authorization conditions) uses 412 bytes.
|
||||
|
||||
@ -1692,7 +1691,7 @@ discovered, which we'll see in <<taproot>>.
|
||||
.MAST Versus MAST
|
||||
****
|
||||
The earliest((("abstract syntax trees (AST)")))((("AST (abstract syntax trees)"))) idea for what we now know as _MAST_ in Bitcoin was
|
||||
_merklized abstract syntax trees_. In an absract syntax tree (AST),
|
||||
_merklized abstract syntax trees_. In an abstract syntax tree (AST),
|
||||
every condition in a script creates a new branch, as show in <<ast>>.
|
||||
|
||||
[[ast]]
|
||||
@ -1701,12 +1700,12 @@ image::images/mbc3_0708.png["An Abstract Syntax Tree (AST) for a script"]
|
||||
|
||||
ASTs are widely used by programs that parse and optimize code for other
|
||||
programs, such as compilers. A merklized AST would commit to every part
|
||||
of a program and so enable the features described in
|
||||
of a program and enable the features described in
|
||||
<<mast>>, but it would require revealing at least one 32-byte digest for
|
||||
every separate part of the program, which would not be very space
|
||||
efficient on the blockchain for most programs.
|
||||
|
||||
What most people in most cases call _MAST_ in Bitcoin today is
|
||||
What people in most cases call _MAST_ in Bitcoin today is
|
||||
_merklized alternative script trees_, a backronym coined by developer
|
||||
Anthony Towns. An alternative script tree is a set of scripts, each
|
||||
one of them complete by itself, where only one can be selected--making
|
||||
@ -1737,22 +1736,22 @@ also serve another use.
|
||||
|
||||
Let's imagine Bob wants to buy something from Alice but he also wants to
|
||||
be able prove later what he paid for in case there's any dispute. Alice
|
||||
and Bob agree on the name of the item or service being sold, e.g.,
|
||||
"Alice's podcast episode #123," and transform that description into a
|
||||
and Bob agree on the name of the item or service being sold (e.g.,
|
||||
"Alice's podcast episode #123"), and transform that description into a
|
||||
number by hashing it and interpreting the hash digest as a number. Bob
|
||||
adds that number to Alice's public key and pays it. The process is
|
||||
called _key tweaking_ and the number is known as a _tweak_.
|
||||
called _key tweaking_, and the number is known as a _tweak_.
|
||||
|
||||
Alice can spend the funds by tweaking her private key using the same
|
||||
number (tweak).
|
||||
|
||||
Later, Bob can prove to anyone what he paid Alice by revealing her
|
||||
underlying key and the description they used. Anyone can verify that
|
||||
the public key which was paid equals the underlying key plus the
|
||||
the public key, which was paid, equals the underlying key plus the
|
||||
hash commitment to the description. If Alice admits that key is hers,
|
||||
then she received the payment. If Alice spent the funds, this further
|
||||
proves she knew the description at the time she signed the spending
|
||||
transaction, since she could only create a valid signature for the
|
||||
transaction since she could only create a valid signature for the
|
||||
tweaked public key if she knew the tweak (the description).
|
||||
|
||||
If neither Alice nor Bob decided to publicly reveal the description they
|
||||
@ -1808,7 +1807,7 @@ using a single key and signature. The story is the same for privacy:
|
||||
because each new key or signature adds data to a transaction, scripted
|
||||
multisignatures disclose data about how many keys and signatures are
|
||||
being used--which may make it easy to figure out which transactions were
|
||||
created by which group of participants. But, because every scriptless
|
||||
created by which group of participants. However, because every scriptless
|
||||
multisignatures looks like every other scriptless
|
||||
multisignature and every single-signature, no privacy-reducing data is
|
||||
leaked.
|
||||
|
||||
@ -92,7 +92,7 @@ signature on this transaction."
|
||||
|
||||
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
|
||||
64 bytes.
|
||||
@ -621,9 +620,9 @@ simple multisignature protocol:
|
||||
|
||||
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
|
||||
published.
|
||||
|
||||
@ -594,10 +594,10 @@ Fees = Sum(Inputs) – Sum(Outputs)
|
||||
----
|
||||
|
||||
This is a somewhat confusing element of transactions and an important
|
||||
point to understand, because if you are constructing your own
|
||||
transactions you must ensure you do not inadvertently include a very
|
||||
point to understand because if you are constructing your own
|
||||
transactions, you must ensure you do not inadvertently include a very
|
||||
large fee by underspending the inputs. That means that you must account
|
||||
for all inputs, if necessary by creating change, or you will end up
|
||||
for all inputs, if necessary, by creating change, or you will end up
|
||||
giving the miners a very big tip!
|
||||
|
||||
For example, if you spend a 20-bitcoin UTXO to make a 1-bitcoin
|
||||
@ -619,7 +619,7 @@ you intended.
|
||||
=== Timelock Defense Against Fee Sniping
|
||||
|
||||
Fee sniping ((("transaction fees", "fee sniping", id="transaction-fee-sniping")))((("fee sniping", id="fee-snipe")))((("timelocks", "fee sniping and", id="timelock-fee-snipe")))((("lock time", "fee sniping and", id="lock-time-fee-snipe")))is a theoretical
|
||||
attack scenario, where miners attempting to rewrite past blocks "snipe"
|
||||
attack scenario where miners attempting to rewrite past blocks "snipe"
|
||||
higher-fee transactions from future blocks to maximize their
|
||||
profitability.
|
||||
|
||||
@ -635,7 +635,7 @@ They can include any transactions that were in the "old" block
|
||||
Essentially they have the option to pull transactions from the "present"
|
||||
into the rewritten "past" when they re-create block #100,000.
|
||||
|
||||
Today, this attack is not very lucrative, because the block subsidy is much
|
||||
Today, this attack is not very lucrative because the block subsidy is much
|
||||
higher than total fees per block. But at some point in the future,
|
||||
transaction fees will be the majority of the reward (or even the
|
||||
entirety of the reward). At that time, this scenario becomes inevitable.
|
||||
@ -649,15 +649,15 @@ no effect—the transactions could only be included in block
|
||||
#100,001 anyway; it's the next block.
|
||||
|
||||
But under a reorganization attack, the miners would not be able to pull
|
||||
high-fee transactions from the mempool, because all those transactions
|
||||
high-fee transactions from the mempool because all those transactions
|
||||
would be timelocked to block #100,001. They can only remine #100,000
|
||||
with whatever transactions were valid at that time, essentially gaining
|
||||
no new fees.
|
||||
|
||||
This does not entirely prevent fee sniping, but it does make it less
|
||||
profitable in some cases and so can help preserve the stability of the
|
||||
profitable in some cases and can help preserve the stability of the
|
||||
Bitcoin network as the block subsidy declines. We recommend all wallets
|
||||
implement anti fee sniping when it doesn't interfere with the wallet's
|
||||
implement anti-fee sniping when it doesn't interfere with the wallet's
|
||||
other uses of the lock time field.
|
||||
|
||||
As Bitcoin continues to mature, and as the subsidy continues to decline,
|
||||
|
||||
@ -222,7 +222,7 @@ receive it. For example:
|
||||
A third technique is to assume all nodes receiving the data have
|
||||
almost all of the same transactions in their mempool, so they can all
|
||||
accept the same compact block. That not only saves us time computing
|
||||
a compact block at each hop, but it means that all each hop can simply
|
||||
a compact block at each hop, but it means that each hop can simply
|
||||
relay the FEC packets to the next hop even before validating them.
|
||||
|
||||
The trade-off for each of the preceding methods is that they work well with
|
||||
@ -238,7 +238,7 @@ The original
|
||||
https://oreil.ly/30ZKi[Bitcoin Relay Network] was((("Bitcoin Relay Network"))) created by
|
||||
developer Matt Corallo in 2015 to enable fast synchronization of
|
||||
blocks between miners with very low latency. The network consisted of
|
||||
several Virtual Private Servers (VPSes) hosted on
|
||||
several virtual private servers (VPSes) hosted on
|
||||
infrastructure around the world and served to connect the majority of
|
||||
miners and mining pools.
|
||||
|
||||
@ -268,7 +268,7 @@ information, including:
|
||||
+Version+:: The Bitcoin P2P protocol version the client "speaks" (e.g., 70002)
|
||||
+nLocalServices+:: A list of local services supported by the node
|
||||
+nTime+:: The current time
|
||||
+addrYou+:: The IP address of the remote node as seen from this node
|
||||
+addrYou+:: The IP address of the remote node, as seen from this node
|
||||
+addrMe+:: The IP address of the local node, as discovered by the local node
|
||||
+subver+:: A subversion showing the type of software running on this node (e.g., [.keep-together]#+/Satoshi:0.9.2.1/+#)
|
||||
+BestHeight+:: The block height of this node's blockchain
|
||||
@ -326,12 +326,12 @@ A node must connect to a few different peers in order to establish
|
||||
diverse paths into the Bitcoin network. Paths are not reliable—nodes
|
||||
come and go—and so the node must continue to discover new nodes as it
|
||||
loses old connections as well as assist other nodes when they bootstrap.
|
||||
Only one connection is needed to bootstrap, because the first node can
|
||||
Only one connection is needed to bootstrap because the first node can
|
||||
offer introductions to its peer nodes and those peers can offer further
|
||||
introductions. It's also unnecessary and wasteful of network resources
|
||||
to connect to more than a handful of nodes. After bootstrapping, a node
|
||||
will remember its most recent successful peer connections, so that if it
|
||||
is rebooted it can quickly reestablish connections with its former peer
|
||||
will remember its most recent successful peer connections so if it
|
||||
is rebooted, it can quickly reestablish connections with its former peer
|
||||
network. If none of the former peers respond to its connection request,
|
||||
the node can use the seed nodes to bootstrap again.
|
||||
|
||||
@ -399,14 +399,14 @@ $ bitcoin-cli getpeerinfo
|
||||
To override the automatic management of peers and to specify a list of
|
||||
IP addresses, users can provide the option +-connect=<IPAddress>+ and
|
||||
specify one or more IP addresses. If this option is used, the node will
|
||||
only connect to the selected IP addresses, instead of discovering and
|
||||
only connect to the selected IP addresses instead of discovering and
|
||||
maintaining the peer connections automatically.
|
||||
|
||||
If there is no traffic on a connection, nodes will periodically send a
|
||||
message to maintain the connection. If a node has not communicated on a
|
||||
connection for too long, it is assumed to be disconnected
|
||||
and a new peer will be sought. Thus, the network dynamically adjusts to
|
||||
transient nodes and network problems, and can organically grow and
|
||||
transient nodes and network problems and can organically grow and
|
||||
shrink as needed without any ((("Bitcoin network", "nodes", "network discovery", startref="bitcoin-network-node-discovery")))((("nodes", "network discovery", startref="node-discovery")))((("network discovery", startref="network-discovery")))central control.
|
||||
|
||||
=== Full Nodes
|
||||
@ -449,7 +449,7 @@ node will have to download hundreds of thousands of blocks to
|
||||
synchronize with the network and reestablish the full blockchain.
|
||||
|
||||
The
|
||||
process of syncing the blockchain starts with the +version+ message,
|
||||
process of syncing the blockchain starts with the +version+ message
|
||||
because that contains +BestHeight+, a node's current blockchain height
|
||||
(number of blocks). A node will see the +version+ messages from its
|
||||
peers, know how many blocks they each have, and be able to compare to
|
||||
@ -549,7 +549,7 @@ verify that a transaction, such as a double-spend of the same UTXO,
|
||||
doesn't exist because it doesn't have a record of all transactions. This
|
||||
vulnerability can be used in a denial-of-service attack or for a
|
||||
double-spending attack against lightweight clients. To defend against this, a lightweight
|
||||
client needs to connect randomly to several clients, to increase the
|
||||
client needs to connect randomly to several clients to increase the
|
||||
probability that it is in contact with at least one honest node. This
|
||||
need to randomly connect means that lightweight clients also are vulnerable to
|
||||
network partitioning attacks or Sybil attacks, where they are connected
|
||||
@ -603,7 +603,7 @@ A bloom filter((("Bitcoin network", "bloom filters", "operational overview", id=
|
||||
to describe a desired pattern without specifying it exactly. Bloom
|
||||
filters offer an efficient way to express a search pattern while
|
||||
protecting privacy. They are used by lightweight clients to ask their peers for
|
||||
transactions matching a specific pattern, without revealing exactly
|
||||
transactions matching a specific pattern without revealing exactly
|
||||
which addresses, keys, or transactions they are searching for.
|
||||
|
||||
In our previous analogy, a tourist without a map is asking for
|
||||
@ -615,7 +615,7 @@ reveals slightly less about the desired destination than asking for "23
|
||||
Church St." Using this technique, a tourist could specify the desired
|
||||
address in more detail such as "ending in U-R-C-H" or less detail such as
|
||||
"ending in H." By varying the precision of the search, the tourist
|
||||
reveals more or less information, at the expense of getting more or less
|
||||
reveals more or less information at the expense of getting more or less
|
||||
specific results. If they ask for a less specific pattern, they get a lot
|
||||
more possible addresses and better privacy, but many of the results are
|
||||
irrelevant. If they ask for a very specific pattern, they get fewer
|
||||
@ -662,7 +662,7 @@ changed from +0+ to +1+.
|
||||
<<bloom2>> is an example of adding a pattern "A" to the simple bloom filter shown in <<bloom1>>.
|
||||
|
||||
Adding a second pattern is as simple as repeating this process. The
|
||||
pattern is hashed by each hash function in turn and the result is
|
||||
pattern is hashed by each hash function in turn, and the result is
|
||||
recorded by setting the bits to +1+. Note that as a bloom filter is
|
||||
filled with more patterns, a hash function result might coincide with a
|
||||
bit that is already set to +1+, in which case the bit is not changed. In
|
||||
@ -726,16 +726,16 @@ transactions of interest to the lightweight client without revealing exactly whi
|
||||
addresses or keys it is interested in.
|
||||
|
||||
A lightweight client will initialize a bloom filter
|
||||
as "empty"; in that state the bloom filter will not match any patterns.
|
||||
as "empty"; in that state, the bloom filter will not match any patterns.
|
||||
The lightweight client will then make a list of all the addresses, keys, and
|
||||
hashes that it is interested in. It will do this by extracting the
|
||||
public key hash and script hash and transaction IDs from any UTXO
|
||||
public key hash, script hash, and transaction IDs from any UTXO
|
||||
controlled by its wallet. The lightweight client then adds each of these to the
|
||||
bloom filter, so that the bloom filter will "match" if these patterns
|
||||
bloom filter so that the bloom filter will "match" if these patterns
|
||||
are present in a transaction, without revealing the patterns themselves.
|
||||
|
||||
The lightweight client will then send a
|
||||
+filterload+ message to the peer, containing the bloom filter to use on
|
||||
+filterload+ message to the peer containing the bloom filter to use on
|
||||
the connection. On the peer, bloom filters are checked against each
|
||||
incoming transaction. The full node checks several parts of the
|
||||
transaction against the bloom filter, looking for a match including:
|
||||
@ -826,11 +826,11 @@ weren't created by the client. They can even download each matching
|
||||
block from a different peer, making it harder for full nodes to connect
|
||||
transactions belonging to a single client across multiple blocks.
|
||||
|
||||
This idea for server-generated filters doesn't offer perfect privacy,
|
||||
This idea for server-generated filters doesn't offer perfect privacy;
|
||||
it still places some costs on full nodes (and it does require lightweight
|
||||
clients use more bandwidth for the block download), and the filters can
|
||||
only be used for confirmed transactions (not unconfirmed transactions),
|
||||
but it is much more private and reliable than BIP37 client-requested
|
||||
clients to use more bandwidth for the block download), and the filters can
|
||||
only be used for confirmed transactions (not unconfirmed transactions). However,
|
||||
it is much more private and reliable than BIP37 client-requested
|
||||
bloom filters.
|
||||
|
||||
After the description of the original idea based on bloom filters,
|
||||
@ -930,7 +930,7 @@ differences:
|
||||
|===
|
||||
|
||||
If we know that we might need to store large numbers (because large
|
||||
differences can happen, even if they are rare) but we'll most often need
|
||||
differences can happen, even if they are rare), but we'll most often need
|
||||
to store small numbers, we can encode each number using a system that
|
||||
uses less space for small numbers and extra space for large numbers.
|
||||
On average, that system will perform better than using the same amount
|
||||
@ -968,14 +968,14 @@ accurate filter.
|
||||
For both the primary and secondary goals to be met, a filter would need
|
||||
to reference two types of information:
|
||||
|
||||
* The script for every output in every transaction in a block.
|
||||
* The script for every output in every transaction in a block
|
||||
|
||||
* The outpoint for every input in every transaction in a block.
|
||||
* The outpoint for every input in every transaction in a block
|
||||
|
||||
An early design for compact block filters included both of those pieces
|
||||
of information, but it was realized that there was a more efficient way
|
||||
of information, but it was realized there was a more efficient way
|
||||
to accomplish the primary goal if we sacrificed the secondary goal. In
|
||||
the new design, a block filter would still references two types of
|
||||
the new design, a block filter would still reference two types of
|
||||
information, but they'd be more closely related:
|
||||
|
||||
* As before, the script for every output in every transaction in a
|
||||
@ -1072,7 +1072,7 @@ finding the differences (deltas) between each entry. That compact block
|
||||
filter is then distributed by peers to their clients (such as wallets).
|
||||
|
||||
A client uses the deltas to reconstruct the original commitments. The
|
||||
client such as a wallet also takes all the output scripts it is
|
||||
client, such as a wallet, also takes all the output scripts it is
|
||||
monitoring for and generates commitments in the same way as BIP158. It
|
||||
checks whether any of its generated commitments match the commitments in
|
||||
the filter.
|
||||
@ -1085,7 +1085,7 @@ compact block filter contains the number 1234. When a client sees that
|
||||
|
||||
There's a 100% guarantee that an accurate filter containing 1234 will
|
||||
allow a client to learn about a block containing 123456, called a _true
|
||||
positive_. However, there's also chance that the block might contain
|
||||
positive_. However, there's also a chance that the block might contain
|
||||
123400, 123401, or almost a hundred other entries that are not what the
|
||||
client is looking for (in this example), ((("false positives")))called a _false positive_.
|
||||
|
||||
@ -1141,7 +1141,7 @@ communications: _Tor transport_.
|
||||
Tor, which
|
||||
stands for _The Onion Routing network_, is a software project and
|
||||
network that offers encryption and encapsulation of data through
|
||||
randomized network paths that offer anonymity, untraceability and
|
||||
randomized network paths that offer anonymity, untraceability, and
|
||||
privacy.
|
||||
|
||||
Bitcoin Core ((("Bitcoin Core", "Tor transport")))offers several configuration options that allow you to run
|
||||
@ -1192,7 +1192,7 @@ children). Any matching orphans are then validated. If valid, they are
|
||||
removed from the orphan pool and added to the mempool,
|
||||
completing the chain that started with the parent transaction. In light
|
||||
of the newly added transaction, which is no longer an orphan, the
|
||||
process is repeated recursively looking for any further descendants,
|
||||
process is repeated recursively looking for any further descendants
|
||||
until no more descendants are found. Through this process, the arrival
|
||||
of a parent transaction triggers a cascade reconstruction of an entire
|
||||
chain of interdependent transactions by reuniting the orphans with
|
||||
|
||||
@ -10,7 +10,7 @@ full nodes (and sometimes light clients) to validate.
|
||||
|
||||
The blockchain data structure is
|
||||
an ordered, back-linked list of blocks of transactions. The blockchain
|
||||
can be stored as a flat file, or in a simple database.
|
||||
can be stored as a flat file or in a simple database.
|
||||
Blocks are linked "back," each referring to the previous block in the
|
||||
chain. The blockchain is often visualized
|
||||
as a vertical stack, with blocks layered on top of each other and the
|
||||
@ -32,8 +32,8 @@ Although a block has just one parent, it can have ((("child blocks")))multiple
|
||||
children. Each of the children commits to the same parent block.
|
||||
Multiple children arise during a blockchain "fork," a temporary
|
||||
situation that can occur when different blocks are discovered almost
|
||||
simultaneously by different miners (see <<forks>>). Eventually, only one
|
||||
child block becomes part of the blockchain accepted by all full nodes and the "fork" is resolved.
|
||||
simultaneously by different miners (see <<forks>>). Eventually only one
|
||||
child block becomes part of the blockchain accepted by all full nodes, and the "fork" is resolved.
|
||||
|
||||
The "previous block hash" field is inside the block header and thereby
|
||||
affects the _current_ block's hash.
|
||||
@ -396,7 +396,7 @@ H<sub>A</sub> = SHA256(SHA256(Transaction A))
|
||||
</pre>
|
||||
++++
|
||||
|
||||
Consecutive pairs of leaf nodes are then summarized in a parent node, by
|
||||
Consecutive pairs of leaf nodes are then summarized in a parent node by
|
||||
concatenating the two hashes and hashing them together. For example, to
|
||||
construct the parent node H~AB~, the two 32-byte hashes of the children
|
||||
are concatenated to create a 64-byte string. That string is then
|
||||
@ -445,12 +445,11 @@ duplicate txids, resulting in a vulnerability (CVE-2012-2459).
|
||||
|
||||
The reason is that if the number of hashes in the list at a given level
|
||||
is odd, the last one is duplicated before computing the next level (which
|
||||
is unusual in Merkle trees). This results in certain sequences of
|
||||
is unusual in merkle trees). This results in certain sequences of
|
||||
transactions leading to the same merkle root. For example, the two
|
||||
trees in <<cve_tree>>:
|
||||
|
||||
[[cve_tree]]
|
||||
[role="figuresmallerninety"]
|
||||
.Two Bitcoin-style merkle tree with the same root but a different number of leaves
|
||||
image::images/mbc3_1104.png["Two Bitcoin-style merkle trees with the same root but a different number of leaves"]
|
||||
|
||||
@ -488,7 +487,7 @@ To prove that a specific transaction is
|
||||
included in a block, a node only needs to produce approximately +log~2~(N)+ 32-byte
|
||||
hashes, constituting ((("authentication path")))((("merkle path")))an _authentication path_ or _merkle path_
|
||||
connecting the specific transaction to the root of the tree. This is
|
||||
especially important as the number of transactions increases, because
|
||||
especially important as the number of transactions increases because
|
||||
the base-2 logarithm of the number of transactions increases much more
|
||||
slowly. This allows Bitcoin nodes to efficiently produce paths of 10 or
|
||||
12 hashes (320–384 bytes), which can provide proof of a single
|
||||
@ -542,7 +541,7 @@ The lightweight client can use this merkle path to connect the transaction to th
|
||||
block header and verify that the transaction is included in the block. The lightweight
|
||||
client also uses the block header to link the block to the rest of the
|
||||
blockchain. The combination of these two links, between the transaction
|
||||
and block, and between the block and blockchain, proves that the
|
||||
and block and between the block and blockchain, proves that the
|
||||
transaction is recorded in the blockchain. All in all, the lightweight client will
|
||||
have received less than a kilobyte of data for the block header and
|
||||
merkle path, an amount of data that is more than a thousand times less
|
||||
@ -643,7 +642,7 @@ used to test segregated witness features.
|
||||
Testnet doesn't just use the same data structures as Bitcoin, it also
|
||||
uses almost exactly the same proof-of-work (PoW) security mechanism as
|
||||
Bitcoin. The notable differences for testnet are that its minimum
|
||||
difficulty is half that of Bitcoin and that it's allowed to include a
|
||||
difficulty is half that of Bitcoin and it's allowed to include a
|
||||
block at the minimum difficulty if that block's timestamp is more than
|
||||
20 minutes after the previous block.
|
||||
|
||||
@ -746,10 +745,10 @@ $ bitcoin-cli -signet getblockchaininfo
|
||||
Regtest, ((("blockchain", "test blockchains", "regtest", id="blockchain-test-regtest")))((("test blockchains", "regtest", id="test-block-regtest")))((("regtest", id="regtest")))which stands for
|
||||
"Regression Testing," is a Bitcoin Core feature that allows you to
|
||||
create a local blockchain for testing purposes. Unlike signet and testnet3, which
|
||||
are a public and shared test blockchain, the regtest blockchains are
|
||||
are public and shared test blockchains, the regtest blockchains are
|
||||
intended to be run as closed systems for local testing. You launch a
|
||||
regtest blockchain from scratch. You may
|
||||
add other nodes to the network, or run it with a single node only to
|
||||
add other nodes to the network or run it with a single node only to
|
||||
test the Bitcoin Core software.
|
||||
|
||||
To start ((("Bitcoin Core", "regtest")))Bitcoin Core in regtest mode, you use the +regtest+ flag:
|
||||
@ -807,7 +806,7 @@ $ bitcoin-cli -regtest generatetoaddress 500 \
|
||||
|
||||
It will only take a few seconds to mine all these blocks, which
|
||||
certainly makes it easy for testing. If you check your wallet balance,
|
||||
you will see that you earned 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):
|
||||
|
||||
----
|
||||
@ -820,10 +819,10 @@ $ bitcoin-cli -regtest getbalance
|
||||
Bitcoin's ((("blockchain", "test blockchains", "development usage")))((("test blockchains", "development usage")))various
|
||||
blockchains (regtest, signet, testnet3, mainnet) offer a range
|
||||
of testing environments for bitcoin development. Use the test
|
||||
blockchains whether you are developing for Bitcoin Core, or another
|
||||
full-node consensus client; an application such as a wallet, exchange,
|
||||
blockchains whether you are developing for Bitcoin Core or another
|
||||
full-node consensus client (an application such as a wallet, exchange,
|
||||
ecommerce site; or even developing novel smart contracts and complex
|
||||
scripts.
|
||||
scripts).
|
||||
|
||||
You can use the test blockchains to establish a development pipeline.
|
||||
Test your code locally on a regtest as you develop it. Once you are
|
||||
@ -837,6 +836,6 @@ into production.
|
||||
|
||||
Now that we know what data the blockchain contains and how cryptographic
|
||||
commitments securely tie the various parts together, we will look at the
|
||||
special commitment that both provides computational security and
|
||||
ensures no block can be changed without invalidating all other blocks
|
||||
special commitment that both provide computational security and
|
||||
ensure no block can be changed without invalidating all other blocks
|
||||
built on top of it: Bitcoin's mining function.
|
||||
|
||||
128
ch12_mining.adoc
128
ch12_mining.adoc
@ -74,7 +74,7 @@ will have been issued. After 2140, no new bitcoin
|
||||
will be issued.
|
||||
|
||||
Bitcoin miners ((("transaction fees")))also earn fees from transactions. Every transaction may
|
||||
include a transaction fee, in the form of a surplus of bitcoins between
|
||||
include a transaction fee in the form of a surplus of bitcoins between
|
||||
the transaction's inputs and outputs. The winning bitcoin miner gets to
|
||||
"keep the change" on the transactions included in the winning block.
|
||||
Today, the fees usually represent only a small percentage of a
|
||||
@ -168,7 +168,7 @@ fixed and diminishing monetary issuance is that the currency tends to be
|
||||
inherently _deflationary_. Deflation is the phenomenon of appreciation
|
||||
of value due to a mismatch in supply and demand that drives up the value
|
||||
(and exchange rate) of a currency. The opposite of inflation, price
|
||||
deflation means that the money has more purchasing power over time.
|
||||
deflation, means that the money has more purchasing power over time.
|
||||
|
||||
Many economists argue that a deflationary economy is a disaster that
|
||||
should be avoided at all costs. That is because in a period of rapid
|
||||
@ -213,7 +213,7 @@ providing a clearinghouse service, basically verifying and clearing all
|
||||
transactions. Bitcoin has no central authority, yet somehow every full
|
||||
node has a complete copy of a public blockchain that it can trust as the
|
||||
authoritative record. The blockchain is not created by a central
|
||||
authority, but is assembled independently by every node in the network.
|
||||
authority but is assembled independently by every node in the network.
|
||||
Somehow, every node in the network, acting on information transmitted
|
||||
across insecure network connections, can arrive at the same conclusion
|
||||
and assemble a copy of the same blockchain as everyone else. This
|
||||
@ -221,7 +221,7 @@ chapter examines the process by which the Bitcoin network achieves
|
||||
global consensus without central authority.
|
||||
|
||||
One of Satoshi Nakamoto's inventions is the decentralized
|
||||
mechanism for _emergent consensus_. Emergent, because consensus is not
|
||||
mechanism for _emergent consensus_. Emergent because consensus is not
|
||||
achieved explicitly—there is no election or fixed moment when consensus
|
||||
occurs. Instead, consensus is an emergent artifact of the asynchronous
|
||||
interaction of thousands of independent nodes, all following simple
|
||||
@ -237,15 +237,15 @@ processes that occur independently on nodes across the network:
|
||||
|
||||
- Independent aggregation of those transactions into new blocks by
|
||||
mining nodes, coupled with demonstrated computation through a
|
||||
Proof-of-Work algorithm
|
||||
proof-of-work algorithm
|
||||
|
||||
- Independent verification of the new blocks by every node and assembly
|
||||
into a chain
|
||||
|
||||
- Independent selection, by every node, of the chain with the most
|
||||
cumulative computation demonstrated through Proof-of-Work
|
||||
cumulative computation demonstrated through proof of work
|
||||
|
||||
In the next few sections we will examine these processes and how they
|
||||
In the next few sections, we will examine these processes and how they
|
||||
interact to create the emergent property of network-wide consensus that
|
||||
allows any Bitcoin node to assemble its own copy of the authoritative,
|
||||
trusted, public, global ((("bitcoins", "mining", "decentralized consensus", startref="bitcoin-mining-consensus")))((("mining", "decentralized consensus", startref="mining-consensus")))((("decentralized consensus", startref="decentral-consensus")))((("emergent consensus", startref="emergent-consensus")))blockchain.
|
||||
@ -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
|
||||
function used in Bitcoin's mining process.
|
||||
@ -762,12 +762,12 @@ f75a100821c34c84395403afd1a8135f685ca69ccf4168e61a90e50f47552f61 -
|
||||
|
||||
The phrase "Hello, World! 32" produces the following hash, which fits our criteria:
|
||||
+09cb91f8250df04a3db8bd98f47c7cecb712c99835f4123e8ea51460ccbec314+. It took 32 attempts to find it. In terms of
|
||||
probabilities, if the output of the hash function is evenly distributed
|
||||
probabilities, if the output of the hash function is evenly distributed,
|
||||
we would expect to find a result with a 0 as the hexadecimal prefix once
|
||||
every 16 hashes (one out of 16 hexadecimal digits 0 through F). In
|
||||
numerical terms, that means finding a hash value that is less than
|
||||
+0x1000000000000000000000000000000000000000000000000000000000000000+. We
|
||||
call this threshold the _target_ and the goal is to find a hash that is
|
||||
call this threshold the _target_, and the goal is to find a hash that is
|
||||
numerically less than the target. If we decrease the target, the task of
|
||||
finding a hash that is less than the target becomes more and more
|
||||
difficult.
|
||||
@ -787,10 +787,10 @@ From the perspective of an observer who knows that the target of the
|
||||
dice game is 2, if someone has succeeded in casting a winning throw it
|
||||
can be assumed that they attempted, on average, 36 throws. In other
|
||||
words, one can estimate the amount of work it takes to succeed from the
|
||||
difficulty imposed by the target. When the algorithm is a based on a
|
||||
difficulty imposed by the target. When the algorithm is based on a
|
||||
deterministic function such as SHA256, the input itself constitutes
|
||||
_proof_ that a certain amount of _work_ was done to produce a result
|
||||
below the target. Hence, _Proof-of-Work_.
|
||||
below the target. Hence, _proof of work_.
|
||||
|
||||
[TIP]
|
||||
====
|
||||
@ -799,7 +799,7 @@ any possible outcome can be calculated in advance. Therefore, an outcome
|
||||
of specified difficulty constitutes proof of a specific amount of work.
|
||||
====
|
||||
|
||||
In <<sha256_example_generator_output2>>, the winning "nonce" is 32 and
|
||||
In <<sha256_example_generator_output2>>, the winning "nonce" is 32, and
|
||||
this result can be confirmed by anyone independently. Anyone can add the
|
||||
number 32 as a suffix to the phrase "Hello, world!" and compute
|
||||
the hash, verifying that it is less than the target:
|
||||
@ -811,7 +811,7 @@ $ echo "Hello, world! 32" | sha256sum
|
||||
|
||||
Although it only takes one hash computation to verify, it took
|
||||
us 32 hash computations to find a nonce that worked. If we had a lower
|
||||
target (higher difficulty) it would take many more hash computations to
|
||||
target (higher difficulty), it would take many more hash computations to
|
||||
find a suitable nonce, but only one hash computation for anyone to
|
||||
verify. Furthermore, by knowing the target, anyone can estimate the
|
||||
difficulty using statistics and therefore know roughly how much work was needed
|
||||
@ -819,13 +819,13 @@ to find such a nonce.
|
||||
|
||||
[TIP]
|
||||
====
|
||||
The Proof-of-Work must produce a hash that is _less than_ the target. A
|
||||
The PoW must produce a hash that is _less than_ the target. A
|
||||
higher target means it is less difficult to find a hash that is below
|
||||
the target. A lower target means it is more difficult to find a hash
|
||||
below the target. The target and difficulty are inversely related.
|
||||
====
|
||||
|
||||
Bitcoin's Proof-of-Work is very similar to the challenge
|
||||
Bitcoin's PoW is very similar to the challenge
|
||||
shown in <<sha256_example_generator_output2>>. The miner constructs a
|
||||
candidate block filled with transactions. Next, the miner calculates the
|
||||
hash of this block's header and sees if it is smaller than the current
|
||||
@ -843,7 +843,7 @@ enough block((("bitcoins", "mining", "Proof-of-Work algorithm", startref="bitcoi
|
||||
|
||||
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"
|
||||
|
||||
@ -36,7 +36,7 @@ payment is open-ended because it contains the user's private identifier
|
||||
to the identifier can "pull" funds and charge the owner again and again.
|
||||
Thus, the payment network has to be secured end-to-end with encryption
|
||||
and must ensure that no eavesdroppers or intermediaries can compromise
|
||||
the payment traffic, in transit or when it is stored (at rest). If a bad
|
||||
the payment traffic in transit or when it is stored (at rest). If a bad
|
||||
actor gains access to the system, he can compromise current transactions
|
||||
_and_ payment tokens that can be used to create new transactions. Worse,
|
||||
when customer data is compromised, the customers are exposed to identity
|
||||
@ -81,7 +81,7 @@ for their customers.
|
||||
|
||||
Unless you are prepared to invest heavily in operational security,
|
||||
multiple layers of access control, and audits (as the traditional banks
|
||||
do) you should think very carefully before taking funds outside of
|
||||
do), you should think very carefully before taking funds outside of
|
||||
Bitcoin's decentralized security context. Even if you have the funds and
|
||||
discipline to implement a robust security model, such a design merely
|
||||
replicates the fragile model of traditional financial networks, plagued
|
||||
@ -262,7 +262,7 @@ Multisignature addresses secure funds by requiring more than one
|
||||
signature to make a payment. The signing keys should be stored in a
|
||||
number of different locations and under the control of different people.
|
||||
In a corporate environment, for example, the keys should be generated
|
||||
independently and held by several company executives, to ensure no
|
||||
independently and held by several company executives to ensure no
|
||||
single person can compromise the funds. Multisignature addresses can
|
||||
also offer redundancy, where a single person holds several keys that are
|
||||
stored in different locations.
|
||||
|
||||
@ -25,7 +25,7 @@ Immutability:: Once a transaction is recorded in the blockchain and
|
||||
sufficient work has been added with subsequent blocks, the transaction's
|
||||
data becomes practically immutable. Immutability is underwritten by energy, as
|
||||
rewriting the blockchain requires the expenditure of energy to produce
|
||||
Proof-of-Work. The energy required and therefore the degree of
|
||||
PoW. The energy required and therefore the degree of
|
||||
immutability increases with the amount of work committed on top of the
|
||||
block containing a transaction.
|
||||
|
||||
@ -65,9 +65,9 @@ without invalidating the signature, thus invalidating the transaction
|
||||
itself.
|
||||
|
||||
Transaction Atomicity:: Bitcoin transactions are atomic. They are either
|
||||
valid and confirmed (mined) or not. Partial transactions cannot be mined
|
||||
valid and confirmed (mined) or not. Partial transactions cannot be mined,
|
||||
and there is no interim state for a transaction. At any point in time a
|
||||
transaction is either mined, or not.
|
||||
transaction is either mined or not.
|
||||
|
||||
Discrete (Indivisible) Units of Value:: Transaction outputs are discrete
|
||||
and indivisible units of value. They can either be spent or unspent, in
|
||||
@ -98,10 +98,10 @@ Recording External State:: A transaction can commit to a data value, via
|
||||
+OP_RETURN+ or pay to contract, representing a state transition in an external state
|
||||
machine.
|
||||
|
||||
Predictable Issuance:: Less than 21 million bitcoin will be issued, at a
|
||||
Predictable Issuance:: Less than 21 million bitcoin will be issued at a
|
||||
predictable rate.
|
||||
|
||||
The list of building blocks is not complete and more are added with each
|
||||
The list of building blocks is not complete, and more are added with each
|
||||
new feature introduced ((("Bitcoin", "as application platform", "primitives, list of", secondary-sortas="application platform", startref="bitcoin-app-platform-primitive")))((("application platform, Bitcoin as", "primitives, list of", startref="app-platform-primitive")))((("primitives", startref="primitive-list")))((("building blocks", startref="build-block")))into Bitcoin.
|
||||
|
||||
=== Applications from Building Blocks
|
||||
@ -115,7 +115,7 @@ Proof-of-Existence (Digital Notary):: Immutability + Timestamp + Durability.
|
||||
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
|
||||
=== Payment Channels and State Channels
|
||||
|
||||
_Payment channels_ are ((("Bitcoin", "as application platform", "payment channels", secondary-sortas="application platform", id="bitcoin-app-platform-payment")))((("application platform, Bitcoin as", "payment channels", id="app-platform-payment")))((("payment channels", id="payment-channel")))a trustless mechanism for exchanging Bitcoin
|
||||
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
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
|
||||
<p class="author">by <span class="firstname">Andreas </span> <span class="othername mi">M. </span> <span class="surname">Antonopoulos</span> and <span class="firstname">David </span> <span class="othername mi">A. </span> <span class="surname">Harding</span></p>
|
||||
|
||||
<p class="copyright">Copyright © 2023 David Harding. All rights reserved.</p>
|
||||
<p class="copyright">Copyright © 2024 David Harding. All rights reserved.</p>
|
||||
|
||||
<p class="printlocation">Printed in the United States of America.</p>
|
||||
|
||||
@ -16,8 +16,8 @@
|
||||
<li><span class="staffrole">Development Editor: </span>Angela Rufino</li>
|
||||
<li><span class="staffrole">Production Editor:</span> Clare Laylock</li>
|
||||
<li><span class="staffrole">Copyeditor:</span> Kim Cofer</li>
|
||||
<li><span class="staffrole">Proofreader:</span></li>
|
||||
<li><span class="staffrole">Indexer:</span></li>
|
||||
<li><span class="staffrole">Proofreader:</span> Heather Walley</li>
|
||||
<li><span class="staffrole">Indexer:</span> nSight, Inc.</li>
|
||||
<li><span class="staffrole">Interior Designer:</span> David Futato</li>
|
||||
<li><span class="staffrole">Cover Designer:</span> Randy Comer</li>
|
||||
<li><span class="staffrole">Illustrator:</span> Kate Dullea</li>
|
||||
|
||||
@ -142,7 +142,7 @@
|
||||
<li>ratijas</li>
|
||||
<li>rating89us</li>
|
||||
<li>Raul Siles (raulsiles)</li>
|
||||
<li>Reproducibility Matters (TheCharlatan)</li>
|
||||
<li><p class="left-align">Reproducibility Matters <span class="keep-together">(TheCharlatan)</span></p></li>
|
||||
<li>Reuben Thomas (rrthomas)</li>
|
||||
<li>Robert Furse (Rfurse)</li>
|
||||
<li>Roberto Mannai (robermann)</li>
|
||||
|
||||
@ -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
|
||||
pass:[<a data-type="xref" data-xrefstyle="chap-num-title" href="#tx_fees">#tx_fees</a>].
|
||||
|
||||
<<c_transactions>>::
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -75,11 +75,11 @@ include::meta/third_edition_changes.asciidoc[]
|
||||
|
||||
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:
|
||||
link:$$https://antonopoulos.com/$$[]
|
||||
[.keep-together]#link:$$https://antonopoulos.com$$[].#
|
||||
|
||||
Follow Andreas on Facebook:
|
||||
link:$$https://facebook.com/AndreasMAntonopoulos$$[]
|
||||
link:$$https://facebook.com/AndreasMAntonopoulos$$[].
|
||||
|
||||
Follow Andreas on Twitter:
|
||||
link:$$https://twitter.com/aantonop$$[]
|
||||
link:$$https://twitter.com/aantonop$$[].
|
||||
|
||||
Follow Andreas on LinkedIn:
|
||||
link:$$https://linkedin.com/company/aantonop$$[]
|
||||
link:$$https://linkedin.com/company/aantonop$$[].
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user