arno/bitcoinbook
1
0
Fork 0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2024-11-25 01:18:18 +00:00
Code Issues Releases Wiki Activity

All: harding edits for complete readthrough

Browse Source
This commit is contained in:
David A. Harding 2023-08-24 10:47:54 +02:00
parent 7da725a096
commit ab1803246f
21 changed files with 487 additions and 648 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
applications.adoc
View File

@ -1,14 +1,11 @@
[[ch12]]
== Blockchain Applications
== Second-Layer Applications
Let's now build on our understanding of Bitcoin by looking at it as an
_application platform_. Nowadays, many people use the term "blockchain"
to refer to any application platform that shares the design principles
of Bitcoin. The term is often misused and applied to many things that
fail to deliver the primary features that Bitcoin's blockchain delivers.
In this chapter we will look at the features offered by the Bitcoin
blockchain as an application platform. We will consider the application
Let's now build on our understanding of the primary Bitcoin system (the
_first layer_) by looking at it as an
platform for other applications, or _second layers_.
In this chapter we will look at the features offered by Bitcoin
as an application platform. We will consider the application
building _primitives_, which form the building blocks of any blockchain
application. We will look at several important applications that use
these primitives, such as client-side validation, payment channels, and
@ -43,7 +40,7 @@ Secure Timestamping:: The consensus rules reject any block whose
timestamp is too far in the future and attempt to prevent blocks with
timestamps too far in the past. This ensures that timestamps
on blocks can be trusted to a certain degree. The timestamp on a block implies an
unspent-before guarantee for the inputs of all included transactions.
unspent-before reference for the inputs of all included transactions.
Authorization:: Digital signatures, validated in a decentralized
network, offer authorization guarantees. Scripts that contain a
@ -218,7 +215,7 @@ to reveal the contract used to tweak the keys. Nothing is publicly
revealed about the contract--not even that a contract between them
exists.
A P2C contract can arbitrary long and detailed, the terms can be written
A P2C contract can be arbitrarily long and detailed, the terms can be written
in any language, and it can reference anything the participants want
because the contract is not validated by full nodes and only the public
key with the commitment is published to the blockchain.
@ -369,7 +366,7 @@ channels", id="BCApayment12")))((("payment (state) channels",
"defined")))are a trustless mechanism for exchanging Bitcoin
transactions between two parties, outside of the Bitcoin blockchain.
These transactions, which would be valid if settled on the Bitcoin
blockchain, are held off-chain instead, waiting for
blockchain, are held offchain instead, waiting for
eventual batch settlement. Because the transactions are not settled,
they can be exchanged without the usual settlement latency, allowing
extremely high transaction throughput, low latency, and
@ -403,7 +400,7 @@ channels in a routed network, first proposed under the name _Lightning
Network_.
Payment channels are part of the broader concept of a _state channel_,
which represents an off-chain alteration of state, secured by eventual
which represents an offchain alteration of state, secured by eventual
settlement in a blockchain. A payment channel is a state channel where
the state being altered is the balance of a virtual currency.
@ -420,7 +417,7 @@ of the channel.
The two parties then exchange signed transactions, called _commitment
transactions_, that alter the initial state. These transactions are
valid transactions in that they _could_ be submitted for settlement by
either party, but instead are held off-chain by each party pending the
either party, but instead are held offchain by each party pending the
channel closure. State updates can be created as fast as each party can
create, sign, and transmit a transaction to the other party. In practice
this means that dozens of transactions per second can be exchanged.
@ -508,7 +505,7 @@ paid to the multisignature 2-of-2 address controlled jointly between
Emma and Fabian. It may have additional outputs for change back to
Emma's wallet.
Once the funding transaction is confirmed, Emma can start streaming
After the funding transaction is confirmed to a sufficent depth, Emma can start streaming
video. Emma's software creates and signs a commitment transaction that
changes the channel balance to credit 0.01 millibit to Fabian's address
and refund 35.99 millibits back to Emma. The transaction signed by Emma
@ -743,10 +740,10 @@ funding transaction locks the channel state in a 2-of-2 multisig, just
like in the example of a simple channel.
The funding transaction may have one or more inputs from Hitesh (adding
up to 5 bitcoin or more), and one or more inputs from Irene (adding up
to 5 bitcoin or more). The inputs have to slightly exceed the channel
up to 5 bitcoins or more), and one or more inputs from Irene (adding up
to 5 bitcoins or more). The inputs have to slightly exceed the channel
capacity in order to cover the transaction fees. The transaction has one
output that locks the 10 total bitcoin to a 2-of-2 multisig address
output that locks the 10 total bitcoins to a 2-of-2 multisig address
controlled by both Hitesh and Irene. The funding transaction may also
have one or more outputs returning change to Hitesh and Irene if their
inputs exceeded their intended channel contribution. This is a single
@ -759,17 +756,17 @@ parties sign, Hitesh and Irene create two different commitment
transactions that are _asymmetric_.
Hitesh has a commitment transaction with two outputs. The first output
pays Irene the 5 bitcoin she is owed _immediately_. The second output
pays Hitesh the 5 bitcoin he is owed, but only after a timelock of 1000
pays Irene the 5 bitcoins she is owed _immediately_. The second output
pays Hitesh the 5 bitcoins he is owed, but only after a timelock of 1000
blocks. The transaction outputs look like this:
----
Input: 2-of-2 funding output, signed by Irene
Output 0 <5 bitcoin>:
Output 0 <5 bitcoins>:
<Irene's Public Key> CHECKSIG
Output 1 <5 bitcoin>:
Output 1 <5 bitcoins>:
<1000 blocks>
CHECKSEQUENCEVERIFY
DROP
@ -777,18 +774,18 @@ Output 1 <5 bitcoin>:
----
Irene has a different commitment transaction with two outputs. The first
output pays Hitesh the 5 bitcoin he is owed immediately. The second
output pays Irene the 5 bitcoin she is owed but only after a timelock of
output pays Hitesh the 5 bitcoins he is owed immediately. The second
output pays Irene the 5 bitcoins she is owed but only after a timelock of
1000 blocks. The commitment transaction Irene holds (signed by Hitesh)
looks like this:
----
Input: 2-of-2 funding output, signed by Hitesh
Output 0 <5 bitcoin>:
Output 0 <5 bitcoins>:
<Hitesh's Public Key> CHECKSIG
Output 1 <5 bitcoin>:
Output 1 <5 bitcoins>:
<1000 blocks>
CHECKSEQUENCEVERIFY
DROP
@ -843,10 +840,10 @@ state and wants to revoke this commitment.
The second output's script looks like this:
----
Output 0 <5 bitcoin>:
Output 0 <5 bitcoins>:
<Irene's Public Key> CHECKSIG
Output 1 <5 bitcoin>:
Output 1 <5 bitcoins>:
IF
# Revocation penalty output
<Revocation Public Key>
@ -880,7 +877,7 @@ Irene will be able to redeem the output and punish Hitesh before the
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. As they accept a new state, they
other's new commitment transactions. After they accept a new state, they
make the prior state impossible to use, by giving each other the
necessary revocation secrets to punish any cheating.
@ -921,7 +918,7 @@ remain open indefinitely and can have billions of intermediate
commitment transactions. In implementations of Lightning
Network, the commitment state is identified by a 48-bit index, allowing
more than 281 trillion (2.8 x 10^14^) state transitions in any single
channel!((("", startref="PSCaymetric12")))
channel.
==== Hash Time Lock Contracts (HTLC)
@ -1147,7 +1144,7 @@ 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
privacy of payments and makes it very difficult to apply surveillance,
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?
@ -1212,8 +1209,8 @@ second-layer routing technology. It can be applied to any blockchain
that supports some basic capabilities, such as multisignature
transactions, timelocks, and basic smart contracts.
If a Lightning Network is layered on top of the Bitcoin network, the
Bitcoin network can gain a significant increase in capacity, privacy,
Lightning Network is layered on top of the Bitcoin network, giving
Bitcoin a significant increase in capacity, privacy,
granularity, and speed, without sacrificing the principles of trustless
operation without intermediaries:
@ -1234,9 +1231,9 @@ Granularity:: A Lightning Network can enable payments at least as small
as the Bitcoin "dust" limit, perhaps even smaller.
Capacity:: A Lightning Network increases the capacity of the Bitcoin
system by several orders of magnitude. There is no practical upper bound
system by several orders of magnitude. The upper bound
to the number of payments per second that can be routed over a Lightning
Network, as it depends only on the capacity and speed of each node.
Network depends only on the capacity and speed of each node.
Trustless Operation:: A Lightning Network uses Bitcoin transactions
between nodes that operate as peers without trusting each other. Thus, a

2
author_bio.html
View File

@ -9,5 +9,5 @@
<p>As a bitcoin entrepreneur, Andreas has founded a number of bitcoin businesses and launched several community open source projects. He serves as an advisor to several bitcoin and cryptocurrency companies. He is a widely published author of articles and blog posts on bitcoin, a permanent host on the popular Let’s Talk Bitcoin podcast, and a frequent speaker at technology and security conferences worldwide.</p>
<p><strong>David A. Harding</strong> is a technical writer focused on creating documentation for open source software. He is the co-author of the Bitcoin Optech weekly newsletter (2018-23), 21.co Bitcoin Computer tutorials (2015-17), and Bitcoin.org developer documentation (2014-15). He is also a Brink.dev grant committee member (2022-23) and former board member (2020-22). David previously worked freelance (2007-15).</p>
<p><strong>David A. Harding</strong> is a technical writer focused on creating documentation for open source software. He is the co-author of the Bitcoin Optech weekly newsletter (2018-23), 21.co Bitcoin Computer tutorials (2015-17), and Bitcoin.org developer documentation (2014-15). He is also a Brink.dev grant committee member (2022-23) and former board member (2020-22).</p>
</section>

246
authorization-authentication.adoc
View File

@ -61,7 +61,7 @@ of conditions to be expressed.
==== Turing Incompleteness
((("Turing incompleteness")))The bitcoin transaction script language
((("Turing incompleteness")))The Bitcoin transaction script language
contains many operators, but is deliberately limited in one important
way--there are no loops or complex flow control capabilities other than
conditional flow control. This ensures that the language is not _Turing
@ -96,25 +96,25 @@ system.
Bitcoin's legacy transaction validation engine relies on two parts of scripts
to validate transactions: an output script and an input script.
An output script is a spending condition placed on an output:
it specifies the conditions that must be met to spend the output in the
An output script
specifies the conditions that must be met to spend the output in the
future, such as who is authorized to spend the output and how they will
be authenticated.
An input script is a script that satisfies the
conditions placed on an output by an output script and allows the output
conditions placed in an output script and allows the output
to be spent. Input scripts are part of every transaction input. Most
of the time in legacy transactions they contain a digital signature produced by the user's
wallet from his or her private key, but not all input scripts
must contain signatures.
Every bitcoin validating node will validate transactions by executing
Every Bitcoin validating node will validate transactions by executing
the output and input scripts. As we saw in
<<c_transactions>>, each input contains an outpoint which refers to a
previous transaction output. The input also contains an input script. The
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 in sequence. The input is
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
part of the overall validation of the transaction.
@ -140,11 +140,9 @@ image::images/mbc2_0603.png["input_and_output_scripts"]
Bitcoin's scripting language is called a stack-based language because it
uses a data structure called a _stack_. A stack is a very simple data
structure that can be visualized as a stack of cards. A stack allows two
operations: push and pop. Push adds an item on top of the stack. Pop
removes the top item from the stack. Operations on a stack can only act
on the topmost item on the stack. A stack data structure is also called
a Last-In-First-Out, or "LIFO" queue.
structure that can be visualized as a stack of cards. A stack has two
base operations: push and pop. Push adds an item on top of the stack. Pop
removes the top item from the stack.
The scripting language executes the script by processing each item from
left to right. Numbers (data constants) are pushed onto the stack.
@ -294,9 +292,7 @@ script:
<Sig> <Pubkey> OP_DUP OP_HASH160 <Hash> OP_EQUALVERIFY OP_CHECKSIG
----
When executed, this combined script will evaluate to TRUE if, and only
if, the input script matches the conditions set by the output script.
In other words, the result will be TRUE if the input script
The result will be TRUE if the input script
has a valid signature from Bob's private key that corresponds to
the public key hash set as an encumbrance.
@ -338,19 +334,6 @@ to tell "m" and "n" apart when they're spoken, so we use the alternative
t-of-k. Both phrases refer to the same type of signature scheme.
====
At this time, Bitcoin Core's transaction relay policy limits multisignature output scripts to at most 3
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
accepted by the network. Note that the limit of 3 keys applies only to
standard (also known as "bare") multisignature scripts, not to
multisignature scripts wrapped in a Pay-to-Script-Hash (P2SH) script.
P2SH multisignature scripts are limited by both policy and consensus to
15 keys, allowing for up to 15-of-15 multisignature. We will learn about
P2SH in <<p2sh>>. All other scripts are consensus limited to 20 keys
per +OP_CHECKMULTSIG+ or +OP_CHECKMULTISIGVERIFY+ opcode, although one
script may include multiple of those opcodes.
The general form of a output script setting a t-of-k multisignature
condition is:
@ -369,7 +352,7 @@ this:
----
The preceding output script can be satisfied with an input script
containing pairs of signatures and public keys:
containing signatures:
----
<Signature B> <Signature C>
@ -381,22 +364,34 @@ to the three listed public keys.
The two scripts together would form the combined validation script:
----
<Signature B> <Signature C> 2 <Public Key A> <Public Key B> <Public Key C> 3 OP_CHECKMULTISIG
<Sig B> <Sig C> 2 <Pubkey A> <Pubkey B> <Pubkey C> 3 OP_CHECKMULTISIG
----
When executed, this combined script will evaluate to TRUE if, and only
if, the input script script matches the conditions set by the output script.
In this case, the condition is whether the input script has
a valid signature from the two private keys that correspond to two of
When executed, this combined script will evaluate to TRUE if
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 3
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
accepted by the network. Note that the limit of 3 keys applies only to
standard (also known as "bare") multisignature scripts, not to
scripts wrapped in another structure like P2SH, P2WSH, or P2TR.
P2SH multisignature scripts are limited by both policy and consensus to
15 keys, allowing for up to 15-of-15 multisignature. We will learn about
P2SH in <<p2sh>>. All other scripts are consensus limited to 20 keys
per +OP_CHECKMULTSIG+ or +OP_CHECKMULTISIGVERIFY+ opcode, although one
script may include multiple of those opcodes.
[[multisig_bug]]
==== An oddity in CHECKMULTISIG execution
((("scripting", "multisignature scripts", "OP_CHECKMULTISIG
oddity")))((("OP_CHECKMULTISIG oddity workaround")))There is an oddity in
++OP_CHECKMULTISIG++'s execution that requires a slight workaround. When
+OP_CHECKMULTISIG+ executes, it should consume K+N+2 items on the stack as
+OP_CHECKMULTISIG+ executes, it should consume t+k+2 items on the stack as
parameters. However, due to the oddity, +OP_CHECKMULTISIG+ will pop an extra
value or one value more than expected.
@ -404,16 +399,16 @@ Let's look at this in greater detail using the previous validation
example:
----
<Signature B> <Signature C> 2 <Public Key A> <Public Key B> <Public Key C> 3 OP_CHECKMULTISIG
<Sig B> <Sig C> 2 <Pubkey A> <Pubkey B> <Pubkey C> 3 OP_CHECKMULTISIG
----
First, +OP_CHECKMULTISIG+ pops the top item, which is +N+ (in this example
"3"). Then it pops +N+ items, which are the public keys that can sign.
First, +OP_CHECKMULTISIG+ pops the top item, which is +k+ (in this example
"3"). Then it pops +k+ items, which are the public keys that can sign.
In this example, public keys A, B, and C. Then, it pops one item, which
is +K+, the quorum (how many signatures are needed). Here M = 2. At this
point, +OP_CHECKMULTISIG+ should pop the final +K+ items, which are the
is +t+, the quorum (how many signatures are needed). Here t = 2. At this
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 (K+1
the implementation causes +OP_CHECKMULTISIG+ to pop one more item (t+1
total) than it should. The extra item is called the _dummy stack
element_ and it is disregarded when checking the
signatures so it has no direct effect on +OP_CHECKMULTISIG+ itself.
@ -429,7 +424,7 @@ replicated forever. Therefore a script should look
like this:
----
OP_0 <Signature B> <Signature C> 2 <Public Key A> <Public Key B> <Public Key C> 3 OP_CHECKMULTISIG
OP_0 <Sign B> <Sig C> 2 <Pubkey A> <Pubkey B> <Pubkey C> 3 OP_CHECKMULTISIG
----
Thus the input script actually used in multisig is not:
@ -441,13 +436,13 @@ Thus the input script actually used in multisig is not:
but instead it is:
----
OP_0 <Signature B> <Signature C>
OP_0 <Sig B> <Sig C>
----
Some people believe this oddity was a bug in the original code for
Bitcoin, but a plausible alternative explanation exists. Verifying
t-of-k signatures can require many more than t or k signature checking
operations. Let's consider a simple example of 1-in-3, with the
operations. Let's consider a simple example of 1-in-5, with the
following combined script:
----
@ -460,7 +455,7 @@ the other keys before it is finally compared to its corresponding
performed even though there's only one signature. One way to eliminate
this redundancy would have been to provide OP_CHECKMULTISIG a map
indicating which provided signature corresponds to which public key,
allowing the OP_CHECKMULTISIG operation to only perform exactly K
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
@ -483,21 +478,20 @@ startref="Smulti07")))
((("transactions", "advanced", "Pay-to-Script-Hash")))((("scripting",
"Pay-to-Script-Hash", id="Spay07")))Pay-to-Script-Hash (P2SH) was
introduced in 2012 as a powerful new type of transaction that greatly
simplifies the use of complex transaction scripts. To explain the need
introduced in 2012 as a powerful new type of operation that greatly
simplifies the use of complex scripts. To explain the need
for P2SH, let's look at a practical example.
((("use cases", "import/export", id="mohamseven")))((("scripting",
"Pay-to-Script-Hash", "import/export example")))((("Pay-to-Script-Hash
(P2SH)", "import/export example")))
Mohammed is an electronics importer based in Dubai. Mohammed's
company uses bitcoin's multisignature feature extensively for its
company uses Bitcoin's multisignature feature extensively for its
corporate accounts. Multisignature scripts are one of the most common
uses of bitcoin's advanced scripting capabilities and are a very
powerful feature. ((("accounts receivable (AR)")))Mohammed's company
uses a multisignature script for all customer payments, known in
accounting terms as "accounts receivable," or AR. With the
multisignature scheme, any payments made by customers are locked in such
uses of Bitcoin's advanced scripting capabilities and are a very
powerful feature. Mohammed's company
uses a multisignature script for all customer payments.
Any payments made by customers are locked in such
a way that they require at least two signatures to release. Mohammed,
his three partners, and their attorney can each provide one signature.
A multisignature scheme like that offers corporate governance
@ -512,9 +506,8 @@ The resulting script is quite long and looks like this:
Although multisignature scripts are a powerful feature, they are
cumbersome to use. Given the preceding script, Mohammed would have to
communicate this script to every customer prior to payment. Each
customer would have to use special bitcoin wallet software with the
ability to create custom transaction scripts, and each customer would
have to understand how to create a transaction using custom scripts.
customer would have to use special Bitcoin wallet software with the
ability to create custom transaction scripts.
Furthermore, the resulting transaction would be about five times larger
than a simple payment transaction, because this script contains very
long public keys. The burden of that extra data would be
@ -524,7 +517,7 @@ node, until it was spent. All of these issues make using complex output scripts
difficult in practice.
P2SH was developed to resolve these practical difficulties and to make
the use of complex scripts as easy as a payment to a Bitcoin address.
the use of complex scripts as easy as a payment to a single-key Bitcoin address.
With P2SH payments, the complex script is replaced with a
commitment, the digest of a cryptographic hash. When a transaction attempting
to spend the UTXO is presented later, it must contain the script that
@ -559,7 +552,7 @@ 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 reedemScript 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 sender to the recipient (spender) of the
in fees and complexity from the spender to the receiver of the
transaction.
Let's look at Mohammed's company, the complex multisignature script, and
@ -654,15 +647,9 @@ of")))((("Pay-to-Script-Hash (P2SH)", "benefits of")))The P2SH feature
offers the following benefits compared to the direct use of complex
scripts in outputs:
- Complex scripts are replaced by shorter commitments in the
transaction output, making the transaction smaller.
- The similarity to original legacy addresses means the sender and the sender's
wallet don't need complex engineering to implement P2SH.
- P2SH shifts the burden of constructing the script to the recipient,
not the sender.
- P2SH shifts the burden in data storage for the long script from the
output (which additionally to being stored on the blockchain is in the
UTXO set) to the input (only stored on the blockchain).
@ -694,7 +681,7 @@ risk, because you can send bitcoin to a P2SH address that cannot be spent later.
====
((("warnings and cautions", "accidental bitcoin invalidation")))P2SH output scripts
contain the hash of a redeem script, which gives no clues as to
the content of the redeem script. The P2SH transaction will be
the content of the redeem script. The P2SH output will be
considered valid and accepted even if the redeem script is invalid. You
might accidentally receive bitcoin in such a way that it cannot later be
spent.
@ -707,28 +694,28 @@ spent.
"data recording output")))((("OP_RETURN operator")))((("data recording
(nonpayment data)")))((("nonpayment data")))((("blockchain (the)",
"nonpayment data recording")))((("digital notary services")))Bitcoin's
distributed and timestamped ledger, the blockchain, has potential uses
distributed and timestamped blockchain has potential uses
beyond payments. Many developers have tried to use the transaction
scripting language to take advantage of the security and resilience of
the system for applications such as digital notary services
and smart contracts. Early attempts to use bitcoin's
the system for applications such as digital notary services.
Early attempts to use Bitcoin's
script language for these purposes involved creating transaction outputs
that recorded data on the blockchain; for example, to record a digital
fingerprint of a file in such a way that anyone could establish
that recorded data on the blockchain; for example, to record a commitment
to a file in such a way that anyone could establish
proof-of-existence of that file on a specific date by reference to that
transaction.
((("blockchain bloat")))((("bloat")))((("unspent transaction outputs
(UTXO)")))((("UTXO sets")))The use of bitcoin's blockchain to store data
unrelated to bitcoin payments is a controversial subject. Many
(UTXO)")))((("UTXO sets")))The use of Bitcoin's blockchain to store data
unrelated to Bitcoin payments is a controversial subject. Many
people consider such use abusive and want to discourage it. Others
view it as a demonstration of the powerful capabilities of blockchain
technology and want to encourage such experimentation. Those who object
to the inclusion of nonpayment data argue that it causes "blockchain
bloat," burdening those running full Bitcoin nodes with carrying the
to the inclusion of nonpayment data argue that it
burdens those running full Bitcoin nodes with carrying the
cost of disk storage for data that the blockchain was not intended to
carry. Moreover, such transactions create UTXOs that cannot be spent,
using the destination legacy Bitcoin address as a freeform 20-byte field.
carry. Moreover, such transactions may create UTXOs that cannot be spent,
using legacy Bitcoin address as a freeform 20-byte field.
Because the address is used for data, it doesn't correspond to a private
key and the resulting UTXO can _never_ be spent; it's a fake payment.
These transactions that can never be spent are therefore never removed
@ -789,10 +776,10 @@ Let's explain that with the following example.
However:
* Alice can create another transaction, double-spending the same inputs without a lock time. Thus, Alice can spend the same UTXO before the 3 months have elapsed.
* Alice can create a conflicting transaction, spending the same inputs without a lock time. Thus, Alice can spend the same UTXO before the 3 months have elapsed.
* Bob has no guarantee that Alice won't do that.
It is important to understand the limitations of transaction lock time. The only guarantee is that Bob will not be able to redeem the presigned transaction before 3 months have elapsed. There is no guarantee that Bob will get the funds. To guarantee that Bob will receive the funds but cannot spend them until 3 months have elapsed, the timelock restriction must be placed on the UTXO itself and be part of the script, rather than on the transaction. This is achieved by the next form of timelock, called Check Lock Time Verify.
It is important to understand the limitations of transaction lock time. The only guarantee is that Bob will not be able to redeem the presigned transaction before 3 months have elapsed. There is no guarantee that Bob will get the funds. One way to guarantee that Bob will receive the funds but cannot spend them until 3 months have elapsed, the timelock restriction must be placed on the UTXO itself and be part of the script, rather than on the transaction. This is achieved by the next form of timelock, called Check Lock Time Verify.
==== Check Lock Time Verify (OP_CLTV)
@ -804,7 +791,7 @@ 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
as is the case with lock time. This allows for much greater
as is the case with lock time. This allows for additional
flexibility in the way timelocks are applied.
In simple terms, by committing to the +OP_CLTV+ opcode in an
@ -823,25 +810,24 @@ results in TRUE, execution continues.
In order to use +OP_CLTV+, you insert it into the redeem script of the
output in the transaction that creates the output. For
example, if Alice is paying Bob's address, the output would normally
contain a P2PKH script like this:
example, if Alice is paying Bob, he might usually accept payment to
the following P2SH script:
----
OP_DUP OP_HASH160 <Bob's Public Key Hash> OP_EQUALVERIFY OP_CHECKSIG
<Bob's public key> OP_CHECKSIG
----
To lock it to a time, say 3 months from now, the transaction would be a
P2SH transaction with a redeem script like this:
To lock it to a time, say 3 months from now, his P2SH script would
instead be:
----
<now + 3 months> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <Bob's Public Key Hash> OP_EQUALVERIFY OP_CHECKSIG
<Bob's pubkey> OP_CHECKSIGVERIFY <now + 3 months> OP_CHECKLOCKTIMEVERIFYG
----
where +<now {plus} 3 months>+ is a block height or time value estimated
3 months from the time the transaction is mined: current block height
{plus} 12,960 (blocks) or current Unix epoch time {plus} 7,760,000
(seconds). For now, don't worry about the +OP_DROP+ opcode that follows
+OP_CHECKLOCKTIMEVERIFY+; it will be explained shortly.
(seconds).
When Bob tries to spend this UTXO, he constructs a transaction that
references the UTXO as an input. He uses his signature and public key in
@ -855,8 +841,8 @@ 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.
More precisely, +OP_CHECKLOCKTIMEVERIFY+ fails and halts execution, marking
the transaction invalid if (source: BIP65):
More precisely, BIP65 explains that +OP_CHECKLOCKTIMEVERIFY+ fails and
halts execution if:
1. the stack is empty; or
2. the top item on the stack is less than 0; or
@ -875,7 +861,7 @@ that of +OP_CLTV+ in the outputs--they must both reference either
block height or time in seconds.
The above implies that a script can never be valid if it must execute
two different calls to +OP_CLTV+, one which uses a height and one which
two different calls to +OP_CLTV+, one that uses a height and one that
uses a time. It can be easy to make this mistake when writing advanced
scripts, so be sure to thoroughly test your scripts on a test network or
use a tool designed to prevent this issue, like a Miniscript compiler.
@ -1001,12 +987,12 @@ various programming languages that use the construct +IF...THEN...ELSE+.
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
At a basic level, Bitcoin conditional opcodes allow us to construct a
script that has two ways of being unlocked, depending on a
+TRUE+/+FALSE+ outcome of evaluating a logical condition. For example,
if x is +TRUE+, the executed code path is A and the ELSE code path is B.
Additionally, bitcoin conditional expressions can be "nested"
Additionally, Bitcoin conditional expressions can be "nested"
indefinitely, meaning that a conditional clause can contain another
within it, which contains another, etc. Bitcoin Script flow control can
be used to construct very complex scripts with hundreds
@ -1018,7 +1004,7 @@ Bitcoin implements flow control using the +OP_IF+, +OP_ELSE+, +OP_ENDIF+, and
+OP_NOTIF+ opcodes. Additionally, conditional expressions can contain
boolean operators such as +OP_BOOLAND+, +OP_BOOLOR+, and +OP_NOT+.
At first glance, you may find the bitcoin's flow control scripts
At first glance, you may find the Bitcoin's flow control scripts
confusing. That is because Bitcoin Script is a stack language. The same
way that +1 {plus} 1+ looks "backward" when expressed as +1 1 OP_ADD+, flow
control clauses in bitcoin also look "backward."
@ -1201,17 +1187,12 @@ startref="flow07")))((("", startref="condition07")))
script example", id="Scomplex07")))In this section we combine many of
the concepts from this chapter into a single example.
((("use cases", "import/export", id="mohamseventwo")))Our example uses
the story of Mohammed, the company owner in Dubai who is operating an
import/export business.
((("transactions", "advanced", "multisignature
scripts")))((("scripting", "multisignature scripts", "import/export
example")))((("multisignature scripts")))In this example, Mohammed
Mohammed is company owner in Dubai who is operating 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
on timelocks. The participants in the multisig scheme are Mohammed, his
two partners Saeed and Zaira, and their company lawyer Abdul. The three
two partners Saeed and Zaira, and their company lawyer. The three
partners make decisions based on a majority rule, so two of the three
must agree. However, in the case of a problem with their keys, they want
their lawyer to be able to recover the funds with one of the three
@ -1232,13 +1213,13 @@ number prefixed as XX):
03 2
04 OP_ELSE
05 <30 days> OP_CHECKSEQUENCEVERIFY OP_DROP
06 <Abdul the Lawyer's Pubkey> OP_CHECKSIGVERIFY
06 <Lawyer's Pubkey> OP_CHECKSIGVERIFY
07 1
08 OP_ENDIF
09 <Mohammed's Pubkey> <Saeed's Pubkey> <Zaira's Pubkey> 3 OP_CHECKMULTISIG
10 OP_ELSE
11 <90 days> OP_CHECKSEQUENCEVERIFY OP_DROP
12 <Abdul the Lawyer's Pubkey> OP_CHECKSIG
12 <Lawyer's Pubkey> OP_CHECKSIG
13 OP_ENDIF
----
====
@ -1269,14 +1250,14 @@ described in <<multisig_bug>>.
The second execution path can only be used after 30 days have elapsed
from the creation of the UTXO. At that time, it requires the signature
of Abdul the lawyer and one of the three partners (a 1-of-3 multisig).
of the lawyer and one of the three partners (a 1-of-3 multisig).
This is achieved by line 7, which sets the quorum for the multisig to
+1+. To select this execution path, the input script would end in
+OP_FALSE OP_TRUE+:
.Spending data for the second execution path (Lawyer + 1-of-3)
----
OP_0 <Saeed's Sig> <Abdul's Sig> OP_FALSE OP_TRUE
OP_0 <Saeed's Sig> <Lawer's Sig> OP_FALSE OP_TRUE
----
[TIP]
@ -1286,13 +1267,13 @@ stack and +TRUE+ is pushed on top of it.
+TRUE+ is therefore popped _first_ by the first +OP_IF+ opcode.
====
Finally, the third execution path allows Abdul the lawyer to spend the
Finally, the third execution path allows the lawyer to spend the
funds alone, but only after 90 days. To select this execution path, the
input script has to end in +OP_FALSE+:
.Input script for the third execution path (Lawyer only)
----
<Abdul's Sig> OP_FALSE
<Lawyer's Sig> OP_FALSE
----
Try running the script on paper to see how it behaves on the stack.
@ -1345,9 +1326,9 @@ would have to include a signature within the transaction input:
----
[...]
"vin" : [
"txid": "abcdef12345...",
"vout": 0,
"scriptSig": “<Bob’s scriptSig>”,
"txid": "abcdef12345...",
"vout": 0,
"scriptSig": “<Bob’s scriptSig>”,
]
[...]
----
@ -1360,9 +1341,9 @@ input script and includes a witness structure:
----
[...]
"vin" : [
"txid": "abcdef12345...",
"vout": 0,
"scriptSig": “”,
"txid": "abcdef12345...",
"vout": 0,
"scriptSig": “”,
]
[...]
“witness”: “<Bob’s witness structure>”
@ -1372,9 +1353,9 @@ input script and includes a witness structure:
===== Wallet construction of P2WPKH
It is extremely important to note that P2WPKH witness programs should only be created by
the payee (recipient) and not converted by the sender from a known
public key, P2PKH script, or address. The sender has no way of knowing
if the recipient's wallet has the ability to construct segwit
the receiver and not converted by the spender from a known
public key, P2PKH script, or address. The spender has no way of knowing
if the receiver's wallet has the ability to construct segwit
transactions and spend P2WPKH outputs.
Additionally, P2WPKH outputs must be constructed from the hash of a
@ -1387,7 +1368,7 @@ private key.
[WARNING]
====
P2WPKH should be constructed by the recipient by converting a compressed
P2WPKH should be constructed by the receiver by converting a compressed
public key to a P2WPKH hash. Neither the spender nor anyone else should
ever transform a P2PKH script, Bitcoin address, or uncompressed public
key to a P2WPKH witness script. In general, a spender should only send
@ -1418,9 +1399,9 @@ satisfy that redeem script, all inside the transaction input:
----
[...]
"vin" : [
"txid": "abcdef12345...",
"vout": 0,
"scriptSig": “<SigA> <SigB> <2 PubA PubB PubC PubD PubE 5 OP_CHECKMULTISIG>”,
"txid": "abcdef12345...",
"vout": 0,
"scriptSig": “<SigA> <SigB> <2 PubA PubB PubC PubD PubE 5 OP_CHECKMULTISIG>”,
]
----
@ -1462,9 +1443,9 @@ the legacy input script field.
----
[...]
"vin" : [
"txid": "abcdef12345...",
"vout": 0,
"scriptSig": “”,
"txid": "abcdef12345...",
"vout": 0,
"scriptSig": “”,
]
[...]
“witness”: “<SigA> <SigB> <2 PubA PubB PubC PubD PubE 5 OP_CHECKMULTISIG>”
@ -1507,10 +1488,10 @@ Legacy P2PKH and
P2SH continue to work for nonupgraded wallets. That leaves two
important scenarios, which are addressed in the next section:
- Ability of a sender's wallet that is not segwit-aware to make a
- Ability of a spender's wallet that is not segwit-aware to make a
payment to a recipient's wallet that can process segwit transactions.
- Ability of a sender's wallet that is segwit-aware to recognize and
- Ability of a spender's wallet that is segwit-aware to recognize and
distinguish between recipients that are segwit-aware and ones that are
not, by their _addresses_.
@ -1523,8 +1504,8 @@ 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
segwit script inside it. Alice's wallet sees this as a "normal" P2SH
address and can make payments to it without any knowledge of segwit.
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.
@ -1697,7 +1678,7 @@ included in the authorization data); we could also have four
commitments for the same cost. An extra commitment would give us up to
eight conditions. With just 16 commitments--512 bytes of commitments--we could have
over 32,000 authorization conditions, far more than could be effectively
used in an entire block of +OP_IF+ statements. With 128 commitments
used in an entire block of transactions filled with +OP_IF+ statements. With 128 commitments
(4,096 bytes), the number of conditions we could create in theory far
exceeds the number of conditions that all the computers in the world
could create.
@ -1857,7 +1838,7 @@ leaked.
There are two downsides of scriptless multisignatures. The first is
that all known secure algorithms for creating them for Bitcoin require more
rounds of interaction or more careful management of state (or both) than
rounds of interaction or more careful management of state than
scripted multisignature. This can be challenging in cases where
signatures are being generated by nearly stateless hardware signing
devices and the keys are physically distributed. For example, if you
@ -1943,10 +1924,10 @@ may appear because any transaction created by a single user who wants it
to be satisfied by a single signature (or a multisignature generated by
multiple different wallets they control) looks identical onchain to a
mutual-satisfaction spend. There's no onchain difference in this case
between a spend by million users involved in an extraordinarily complex
between a spend by a million users involved in an extraordinarily complex
contract or a single user just spending their saved bitcoins.
When spending is possible using just the key, such for a single signature
When spending is possible using just the key, such as for a single signature
or scriptless multisignature, that is called _keypath spending_. When
the tree of scripts is used, that is called _scriptpath spending_.
For keypath spending, the data that gets put onchain is the public key
@ -1962,7 +1943,7 @@ in this context. The witness structure includes the following information:
merkle root to produce the taproot output key. This underlying key
is called the _taproot internal key_
3. The leaf script to execute
3. The script to execute, called the _leaf script_
4. One 32-byte hash for each junction in merkle tree along the path that connects the leaf to the merkle root
@ -2016,7 +1997,8 @@ Additionally, any signature-checking operation which is not expected
OP_SUCCESSx opcodes::
Opcodes in previous versions of script which were unusable are now
redefined to cause an entire script to succeed if they are used.
This allows future soft forks to redefine them as not succeeding, which
This allows future soft forks to redefine them as not succeeding under
certain circumstances, which
is a restriction and so is possible to do in a soft fork. (The
opposite, to define a not-succeeding operation as a success can only
be done in a hard fork, which is a much more challenging upgrade

10
bips.adoc
View File

@ -2,18 +2,18 @@
[appendix]
== Bitcoin Improvement Proposals
((("bitcoin improvement proposals", "types of")))Bitcoin Improvement Proposals are design documents providing information to the bitcoin community, or for describing a new feature for bitcoin or its processes or environment.
((("bitcoin improvement proposals", "types of")))Bitcoin Improvement Proposals are design documents providing information to the Bitcoin community, or for describing a new feature for Bitcoin or its processes or environment.
As per BIP1 _BIP Purpose and Guidelines_, there are three 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.
_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.
((("bitcoin improvement proposals", "repository of")))BIPs are recorded in a versioned repository on GitHub: https://github.com/bitcoin/bips[https://github.com/bitcoin/bips].
An MIT-licensed document from the open source Bitcoin Core project,
reproduced here in edited form, describes which BIPs it implements, including listing
the version of Bitcoin Core where support for each BIP was added or
the Pull Request (PR) and version of Bitcoin Core where support for each BIP was added or
significantly changed.
BIPs that are implemented by Bitcoin Core:

13
bitcoin-core.adoc
View File

@ -9,7 +9,7 @@ verify the integrity of the bitcoins they receive. The Bitcoin system
was designed so that it's possible for software running entirely on your
local computer to perfectly prevent counterfeiting, debasement, and
several other critical problems. Software which provides that function
is called a full verification node because it verifies every confirmed
is called a _full verification node_ because it verifies every confirmed
Bitcoin transaction against every rule in the system. Full verification
nodes, _full nodes_ for short, may also provide tools and data for
understanding how Bitcoin works and what is currently happening in the
@ -306,8 +306,7 @@ fixes the error.
executables")))((("core executables", seealso="Bitcoin Core")))Next, you
will compile the source code, a process that can take up to an hour to
complete, depending on the speed of your CPU and available memory.
During the compilation process you should see output every few seconds
or every few minutes, or an error if something goes wrong. If an error
If an error
occurs, or the compilation process is interrupted, it can be resumed any
time by typing +make+ again. Type +make+ to start compiling the
executable application:
@ -650,10 +649,10 @@ afterward continues to download the full blocks, validating them as it
goes.
Once you are happy with the configuration options you have selected, you
should add bitcoin to the startup scripts in your operating system, so
should add Bitcoin Core to the startup scripts in your operating system, so
that it runs continuously and restarts when the operating system
restarts. You will find a number of example startup scripts for various
operating systems in bitcoin's source directory under _contrib/init_ and
operating systems in Bitcoin Core's source directory under _contrib/init_ and
a _README.md_ file showing which system uses which script.((("",
startref="BCnode03")))((("", startref="BNcore03")))
@ -1025,9 +1024,7 @@ any higher level Bitcoin Core RPC wrappers), as seen in <<cookie_auth>>.
$ cat .bitcoin/.cookie
__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/
$ 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/
{"result":{"chain":"main","blocks":799278,"headers":799278,"bestblockhash":"000000000000000000018387c50988ec705a95d6f765b206b6629971e6978879","difficulty":53911173001054.59,"time":1689703111,"mediantime":1689701260,"verificationprogress":0.9999979206082515,"initialblockdownload":false,"chainwork":"00000000000000000000000000000000000000004f3e111bf32bcb47f9dfad5b","size_on_disk":563894577967,"pruned":false,"warnings":""},"error":null,"id":"curltest"}
----

19
blockchain.adoc
View File

@ -46,7 +46,7 @@ following it, it cannot be changed without forcing a recalculation of
all subsequent blocks. Because such a recalculation would require
enormous computation (and therefore energy consumption), the existence
of a long chain of blocks makes the blockchain's deep history impractical to change,
which is a key feature of bitcoin's security.
which is a key feature of Bitcoin's security.
One way to think about the blockchain is like layers in a geological
formation, or glacier core sample. The surface layers might change with
@ -72,7 +72,7 @@ infinitesimal.
((("blocks", "structure of")))((("blockchain (the)", "block
structure")))A block is a container data structure that aggregates
transactions for inclusion in the public ledger, the blockchain. The
transactions for inclusion in the blockchain. The
block is made of a header, containing metadata, followed by a long list
of transactions that make up the bulk of its size. The block header is
80 bytes, whereas the total size of all transactions in a block can be
@ -88,7 +88,7 @@ header. <<block_structure1>> describes how Bitcoin Core stores the structure of
|Size| Field | Description
| 4 bytes | Block Size | The size of the block, in bytes, following this field
| 80 bytes | Block Header | Several fields form the block header
| 1-9 bytes (compactSize) | Transaction Counter | How many transactions follow
| 1-3 bytes (compactSize) | Transaction Counter | How many transactions follow
| Variable | Transactions | The transactions recorded in this block
|=======
@ -120,20 +120,19 @@ process and will be discussed in more detail in <<mining>>.
((("blockchain (the)", "block identifiers")))((("blocks", "block
height")))((("blocks", "block hash")))The primary identifier of a block
is its cryptographic hash, a digital fingerprint, made by hashing the
is its cryptographic hash, a commitment made by hashing the
block header twice through the SHA256 algorithm. The resulting 32-byte
hash is called the _block hash_ but is more accurately the _block header
hash_, pass:[<span role="keep-together">because only the block header is
used to compute it. For example,</span>]
+000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f+ is
the block hash of the first block on Bitcoin's block chain. The block hash
the block hash of the first block on Bitcoin's blockchain. The block hash
identifies a block uniquely and unambiguously and can be independently
derived by any node by simply hashing the block header.
Note that the block hash is not actually included inside the block's
data structure, neither when the block is transmitted on the network,
nor when it is stored on a node's persistent storage as part of the
blockchain. Instead, the block's hash is computed by each node as the
data structure.
Instead, the block's hash is computed by each node as the
block is received from the network. The block hash might be stored in a
separate database table as part of the block's metadata, to facilitate
indexing and faster retrieval of blocks from disk.
@ -202,7 +201,7 @@ The following identifier hash belongs to the genesis block:
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
----
You can search for that block hash in any block explorer website, such
You can search for that block hash in almost any block explorer website, such
as _blockstream.info_, and you will find a page describing the contents
of this block, with a URL containing that hash:
@ -327,7 +326,7 @@ transactions and permitting a very efficient process to verify whether a
transaction is included in a block. A merkle tree is constructed by
recursively hashing pairs of elements until there is only one hash, called
the _root_, or _merkle root_. The cryptographic hash algorithm used in
bitcoin's merkle trees is SHA256 applied twice, also known as
Bitcoin's merkle trees is SHA256 applied twice, also known as
double-SHA256.
When N data elements are hashed and summarized in a merkle tree, you can

38
errata.adoc
View File

@ -14,8 +14,8 @@ sections in Nakamoto's original paper.
=== Abstract
____
The longest chain not only serves as proof of the sequence of events
witnessed, but proof that it came from the largest pool of CPU power.
"The longest chain not only serves as proof of the sequence of events
witnessed, but proof that it came from the largest pool of CPU power."
____
* *Implementation detail:* If each link in the chain (called "blocks"
@ -44,9 +44,9 @@ instead of saying "CPU power" it is perhaps more correct to say
in generating the POW.
____
As long as a majority of CPU power is controlled by nodes that are not
"As long as a majority of CPU power is controlled by nodes that are not
cooperating to attack the network, they’ll generate the longest chain
and outpace attackers.
and outpace attackers."
____
* *Terminology change:* The term "nodes" today is used to refer to
@ -84,10 +84,10 @@ than about 30% of the network".
=== Transactions
____
We define an electronic coin as a chain of digital signatures. Each
"We define an electronic coin as a chain of digital signatures. Each
owner transfers the coin to the next by digitally signing a hash of the
previous transaction and the public key of the next owner and adding
these to the end of the coin.
these to the end of the coin."
____
* *Implementation detail:* Bitcoin implements a more general version of
@ -107,9 +107,9 @@ chain-like; it’s more accurately described as a directed acyclic graph
=== Proof-of-Work
____
we implement the proof-of-work by incrementing a nonce in the block
"we implement the proof-of-work by incrementing a nonce in the block
until a value is found that gives the block’s hash the required zero
bits.
bits."
____
* *Implementation detail:* Adam Back’s Hashcash implementation requires
@ -119,7 +119,7 @@ specified integer, which effectively allows a fractional number of bits
to be specified.
____
Proof-of-work is essentially one-CPU-one-vote.
"Proof-of-work is essentially one-CPU-one-vote."
____
* *Important note:* the vote here is not on the rules of the system but
@ -135,8 +135,8 @@ transaction as payment, and honest nodes will never accept a block
containing them."
____
proof-of-work difficulty is determined by a moving average targeting an
average number of blocks per hour.
"proof-of-work difficulty is determined by a moving average targeting an
average number of blocks per hour."
____
* *Implementation detail:* A moving average is not used. Instead, every
@ -153,8 +153,8 @@ that the adjustment can not increase block production speed by more than
=== Reclaiming Disk Space
____
Once the latest transaction in a coin is buried under enough blocks, the
spent transactions before it can be discarded to save disk space
"Once the latest transaction in a coin is buried under enough blocks, the
spent transactions before it can be discarded to save disk space"
____
* *Possible post-publication discovery:* Although the Merkle Tree
@ -168,10 +168,10 @@ nodes will need to process all transactions.
=== Simplified Payment Verification
____
One strategy to protect against this would be to accept alerts from
"One strategy to protect against this would be to accept alerts from
network nodes when they detect an invalid block, prompting the user’s
software to download the full block and alerted transactions to confirm
the inconsistency.
the inconsistency."
____
* *Important Note:* although software has been produced that implements
@ -184,8 +184,8 @@ the past.
=== Privacy
____
Some linking is still unavoidable with multi-input transactions, which
necessarily reveal that their inputs were owned by the same owner
"Some linking is still unavoidable with multi-input transactions, which
necessarily reveal that their inputs were owned by the same owner"
____
* *Post-publication invention:* it isn't clear that different inputs
@ -203,11 +203,11 @@ it has been in use since 2015.
=== Calculations
____
The receiver generates a new key pair and gives the public key to the
"The receiver generates a new key pair and gives the public key to the
sender shortly before signing. This prevents the sender from preparing a
chain of blocks ahead of time by working on it continuously until he is
lucky enough to get far enough ahead, then executing the transaction at
that moment.
that moment."
____
* *Post-publication discovery:* nothing about the receiver generating a

31
fees.adoc
View File

@ -13,9 +13,9 @@ use to determine which keys control which bitcoins.
To protect himself against conflicting transactions, it would be wise
for Bob to wait until the transaction from Alice is included in the
blockchain before he considers the money he received as his to spend.
He may want to wait even longer than that, as we discussed in
<<confirmation_score>>. For Alice's transaction to be included in the
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 produced in a given amount of time and each
block only has a limited amount of space. Only the miner who creates
@ -92,7 +92,7 @@ Bitcoin for spenders to pay transaction fees. There are exceptions,
such as for merchants which accept unconfirmed transactions and in
protocols that don't immediately broadcast transactions after they are
signed (preventing the spender from being able to choose an appropriate
fee for the current market).
fee for the current market). We'll explore those exceptions later.
=== Fees and fee rates
@ -123,7 +123,7 @@ fee rates.
[WARNING]
====
Be careful accepting input for fee rates. If a user copy and pastes a
Be careful accepting input for fee rates. If a user copies and pastes a
fee rate printed in one denominator into a field using a different
enumerator, they could overpay fees by 1,000 times. If they instead
switch the enumerator, they could theoretically overpay by 100,000,000
@ -196,7 +196,7 @@ bumping in Bitcoin, Replace-By-Fee (RBF) and Child Pays For Parent
To increase the fee of a transaction using RBF fee bumping, you create
a conflicting version of the transaction which pays a higher fee. Two
or more transactions are considered to be _conflicting transactions_ if
only one of them can be included in a valid block chain, forcing a miner
only one of them can be included in a valid blockchain, forcing a miner
to chose only one of them. Conflicts occur when two or more transactions
each try to spend one of the same UTXOs, i.e. they each include an input
that has the same outpoint (reference to the output of a previous
@ -292,9 +292,16 @@ having "Sending support" on
https://bitcoinops.org/en/compatibility/#replace-by-fee-rbf
As a developer, if you plan to implement RBF fee bumping, you will first
need to implement the signaling specified in BIP125, which is a simple
need to decided 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
full-RBF replacements. If you choose opt-in RBF, your wallet will need
to implement the signaling specified in BIP125, which is a simple
modification to any one of the sequence fields in a transaction (see
<<sequence>>).
<<sequence>>). If you choose full RBF, you don't need to include any
signaling in your transactions. Everything else related to RBF is the
same for both approaches.
When you need to fee bump a transaction, you will simply create a new
transaction that spends at least one of the same UTXOs as the original
@ -361,7 +368,7 @@ transaction is called a _child transaction_.
As we learned in <<outpoints>>, every input in a confirmed transaction
must reference the unspent output of a transaction which appears earlier
in the block chain (whether earlier in the same block or in a previous
in the blockchain (whether earlier in the same block or in a previous
block). That means a miner who wants to confirm a child transaction
must also ensure that its parent transaction is confirmed. If the
parent transaction hasn't been confirmed yet but the child transaction
@ -453,12 +460,12 @@ is that they can sometimes prevent someone from being able to use fee
bumping. Making it impossible or difficult to fee bump a transaction is
called _transaction pinning_.
One of the major denial of service concerns revolve around the effect of
One of the major denial of service concerns revolve's around the effect of
transaction relationships. Whenever the output of a transaction is
spent, that transaction's identifier (txid) is referenced by the child
transaction. However, when a transaction is replaced, the replacement
has a different txid. If that replacement transaction gets confirmed,
none of its descendants can be included in the same block chain. It's
none of its descendants can be included in the same blockchain. It's
possible to recreate and re-sign the descendant transactions, but that's
not guaranteed to happen. This has related but divergent implications
for RBF and CPFP:
@ -497,7 +504,7 @@ Additionally, a transaction and all of its descendants is not
that transaction is mined--none of those transactions can now be
confirmed unless there's a rare blockchain reorganization. Bitcoin
Core will remove from its mempool every transaction that can no longer
be confirmed on the current block chain. At it's worst, that can
be confirmed on the current blockchain. At it's worst, that can
waste an enormous amount of your node's bandwidth and possibly be used
to prevent transactions from propagating correctly.
+

24
glossary.asciidoc
View File

@ -15,7 +15,7 @@ bitcoin::
The name of the currency unit (the coin), the network, and the software.
block::
A grouping of transactions, marked with a timestamp, and a fingerprint of the previous block. The block header is hashed to produce a proof of work, thereby validating the transactions. Valid blocks are added to the main blockchain by network consensus.
A grouping of transactions, marked with a timestamp, and a commitment to the previous block. The block header is hashed to produce a proof of work, thereby validating the transactions. Valid blocks are added to the main blockchain by network consensus.
blockchain::
A list of validated blocks, each linking to its predecessor all the way to the genesis block.
@ -41,7 +41,7 @@ confirmations::
Once a transaction is included in a block, it has one confirmation. As soon as _another_ block is mined on the same blockchain, the transaction has two confirmations, and so on. Six or more confirmations is considered sufficient proof that a transaction cannot be reversed.
consensus::
When several nodes, usually most nodes on the network, all have the same blocks in their locally-validated best block chain.
When several nodes, usually most nodes on the network, all have the same blocks in their locally-validated best blockchain.
Not to be confused with consensus rules.
consensus rules::
@ -58,7 +58,7 @@ difficulty target::
A difficulty at which all the computation in the network will find blocks approximately every 10 minutes.
double-spending::
Double spending is the result of successfully spending some money more than once. Bitcoin protects against double-spending by verifying each transaction added to the block chain to ensure that the inputs for the transaction had not previously already been spent.
Double spending is the result of successfully spending some money more than once. Bitcoin protects against double-spending by verifying each transaction added to the blockchain to ensure that the inputs for the transaction had not previously already been spent.
ECDSA::
Elliptic Curve Digital Signature Algorithm or ECDSA is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners.
@ -70,7 +70,7 @@ fees::
The sender of a transaction often includes a fee to the network for processing the requested transaction. Most transactions require a minimum fee of 0.5 mBTC.
fork::
Fork, also known as accidental fork, occurs when two or more blocks have the same block height, forking the block chain. Typically occurs when two or more miners find blocks at nearly the same time. Can also happen as part of an attack.
Fork, also known as accidental fork, occurs when two or more blocks have the same block height, forking the blockchain. Typically occurs when two or more miners find blocks at nearly the same time. Can also happen as part of an attack.
genesis block::
The first block in the blockchain, used to initialize the cryptocurrency.
@ -82,8 +82,9 @@ hard fork::
hardware wallet::
A hardware wallet is a special type of bitcoin wallet which stores the user's private keys in a secure hardware device.
//FIXME: needs improvement
hash::
A digital fingerprint of some binary input.
A digital commitment to some binary input.
hashlocks::
A hashlock is a type of encumbrance that restricts the spending of an output until a specified piece of data is publicly revealed. Hashlocks have the useful property that once any hashlock is opened publicly, any other hashlock secured using the same key can also be opened. This makes it possible to create multiple outputs that are all encumbered by the same hashlock and which all become spendable at the same time.
@ -110,7 +111,7 @@ Lightning Networks::
Lightning Network is a proposed implementation of Hashed Timelock Contracts (HTLCs) with bi-directional payment channels which allows payments to be securely routed across multiple peer-to-peer payment channels. This allows the formation of a network where any peer on the network can pay any other peer even if they don't directly have a channel open between each other.
Lock time::
Lock time is the part of a transaction which indicates the earliest time or earliest block when that transaction may be added to the block chain.
Lock time is the part of a transaction which indicates the earliest time or earliest block when that transaction may be added to the blockchain.
mempool::
The bitcoin Mempool (memory pool) is a collection of all transaction data in a block that have been verified by Bitcoin nodes, but are not yet confirmed.
@ -133,15 +134,12 @@ network::
nonce::
The "nonce" in a bitcoin block is a 32-bit (4-byte) field whose value is set so that the hash of the block will contain a run of leading zeros. The rest of the fields may not be changed, as they have a defined meaning.
off-chain transactions::
An off-chain transaction is the movement of value outside of the block chain. While an on-chain transaction&#x2014;usually referred to as simply __a transaction__&#x2014;modifies the blockchain and depends on the blockchain to determine its validity an off-chain transaction relies on other methods to record and validate the transaction.
offchain transactions::
An offchain transaction is the movement of value outside of the blockchain. While an onchain transaction&#x2014;usually referred to as simply __a transaction__&#x2014;modifies the blockchain and depends on the blockchain to determine its validity an offchain transaction relies on other methods to record and validate the transaction.
opcode::
Operation codes from the Bitcoin Script language which push data or perform functions within a pubkey script or signature script.
Open Assets protocol::
The Open Assets Protocol is a simple and powerful protocol built on top of the Bitcoin blockchain. It allows issuance and transfer of user-created assets. The Open Assets protocol is an evolution of the concept of colored coins.
OP_RETURN::
An opcode used in one of the outputs in an OP_RETURN transaction. Not to be confused with OP_RETURN transaction.
@ -176,7 +174,7 @@ paper wallet::
In the most specific sense, a paper wallet is a document containing all of the data necessary to generate any number of Bitcoin private keys, forming a wallet of keys. However, people often use the term to mean any way of storing bitcoin offline as a physical document. This second definition also includes paper keys and redeemable codes.
payment channels::
A micropayment channel or payment channel is class of techniques designed to allow users to make multiple Bitcoin transactions without committing all of the transactions to the bitcoin blockchain. In a typical payment channel, only two transactions are added to the block chain but an unlimited or nearly unlimited number of payments can be made between the participants.
A micropayment channel or payment channel is class of techniques designed to allow users to make multiple Bitcoin transactions without committing all of the transactions to the bitcoin blockchain. In a typical payment channel, only two transactions are added to the blockchain but an unlimited or nearly unlimited number of payments can be made between the participants.
pooled mining::
Pooled mining is a mining approach where multiple generating clients contribute to the generation of a block, and then split the block reward according the contributed processing power.
@ -229,7 +227,7 @@ soft fork::
Not to be confused with fork, hard fork, software fork or Git fork.
stale block::
Block that was successfully mined but that isn’t included on the current best block chain, likely because some other block at the same height had its chain extended first. Not to be confused with orphan block.
Block that was successfully mined but that isn’t included on the current best blockchain, likely because some other block at the same height had its chain extended first. Not to be confused with orphan block.
timelocks::
A timelock is a type of encumbrance that restricts the spending of some bitcoin until a specified future time or block height. Timelocks feature prominently in many Bitcoin contracts, including payment channels and hashed timelock contracts.

62
intro.adoc
View File

@ -36,7 +36,7 @@ transactions. Any participant in the Bitcoin network may operate as a
miner, using their computing devices to help secure
transactions. Every 10 minutes, on average, one Bitcoin miner can add security to
past transactions and is rewarded with both brand new
bitcoin and the fees paid by recent transactions. Essentially, Bitcoin
bitcoins and the fees paid by recent transactions. Essentially, Bitcoin
mining decentralizes the currency-issuance
and clearing functions of a central bank and replaces the need for any
central bank.
@ -54,14 +54,14 @@ mining function across the network. The difficulty of the computational
task that miners must perform is adjusted dynamically so that, on
average, someone succeeds every 10 minutes regardless of how many miners
(and how much processing) are competing at any moment. The protocol also
periodically decreases the number of new bitcoins are created,
limiting the total number of bitcoins that will be created to a fixed total
periodically decreases the number of new bitcoins that are created,
limiting the total number of bitcoins that will ever be created to a fixed total
just below 21 million coins. The result is that the number of bitcoins in
circulation closely follows an easily predictable curve where half of
the remaining coins are added to circulation every four years. At
approximately block 1,411,200, which is expected to be produced around
the year 2035, 99% of all bitcoins
that will ever exist will have been issued. Due to bitcoin's
that will ever exist will have been issued. Due to Bitcoin's
diminishing rate of issuance, over the long term, the Bitcoin currency
is deflationary. Furthermore, nobody can force you to accept
any bitcoins that were created beyond the
@ -70,7 +70,7 @@ expected issuance rate.
Behind the scenes, Bitcoin is also the name of the protocol, a peer-to-peer network, and a distributed computing innovation. Bitcoin builds on decades of research in cryptography and distributed systems and includes at least four key innovations brought together in a unique and powerful combination. Bitcoin consists of:
* A decentralized peer-to-peer network (the Bitcoin protocol)
* A public transaction ledger (the blockchain)
* A public transaction journal (the blockchain)
* ((("mining and consensus", "consensus rules", "satisfying")))A set of rules for independent transaction validation and currency issuance (consensus rules)
* A mechanism for reaching global decentralized consensus on the valid blockchain (Proof-of-Work algorithm)
@ -164,7 +164,6 @@ derived from the original implementation written by Satoshi Nakamoto.
((("security", "wallet selection")))Bitcoin wallets 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.
[role="pagebreak-before"]
===== Types of Bitcoin wallets
Bitcoin wallets can be categorized as follows, according to the platform:
@ -203,7 +202,7 @@ role in how much security and privacy the user obtains when using the
hardware signing device.
===== Full-node vs. Lightweight
Another way to categorize bitcoin wallets is by their degree of autonomy and how they interact with the Bitcoin network:
Another way to categorize Bitcoin wallets is by their degree of autonomy and how they interact with the Bitcoin network:
Full-node:: ((("full-node")))A full node is a program that validates the
entire history of Bitcoin transactions (every transaction by every user,
@ -247,8 +246,8 @@ A very important additional consideration is _who controls the keys_. As
we will see in subsequent chapters, access to bitcoins is
controlled by "private keys", which are like very long PIN numbers. If
you are the only one to have *control* over these private
keys, you are in control of your bitcoin. Conversely, if you do not have
control, then your bitcoin is managed by a third-party who
keys, you are in control of your bitcoins. Conversely, if you do not have
control, then your bitcoins are managed by a third-party who
ultimately controls your funds on your behalf. Key management software falls into two
important categories based on control: _wallets_, where you
control the keys, and the funds and accounts with custodians where some
@ -264,16 +263,6 @@ accounts with third parties (you don't control the keys). The lines between diff
are sometimes blurry, as software runs on multiple platforms and can
interact with the network in different ways.
For the purposes of this book, we will be demonstrating the use of a
variety of downloadable Bitcoin software, from the reference
implementation (Bitcoin Core) to mobile and web software. Some of the
examples will require the use of Bitcoin Core, which, in addition to
being a full node, also exposes APIs to the wallet, network, and
transaction services. If you are planning to explore the programmatic
interfaces into the Bitcoin system, you will need to run Bitcoin Core,
or one of the alternative full node implementations.((("", startref="GSwallet01")))((("",
startref="Wselect01")))
==== Quick Start
((("getting started", "quick start example",
@ -374,19 +363,19 @@ ensure you aren't being phished.
==== Bitcoin addresses
Alice is now ready to start using her new bitcoin wallet. ((("", startref="GSquick01")))((("", startref="Wquick01"))) Her wallet application randomly generated a private key (described in more detail in <<private_keys>>) which will be used to derive Bitcoin addresses that direct to her wallet. At this point, her Bitcoin addresses are not known to the Bitcoin network or "registered" with any part of the Bitcoin system. Her Bitcoin addresses are simply numbers that correspond to her private key that she can use to control access to the funds. The addresses are generated independently by her wallet without reference or registration with any service.
Alice is now ready to start using her new Bitcoin wallet. ((("", startref="GSquick01")))((("", startref="Wquick01"))) Her wallet application randomly generated a private key (described in more detail in <<private_keys>>) which will be used to derive Bitcoin addresses that direct to her wallet. At this point, her Bitcoin addresses are not known to the Bitcoin network or "registered" with any part of the Bitcoin system. Her Bitcoin addresses are simply numbers that correspond to her private key that she can use to control access to the funds. The addresses are generated independently by her wallet without reference or registration with any service.
[TIP]
====
((("addresses", "security of")))((("security", "bitcoin addresses")))There
are a variety of Bitcoin addresses and invoice formats. Addresses and
invoices can be shared with other bitcoin users
who can use them to send bitcoin directly to your wallet. You can share
invoices can be shared with other Bitcoin users
who can use them to send bitcoins directly to your wallet. You can share
an address or invoice with other people without worrying about the
security of your bitcoins. Unlike a bank account number, nobody who
learns one of your Bitcoin addresses can withdraw money from your wallet--you
must initiate all spends. However, if you give two people the same
address, they will be able to see how much bitcoin the other person sent
address, they will be able to see how many bitcoins the other person sent
you. If you post your address publicly, everyone will be able to see
how much bitcoin other people sent to that address. To protect your privacy, you
should generate a new invoice with a new address each time you request a
@ -420,10 +409,10 @@ Bitcoin transactions are irreversible. Most electronic payment networks such as
[role="pagebreak-before"]
Here are some methods for acquiring bitcoin as a new user:
* Find a friend who has bitcoin and buy some from him or her directly. Many Bitcoin users start this way. This method is the least complicated. One way to meet people with bitcoin is to attend a local Bitcoin meetup listed at https://meetup.com[Meetup.com].
* Earn bitcoin by selling a product or service for bitcoin. If you are a programmer, sell your programming skills. If you're a hairdresser, cut hair for bitcoin.
* ((("Coin ATM Radar")))((("ATMs, locating")))Use a bitcoin ATM in your city. A bitcoin ATM is a machine that accepts cash and sends bitcoin to your smartphone bitcoin wallet.
* ((("exchange rates", "listing services")))Use a bitcoin currency exchange linked to your bank account. Many countries now have currency exchanges that offer a market for buyers and sellers to swap bitcoin with local currency. Exchange-rate listing services, such as https://bitcoinaverage.com[BitcoinAverage], often show a list of bitcoin exchanges for each currency.
* Find a friend who has bitcoins and buy some from him or her directly. Many Bitcoin users start this way. This method is the least complicated. One way to meet people with bitcoins is to attend a local Bitcoin meetup listed at https://meetup.com[Meetup.com].
* Earn bitcoin by selling a product or service for bitcoin. If you are a programmer, sell your programming skills. If you're a hairdresser, cut hair for bitcoins.
* ((("Coin ATM Radar")))((("ATMs, locating")))Use a Bitcoin ATM in your city. A Bitcoin ATM is a machine that accepts cash and sends bitcoins to your smartphone Bitcoin wallet.
* ((("exchange rates", "listing services")))Use a Bitcoin currency exchange linked to your bank account. Many countries now have currency exchanges that offer a market for buyers and sellers to swap bitcoins with local currency. Exchange-rate listing services, such as https://bitcoinaverage.com[BitcoinAverage], often show a list of Bitcoin exchanges for each currency.
[TIP]
====
@ -439,26 +428,27 @@ touches traditional systems, such as currency exchanges, national and
international regulations often apply. In order to exchange bitcoin for
your national currency, you will often be required to provide proof of
identity and banking information. Users should be aware that once a
Bitcoin address is attached to an identity, other associated bitcoin
Bitcoin address is attached to an identity, other associated Bitcoin
transactions may also become easy to identify and track--including
transactions made earlier. This is one reason
many users choose to maintain dedicated exchange accounts independent from
their wallets.
====
Alice was introduced to Bitcoin by a friend so she has an easy way to acquire her first bitcoin. Next, we will look at how she buys bitcoin from her friend Joe and how Joe sends the bitcoin to her 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 wallet.
[[bitcoin_price]]
==== Finding the Current Price of Bitcoin
((("getting started", "exchange rates")))((("exchange rates", "determining")))Before Alice can buy bitcoin from Joe, they have to agree on the _exchange rate_ between bitcoin and US dollars. This brings up a common question for those new to bitcoin: "Who sets the bitcoin price?" The short answer is that the price is set by markets.
((("getting started", "exchange rates")))((("exchange rates", "determining")))Before Alice can buy bitcoin from Joe, they have to agree on the _exchange rate_ between bitcoin and US dollars. This brings up a common question for those new to Bitcoin: "Who sets the price
of bitcoins?" The short answer is that the price is set by markets.
((("exchange rates", "floating")))((("floating exchange rate")))Bitcoin, like most other currencies, has a _floating exchange rate_. That means that the value of bitcoin fluctuates according to supply and demand in the various markets where it is traded. For example, the "price" of bitcoin in US dollars is calculated in each market based on the most recent trade of bitcoin and US dollars. As such, the price tends to fluctuate minutely several times per second. A pricing service will aggregate the prices from several markets and calculate a volume-weighted average representing the broad market exchange rate of a currency pair (e.g., BTC/USD).
((("exchange rates", "floating")))((("floating exchange rate")))Bitcoin, like most other currencies, has a _floating exchange rate_. That means that the value of bitcoin fluctuates according to supply and demand in the various markets where it is traded. For example, the "price" of bitcoin in US dollars is calculated in each market based on the most recent trade of bitcoins and US dollars. As such, the price tends to fluctuate minutely several times per second. A pricing service will aggregate the prices from several markets and calculate a volume-weighted average representing the broad market exchange rate of a currency pair (e.g., BTC/USD).
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]:: ((("BitcoinAverage")))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 crypto-currencies, including bitcoin.
https://coincap.io/[CoinCap]:: A service listing the market capitalization and exchange rates of hundreds of crypto-currencies, including bitcoins.
https://www.cmegroup.com/markets/cryptocurrencies/cme-cf-cryptocurrency-benchmarks.html?redirect=/trading/cryptocurrency-indices/cf-bitcoin-reference-rate.html[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
@ -471,7 +461,7 @@ currencies.
((("getting started", "sending and receiving bitcoin",
id="GSsend01")))((("spending bitcoin", "bitcoin wallet quick start
example")))((("spending bitcoin", see="also transactions")))Alice has
decided to buy 0.001 bitcoin. After she and Joe check the exchange rate,
decided to buy 0.001 bitcoins. After she and Joe check the exchange rate,
she gives Joe an appropriate amount of cash, opens her mobile wallet
application, and selects Receive. This
displays a QR code with Alice's first Bitcoin address.
@ -479,7 +469,7 @@ displays a QR code with Alice's first Bitcoin address.
Joe then selects Send on his smartphone wallet and opens the QR code
scanner. This allows Joe to scan the barcode with his smartphone camera
so that he doesn't have to type in Alice's Bitcoin address, which is
quite long and difficult to type.
quite long.
Joe now has Alice's Bitcoin address set as the recipient. Joe enters the
amount as 0.001 bitcoins (BTC), see <<wallet-send>>. Some wallets may
@ -521,7 +511,7 @@ transaction, Alice's wallet will indicate that it is receiving
[[confirmations]]
.Confirmations
****
((("getting started", "confirmations")))((("confirmations", "bitcoin wallet quick start example")))((("confirmations", see="also mining and consensus; transactions")))((("clearing", seealso="confirmations")))At first, Alice's address will show the transaction from Joe as "Unconfirmed." This means that the transaction has been propagated to the network but has not yet been recorded in the bitcoin transaction ledger, known as the blockchain. To be confirmed, a transaction must be included in a block and added to the blockchain, which happens every 10 minutes, on average. In traditional financial terms this is known as _clearing_. For more details on propagation, validation, and clearing (confirmation) of bitcoin transactions, see <<mining>>.
((("getting started", "confirmations")))((("confirmations", "bitcoin wallet quick start example")))((("confirmations", see="also mining and consensus; transactions")))((("clearing", seealso="confirmations")))At first, Alice's address will show the transaction from Joe as "Unconfirmed." This means that the transaction has been propagated to the network but has not yet been recorded in the Bitcoin transaction journal, known as the blockchain. To be confirmed, a transaction must be included in a block and added to the blockchain, which happens every 10 minutes, on average. In traditional financial terms this is known as _clearing_. For more details on propagation, validation, and clearing (confirmation) of bitcoin transactions, see <<mining>>.
****
Alice is now the proud owner of 0.001 BTC that she can spend. Over the next few days, Alice buys more bitcoin using an ATM and an exchange. In the next chapter we will look at her first purchase with bitcoin, and examine the underlying transaction and propagation technologies in more detail.((("", startref="BCbasic01")))
Alice is now the proud owner of 0.001 BTC that she can spend. Over the next few days, Alice buys more bitcoin using an ATM and an exchange. In the next chapter we will look at her first purchase with Bitcoin, and examine the underlying transaction and propagation technologies in more detail.((("", startref="BCbasic01")))

43
keys.adoc
View File

@ -44,7 +44,7 @@ of unforgeable digital signatures. Bitcoin uses
elliptic curve addition and multiplication as the basis for its cryptography.
In Bitcoin, we can use public key cryptography to create a key pair that
controls access to bitcoin. The key pair consists of a private key
controls access to bitcoins. The key pair consists of a private key
and a public key derived from the private key. The public key is used to
receive funds, and the private key is used to sign transactions to spend
the funds.
@ -75,13 +75,13 @@ generate a public key (K).
****
((("cryptography", "asymmetric")))((("digital signatures", "asymmetric
cryptography and")))((("asymmetric cryptography")))Why is asymmetric
cryptography used in bitcoin? It's not used to "encrypt" (make secret)
the transactions. Rather, the useful property of asymmetric cryptography
cryptography used in Bitcoin? It's not used to "encrypt" (make secret)
the transactions. Rather, a useful property of asymmetric cryptography
is the ability to generate _digital signatures_. A private key can be
applied to the digital fingerprint of a transaction to produce a
applied to a transaction to produce a
numerical signature. This signature can only be produced by someone with
knowledge of the private key. However, anyone with access to the public
key and the transaction fingerprint can use them to _verify_ the
key and the transaction can use them to _verify_ the
signature. This useful property of asymmetric cryptography makes it
possible for anyone to verify every signature on every transaction,
while ensuring that only the owners of private keys can produce valid
@ -96,7 +96,7 @@ generation")))((("warnings and cautions", "private key protection")))A
private key is simply a number, picked at random. Control
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 bitcoin by proving
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
to giving them control over the bitcoins secured by that key. The private
@ -106,7 +106,7 @@ forever lost, too.
[TIP]
====
A bitcoin private key is just a number. You can pick your private keys
A Bitcoin private key is just a number. You can pick your private keys
randomly using just a coin, pencil, and paper: toss a coin 256 times and
you have the binary digits of a random private key you can use in a
Bitcoin wallet. The public key can then be generated from the private
@ -156,7 +156,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 contain 10^80^ atoms.
====
@ -213,7 +213,7 @@ two dimensions, which makes it difficult to visualize. However, the math
is identical to that of an elliptic curve over real numbers. As an
example, <<ecc-over-F17-math>> shows the same elliptic curve over a much
smaller finite field of prime order 17, showing a pattern of dots on a
grid. The +secp256k1+ bitcoin elliptic curve can be thought of as a much
grid. The +secp256k1+ Bitcoin elliptic curve can be thought of as a much
more complex pattern of dots on a unfathomably large grid.
[[ecc-over-F17-math]]
@ -499,8 +499,8 @@ This brings us back to the problem of receivers like Bob having to give
spenders like Alice a long public key. The shortest version of Bitcoin
public keys known to the developers of early Bitcoin were 65 bytes, the
equivalent of 130 characters when written in hexadecimal. However, Bitcoin
already contained several data structures much larger than 65 bytes
which needed to be securely referenced in other parts of Bitcoin using the
already contains several data structures much larger than 65 bytes
that need to be securely referenced in other parts of Bitcoin using the
smallest amount of data that was secure.
Bitcoin accomplishes that with a _hash function_, a function which takes
@ -819,7 +819,7 @@ in later protocol upgrades.
However, some software still needs to support uncompressed public keys,
such as a wallet application importing private keys from an older
wallet. When the new wallet scans the block chain for old P2PKH outputs
wallet. When the new wallet scans the blockchain for old P2PKH outputs
and inputs, it needs to know whether to scan the 65-byte keys (and
commitments to those keys) or 33-byte keys (and their commitments). Failure
to scan for the correct type can lead to the user not being able to
@ -928,7 +928,7 @@ All addresses based on hash functions are theoretically vulnerable to an
attacker independently finding the same input that produced the hash
function output (commitment). In the case of Bitcoin, if they find the
input the same way the original user did, they'll know the user's private
key and be able to spend that user's bitcoin. The chance of an attacker
key and be able to spend that user's bitcoins. The chance of an attacker
independently generating the input for an existing commitment is
proportional to the strength of the hash algorithm. For a secure
160-bit algorithm like HASH160, the probability is 1-in-2^160^. This is
@ -1414,9 +1414,8 @@ For more information, see <<hd_wallets>>.
[options="header"]
|=======
|Type|Prefix|Description
| Raw | None | 32 bytes
| Hex | None | 64 hexadecimal digits
| WIF | 5 | Base58Check encoding: base58 with version prefix of 128- and 32-bit checksum
| WIF | 5 | Base58Check encoding: base58 with version prefix of 128 and 32-bit checksum
| WIF-compressed | K or L | As above, with added suffix 0x01 before encoding
|=======
@ -1434,9 +1433,7 @@ For more information, see <<hd_wallets>>.
All of these representations are different ways of showing the same
number, the same private key. They look different, but any one format
can easily be converted to any other format. Note that the "raw binary"
is not shown in <<table_4-3>> as any encoding for display here would, by
definition, not be raw binary data.
can easily be converted to any other format.
[[comp_priv]]
===== Compressed private keys
@ -1489,7 +1486,7 @@ prefix). The goal here is to signal to the wallet importing these
private keys whether it must search the blockchain for compressed or
uncompressed public keys and addresses.
If a bitcoin wallet is able to implement compressed public keys, it will
If a Bitcoin wallet is able to implement compressed public keys, it will
use those in all transactions. The private keys in the wallet will be
used to derive the public key points on the curve, which will be
compressed. The compressed public keys will be used to produce Bitcoin
@ -1524,7 +1521,7 @@ checking to see if it matches the desired vanity pattern, repeating
billions of times until a match is found.
Once a vanity address matching the desired pattern is found, the private
key from which it was derived can be used by the owner to spend bitcoin
key from which it was derived can be used by the owner to spend bitcoins
in exactly the same way as any other address. Vanity addresses are no
less or more secure than any other address. They depend on the same
Elliptic Curve Cryptography (ECC) and SHA as any other address. You can
@ -1533,7 +1530,7 @@ pattern than you can any other address.
Eugenia is a children's
charity director operating in the Philippines. Let's say that Eugenia is
organizing a bitcoin fundraising drive and wants to use a vanity Bitcoin
organizing a fundraising drive and wants to use a vanity Bitcoin
address to publicize the fundraising. Eugenia will create a vanity
address that starts with "1Kids" to promote the children's charity
fundraiser. Let's see how this vanity address will be created and what
@ -1639,7 +1636,7 @@ the future unless the above problems are solved.
((("keys and addresses", "advanced forms", "paper wallets")))((("paper
wallets", id="paperw04")))((("wallets", "types of", "paper wallets",
id="Wpaper04")))Paper wallets are bitcoin private keys printed on paper.
id="Wpaper04")))Paper wallets are private keys printed on paper.
Often the paper wallet also includes the corresponding Bitcoin address
for convenience, but this is not necessary because it can be derived
from the private key.
@ -1649,7 +1646,7 @@ from the private key.
Paper wallets are an OBSOLETE technology and are dangerous for most
users. There are many subtle pitfalls involved in generating them, not
least of which the possibility that the generating code is compromised
with a "back door". Hundreds of bitcoin have been stolen this way. Paper
with a "back door". Many bitcoins have been stolen this way. Paper
wallets are shown here for informational purposes only and should not be
used for storing bitcoin. Use a recovery code to backup your
keys, possibly with a hardware signing device to store keys and sign transactions. DO NOT

2
meta/third_edition_changes.asciidoc
View File

@ -28,7 +28,7 @@ Chapter 8::
multisignatures, and threshold signatures.
Chapter 9::
Almost entirely new text about fees, fee market, RBF and CPFP fee
Almost entirely new text about fees, RBF and CPFP fee
bumping, transaction pinning, package relay, and CPFP carve-out.
Chapter 10::

246
mining.adoc
View File

@ -3,10 +3,10 @@
((("mining and consensus", "purpose of")))The word "mining" is somewhat
misleading. By evoking the extraction of precious metals, it focuses our
attention on the reward for mining, the new bitcoin created in each
attention on the reward for mining, the new bitcoins created in each
block. Although mining is incentivized by this reward, the primary
purpose of mining is not the reward or the generation of new coins. If
you view mining only as the process by which coins are created, you are
purpose of mining is not the reward or the generation of new bitcoins. If
you view mining only as the process by which bitcoins are created, you are
mistaking the means (incentives) as the goal of the process. Mining is
the mechanism that underpins the decentralized clearinghouse, by which
transactions are validated and cleared. Mining is one of the inventions that
@ -16,7 +16,7 @@ basis for P2P digital cash.
((("mining and consensus", "decentralized consensus")))((("central
trusted authority")))Mining _secures the Bitcoin system_ and enables the
emergence of network-wide _consensus without a central authority_.
((("fees", "transaction fees")))The reward of newly minted coins and
((("fees", "transaction fees")))The reward of newly minted bitcoins and
transaction fees is an incentive scheme that aligns the actions of
miners with the security of the network, while simultaneously
implementing the monetary supply.
@ -28,17 +28,17 @@ Mining
is one of the mechanisms by which Bitcoin's _consensus security_ is _decentralized_.
====
Miners record new transactions on the global ledger. A
Miners record new transactions on the global blockchain. A
new block, containing transactions that occurred since the last block,
is "mined" every 10 minutes on average, thereby adding those
is _mined_ every 10 minutes on average, thereby adding those
transactions to the blockchain. Transactions that become part of a block
and added to the blockchain are considered "confirmed," which allows the
new owners of bitcoin to know that irrevocable effort was expended
securing the bitcoin they received in those
and added to the blockchain are considered _confirmed_, which allows the
new owners of the bitcoins to know that irrevocable effort was expended
securing the bitcoins they received in those
transactions.
Additionally, transactions in the blockchain have a _topological order_
defined by their position in the block chain. One transaction is
defined by their position in the blockchain. One transaction is
earlier than another if it appears in an earlier block or if it appears
earlier in the same block. In the Bitcoin protocol, a transaction is
only valid if it spends the outputs of transactions that appeared
@ -55,7 +55,7 @@ we'll discuss that idea further in <<single_use_seals>>.
((("fees", "mining rewards")))((("mining and consensus", "mining rewards
and fees")))((("Proof-of-Work algorithm")))((("mining and consensus",
"Proof-of-Work algorithm")))Miners receive two types of rewards in
return for the security provided by mining: new coins created with each
return for the security provided by mining: new bitcoins created with each
new block (called the _subsidy_), and transaction fees from all the transactions included in
the block. To earn this reward, miners compete to satisfy a challenge
based on a cryptographic hash algorithm. The
@ -71,23 +71,23 @@ amount of newly created bitcoin a miner can add to a block decreases
approximately every four years (or precisely every 210,000 blocks). It
started at 50 bitcoins per block in January of 2009 and halved to 25
bitcoins per block in November of 2012. It halved again to 12.5 bitcoins
in July 2016, and again to 6.25 in May 2020. Based on this formula, bitcoin mining rewards decrease
exponentially until approximately the year 2140, when all bitcoin
in July 2016, and again to 6.25 in May 2020. Based on this formula, mining rewards decrease
exponentially until approximately the year 2140, when all bitcoins
will have been issued. After 2140, no new bitcoin
will be issued.
Bitcoin miners also earn fees from transactions. Every transaction may
include a transaction fee, in the form of a surplus of bitcoin 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 bitcoin
Today, the fees usually represent only a small percentage of a
miner's income, with the
vast majority coming from the newly minted bitcoin. However, as the
vast majority coming from the newly minted bitcoins. However, as the
reward decreases over time and the number of transactions per block
increases, a greater proportion of bitcoin mining earnings will come
increases, a greater proportion of mining earnings will come
from fees. Gradually, the mining reward will be dominated by transaction
fees, which will form the primary incentive for miners. After 2140, the
amount of new bitcoin in each block drops to zero and bitcoin mining
amount of new bitcoins in each block drops to zero and mining
will be incentivized only by transaction fees.
In this chapter, we will first examine mining as a monetary supply
@ -104,24 +104,24 @@ consensus.
((("mining and consensus", "bitcoin economics and currency
creation")))((("currency creation")))((("money supply")))((("issuance
rate")))Bitcoin are "minted" during the creation of each block at a
rate")))Bitcoin are minted during the creation of each block at a
fixed and diminishing rate. Each block, generated on average every 10
minutes, contains entirely new bitcoin, created from nothing. Every
minutes, contains entirely new bitcoins, created from nothing. Every
210,000 blocks, or approximately every four years, the currency issuance
rate is decreased by 50%. For the first four years of operation of the
network, each block contained 50 new bitcoin.
network, each block contained 50 new bitcoins.
The first halving occurred at block 210,000. The next expected halving
after publication of this book will occur at block 840,000, which will
probably be produced in April or May of 2024.
The rate of new coins decreases
The rate of new bitcoins decreases
exponentially over 32 of these _halvings_ until block 6,720,000 (mined
approximately in year 2137), when it reaches the minimum currency unit
of 1 satoshi. Finally, after 6.93 million blocks, in approximately 2140,
almost 2,099,999,997,690,000 satoshis, or almost 21 million bitcoin,
will have been issued. Thereafter, blocks will contain no new bitcoin, and
will have been issued. Thereafter, blocks will contain no new bitcoins, and
miners will be rewarded solely through the transaction fees.
<<bitcoin_money_supply>> shows the total bitcoin in circulation over
<<bitcoin_money_supply>> shows the total bitcoins in circulation over
time, as the issuance of currency decreases.
[[bitcoin_money_supply]]
@ -130,8 +130,8 @@ image::images/mbc2_1001.png["BitcoinMoneySupply"]
[NOTE]
====
The maximum number of coins mined is the _upper limit_ of possible
mining rewards for bitcoin. In practice, a miner may intentionally mine
The maximum number of bitcoinss mined is the _upper limit_ of possible
mining rewards for Bitcoin. In practice, a miner may intentionally mine
a block taking less than the full reward. Such blocks have already been
mined and more may be mined in the future, resulting in a lower total
issuance of the currency.
@ -187,7 +187,7 @@ deflation is associated with a collapse in demand because that is the
most obvious example of deflation we have to study. In a fiat currency with the
possibility of unlimited printing, it is very difficult to enter a
deflationary spiral unless there is a complete collapse in demand and an
unwillingness to print money. Deflation in bitcoin is not caused by a
unwillingness to print money. Deflation in Bitcoin is not caused by a
collapse in demand, but by a predictably constrained supply.
The positive aspect of deflation, of course, is that it is the opposite
@ -217,17 +217,17 @@ about who owns what, without having to trust anyone? All traditional
payment systems depend on a trust model that has a central authority
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 ledger that it can trust as the
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.
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 public ledger as everyone else. This
and assemble a copy of the same blockchain as everyone else. This
chapter examines the process by which the Bitcoin network achieves
global consensus without central authority.
((("emergent consensus")))((("mining and consensus", "emergent
consensus")))Satoshi Nakamoto's main invention is the decentralized
consensus")))One of Satoshi Nakamoto's inventions is the decentralized
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
@ -239,7 +239,6 @@ authority or trust, derive from this invention.
Bitcoin's decentralized consensus emerges from the interplay of four
processes that occur independently on nodes across the network:
[role="pagebreak-before"]
- Independent verification of each transaction, by every full node,
based on a comprehensive list of criteria
@ -256,7 +255,7 @@ processes that occur independently on nodes across the network:
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 ledger.
trusted, public, global blockchain.
[[tx_verification]]
=== Independent Verification of Transactions
@ -285,7 +284,7 @@ criteria:
- The transaction weight is low enough to allow it to fit in a block.
- Each output value, as well as the total, must be within the allowed
range of values (zero or more, but less than 21m coins).
range of values (zero or more, but not exceeding 21 million bitcoins).
- Lock time is equal to +INT_MAX+, or lock time and sequence
values are satisfied according to the lock time and BIP68 rules.
@ -319,46 +318,20 @@ _mempool_.
((("mining and consensus", "mining nodes")))((("Bitcoin nodes", "mining
nodes")))Some of the nodes on the Bitcoin network are specialized nodes
called _miners_. Jing is a computer
engineering student in Shanghai, China, who is a Bitcoin miner. Jing
called _miners_. Jing is a
Bitcoin miner; he
earns bitcoin by running a "mining rig," which is a specialized
computer-hardware system designed to mine bitcoin. Jing's specialized
mining hardware is connected to a server running a full node.
Unlike Jing, some miners mine without a full node, as we will see in
<<mining_pools>>. Like every other full node, Jing's node receives and
Like every other full node, Jing's node receives and
propagates unconfirmed transactions on the Bitcoin network. Jing's node,
however, also aggregates these transactions into new blocks.
Jing's node is listening for new blocks, propagated on the Bitcoin
network, as do all nodes. However, the arrival of a new block has
special significance for a mining node. Each round of mining
effectively ends with the propagation of a new block that acts as an
announcement of a winner. To miners, receiving a valid new block means
someone else won. However, the end of one
round is also the beginning of the next round. The new
block is
also the start of the search for the next block.
=== Aggregating Unconfirmed Transactions into Blocks
((("mining and consensus", "aggregating transactions into blocks",
id="MACaggreg10")))((("transactions", "aggregating into blocks",
id="Taggreg10")))((("blocks", "aggregating transactions into",
id="Baggreg10")))((("blocks", "candidate blocks")))((("candidate
blocks")))((("transaction pools")))((("memory pools (mempools)")))After
validating transactions, a Bitcoin node will add them to the mempool
where transactions wait until they can be
included (mined) into a block. Jing's node collects, validates, and
relays new transactions just like any other node. Unlike other nodes,
however, Jing's node will then aggregate these unconfirmed transactions into a
_candidate block_.
Let's follow the blocks that were created during the time Alice made a
purchase from Bob (see <<spending_bitcoin>>). Alice's
transaction was included in a block. For the purpose of
demonstrating the concepts in this chapter, let's assume that block was
mined by Jing's mining system and follow Alice's transaction as it
becomes part of this new block.
purchase from Bob (see <<spending_bitcoin>>). For the purpose of
demonstrating the concepts in this chapter, let's assume the block
containing Alice's transaction was mined by Jing's mining system and
follow Alice's transaction as it becomes part of this new block.
Jing's mining node maintains a local copy of the blockchain. By the time
((("use cases", "buying coffee")))Alice buys something, Jing's
@ -373,7 +346,7 @@ of the search to create the next block.
During the previous several minutes, while Jing's node was searching for a
solution to the previous block, it was also collecting transactions in
preparation for the next block. By now it has collected a few thousand
transactions in the memory pool. Upon receiving the new block and
transactions in its memory pool. Upon receiving the new block and
validating it, Jing's node will also compare it against all the
transactions in the memory pool and remove any that were included in
that block. Whatever transactions remain in the memory pool are
@ -400,13 +373,13 @@ the mining effort.
Jing's node creates the coinbase transaction as a payment to his own
wallet. The total amount of
reward that Jing collects for mining a block is the sum of the coinbase
reward (6.25 new bitcoin in 2023) and the transaction fees from all
reward that Jing collects for mining a block is the sum of the block
subsidy (6.25 new bitcoins in 2023) and the transaction fees from all
the transactions included in the block.
Unlike regular transactions, the coinbase transaction does not consume
(spend) UTXOs as inputs. Instead, it has only one input, called the
_coinbase input_, which creates bitcoin from nothing. The coinbase transaction
_coinbase input_, which implicitly contains the block reward. The coinbase transaction
must have at least one output and may have as many outputs as will fit
in the block. It's common for coinbase transactions in 2023 to have two
outputs: one of these is a zero-value output that uses +OP_RETURN+ to
@ -516,7 +489,7 @@ structure of the coinbase transaction's input.
|Size| Field | Description
| 32 bytes | Transaction Hash | All bits are zero: Not a transaction hash reference
| 4 bytes | Output Index | All bits are ones: 0xFFFFFFFF
| 1&#x2013;9 bytes (VarInt) | Coinbase Data Size | Length of the coinbase data, from 2 to 100 bytes
| 1 byte | Coinbase Data Size | Length of the coinbase data, from 2 to 100 bytes
| Variable | Coinbase Data | Arbitrary data used for extra nonce and mining tags. In v2 blocks; must begin with block height
| 4 bytes | Sequence Number | Set to 0xFFFFFFFF
|=======
@ -582,8 +555,8 @@ nonce field.
[TIP]
====
The protocol upgrades defined in BIPs 34, 66, and 65 occurred in that
order--with BIP66 (strict DER) occuring before BIP65
(+OP_CHECKTIMELOCKVERIFY+)--so Bitcoin developers often list them in
order, with BIP66 (strict DER) occuring before BIP65
(+OP_CHECKTIMELOCKVERIFY+), so Bitcoin developers often list them in
that order rather than sorted numerically.
====
@ -609,7 +582,7 @@ step is to commit to all the transactions using merkle trees. Each
transaction is listed using its witness transaction identifier (_wtxid_)
in topographical order, with 32 0x00 bytes standing in for the wtxid of
the first transaction (the coinbase). As we saw in the <<merkle_trees>>
the last wtxid is hashed with itslef if there are an odd number of wtxids,
the last wtxid is hashed with itself if there are an odd number of wtxids,
creating nodes that each containing the hash of one transaction. The
transaction hashes are then combined, in pairs, creating each level of
the tree, until all the transactions are summarized into one node at the
@ -618,7 +591,7 @@ 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 in none of the transactions in the blook are
This step may be skipped if none of the transactions in the blook 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
@ -675,7 +648,7 @@ result, called a _digest_. The digest is a digital commitment to the
input. For any specific input, the resulting digest will always be the
same and can be easily calculated and
verified by anyone implementing the same hash algorithm.
((("collisions")))The key characteristic of a cryptographic hash
((("collisions")))A key characteristic of a cryptographic hash
algorithm is that it is computationally infeasible to find two different
inputs that produce the same digest (known as a _collision_). As a
corollary, it is also virtually impossible to select an input in such a
@ -683,7 +656,7 @@ way as to produce a desired digest, other than trying random
inputs.
With SHA256, the output is always 256 bits long, regardless of the size
of the input. For example, we will to calculate the SHA256 hash of the
of the input. For example, we will calculate the SHA256 hash of the
phrase, "Hello, World!"
----
@ -692,13 +665,13 @@ d9014c4624844aa5bac314773d6b689ad467fa4e1d1a50a1b8a99d5a95f72ff5 -
----
This
256-bit number (represented in hex) is the _hash_ or _digest_ of the phrase and depends on
256-bit output (represented in hex) is the _hash_ or _digest_ of the phrase and depends on
every part of the phrase. Adding a single letter, punctuation mark, or
any other character will produce a different hash.
The number used as a variable in such a scenario is called a _nonce_.
A variable used in such a scenario is called a _nonce_.
The nonce is used to vary the output of a cryptographic function, in
this case to vary the SHA256 fingerprint of the phrase.
this case to vary the output of the SHA256 commitment to the phrase.
To make a challenge out of this algorithm, let's set a target: find a
phrase that produces a hexadecimal hash that starts with a zero.
@ -733,7 +706,7 @@ first round, the target is 12. Unless you throw double-six, you win. In
the next round the target is 11. Players must throw 10 or less to win,
again an easy task. Let's say a few rounds later the target is down to
5. Now, more than half the dice throws will exceed the target and
therefore be invalid. It takes exponentially more dice throws to win,
therefore be invalid. It takes more dice throws to win
the lower the target gets. Eventually, when the target is 2 (the minimum
possible), only one throw out of every 36, or about 3% of them, will produce a
winning result.
@ -769,7 +742,7 @@ 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
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 how much work was needed
difficulty using statistics and therefore know roughly how much work was needed
to find such a nonce.
[TIP]
@ -937,14 +910,6 @@ persist through the next 2,016 blocks. Therefore, large discrepancies
between hashing power and difficulty might take several 2,016 block
cycles to balance out.
[TIP]
====
The difficulty of mining a bitcoin block is approximately '10 minutes of
processing' for the entire network, based on the time it took to mine
the previous 2,016 blocks, adjusted every 2,016 blocks. This is achieved
by lowering or raising the target.
====
Note that the target is independent of the number of transactions or the
value of transactions. This means that the amount of hashing power and
therefore electricity expended to secure bitcoin is also entirely
@ -975,8 +940,8 @@ a decentralized network, which means that each participant has his or
her own perspective of time. Events on the network do not occur
instantaneously everywhere. Network latency must be factored into the
perspective of each node. Eventually everything is synchronized to
create a common ledger. Bitcoin reaches consensus every 10 minutes about
the state of the ledger as it existed in the _past_.
create a common blockchain. Bitcoin reaches consensus every 10 minutes about
the state of the blockchain as it existed in the _past_.
The timestamps set in block headers are set by the miners. There is a
certain degree of latitude allowed by the consensus rules to account for
@ -1100,7 +1065,7 @@ don't miners write themselves a transaction for a thousand bitcoins
instead of the correct reward? Because every node validates blocks
according to the same rules. An invalid coinbase transaction would make
the entire block invalid, which would result in the block being rejected
and, therefore, that transaction would never become part of the ledger.
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
@ -1124,9 +1089,9 @@ 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
many secondary chains later becomes primary. When sibling blocks occur,
secondary chains later becomes primary. When sibling blocks occur,
they're usually the result of an
almost simultaneous mining of blocks at the same height.
almost simultaneous mining of different blocks at the same height.
When a new block is received, a node will try to add it onto the
existing blockchain. The node will look at the block's "previous block
@ -1136,7 +1101,8 @@ of the time, the parent will be the "tip" of the best chain, meaning
this new block extends the best chain.
Sometimes the new block does not extend
the best chain. In that case, the node will attach the new block to a
the best chain. In that case, the node will attach the new block's
header to a
secondary chain and then compare the work of the secondary chain to the
previous best chain. If the secondary chain is now the best chain, the
node will accordingly _reorganize_ its view of confirmed transactions
@ -1179,7 +1145,7 @@ network hash rate in order to create a chain with equal proof of work.
Shorter times between blocks doesn't result in earlier settlement. Its
only advantage is providing weaker guarantees to people who are willing
to accept those guarantees. For example, if you're willing to accept
three minutes of miners agreeing on the best block chain as sufficient
three minutes of miners agreeing on the best blockchain as sufficient
security, you'd prefer a system with 1-minute blocks, where you could
wait for three blocks, over a system with 10-minute blocks. The shorter
the time between blocks, the more miner work is wasted on accidental
@ -1215,9 +1181,9 @@ a rapid pace.
[[extra_nonce]]
==== The Extra Nonce Solution
((("nonce values")))Since 2012, bitcoin mining has evolved to resolve a
((("nonce values")))Since 2012, mining has evolved to resolve a
fundamental limitation in the structure of the block header. In the
early days of bitcoin, a miner could find a block by iterating through
early days of Bitcoin, a miner could find a block by iterating through
the nonce until the resulting hash was below the target. As difficulty
increased, miners often cycled through all 4 billion values of the nonce
without finding a block. However, this was easily resolved by updating
@ -1226,11 +1192,11 @@ timestamp is part of the header, the change would allow miners to
iterate through the values of the nonce again with different results.
Once mining hardware exceeded 4 GH/sec, however, this approach became
increasingly difficult because the nonce values were exhausted in less
than a second. As ASIC mining equipment started pushing and then
than a second. As ASIC mining equipment started
exceeding the TH/sec hash rate, the mining software needed more space
for nonce values in order to find valid blocks. The timestamp could be
stretched a bit, but moving it too far into the future would cause the
block to become invalid. A new source of "change" was needed in the
block to become invalid. A new source of variation was needed in the
block header.
One solution that was widely implemented was to use the coinbase transaction as a
@ -1262,8 +1228,8 @@ alone (also known as solo miners) don't stand a chance. The likelihood
of them finding a block to offset their electricity and hardware costs
is so low that it represents a gamble, like playing the lottery. Even
the fastest consumer ASIC mining system cannot keep up with commercial
systems that stack tens of thousands of these chips in giant warehouses
near hydroelectric powerstations. Many miners now collaborate to form mining
operations that stack tens of thousands of these systems in giant warehouses
near powerstations. Many miners now collaborate to form mining
pools, pooling their hashing power and sharing the reward among
thousands of participants. By participating in a pool, miners get a
smaller share of the overall reward, but typically get rewarded every
@ -1440,11 +1406,9 @@ include in their blocks.((("",
startref="MAChash10")))((("", startref="MACoverpool10")))
[[consensus_attacks]]
=== Consensus Attacks
=== Hashrate Attacks
((("mining and consensus", "consensus attacks",
id="Cattack10")))((("security", "consensus attacks",
id="Sconsens10")))Bitcoin's consensus mechanism is, at least
Bitcoin's consensus mechanism is, at least
theoretically, vulnerable to attack by miners (or pools) that attempt to
use their hashing power to dishonest or destructive ends. As we saw, the
consensus mechanism depends on having a majority of the miners acting
@ -1453,17 +1417,17 @@ can achieve a significant share of the mining power, they can attack the
consensus mechanism so as to disrupt the security and availability of
the Bitcoin network.
It is important to note that consensus attacks have the greatest effect on future
It is important to note that hashrate attacks have the greatest effect on future
consensus. Confirmed transactions on the best blockchain
become more and more immutable as time passes. While in theory,
a fork can be achieved at any depth, in practice, the computing power
needed to force a very deep fork is immense, making old blocks
very hard to change. Consensus attacks also do not affect the security
very hard to change. Hashrate attacks also do not affect the security
of the private keys and signing algorithms.
One attack scenario against the consensus mechanism is called the _majority
attack_ or _51% attack._ In this scenario a group of miners, controlling a majority
of the total network's hashing power (such as 51%), collude to attack bitcoin.
of the total network's hashing power (such as 51%), collude to attack Bitcoin.
With the ability to mine the majority of the blocks, the attacking
miners can cause deliberate "forks" in the blockchain and double-spend
transactions or execute denial-of-service attacks against specific
@ -1488,7 +1452,7 @@ customer service. This is similar to the practice of coffee shops that
accept credit card payments without a signature for amounts below $25,
because the risk of a credit-card chargeback is low while the cost of
delaying the transaction to obtain a signature is comparatively larger.
In contrast, selling a more expensive item for bitcoin runs the risk of
In contrast, selling a more expensive item for bitcoins runs the risk of
a double-spend attack, where the buyer broadcasts a competing
transaction that spends one of the same inputs (UTXOs) and cancels the payment
to the merchant.
@ -1497,12 +1461,12 @@ to double-spend their own transactions in the new chain, thus undoing
the corresponding transaction in the old chain.
//TODO:distinguish between majority attack and sub-majority "reorg"
//attack. Consensus attack
//attack.
In our example, malicious attacker Mallory goes to ((("use cases",
"retail sales", id="carolten")))Carol's gallery and purchases a
set of beautiful triptych paintings depicting Satoshi Nakamoto as Prometheus.
Carol sells "The Great Fire" paintings for $250,000 in bitcoin to
set of beautiful paintings depicting Satoshi Nakamoto as Prometheus.
Carol sells the paintings for $250,000 in bitcoins to
Mallory. Instead of waiting for six or more confirmations on the
transaction, Carol wraps and hands the paintings to Mallory after only
one confirmation. Mallory works with an accomplice, Paul, who operates a
@ -1513,13 +1477,13 @@ 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,
instead of paying it to Carol, essentially allowing Mallory to keep the
bitcoin. Paul then directs the mining pool to mine an additional block,
bitcoins. Paul then directs the mining pool to mine an additional block,
so as to make the chain containing the double-spend transaction longer
than the original chain (causing a fork below the block containing
Mallory's transaction). When the blockchain fork resolves in favor of
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 bitcoin payment. Throughout all this activity, Paul's mining
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
every transaction or block.((("", startref="carolten")))
@ -1537,7 +1501,7 @@ be convenient and efficient even if the buyer has to wait 24 hours for
delivery, which would correspond to approximately 144 confirmations.
In addition to a double-spend attack, the other scenario for a consensus
attack is to deny service to specific bitcoin participants (specific
attack is to deny service to specific participants (specific
Bitcoin addresses). An attacker with a majority of the mining power can
censor transactions. If they are included in a block
mined by another miner, the attacker can deliberately fork and remine
@ -1553,7 +1517,7 @@ Despite its name, the 51% attack scenario doesn't actually require 51%
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
consensus 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
generation of some blocks with their "honest" mining power. One way to
@ -1561,7 +1525,7 @@ 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
he can invalidate, or the more blocks in the future he can control.
Security research groups have used statistical modeling to claim that
various types of consensus attacks are possible with as little as 30% of
various types of hashrate attacks are possible with as little as 30% of
the hashing power.
The centralization of control caused by mining pools has
@ -1571,26 +1535,24 @@ blocks and also controls which transactions are included. This gives the
pool operator the power to exclude transactions or introduce
double-spend transactions. If such abuse of power is done in a limited
and subtle way, a pool operator could conceivably profit from a
consensus attack without being noticed.
hashrate attack without being noticed.
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
malicious attack aimed at crippling Bitcoin would require enormous
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's consensus by simultaneously
well-funded attacker could attack Bitcoin by simultaneously
amassing mining hardware, compromising pool operators, and attacking
other pools with denial-of-service. All of these scenarios are
theoretically possible.
Undoubtedly, a serious consensus attack would erode confidence in
Undoubtedly, a serious hashrate attack would erode confidence in
Bitcoin in the short term, possibly causing a significant price decline.
However, the Bitcoin network and software are constantly evolving, so
consensus attacks would be met with immediate countermeasures by the
Bitcoin community, making Bitcoin more robust.((("",
startref="Cattack10")))((("", startref="MACattack10")))((("",
startref="Sconsens10")))
attacks would be met with countermeasures by the
Bitcoin community.
[[consensus_changes]]
=== Changing the Consensus Rules
@ -1709,7 +1671,7 @@ fork.
Consensus rules may differ in obvious and explicit ways, in the
validation of transactions or blocks. The rules may also differ in more
subtle ways, in the implementation of the consensus rules as they apply
to bitcoin scripts or cryptographic primitives such as digital
to Bitcoin scripts or cryptographic primitives such as digital
signatures. Finally, the consensus rules may differ in unanticipated
ways because of implicit consensus constraints imposed by system
limitations or implementation details. An example of the latter was seen
@ -1783,7 +1745,7 @@ for decentralized consensus. Just as other innovations in development changed bo
and products of software and created new methodologies, new tools, and
new communities in its wake, consensus software development also
represents a new frontier in computer science. Out of the debates,
experiments, and tribulations of the bitcoin development roadmap, we
experiments, and tribulations of Bitcoin development, we
will see new development tools, practices, methodologies, and
communities emerge.
@ -1793,18 +1755,9 @@ system into two competing systems is seen by many as an unacceptable
risk. As a result, many developers are reluctant to use the hard fork
mechanism to implement upgrades to the consensus rules, unless there is
near-unanimous support from the entire network. Any hard fork proposals
that do not have near-unanimous support are considered too "contentious"
that do not have near-unanimous support are considered too contentious
to attempt without risking a partition of the system.
The issue of hard forks is highly controversial in the bitcoin
development community. Some
developers are opposed to any form of hard fork, seeing it as too risky.
Others see the mechanism of hard fork as an essential tool for upgrading
the consensus rules in a way that avoids "technical debt" and provides a
clean break with the past. Finally, some developers see hard forks as a
mechanism that should be used rarely, with a lot of advance planning and
only under near-unanimous consensus.
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,
and the methods for signaling and activation of
@ -1840,8 +1793,8 @@ nonupgraded nodes out of consensus.
===== Soft forks redefining NOP opcodes
((("opcodes", "redefinition by soft forks")))((("soft forks",
"redefinition of NOP codes")))A number of soft forks have been
implemented in bitcoin, based on the re-interpretation of NOP opcodes.
"redefinition of NOP codes")))Two soft forks have been
implemented in Bitcoin, based on the re-interpretation of NOP opcodes.
Bitcoin Script had ten opcodes reserved for future use, NOP1 through
NOP10. Under the consensus rules, the presence of these opcodes in a
script is interpreted as a null-potent operator, meaning they have no
@ -1904,7 +1857,7 @@ This mechanism was introduced by BIP34.
==== BIP34 Signaling and Activation
((("bitcoin improvement proposals", "Block v2, Height in Coinbase
(BIP34)")))The first implementation, in BIP34, used the block version
(BIP34)")))BIP34 used the block version
field to allow miners to signal readiness for a specific consensus rule
change. Prior to BIP34, the block version was set to "1" by
_convention_ not enforced by _consensus_.
@ -1914,7 +1867,7 @@ BIP34 defined a consensus rule change that required the coinbase field
to BIP34, the coinbase could contain any arbitrary data the miners
chose to include. After activation of BIP34, valid blocks had to
contain a specific block-height at the beginning of the coinbase and be
identified with a version number greater than or equal to "2."
identified with a block version number greater than or equal to "2."
To signal their readiness to enforce the rules of BIP34, miners set the block
version to "2," instead of "1." This did not immediately make version
@ -1948,12 +1901,11 @@ mechanism was used twice more to activate soft forks:
- https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki[BIP66]
Strict DER Encoding of Signatures was activated by BIP34 style
signaling with a block version "3" and invalidating version "2"
blocks.
signaling with a block version "3".
- https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki[BIP65]
+CHECKLOCKTIMEVERIFY+ was activated by BIP34 style signaling with a
block version "4" and invalidating version "3" blocks.
block version "4".
After the activation of BIP65, the signaling and activation mechanism
of BIP34 was retired and replaced with the BIP9 signaling mechanism
@ -2147,7 +2099,7 @@ future attempt to activate a soft fork.
development")))((("development environment", "consensus software
development")))Consensus software 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
By its very nature, Bitcoin sets a very high bar on coordination and
consensus for changes. As a decentralized system, it has no "authority"
that can impose its will on the participants of the network. Power is
diffused between multiple constituencies such as miners, protocol

29
network.adoc
View File

@ -29,7 +29,7 @@ consensus network.
((("Bitcoin network", "defined")))The term "Bitcoin network" refers to
the collection of nodes running the Bitcoin P2P protocol. In addition to
the Bitcoin P2P protocol, there are other protocols that
are used for mining and lightweight or mobile wallets. These additional
are used for mining and lightweight wallets. These additional
protocols are provided by gateway routing servers that access the
Bitcoin network using the Bitcoin P2P protocol and then extend that
network to nodes running other protocols. For example, Stratum servers
@ -48,9 +48,8 @@ supporting. A Bitcoin full node validates blocks and may contain other
functions, such as routing, mining, and wallet services.
Some nodes, called _archival full nodes_, also maintain a
complete and up-to-date copy of the blockchain. Full nodes can
autonomously and authoritatively verify any transaction without external
reference. Those nodes can
complete and up-to-date copy of the blockchain.
Those nodes can
serve data to clients that store
only a subset of the blockchain and partly verify transactions using a method
called _simplified payment verification_, or SPV. ((("lightweight
@ -89,21 +88,13 @@ mining or wallet functions. These nodes act as network edge routers,
allowing various other services (exchanges, wallets, block explorers,
merchant payment processing) to be built on top.
The extended Bitcoin network includes the network running the Bitcoin
P2P protocol, described earlier, as well as nodes running specialized
protocols. Attached to the main Bitcoin P2P network are a number of pool
servers and protocol gateways that connect nodes running other
protocols. These other protocol nodes are mostly pool mining nodes (see
<<mining>>) and lightweight wallet clients, which do not carry a full
copy of the blockchain.
=== Compact Block Relay
When a miner finds a new block, they announce it to the Bitcoin network
(which includes other miners). The miner who found that block can start
building on top of it immediately; all other miners who haven't learned
about the block yet will continue building on top of the previous block
until they do learn about it (and, ideally, they also validate it).
until they do learn about it.
If, before they learn about the new block, one of those other
miners creates a block, their block will be in competition with the
@ -476,7 +467,7 @@ 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
how many blocks it has in its own blockchain. Peered nodes will exchange
a +getheaders+ message that contains the hash (fingerprint) of the top
a +getheaders+ message that contains the hash of the top
block on their local blockchain. One of the peers will be able to
identify the received hash as belonging to a block that is not at the
top, but rather belongs to an older block, thus deducing that its own
@ -1197,11 +1188,9 @@ pools")))((("memory pools (mempools)")))Almost every node on the Bitcoin
network maintains a temporary list of unconfirmed transactions called
the _memory pool_ (_mempool_). Nodes use this pool
to keep track of transactions that are known to the network but are not
yet included in the blockchain. For example, a wallet node will use the
mempool to track incoming payments to the user's wallet that
have been received on the network but are not yet confirmed.
yet included in the blockchain, called _unconfirmed transactions_.
As transactions are received and verified, they are added to the
As unconfirmed transactions are received and verified, they are added to the
mempool and relayed to the neighboring nodes to propagate on
the network.
@ -1236,9 +1225,7 @@ Whereas the mempool and orphan pools represent a single node's local
perspective and might vary significantly from node to node depending
upon when the node was started or restarted, the UTXO database represents
the emergent consensus of the network and therefore will not usually
vary between nodes. Furthermore, the mempool and orphan pools only
contain unconfirmed transactions, while the UTXO database only contains
confirmed outputs.
vary between nodes.
Now that we have a understanding of many of the data types and
structures used by nodes and clients to send data across the Bitcoin

163
overview.adoc
View File

@ -8,9 +8,9 @@ payment systems, does not require trust in third parties. Instead of a central
trusted authority, in Bitcoin, each user can use software running on
their own computer to verify the correct operation of every
aspect of the Bitcoin system.
In this chapter, we will examine bitcoin from a high level by tracking a
In this chapter, we will examine Bitcoin from a high level by tracking a
single transaction through the Bitcoin system and watch as it
is recorded on the blockchain, the distributed ledger of all
is recorded on the blockchain, the distributed journal of all
transactions. Subsequent chapters will delve into the technology behind
transactions, the network, and mining.
@ -20,7 +20,7 @@ In the overview diagram shown in <<bitcoin-overview>>, we see that the
Bitcoin system consists of users with wallets containing keys,
transactions that are propagated across the network, and miners who
produce (through competitive computation) the consensus blockchain,
which is the authoritative ledger of all transactions.
which is the authoritative journal of all transactions.
((("blockchain explorer sites")))Each example in this chapter is based
on an actual transaction made on the Bitcoin network, simulating the
@ -54,7 +54,7 @@ it in detail.
====
Searching information on a block explorer may disclose to its operator
that you're interested in that information, allowing them to associate
it with your IP address, browser fingerprint, past searches, or other
it with your IP address, browser details, past searches, or other
identifiable information. If you look up the transactions in this book,
the operator of the block explorer might guess that you're learning
about Bitcoin, which shouldn't be a problem. But if you look up your
@ -69,10 +69,10 @@ Alice, introduced in the previous chapter, is a new user who has just
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 retail 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
Bitcoin option to its website. The prices at Bob's store are listed in
the local currency (US dollars), but at checkout, customers have the
option of paying in either dollars or bitcoin.
@ -88,7 +88,7 @@ _invoice_ (<<invoice-QR>>).
Unlike a QR code that simply contains a destination Bitcoin address, this
invoice is a QR-encoded URI that contains a destination address,
a payment amount, and a description.
This allows a bitcoin wallet application to prefill the
This allows a Bitcoin wallet application to prefill the
information used to send the payment while showing a human-readable
description to the user. You can scan the QR code with a bitcoin wallet
application to see what Alice would see.
@ -161,7 +161,7 @@ can spend that amount in subsequent transactions.
=== Bitcoin Transactions
((("transactions", "defined")))In simple terms, a transaction tells the
network that the owner of some bitcoin value has authorized the transfer
network that the owner of certain bitcoins has authorized the transfer
of that value to another owner. The new owner can now spend the bitcoin
by creating another transaction that authorizes the transfer to another
owner, and so on, in a chain of ownership.
@ -170,21 +170,21 @@ owner, and so on, in a chain of ownership.
((("transactions", "overview of", id="Tover02")))((("outputs and
inputs", "basics of")))Transactions are like lines in a double-entry
bookkeeping ledger. Each transaction contains one or more "inputs,"
bookkeeping ledger. Each transaction contains one or more _inputs_,
which spend funds. On the other side of
the transaction, there are one or more "outputs," which receive funds.
the transaction, there are one or more _outputs_, which receive funds.
((("fees", "transaction fees")))The inputs
and outputs do not necessarily add up to the same
amount. Instead, outputs add up to slightly less than inputs and the
difference represents an implied _transaction fee_, which is a small
payment collected by the miner who includes the transaction in the
ledger. A bitcoin transaction is shown as a bookkeeping ledger entry in
blockchain. A Bitcoin transaction is shown as a bookkeeping ledger entry in
<<transaction-double-entry>>.
The transaction also contains proof of ownership for each amount of
bitcoin (inputs) whose value is being spent, in the form of a digital
bitcoins (inputs) whose value is being spent, in the form of a digital
signature from the owner, which can be independently validated by
anyone. ((("spending bitcoin", "defined")))In bitcoin terms, "spending"
anyone. ((("spending bitcoin", "defined")))In Bitcoin terms, spending
is signing a transaction that transfers value from a previous
transaction over to a new owner identified by a Bitcoin address.
@ -196,7 +196,7 @@ image::images/mbc2_0203.png["Transaction Double-Entry"]
((("chain of transactions")))Alice's payment to Bob's Store uses a
previous transaction's output as its input. In the previous chapter,
Alice received bitcoin from her friend Joe in return for cash.
Alice received bitcoins from her friend Joe in return for cash.
We've labeled that as _Transaction 1_ (Tx1) in <<transaction-chain>>.
Tx1 sent 0.001 bitcoins (100,000 satoshis) to an output locked by
@ -260,7 +260,7 @@ This is because transaction inputs,
like currency notes, cannot be partly spent. If you purchase a $5 US dollar
item in a store but use a $20 dollar bill to pay for the item, you
expect to receive $15 dollars in change. The same concept applies to
bitcoin transaction inputs. If you purchased an item that costs 5
Bitcoin transaction inputs. If you purchased an item that costs 5
bitcoins but only had an input worth 20 bitcoins to use, you would send one
output of 5 bitcoins to the store owner and one output of 15 bitcoins back
to yourself as change (not counting your transaction fee).
@ -298,8 +298,8 @@ the desired payment plus transaction fees, the wallet will need to
generate some change. This is very similar to how people handle cash. If
you always use the largest bill in your pocket, you will end up with a
pocket full of loose change. If you only use the loose change, you'll
always have only big bills. People subconsciously find a balance between
these two extremes, and bitcoin wallet developers strive to program this
often have only big bills. People subconsciously find a balance between
these two extremes, and Bitcoin wallet developers strive to program this
balance.
==== Common Transaction Forms
@ -322,8 +322,8 @@ generated by wallets and businesses to clean up lots of smaller amounts.
.Consolidation transaction aggregating funds
image::images/mbc2_0206.png["Aggregating Transaction"]
Finally, another transaction form that is seen often on the bitcoin
ledger is _payment batching_ that pays to multiple outputs
Finally, another transaction form that is seen often on the
blockchain is _payment batching_ that pays to multiple outputs
representing multiple recipients (<<transaction-distributing>>).
This type of transaction is sometimes used by commercial entities to
distribute funds, such as when processing payroll payments to multiple
@ -394,8 +394,8 @@ Finally, for the transaction to be processed by the network in a 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
miner as a fee for validating and including the transaction in a block
to be recorded on the blockchain.
miner as a fee for including the transaction in a block
that gets recorded on the blockchain.
[[transaction-alice-url]]
[TIP]
@ -403,7 +403,7 @@ to be recorded on the blockchain.
View the https://blockstream.info/tx/466200308696215bbc949d5141a49a4138ecdfdfaa2a8029c1f9bcecd1f96177[transaction from Alice to Bob's Store].
====
==== Adding the Transaction to the Ledger
==== Adding the Transaction to the Blockchain
The transaction created by Alice's wallet application
contains everything necessary to confirm ownership of the funds and
@ -417,7 +417,7 @@ blocks are added.
===== Transmitting the transaction
((("propagation", "process of")))Because the transaction contains all
the information necessary to process, it does not matter how or where it
the information necessary for it to be processed, it does not matter how or where it
is transmitted to the Bitcoin network. The Bitcoin network is a
peer-to-peer network, with each Bitcoin peer participating by
connecting to several other Bitcoin peers. The purpose of the Bitcoin
@ -437,8 +437,8 @@ Alice's wallet application can send the new
transaction to any Bitcoin node over any type of
connection: wired, WiFi, mobile, etc. It can also send the transaction
to another program (such as a block explorer) that will relay it to a
node. Her bitcoin wallet does not have
to be connected to Bob's bitcoin wallet directly and she does not have
node. Her Bitcoin wallet does not have
to be connected to Bob's Bitcoin wallet directly and she does not have
to use the internet connection offered by Bob, though both those
options are possible, too. ((("propagation", "flooding
technique")))((("flooding technique")))Any Bitcoin node that receives a
@ -450,7 +450,7 @@ few seconds.
===== Bob's view
If Bob's bitcoin wallet application is directly connected to Alice's
If Bob's Bitcoin wallet application is directly connected to Alice's
wallet application, Bob's wallet application might be the first to
receive the transaction. However, even if Alice's wallet sends the
transaction through other nodes, it will reach Bob's wallet within a few
@ -475,7 +475,7 @@ Transactions are bundled into _blocks_. Blocks have a very small header
that must be formed in a very specific way, requiring an enormous
amount of computation to get right--but only a small amount of
computation to verify as correct.
The mining process serves two purposes in bitcoin:
The mining process serves two purposes in Bitcoin:
* ((("mining and consensus", "consensus rules", "security provided
by")))((("consensus", see="mining and consensus")))Miners can only
@ -485,7 +485,7 @@ only include valid transactions in their blocks and the blocks they
build upon. This allows users to optionally make a trust-based
assumption that any transaction in a block is a valid transaction.
* Mining currently creates new bitcoin's in each block, almost like a central bank
* Mining currently creates new bitcoins in each block, almost like a central bank
printing new money. The amount of bitcoin created per block is limited
and diminishes with time, following a fixed issuance schedule.
@ -493,25 +493,25 @@ and diminishes with time, following a fixed issuance schedule.
Mining achieves a fine balance between cost and reward. Mining uses
electricity to solve a computational problem. A successful miner will
collect a _reward_ in the form of new bitcoins and transaction fees.
However, the reward will only be collected if the miner has correctly
validated all the transactions, to the satisfaction of the rules of
_consensus_. This delicate balance provides security for Bitcoin without
a central authority.
However, the reward will only be collected if the miner has only
included valid transactions, with the Bitcoin Protocol's rules for
_consensus_ dermining what is valid. This delicate balance provides
security for Bitcoin without a central authority.
Mining is designed to be a decentralized lottery. Each miner can create
their own lottery ticket by creating a _block template_ that includes
their own lottery ticket by creating a _candidate block_ that includes
the new transactions they want to mine plus some additional data fields.
The miner inputs their template into a specially-designed algorithm that
The miner inputs their candidate into a specially-designed algorithm that
scrambles (or "hashes") the data, producing output that looks nothing
like the input data. This _hash_ function will always produce the same
output for the same input--but nobody can predict what the output will
look like for a new input, even if it is only slighly different from a
previous input. If the output of hash function matches a template
determined by the Bitcoin protocol, the miner wins the lottery and
Bitcoin users will accept the block template with its transactions as a
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 block template and tries again. As of this
writing, the number of block templates miners need to try before finding
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
many times the hash function needs to be run.
@ -523,77 +523,35 @@ verification process is able to probabalistically prove the work was
done, so the data necessary to generate that proof--in this case, the
block--is called Proof-of-Work (PoW).
((("mining and consensus", "mining farms and pools")))
((("use cases", "mining for
bitcoin")))Jing is an entrepreneur in Shanghai. Jing runs a _mining farm_,
which is a business that runs thousands of specialized mining computers,
competing for the block reward. Jing's mining
computers compete against thousands of similar systems in the global
lottery to create the next block.
Jing started mining in 2010 using a very fast desktop computer to find a
suitable Proof-of-Work for new blocks. As more miners started joining
the Bitcoin network, the Bitcoin protocol automatically increased the
difficulty of finding a new block.
Soon, Jing and other miners upgraded to more specialized hardware, such
as high-end dedicated graphical processing units (GPUs)
used in gaming desktops. At the time of this writing,
the difficulty is so high that it is profitable only to mine with
((("application-specific integrated circuits
(ASIC)")))application-specific integrated circuits (ASIC), essentially
hundreds of mining algorithms printed in hardware, running in parallel
on a single silicon chip. ((("mining pools", "defined")))Jing's company
also participates in a _mining pool_, which much like a lottery pool
allows several participants to share their efforts and rewards. Jing's
company now runs a warehouse containing thousands of ASIC miners to
mine for bitcoins 24 hours a day. The company pays its electricity costs
by selling the bitcoins it is able to generate from mining, creating some
income from the profits.
[[confirmation_score]]
=== Mining Transactions in Blocks
((("blocks", "mining transactions in")))New transactions are constantly
flowing into the network from user wallets and other applications. As
these are seen by the Bitcoin network nodes, they get added to a
temporary pool of unverified transactions maintained by each node. As
miners construct a new _candidate block_, they add unverified transactions from this
pool to the candidate block and then attempt to prove the validity of that
candidate block, with the mining algorithm (Proof-of-Work). The process of mining
is explained in detail in <<mining>>.
Transactions are added to the new block, prioritized by the highest fee rate
transactions first and a few other criteria. Each miner starts the
process of mining a new candidate block of transactions as soon as he receives the
process of mining a new candidate block of transactions as soon as they receive the
previous block from the network, knowing that some other miner won that
iteration of the lottery. He immediately creates a new candidate block
with a commitment to the previous block, fills it with transactions, and starts
iteration of the lottery. They immediately create a new candidate block
with a commitment to the previous block, fill it with transactions, and start
calculating the Proof-of-Work for the candidate block. Each miner includes a
special transaction in his candidate block, one that pays his own Bitcoin address
special transaction in their candidate blocks, one that pays their own Bitcoin address
the block reward plus the sum of
transaction fees from all the transactions included in the candidate block. If he
finds a solution that makes the candidate into a valid block, he receives this reward
transaction fees from all the transactions included in the candidate block. If they
finds a solution that makes the candidate into a valid block, they receives this reward
after his successful block is added to the global blockchain and the
reward transaction he included becomes spendable. ((("mining pools",
"operation of")))Jing, who participates in a mining pool, has set up his
"operation of")))Miners who participates in a mining pool have set up their
software to create candidate blocks that assign the reward to a pool address.
From there, a share of the reward is distributed to Jing and other
miners in proportion to the amount of work they contributed in the last
round.
From there, a share of the reward is distributed to members of the pool
miners in proportion to the amount of work they contributed.
((("candidate blocks")))((("blocks", "candidate blocks")))Alice's
transaction was picked up by the network and included in the pool of
unverified transactions. Once validated by a full node, it was
included in a block template generated by Jing's
mining pool. All the miners participating in that mining pool
immediately start trying to generate a Proof-of-Work for the block template.
included in a candidate block.
Approximately five minutes after the transaction was first transmitted
by Alice's wallet, one of Jing's ASIC miners found a solution for the
block and announced it to the network. After each other miner
by Alice's wallet, a miner finds a solution for the
block and announces it to the network. After each other miner
validates the winning block, they start a new lottery to generate the next
block.
Jing's winning block containing Alice's transaction became part of the
The winning block containing Alice's transaction became part of the
blockchain. The block containing Alice's transaction is counted as one
_confirmation_ of that transaction. After the block containing Alice's
transaction has propagated through the network, creating an alternative
@ -612,7 +570,7 @@ Alice paying miners a share of the money she previously paid Bob. This
dishonest behavior will require they expend the effort required to
create two new blocks. Instead, miners who behave honestly can create a
single new block and and receive all of the fees from the transactions
they include in it, plus the block reward. Normally, the high cost of
they include in it, plus the block subsidy. Normally, the high cost of
dishonestly creating two blocks for a small additional payment is much
less profitable than honestly creating a new block, making it unlikely
that a confirmed transaction will be deliberately changed. For Bob, this
@ -626,7 +584,8 @@ https://blockstream.info/block/000000000000000000027d39da52dd790d98f85895b02e764
====
((("confirmations", "role in transactions")))Approximately 19 minutes
after Jing's block, a new block is mined by another miner. Because this
after the block containing Alice's transaction is broadcast, a new block
is mined by another miner. Because this
new block is built on top of the block that contained Alice's
transaction (giving Alice's transaction two confirmations) Alice's
transaction can now only be changed if two alternative blocks are
@ -659,24 +618,24 @@ image::images/mbc2_0209.png["Alice's transaction included in a block"]
Now that Alice's
transaction has been embedded in the blockchain as part of a block, it
is part of the distributed ledger of Bitcoin and visible to all Bitcoin
applications. Each bitcoin full node can independently verify the
is visible to all Bitcoin
applications. Each Bitcoin full node can independently verify the
transaction as valid and spendable. Full nodes validate every transfer
of the funds from the moment the bitcoin were first generated in
of the funds from the moment the bitcoins were first generated in
a block through each subsequent transaction until they reach
Bob's address. Lightweight clients can do what is called a simplified
payment verification (see <<spv_nodes>>) by confirming that the
Bob's address. Lightweight clients can partially verify payments
by confirming that the
transaction is in the blockchain and has several blocks mined after it,
thus providing assurance that the miners expended significant effort
committing to it.
committing to it (see <<spv_nodes>>).
Bob can now spend the output from this and other transactions. For
example, Bob can pay a contractor or supplier by transferring value from
Alice's podcast payment to these new owners.
As Bob spends the payments received from Alice and other customers, he
extends the chain of transactions. Let's assume that Bob pays his web
designer Gopesh((("use cases", "offshore contract services"))) in
Bangalore for a new website page. Now the chain of transactions will
designer Gopesh
for a new website page. Now the chain of transactions will
look like <<block-alice2>>.
[[block-alice2]]

15
preface.asciidoc
View File

@ -9,7 +9,7 @@ Two years later, after creating a number of small startups to explore various Bi
=== Intended Audience
((("intended audience")))This book is mostly intended for coders. If you can use a programming language, this book will teach you how cryptographic currencies work, how to use them, and how to develop software that works with them. The first few chapters are also suitable as an in-depth introduction to Bitcoin for noncoders—those trying to understand the inner workings of bitcoin and cryptocurrencies.
((("intended audience")))This book is mostly intended for coders. If you can use a programming language, this book will teach you how cryptographic currencies work, how to use them, and how to develop software that works with them. The first few chapters are also suitable as an in-depth introduction to Bitcoin for noncoders—those trying to understand the inner workings of Bitcoin and cryptocurrencies.
=== Why Are There Bugs on the Cover?
@ -55,13 +55,13 @@ All the code snippets can be replicated on most operating systems with a minimal
Some of the code snippets and code output have been reformatted for print. In all such cases, the lines have been split by a backslash (\) character, followed by a newline character. When transcribing the examples, remove those two characters and join the lines again and you should see identical results as shown in the example.
All the code snippets use real values and calculations where possible, so that you can build from example to example and see the same results in any code you write to calculate the same values. For example, many of the private keys and corresponding public keys and addresses are real. The sample transactions, blocks, and blockchain references are all part of the actual Bitcoin blockchain, so you can review them on any Bitcoin system.
All the code snippets use real values and calculations where possible, so that you can build from example to example and see the same results in any code you write to calculate the same values.
=== Using Code Examples
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 a CD-ROM of 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.
((("attribution")))We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by Andreas M. Antonopoulos and David A. Harding (O’Reilly). Copyright 2023 Andreas M. Antonopoulos, 978-1-491-95438-6.”
((("attribution")))We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by Andreas M. Antonopoulos and David A. Harding (O’Reilly). Copyright 2023, ISBN 978-1-491-95438-6.”
((("open source licenses")))Some editions of this book are offered under an open source license, such as https://creativecommons.org/licenses/by-nc/4.0/[CC-BY-NC], in which case the terms of that license apply.
@ -119,7 +119,6 @@ Follow us on Twitter: link:$$https://twitter.com/oreillymedia$$[]
Watch us on YouTube: link:$$https://www.youtube.com/oreillymedia$$[]
[role="pagebreak-before"]
=== Contacting the Authors
You can contact Andreas M. Antonopoulos on his personal site:
@ -147,9 +146,9 @@ link:$$https://dtrt.org/$$[]
_By Andreas M. Antonopoulos_
((("acknowledgments", id="acknowledge0")))This book represents the efforts and contributions of many people. I am grateful for all the help I received from friends, colleagues, and even complete strangers, who joined me in this effort to write the definitive technical book on cryptocurrencies and bitcoin.
((("acknowledgments", id="acknowledge0")))This book represents the efforts and contributions of many people. I am grateful for all the help I received from friends, colleagues, and even complete strangers, who joined me in this effort to write the definitive technical book on cryptocurrencies and Bitcoin.
It is impossible to make a distinction between the bitcoin technology and the bitcoin community, and this book is as much a product of that community as it is a book on the technology. My work on this book was encouraged, cheered on, supported, and rewarded by the entire bitcoin community from the very beginning until the very end. More than anything, this book has allowed me to be part of a wonderful community for two years and I can't thank you enough for accepting me into this community. There are far too many people to mention by name—people I've met at conferences, events, seminars, meetups, pizza gatherings, and small private gatherings, as well as many who communicated with me by Twitter, on reddit, on bitcointalk.org, and on GitHub who have had an impact on this book. Every idea, analogy, question, answer, and explanation you find in this book was at some point inspired, tested, or improved through my interactions with the community. Thank you all for your support; without you this book would not have happened. I am forever grateful.
It is impossible to make a distinction between the Bitcoin technology and the Bitcoin community, and this book is as much a product of that community as it is a book on the technology. My work on this book was encouraged, cheered on, supported, and rewarded by the entire Bitcoin community from the very beginning until the very end. More than anything, this book has allowed me to be part of a wonderful community for two years and I can't thank you enough for accepting me into this community. There are far too many people to mention by name—people I've met at conferences, events, seminars, meetups, pizza gatherings, and small private gatherings, as well as many who communicated with me by Twitter, on reddit, on bitcointalk.org, and on GitHub who have had an impact on this book. Every idea, analogy, question, answer, and explanation you find in this book was at some point inspired, tested, or improved through my interactions with the community. Thank you all for your support; without you this book would not have happened. I am forever grateful.
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.
@ -157,7 +156,7 @@ Thanks also to those who supported me when I submitted my book proposal to O'Rei
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.
@ -201,7 +200,7 @@ of you often and know that my contributions to this book would not have
been possible without all that you've done for me.
[[github_contrib]]
==== Early Release Draft (GitHub Contributions)
=== Early Release Draft (GitHub Contributions)
Many contributors offered comments, corrections, and additions to the early-release draft on GitHub. Thank you all for your contributions to this book.

22
security.adoc
View File

@ -50,7 +50,7 @@ It does not reveal any private information, such as the
identities of the parties, and cannot be used to authorize additional
payments. Therefore, a Bitcoin payment network does not need to be
encrypted or protected from eavesdropping. In fact, you can broadcast
bitcoin transactions over an open public channel, such as unsecured WiFi
Bitcoin transactions over an open public channel, such as unsecured WiFi
or Bluetooth, with no loss of security.
Bitcoin's decentralized security model puts a lot of power in the hands
@ -63,7 +63,7 @@ able to adequately secure their keys and get hacked, one by one.
==== Developing Bitcoin Systems Securely
((("decentralized systems", "bitcoin as")))The most important principle
((("decentralized systems", "bitcoin as")))A critical principle
for Bitcoin developers is decentralization. Most developers will be
familiar with centralized security models and might be tempted to apply
these models to their Bitcoin applications, with disastrous results.
@ -114,7 +114,7 @@ many servers layered in concentric circles of diminishing trust.
((("mining and consensus", "security and consensus")))Bitcoin security
architecture is different. In Bitcoin, the consensus system creates a
trusted public ledger that is completely decentralized. A correctly
trusted blockchain that is completely decentralized. A correctly
validated blockchain uses the genesis block as the root of trust,
building a chain of trust up to the current block. Bitcoin systems can
and should use the blockchain as their root of trust. When designing a
@ -140,7 +140,7 @@ The numerous examples of hacked Bitcoin exchanges serve to underscore
this point because their security architecture and design fails even
under the most casual scrutiny. These centralized implementations had
invested trust explicitly in numerous components outside the Bitcoin
blockchain, such as hot wallets, centralized ledger databases,
blockchain, such as hot wallets, centralized databases,
vulnerable encryption keys, and similar schemes.((("",
startref="Sprinc11")))
@ -197,7 +197,7 @@ we will examine various best practices for practical user security.
wallets")))((("wallets", "types of", "paper wallets")))((("paper
wallets", see="also wallets")))Because most users are far more
comfortable with physical security than information security, a very
effective method for protecting bitcoin is to convert them into physical
effective method for protecting bitcoins is to convert them into physical
form. Bitcoin keys, and the seeds used to create them, are nothing more than long numbers. This means that
they can be stored in a physical form, such as printed on paper or
etched on a metal plate. Securing the keys then becomes as simple as
@ -219,9 +219,9 @@ form of tamper-proof hardware signing devices. Unlike a smartphone or desktop
computer, a Bitcoin hardware signing device only needs to hold keys and
use them to generate signatures. Without general-purpose software to
compromise and
with limited interfaces, hardware signing devices can deliver an almost
foolproof level of security to nonexpert users. Hardware
signing devices may become the predominant method of bitcoin storage.
with limited interfaces, hardware signing devices can deliver strong
security to nonexpert users. Hardware
signing devices may become the predominant method of storing bitcoins.
==== Ensuring Your Access
@ -235,7 +235,7 @@ project lost almost 7,000 bitcoin. In their effort to prevent theft, the
owners had implemented a complex series of encrypted backups. In the end
they accidentally lost the encryption keys, making the backups worthless
and losing a fortune. Like hiding money by burying it in the desert, if
you secure your bitcoins too well you might not be able to find it again.
you secure your bitcoins too well you might not be able to find them again.
[WARNING]
====
@ -253,7 +253,7 @@ more details, see <<ch05_wallets>>.
Would you carry your entire net worth in cash in your wallet? Most
people would consider that reckless, yet Bitcoin users often keep all
their bitcoin using a single wallet application. Instead, users should spread the risk
their bitcoins using a single wallet application. Instead, users should spread the risk
among multiple and diverse Bitcoin applications. Prudent users will keep only
a small fraction, perhaps less than 5%, of their bitcoins in an online or
mobile wallet as "pocket change." The rest should be split between a few
@ -264,7 +264,7 @@ storage).
((("multisig addresses")))((("addresses", "multisig
addresses")))Whenever a company or individual stores large amounts of
bitcoin, they should consider using a multisignature Bitcoin address.
bitcoins, they should consider using a multisignature Bitcoin address.
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.

51
signatures.adoc
View File

@ -111,7 +111,7 @@ that is appended to the signature. Every signature has either an
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) different parts of the
flags, each signature signing (committing) to different parts of the
transaction.
Remember, each input may contain one or more signatures. As
@ -167,14 +167,6 @@ By including the
+SIGHASH+ flag itself, the signature commits the
+SIGHASH+ type as well, so it can't be changed (e.g., by a miner).
[NOTE]
====
All +SIGHASH+ types sign the transaction lock time field (see
<<lock_time>>). In addition, the +SIGHASH+ type
itself is appended to the transaction before it is signed, so that it
can't be modified once signed.
====
In
<<serialization_of_signatures_der>>, we will see that the last part of the
DER-encoded signature was +01+, which is the +SIGHASH_ALL+ flag for ECDSA signatures. This
@ -282,14 +274,14 @@ Linearity::
variables and then running a function on that sum will produce the
same value as running the function on each of the variables
independently and then summing together the results, e.g.
+f(x + y + z) = f(x) + f(y) + f(z)+; this property is called
+f(x + y + z) == f(x) + f(y) + f(z)+; this property is called
_additivity_. The second property is that multiplying a variable and
then running a function on that product will produce the same value as
running the function on the variable and then multiplying it by the
same amount, e.g. +f(a * x) = a * f(x)+; this property is called
same amount, e.g. +f(a * x) == a * f(x)+; this property is called
_homogeneity of degree 1_.
+
In cryptographic operations, some of the functions may be private (such
In cryptographic operations, some functions may be private (such
as functions involving private keys or secret nonces), so being able
to get the same result whether performing an operation inside or
outside of a function makes it easy for multiple parties to coordinate
@ -366,7 +358,7 @@ generator +G=5+ to get her public key +xG=15+. She gives Bob +15+.
2. Bob chooses +e=11+ and gives it to Alice.
3. Alice generates +s = 40 = 7 + 11*3+. She gives Bob +40+.
3. Alice generates +s = 40 = 7 + 11 * 3+. She gives Bob +40+.
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
@ -406,21 +398,21 @@ identity protocol that make it secure:
commits to her public nonce. Consider what could happen if someone
who didn't know +x+ wanted to impersonate Alice, and Bob accidentally
gave them the challenge scalar +e+ before they told him the public
nonce +kG+. This allows them to change parameters on both sides of
nonce +kG+. This allows the impersonator to change parameters on both sides of
the equation that Bob will use for verification, +sG == kG + exG+,
specifically they can change both +sG+ and +kG+. Think about a
simplified form of that expression: x = y + a. If you can change both
+x+ and +y+, you can cancel out +a+ using +x = (x - a) + a+. Any
+x+ and +y+, you can cancel out +a+ using +x' = (x - a) + a+. Any
value you choose for +x+ will now satisfy the equation. For the
actual equation they simply choose a random number for +s+, generate
+sG+, and then use EC subtraction to select a +kG+ that equals +kG =
actual equation the impersonator simply chooses a random number for +s+, generates
+sG+, and then uses EC subtraction to select a +kG+ that equals +kG =
sG - exG+. They give Bob their calculated +kG+ and later their random
+sG+, and Bob thinks that's valid because +sG == (sG - exG) + exG+.
This explains why the order of operations in the protocol is
essential: Bob must only give Alice the challenge scalar after Alice
has committed to her public nonce.
The interactive identity protocol described matches part of Claus
The interactive identity protocol described here matches part of Claus
Schnorr's original description, but it lacks two essential features we
need for the decentralized Bitcoin network. The first of these is that
it relies on Bob waiting for Alice to commit to her public nonce and
@ -475,8 +467,9 @@ concern. In BIP32 key derivation, as described in
takes a public key and adds to it a non-secret value to produce a
derived public key. That means it's also possible to add that
non-secret value to a valid signature for one key to produce a signature
for a related key that's valid but which wasn't authorized by someone
possessing the private key. To protect BIP32 unhardened derivation and
for a related key. That related signature is valid but it wasn't
authorized by the person possessing the private key, which is a major
security failure. To protect BIP32 unhardened derivation and
also support several protocols people wanted to build on top of schnorr
signatures, Bitcoin's version of schnorr signatures, called _BIP340
schnorr signatures for secp256k1_, also commits to the public key being
@ -539,7 +532,7 @@ They're serialized in the order of +kG+ and then +s+, producing exactly
64 bytes.
The taproot soft fork, also called v1 segwit, introduced schnorr signatures
to Bitcoin and is the only way they are used as of this writing. When
to Bitcoin and is the only way they are used in Bitcoin as of this writing. When
used with either taproot keypath or scriptpath spending, a 64-byte
schnorr signature is considered to use a default signature hash (sighash)
that is +SIGHASH_ALL+. If an alternative sighash is used, or if the
@ -823,10 +816,10 @@ signatures are created by a mathematical function _F_~_sig_~
that produces a signature composed of two values. In ECDSA, those two
values are _R_ and _s_.
((("public and private keys", "key pairs", "ephemeral")))The signature
The signature
algorithm first generates a private nonce (_k_) and derives from it a public
nonce (_K_). The _R_ value of the digital signature is then the x
coordinate of the ephemeral public key _K_.
coordinate of the nonce _K_.
From there, the algorithm calculates the _s_ value of the signature,
such that. Like we did with schnorr signatures, operations involving
@ -858,9 +851,6 @@ where:
If the x coordinate of the calculated point _K_ is equal to _R_, then
the verifier can conclude that the signature is valid.
Note that in verifying the signature, the private key is neither known
nor revealed.
[TIP]
====
ECDSA is necessarily a fairly complicated piece of math; a full
@ -893,10 +883,6 @@ as follows:
* +S+&#x2014;++4b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813++
* A suffix (+0x01+) indicating the type of hash used (+SIGHASH_ALL+)
See if you can decode Alice's serialized (DER-encoded) signature using
this list. The important numbers are +R+ and +S+; the rest of the data
is part of the DER encoding scheme.
[[nonce_warning]]
=== The Importance of Randomness in Signatures
@ -952,11 +938,6 @@ startref="Tdigsig06")))
=== Segregated Witness's New Signing Algorithm
Segregated Witness modified the semantics of the four signature
verification functions from legacy Bitcoin Script (+CHECKSIG+, +CHECKSIGVERIFY+, +CHECKMULTISIG+,
and +CHECKMULTISIGVERIFY+), changing the way a transaction commitment
hash is calculated.
Signatures in bitcoin transactions are applied on a _commitment hash_,
which is calculated from the transaction data, locking specific parts of
the data indicating the signer's commitment to those values. For

5
tools/discouraged.sh
View File

@ -15,6 +15,7 @@ done
for f in $( git ls-files | grep -v "$0" ) ; do
{
echo -n
grep "bitcoin's" $f
} | if grep . ; then echo "DISCOURAGED WORDS FOUND IN $f" ; exit 1 ; fi
done
@ -34,6 +35,8 @@ BIP [0-9]
\<redeemScript\>
\<nAmount\>
\<nValue\>
\<off-chain\>
\<on-chain\>
witness field
witness element
feerate
@ -44,3 +47,5 @@ k-of-n
blockchain.info
blockchain.com
[a-zA-Z]---[a-zA-Z]
fingerprint
block chain

12
transactions.adoc
View File

@ -290,7 +290,7 @@ pieces of information from it:
One of Bitcoin's consensus rules forbids any output from being spent
more than once within a valid blockchain. This is the rule against
_double spending_: Alice can't use the same previous output to pay
both Bob and Carol is separate transactions. Two transactions which each try to spend the
both Bob and Carol in separate transactions. Two transactions which each try to spend the
same previous output are called _conflicting transactions_ because
only one of them can be included in a valid blockchain.
@ -707,7 +707,7 @@ have various processes for interrogating witnesses to (ideally) only
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
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
equal four. We could even omit the need for a person and just use the
@ -844,7 +844,7 @@ example, Alice can use a sighash to allow Bob to help her pay some
transaction fees. This mutates Alice's transaction but only in a way
that Alice wants. For that reason, we will occasionally prefix the
word _unwanted_ to the term _transaction malleability_. Even when we
and other Bitcoin technical writers use the base term, we're almost
and other Bitcoin technical writers use the shorter term, we're almost
certainly talking about the unwanted variant of malleability.
====
@ -867,11 +867,11 @@ money, so she cooperates with Bob to create a chain of transactions.
bitcoins to two outputs. The first output spends some of Alice's
money; the second output returns the remainder of the bitcoins back to
the script requiring Alice and Bob's signatures. Before signing this
transaction, they create a new refund transaction, Tx~1~.
transaction, they create a new refund transaction, Tx~1~
- Tx~1~ spends the second output of Tx~0~ to two new outputs, one to
Alice for her share of the joint funds, and one to Bob for his share.
Alice and Bob both sign this transaction before they sign Tx~0~.
Alice and Bob both sign this transaction before they sign Tx~0~
There's no circular dependency here and, if we ignore third-party
transaction malleability, this looks like it should provide us with a
@ -1038,7 +1038,7 @@ Some of the special rules for coinbase transactions include:
- They may only have one input.
- The single input must have outpoint with a null txid (consisting entirely
- The single input must have an outpoint with a null txid (consisting entirely
of zeroes) and a maximal output index (0xffffffff). This prevents the
coinbase transaction from referencing a previous transaction output,
which would (at the very least) be confusing given that the coinbase

35
wallets.adoc
View File

@ -303,7 +303,7 @@ Aezeed::
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 funds associated with a wallet without scanning the entire
blockchain, which is especially useful for privacy-focused wallets.
blockchain, which is especially useful for privacy-focused lightweight clients.
It includes support for changing the passphrase or changing other
aspects of the recovery code without needing to move funds to a new
seed--the user need only back up a new recovery code. One
@ -414,8 +414,9 @@ The most important data in a wallet database is its private keys. If
you lose access to the private keys, you lose the ability to spend your
bitcoins. Deterministic key derivation and recovery codes provide a
reasonably robust solution for backing up and recovering your keys and
the bitcoins they control. But many wallet databases store more than
just keys. They also also store user-provided information about every
the bitcoins they control. However, it's important to consider that
many wallet databases store more than
just keys--they also also store user-provided information about every
transaction they sent or received.
For example, when Bob creates a new address as part of sending an
@ -499,7 +500,7 @@ even a small fraction of every possible key in a BIP32 tree, which means
that recovering from data loss requires knowing more than just the
recovery code, the algorithm for obtaining your seed (e.g. BIP39), and
the deterministic key derivation algorithm
(e.g., BIP32)---it also requires knowing what paths in the tree of keys
(e.g., BIP32)--it also requires knowing what paths in the tree of keys
your wallet application used for generating the specific keys it distributed.
Two solutions to this problem have been adopted. The first is using
@ -592,7 +593,7 @@ A few example descriptors are shown in <<sample_descriptors>>.
| P2SH multi-signature requring two signatures corresponding to these two keys
| pkh([d34db33f/44'/0'/0']xpub6ERA...RcEL/1/*)
| P2PKH scripts for the BIP32 wallet with fingerprint d34db33f with the extended public key (xpub) at the path M/44'/0'/0', which is xpub6ERA...RcEL, using the keys at M/1/* of that xpub.
| P2PKH scripts for the BIP32 +d34db33f+ with the extended public key (xpub) at the path M/44'/0'/0', which is xpub6ERA...RcEL, using the keys at M/1/* of that xpub.
|===
It has long been the trend for wallet applications designed only for
@ -899,18 +900,6 @@ combination with a carefully planned process for backup and recovery,
considering the possibility of surviving the owner and allowing his or
her family to recover the cryptocurrency estate.
===== Working with BIP39 recovery codes
BIP39 is implemented as a library in many different programming
languages:
https://github.com/trezor/python-mnemonic[python-mnemonic]:: The
reference implementation of the standard by the SatoshiLabs team that
proposed BIP39, in Python
https://github.com/bitcoinjs/bip39[bitcoinjs/bip39]:: An implementation
of BIP39, as part of the popular bitcoinJS framework, in JavaScript
[[hd_wallet_details]]
==== Creating an HD Wallet from the Seed
@ -1077,7 +1066,7 @@ An extended public key can be used, therefore, to derive all of the
_public_ keys (and only the public keys) in that branch of the HD wallet
structure.
This shortcut can be used to create very secure public key-only
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
@ -1162,17 +1151,17 @@ image::images/mbc2_0511.png["ChildPublicDerivation"]
==== Using an Extended Public Key on a Web Store
((("wallets", "technology of", "using extended public keys on web
stores")))Let's see how HD wallets are used by continuing our story with
stores")))Let's see how HD wallets are used by looking at
Gabriel's web store.((("use cases", "web store", id="gabrielfivetwo")))
Gabriel first set up his web store as a hobby, based on a simple hosted
Wordpress page. His store was quite basic with only a few pages and an
order form with a single bitcoin address.
Gabriel used the first bitcoin address generated by his regular wallet as
Gabriel used the first Bitcoin address generated by his regular wallet as
the main bitcoin address for his store.
Customers would submit an order using the form and send payment to
Gabriel's published bitcoin address, triggering an email with the order
Gabriel's published Bitcoin address, triggering an email with the order
details for Gabriel to process. With just a few orders each week, this
system worked well enough, even though it weakened the privacy of
Gabriel, his clients, and the people he paid.
@ -1351,7 +1340,7 @@ m/44'/0' and Bitcoin Testnet is m/44++&#x27;++/1++&#x27;++.
The third level of the tree is "account," which allows users to
subdivide their wallets into separate logical subaccounts, for
accounting or organizational purposes. For example, an HD wallet might
contain two bitcoin "accounts": m/44++&#x27;++/0++&#x27;++/0++&#x27;++
contain two Bitcoin "accounts": m/44++&#x27;++/0++&#x27;++/0++&#x27;++
and m/44++&#x27;++/0++&#x27;++/1++&#x27;++. Each account is the root of
its own subtree.
@ -1363,7 +1352,7 @@ normal derivation. This is to allow this level of the tree to export
extended public keys for use in a nonsecured environment. Usable
addresses are derived by the HD wallet as children of the fourth level,
making the fifth level of the tree the "address_index." For example, the
third receiving address for bitcoin payments in the primary account
third receiving address for payments in the primary account
would be M/44++&#x27;++/0++&#x27;++/0++&#x27;++/0/2. <<table_4-9>> shows
a few more examples.