removing 2e index tags

develop
theresa jones 8 months ago
parent 02f8c485c1
commit 140ba650e8

@ -14,7 +14,7 @@ routed payment channels (Lightning Network).
=== Building Blocks (Primitives)
((("blockchain applications", "building blocks for
(primitives)")))((("primitives")))When operating correctly and over the
(primitives)")))When operating correctly and over the
long term, the Bitcoin system offers certain guarantees, which can be
used as building blocks to create applications. These include:
@ -107,13 +107,13 @@ new feature introduced into Bitcoin.
=== Applications from Building Blocks
((("blockchain applications", "examples of")))The building blocks
The building blocks
offered by Bitcoin are elements of a trust platform that can be used to
compose applications. Here are some examples of applications that exist
today and the building blocks they use:
Proof-of-Existence (Digital Notary):: ((("digital notary
services")))((("Proof of Existence")))Immutability + Timestamp + Durability.
services")))Immutability + Timestamp + Durability.
A transaction on the blockchain can commit to a value,
proving that a piece of data existed at the time
it was recorded (Timestamp). The commitment cannot be modified ex-post-facto
@ -136,17 +136,17 @@ Double-Spend) the settlement on a shorter timelock (Timelock).
=== Colored Coins
((("blockchain applications", "colored coins",
id="BCAcoins12")))((("colored coins", id="color12")))The first
id="BCAcoins12")))The first
blockchain application we will discuss is _colored coins_.
((("extrinsic asset management")))Colored coins refers to a set of
Colored coins refers to a set of
similar technologies that use Bitcoin transactions to record the
creation, ownership, and transfer of extrinsic assets other than
bitcoin. By "extrinsic" we mean assets that are not stored directly on
the bitcoin blockchain, as opposed to bitcoin itself, which is an asset
intrinsic to the blockchain.
((("digital asset management")))Colored coins are used to track digital
Colored coins are used to track digital
assets as well as physical assets held by third parties and traded
through colored coins certificates of ownership. Digital asset colored
coins can represent intangible assets such as a stock certificate,
@ -155,7 +155,7 @@ intellectual property (trademarks, copyrights, etc.). Tangible asset
colored coins can represent certificates of ownership of commodities
(gold, silver, oil), land title, automobiles, boats, aircraft, etc.
((("Enhanced Padded-Order-Based Coloring (EPOBC)")))The term derives
The term derives
from the idea of "coloring" or marking a nominal amount of bitcoin, for
example, a single satoshi, to represent something other than the bitcoin
amount itself. As an analogy, consider stamping a $1 note with a message
@ -379,7 +379,7 @@ underlying data transport mechanism is not the channel. We use the term
channel to represent the relationship and shared state between two
parties, outside of the blockchain.
((("payment (state) channels", "concept of")))To further explain this
To further explain this
concept, think of a TCP stream. From the perspective of higher-level
protocols it is a "socket" connecting two applications across the
internet. But if you look at the network traffic, a TCP stream is just a
@ -406,7 +406,7 @@ the state being altered is the balance of a virtual currency.
==== State Channels—Basic Concepts and Terminology
((("payment (state) channels", "terminology")))A state channel is
A state channel is
established between two parties, through a transaction that locks a
shared state on the blockchain. This is called the _funding transaction_.
This single transaction must be transmitted to
@ -453,7 +453,7 @@ image::images/mbc2_1204.png["A payment channel between Bob and Alice, showing th
==== Simple Payment Channel Example
((("payment (state) channels", "example of", id="PSCexample12")))To
To
explain state channels, we start with a very simple example. We
demonstrate a one-way channel, meaning that value is flowing in one
direction only. We will also start with the naive assumption that no one
@ -547,7 +547,7 @@ the commitment transactions that update the balance of the channel.
In the end, only two transactions are recorded on the blockchain: the
funding transaction that established the channel and a settlement
transaction that allocated the final balance correctly between the two
participants.((("", startref="PSCexample12")))
participants.
[[video_payment_channel]]
.Emma's payment channel with Fabian, showing the commitment transactions that update the balance of the channel
@ -698,7 +698,7 @@ settlement transaction they can close the channel and redeem their
balance immediately. Worst case, one of the parties can be petty, refuse
to cooperate, and force the other party to do a unilateral close with
the most recent commitment transaction. But if they do that, they have
to wait for their funds too.((("", startref="PSCtrust12")))
to wait for their funds too.
==== Asymmetric Revocable Commitments
@ -922,7 +922,7 @@ channel.
==== Hash Time Lock Contracts (HTLC)
((("Hash Time Lock Contracts (HTLC)")))((("payment (state) channels",
((("payment (state) channels",
"Hash Time Lock Contracts (HTLC)")))Payment channels can be further
extended with a special type of smart contract that allows the
participants to commit funds to a redeemable secret, with an expiration
@ -973,7 +973,7 @@ redeemed by _anyone_ who has the secret +R+. An HTLC can take many
different forms with slight variations to the script. For example,
adding a +CHECKSIG+ operator and a public key in the first clause
restricts redemption of the hash to a particular recipient, who must also
know the secret +R+.((("", startref="BCApayment12")))
know the secret +R+.
[[lightning_network]]
=== Routed Payment Channels (Lightning Network)
@ -998,7 +998,7 @@ https://github.com/lightning/bolts/blob/master/00-introduction.md[_Basics of Lig
==== Basic Lightning Network Example
((("Lightning Network", "basic example")))Let's see how this works.
Let's see how this works.
In this example, we have five participants: Alice, Bob, Carol, Diana,
and Eric. These five participants have opened payment channels with each
@ -1114,7 +1114,7 @@ refund if the channel was closed or the routed payment failed.
==== Lightning Network Transport and Pathfinding
((("Lightning Network", "transport and pathfinding")))All communications
All communications
between LN nodes are encrypted point-to-point. In addition, nodes have a
long-term public key that they use as an
identifier and to authenticate each other.
@ -1204,7 +1204,7 @@ hops to go.
==== Lightning Network Benefits
((("Lightning Network", "benefits of")))A Lightning Network is a
A Lightning Network is a
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.

@ -37,7 +37,7 @@ Script is a very simple language. It requires minimal processing and
cannot easily do many of the fancy things modern programming languages
can do.
((("Pay-to-Public-Key-Hash (P2PKH)")))When legacy transactions were the
When legacy transactions were the
most commonly used type of transaction, the majority of transactions processed
through the Bitcoin network had the form "Payment to Bob's Bitcoin
address" and used a script called a Pay-to-Public-Key-Hash script.
@ -53,7 +53,7 @@ conditions for spending and how those conditions can be satisfied.
[TIP]
====
((("programmable money")))Bitcoin transaction validation is not based on
Bitcoin transaction validation is not based on
a static pattern, but instead is achieved through the execution of a
scripting language. This language allows for a nearly infinite variety
of conditions to be expressed.
@ -61,14 +61,14 @@ of conditions to be expressed.
==== Turing Incompleteness
((("Turing incompleteness")))The Bitcoin transaction script language
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
Complete_, meaning that scripts have limited complexity and predictable
execution times. Script is not a general-purpose language.
((("denial-of-service attacks")))((("denial-of-service attacks",
see="also security")))((("security", "denial-of-service attacks")))These
((("denial-of-service attacks",
see="also security")))These
limitations ensure that the language cannot be used to create an
infinite loop or other form of "logic bomb" that could be embedded in a
transaction in a way that causes a denial-of-service attack against the
@ -78,7 +78,7 @@ validation mechanism from being used as a vulnerability.
==== Stateless Verification
((("stateless verification")))The Bitcoin transaction script language is
The Bitcoin transaction script language is
stateless, in that there is no state prior to execution of the script,
or state saved after execution of the script. All the
information needed to execute a script is contained within the script
@ -205,7 +205,7 @@ to know that the number 2 satisfies the script.
[TIP]
====
((("transactions", "valid and invalid")))Transactions are valid if the
Transactions are valid if the
top result on the stack is +TRUE+, which is any
non-zero value.
Transactions are invalid if the top value on the stack is +FALSE+ (the
@ -261,7 +261,7 @@ failed to satisfy the spending conditions placed on the output.
[[p2pkh]]
==== Pay-to-Public-Key-Hash (P2PKH)
((("Pay-to-Public-Key-Hash (P2PKH)")))
A Pay-to-Public-Key-Hash or "P2PKH" script uses an output script that
contains a hash which commits to a public key. P2PKH is best known as
the basis for a legacy Bitcoin address. A P2PKH output can be spent by
@ -301,7 +301,7 @@ data-xrefstyle="select: labelnumber">#P2PubKHash1</a>] and pass:[<a
data-type="xref" href="#P2PubKHash2" data-xrefstyle="select:
labelnumber">#P2PubKHash2</a>] show (in two parts) a step-by-step
execution of the combined script, which will prove this is a valid
transaction.((("", startref="Tsript06")))((("",
transaction.((("",
startref="Stransact06")))
[[P2PubKHash1]]
@ -316,7 +316,7 @@ image::images/mbc2_0606.png["Tx_Script_P2PubKeyHash_2"]
=== Scripted multisignatures
((("transactions", "advanced", "multisignature
scripts")))((("transactions", "advanced", id="Tadv07")))((("scripting",
scripts")))((("scripting",
"multisignature scripts", id="Smulti07")))((("multisignature
scripts")))Multisignature scripts set a condition where _k_ public keys
are recorded in the script and at least _t_ of those must provide
@ -389,7 +389,7 @@ script may include multiple of those opcodes.
==== An oddity in CHECKMULTISIG execution
((("scripting", "multisignature scripts", "OP_CHECKMULTISIG
oddity")))((("OP_CHECKMULTISIG oddity workaround")))There is an oddity in
oddity")))There is an oddity in
++OP_CHECKMULTISIG++'s execution that requires a slight workaround. When
+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
@ -476,13 +476,13 @@ startref="Smulti07")))
[[p2sh]]
=== Pay-to-Script-Hash (P2SH)
((("transactions", "advanced", "Pay-to-Script-Hash")))((("scripting",
((("scripting",
"Pay-to-Script-Hash", id="Spay07")))Pay-to-Script-Hash (P2SH) was
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",
((("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
@ -525,7 +525,7 @@ matches the commitment in addition to the data which satisfies the script. In si
P2SH means "pay to a script matching this hash, a script that will be
presented later when this output is spent."
((("redeem scripts")))((("scripting", "redeem scripts")))In P2SH
In P2SH
transactions, the script that is replaced by a hash is referred
to as the _redeem script_ because it is presented to the system at
redemption time rather than as an output script. <<without_p2sh>> shows
@ -618,7 +618,7 @@ If the redeem script hash matches, the redeem script is executed:
==== P2SH Addresses
((("scripting", "Pay-to-Script-Hash",
"addresses")))((("Pay-to-Script-Hash (P2SH)", "addresses")))((("bitcoin
"addresses")))((("bitcoin
improvement proposals", "Address Format for P2SH (BIP13)")))Another
important part of the P2SH feature is the ability to encode a script
hash as an address, as defined in BIP13. P2SH addresses are Base58Check
@ -643,7 +643,7 @@ payment does not see the script.
==== Benefits of P2SH
((("scripting", "Pay-to-Script-Hash", "benefits
of")))((("Pay-to-Script-Hash (P2SH)", "benefits of")))The P2SH feature
of")))The P2SH feature
offers the following benefits compared to the direct use of complex
scripts in outputs:
@ -679,7 +679,7 @@ risk, because you can send bitcoin to a P2SH address that cannot be spent later.
[WARNING]
====
((("warnings and cautions", "accidental bitcoin invalidation")))P2SH output scripts
P2SH output scripts
contain the hash of a redeem script, which gives no clues as to
the content of the redeem script. The P2SH output will be
considered valid and accepted even if the redeem script is invalid. You
@ -690,10 +690,10 @@ spent.
[[op_return]]
=== Data Recording Output (OP_RETURN)
((("transactions", "advanced", "data recording output")))((("scripting",
"data recording output")))((("OP_RETURN operator")))((("data recording
(nonpayment data)")))((("nonpayment data")))((("blockchain (the)",
"nonpayment data recording")))((("digital notary services")))Bitcoin's
((("scripting",
"data recording output")))((("data recording
(nonpayment data)")))((("blockchain (the)",
"nonpayment data recording")))Bitcoin's
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
@ -705,8 +705,8 @@ 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
((("unspent transaction outputs
(UTXO)")))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
@ -739,7 +739,7 @@ expensive database operations.
OP_RETURN <data>
----
((("Proof of Existence")))((("DOCPROOF prefix")))The data portion
The data portion
often represents a hash, such as the output
from the SHA256 algorithm (32 bytes). Some applications put a prefix in
front of the data to help identify the application. For example, the
@ -769,7 +769,7 @@ being included in a block until a specific block height, but it does not
prevent spending the funds in another transaction earlier than that.
Let's explain that with the following example.
((("use cases", "buying coffee", id="alicesseven")))Alice signs a transaction spending one of her outputs to Bob's address, and sets the transaction lock time to 3 months in the future. Alice sends that transaction to Bob to hold. With this transaction Alice and Bob know that:
Alice signs a transaction spending one of her outputs to Bob's address, and sets the transaction lock time to 3 months in the future. Alice sends that transaction to Bob to hold. With this transaction Alice and Bob know that:
* Bob cannot transmit the transaction to redeem the funds until 3 months have elapsed.
* Bob may transmit the transaction after 3 months.
@ -783,7 +783,7 @@ It is important to understand the limitations of transaction lock time. The only
==== Check Lock Time Verify (OP_CLTV)
((("Check Lock Time Verify (OP_CLTV)", id="cltv07")))((("timelocks", "Check
((("timelocks", "Check
Lock Time Verify (OP_CLTV)")))((("scripting", "timelocks", "Check Lock Time
Verify (OP_CLTV)")))((("bitcoin improvement proposals",
"OP_CHECKLOCKTIMEVERIFY (BIP65)")))In December 2015, a new form of
@ -891,7 +891,7 @@ expired.
By introducing timelock functionality directly into the scripting
language, +OP_CLTV+ allows us to develop some very interesting complex
scripts.((("", startref="cltv07")))
scripts.
The standard is defined in
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki[BIP65
@ -902,7 +902,7 @@ https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki[BIP65
Lock time and +OP_CLTV+ are ((("timelocks", "relative timelocks",
id="Trelative07")))((("scripting", "timelocks", "relative
timelocks")))((("relative timelocks", id="relativetime07")))both
timelocks")))both
_absolute timelocks_ in that they specify an absolute point in time. The
next two timelock features we will examine are _relative timelocks_ in
that they specify, as a condition of spending an output, an elapsed time
@ -938,7 +938,7 @@ the consensus rules.
==== Relative Timelocks with OP_CSV
((("scripting", "timelocks", "relative timelocks with
CHECKSEQUENCEVERIFY")))((("CHECKSEQUENCEVERIFY (CSV)")))Just like OP_CLTV
CHECKSEQUENCEVERIFY")))Just like OP_CLTV
and lock time, there is a script opcode for relative timelocks that
leverages the sequence value in scripts. That opcode is
+OP_CHECKSEQUENCEVERIFY+, commonly referred to as +OP_CSV+ for short.
@ -970,7 +970,7 @@ is, they're kept off the blockchain (_offchain_). A child transaction cannot be
parent transaction has been propagated, mined, and aged by the time
specified in the relative timelock. One application of this use case can
be seen in <<state_channels>> and <<lightning_network>>.((("",
startref="relativetime07")))((("", startref="Trelative07")))
startref="relativetime07")))
+OP_CSV+ is defined in detail in
https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki[BIP112,
@ -978,9 +978,9 @@ CHECKSEQUENCEVERIFY].
=== Scripts with Flow Control (Conditional Clauses)
((("transactions", "advanced", "flow control scripts")))((("scripting",
((("scripting",
"flow control scripts", id="Sflow07")))((("conditional clauses",
id="condition07")))((("flow control", id="flow07")))One of the more
id="condition07")))One of the more
powerful features of Bitcoin Script is flow control, also known as
conditional clauses. You are probably familiar with flow control in
various programming languages that use the construct +IF...THEN...ELSE+.
@ -1041,13 +1041,13 @@ comes _before_ the +IF+ opcode.
==== Conditional Clauses with VERIFY Opcodes
((("VERIFY opcodes")))((("IF clauses")))((("opcodes", "VERIFY")))Another
Another
form of conditional in Bitcoin Script is any opcode that ends in
+VERIFY+. The +VERIFY+ suffix means that if the condition evaluated is
not +TRUE+, execution of the script terminates immediately and the
transaction is deemed invalid.
((("guard clauses")))Unlike an +IF+ clause, which offers alternative
Unlike an +IF+ clause, which offers alternative
execution paths, the +VERIFY+ suffix acts as a _guard clause_,
continuing only if a precondition is met.
@ -1104,7 +1104,7 @@ A very common use for flow control in Bitcoin Script is to construct a
script that offers multiple execution paths, each a different way
of redeeming the UTXO.
((("use cases", "buying coffee")))Let's look at a simple example, where
Let's look at a simple example, where
we have two signers, Alice and Bob, and either one is able to redeem.
With multisig, this would be expressed as a 1-of-2 multisig script. For
the sake of demonstration, we will do the same thing with an +OP_IF+
@ -1178,12 +1178,12 @@ Using this construct, we can build redeem scripts with tens or hundreds
of execution paths, each offering a different way to redeem the UTXO. To
spend, we construct an input script that navigates the execution
path by putting the appropriate +TRUE+ and +FALSE+ values on the stack
at each flow control point.((("", startref="Sflow07")))((("",
startref="flow07")))((("", startref="condition07")))
at each flow control point.((("",
startref="flow07")))
=== Complex Script Example
((("transactions", "advanced", "example")))((("scripting", "complex
((("scripting", "complex
script example", id="Scomplex07")))In this section we combine many of
the concepts from this chapter into a single example.
@ -1378,7 +1378,7 @@ to the receiver in the manner that the receiver indicated.
[[p2wsh]]
===== Pay-to-Witness-Script-Hash (P2WSH)
The ((("use cases", "import/export", id="mohamappd")))second type of
The second type of
segwit v0 witness program corresponds to a Pay-to-Script-Hash (P2SH) script. We
saw this type of script in <<p2sh>>. In that example, P2SH was used by
Mohammed's company to express a multisignature script. Payments to

@ -2,7 +2,7 @@
[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 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:
@ -10,7 +10,7 @@ _Standard_ BIP:: Describes any change that affects most or all Bitcoin implement
_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].
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 Pull Request (PR) and version of Bitcoin Core where support for each BIP was added or

@ -25,7 +25,7 @@ create and examine data related to the blockchain and network.
=== From Bitcoin to Bitcoin Core
((("open source licenses")))((("Nakamoto, Satoshi")))Bitcoin is an _open
Bitcoin is an _open
source_ project and the source code is available under an open (MIT)
license, free to download and use for any purpose. More than just being
open source, Bitcoin is developed by
@ -35,7 +35,7 @@ contributors with about a dozen developers working on the code almost
full-time and several dozen more on a part-time basis. Anyone can
contribute to the code&#x2014;including you!
((("bitcoin whitepaper")))((("Satoshi client")))((("reference
((("reference
implementation", see="Bitcoin Core")))((("Bitcoin Core", "reference
implementation")))When Bitcoin was created by Satoshi Nakamoto, the
software was mostly completed before publication of the whitepaper reproduced in
@ -51,7 +51,7 @@ wallets, a transaction and block validation engine, tools for block construction
of Bitcoin peer-to-peer communication.
<<bitcoin_core_architecture>> shows the architecture of Bitcoin
Core.((("Bitcoin Core", "architecture")))
Core.
[[bitcoin_core_architecture]]
.Bitcoin Core architecture (Source: Eric Lombrozo)
@ -68,7 +68,7 @@ several major upgrades to Bitcoin.
=== Bitcoin Development Environment
((("development environment", "setup", see="Bitcoin Core")))If you're a
If you're a
developer, you will want to set up a development environment with all
the tools, libraries, and support software for writing Bitcoin
applications. In this highly technical chapter, we'll walk through that
@ -81,7 +81,7 @@ next chapter, which is less technical.
((("Bitcoin Core", "compiling from source code",
id="BCsource03")))((("Bitcoin Core", "compiling from source code",
"downloading")))((("code examples, obtaining and using")))Bitcoin Core's
"downloading")))Bitcoin Core's
source code can be downloaded as an archive or by cloning the
source repository from GitHub. ((("Bitcoin Core
downloads")))On the https://bitcoincore.org/bin/[Bitcoin Core download
@ -93,7 +93,7 @@ https://github.com/bitcoin/bitcoin[GitHub bitcoin page].
[TIP]
====
((("$ symbol")))((("shell commands")))((("terminal applications")))In
In
many of the examples in this chapter we will be using the operating
system's command-line interface (also known as a "shell"), accessed via
a "terminal" application. The shell will display a prompt; you type a
@ -107,7 +107,7 @@ system's responses to that command. When you see the next +$+ prefix,
you'll know it's a new command and you should repeat the process.
====
((("cloning source code")))((("source code, cloning", seealso="Bitcoin
((("source code, cloning", seealso="Bitcoin
Core")))In this example, we are using the +git+ command to create a
local copy ("clone") of the source code:
@ -124,7 +124,7 @@ Resolving deltas: 100% (175649/175649), done.
[TIP]
====
((("distributed version control systems")))Git is the most widely used
Git is the most widely used
distributed version control system, an essential part of any software
developer's toolkit. You may need to install the +git+ command, or a
graphical user interface for git, on your operating system if you do not
@ -192,7 +192,7 @@ nothing to commit, working tree clean
==== Configuring the Bitcoin Core Build
((("Bitcoin Core", "compiling from source code", "build
configuration")))((("documentation")))((("build documentation",
configuration")))((("build documentation",
seealso="Bitcoin Core")))The source code includes documentation, which
can be found in a number of files. Review the main documentation located
in _README.md_ in the _bitcoin_ directory.
@ -303,7 +303,7 @@ fixes the error.
==== Building the Bitcoin Core Executables
((("Bitcoin Core", "compiling from source code", "core
executables")))((("core executables", seealso="Bitcoin Core")))Next, you
executables")))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.
If an error
@ -343,7 +343,7 @@ libtool: install: /usr/bin/install -c bitcoin-tx /usr/local/bin/bitcoin-tx
...
----
((("", startref="BCsource03")))The default installation of +bitcoind+
The default installation of +bitcoind+
puts it in _/usr/local/bin_. You can confirm that Bitcoin Core is
correctly installed by asking the system for the path of the
executables, as follows:
@ -358,7 +358,7 @@ $ which bitcoin-cli
=== Running a Bitcoin Core Node
((("Bitcoin Core", "running core nodes", id="BCnode03")))((("Bitcoin
((("Bitcoin
nodes", "running core nodes", id="BNcore03")))Bitcoin's peer-to-peer
network is composed of network "nodes," run mostly by individuals and
some of the businesses that provide Bitcoin services. Those running
@ -393,7 +393,7 @@ https://blockstream.com/satellite/[Blockstream Satellite].
[TIP]
====
((("warnings and cautions", "core node resource
requirements")))((("resource requirements")))Bitcoin Core keeps a full
requirements")))Bitcoin Core keeps a full
copy of the blockchain by default, with nearly every transaction that has ever
been confirmed on the Bitcoin network since its inception in 2009. This
dataset is hundreds of gigabytes in size and is downloaded incrementally
@ -437,9 +437,9 @@ node.
==== Configuring the Bitcoin Core Node
((("Bitcoin Core", "running core nodes", "configuring")))((("warnings
((("warnings
and cautions", "password creation")))((("passwords",
"creating")))((("security", "passwords")))Bitcoin Core will look for a
"creating")))Bitcoin Core will look for a
configuration file in its data directory on every start. In this section
we will examine the various configuration options and set up a
configuration file. To locate the configuration file, run +bitcoind
@ -488,7 +488,7 @@ Options:
[many more options]
----
((("configuration options", seealso="Bitcoin Core")))Here are some of
Here are some of
the most important options that you can set in the configuration file,
or as command-line parameters to +bitcoind+:
@ -532,7 +532,7 @@ Use it to reduce memory use on memory-constrained nodes.
****
((("Bitcoin Core", "running core nodes", "database
options")))((("transactions", "database configuration
options")))((("txindex option")))((("full indexing option")))By default,
options")))By default,
Bitcoin Core builds a database containing _only_ the transactions
related to the user's wallet. If you want to be able to access _any_
transaction with commands like +getrawtransaction+ (see
@ -654,11 +654,11 @@ 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 Core's source directory under _contrib/init_ and
a _README.md_ file showing which system uses which script.((("",
startref="BCnode03")))((("", startref="BNcore03")))
startref="BCnode03")))
=== Bitcoin Core Application Programming Interface (API)
((("Bitcoin Core", "Bitcoin Core API", id="BCapi03")))Bitcoin Core
Bitcoin Core
implements a JSON-RPC interface that can also be accessed using
the command-line helper +bitcoin-cli+. The command line allows us to
experiment interactively with the capabilities that are also available
@ -723,7 +723,7 @@ and their expected output.
==== Getting Information on Bitcoin Core's Status
((("Bitcoin Core", "Bitcoin Core API", "status information")))Bitcoin
Bitcoin
Core provides status reports on different modules through the JSON-RPC
interface. The most important commands include +getblockchaininfo+,
+getmempoolinfo+, +getnetworkinfo+ and +getwalletinfo+.
@ -811,7 +811,7 @@ e739df2f899c49dc267c0ad280aca6dab0d2fa2b42a45182fc83e81713010000
[TIP]
====
((("transaction IDs (txd)")))((("malleability")))A transaction ID (txid)
A transaction ID (txid)
is not authoritative. Absence of a txid in the blockchain does not mean
the transaction was not processed. This is known as "transaction
malleability," because transactions can be modified prior to
@ -905,7 +905,7 @@ transmitted from one owner to the next.
==== Exploring Blocks
((("blocks", "block height")))((("blocks", "block hash")))Exploring
Exploring
blocks is similar to exploring transactions. However, blocks can be
referenced either by the block _height_ or by the block _hash_. First,
let's find a block by its height.
@ -985,7 +985,7 @@ we'll examine those in detail in <<mining>>.
==== Using Bitcoin Core's Programmatic Interface
((("Bitcoin Core", "Bitcoin Core API", "using programmatic
interface")))((("programmatic interface", id="progint03")))The
interface")))The
+bitcoin-cli+ helper is very useful for exploring the Bitcoin Core API
and testing functions. But the whole point of an application programming
interface is to access functions programmatically. In this section we
@ -1102,7 +1102,7 @@ and more clearly demonstrates the use of a programmatic interface.
In <<rpc_block>>, we first retrieve a block, then retrieve each of
the transactions within it by reference to each transaction ID. Next,
we iterate through each of the transaction's outputs and add up the
value.((("", startref="alicethree")))
value.
[[rpc_block]]
.Retrieving a block and adding all the transaction outputs
@ -1126,16 +1126,16 @@ block is 10,322.07722534 BTC (including 25 BTC reward and 0.0909 BTC in
fees). Compare that to the amount reported by a block explorer site by
searching for the block hash or height. Some block explorers report the
total value excluding the reward and excluding the fees. See if you can
spot the difference.((("", startref="BCapi03")))((("",
spot the difference.((("",
startref="progint03")))
[[alt_libraries]]
=== Alternative Clients, Libraries, and Toolkits
((("Bitcoin Core", "alternatives to", id="BCalt03")))((("clients,
((("clients,
libraries, and toolkits", id="clients03")))((("libraries, clients, and
toolkits", id="librar03")))((("toolkits, libraries, and clients",
id="toolkit03")))((("third-party API clients", id="thirdpart03")))There
id="toolkit03")))There
are many alternative clients, libraries, toolkits, and even full-node
implementations in the bitcoin ecosystem. These are implemented in a
variety of programming languages, offering programmers native interfaces
@ -1172,9 +1172,9 @@ https://bitcoin-s.org/[bitcoin-s]:: A Bitcoin implementation in Scala
https://github.com/MetacoSA/NBitcoin[NBitcoin]:: Comprehensive bitcoin library for the .NET framework
Many more libraries exist in a variety of other programming languages
and more are created all the time.((("", startref="BCalt03")))((("",
startref="clients03")))((("", startref="thirdpart03")))((("",
startref="toolkit03")))((("", startref="librar03")))
and more are created all the time.((("",
startref="clients03")))((("",
startref="toolkit03")))
If you followed the instructions in this chapter, you now have Bitcoin
Core running and have begun exploring the network and blockchain using

@ -8,19 +8,19 @@ structure of the blockchain and see how it uses cryptographic
commitments and other clever tricks to make every part of it easy for
full nodes (and sometimes light clients) to validate.
((("blockchain (the)", "overview of")))The blockchain data structure is
The blockchain data structure is
an ordered, back-linked list of blocks of transactions. The blockchain
can be stored as a flat file, or in a simple database.
Blocks are linked "back," each referring to the previous block in the
chain. ((("blocks", "block height")))The blockchain is often visualized
chain. The blockchain is often visualized
as a vertical stack, with blocks layered on top of each other and the
first block serving as the foundation of the stack. The visualization of
blocks stacked on top of each other results in the use of terms such as
"height" to refer to the distance from the first block, and "top" or
"tip" to refer to the most recently added block.
((("blocks", "block hash")))((("blocks", "genesis block")))((("blocks",
"parent blocks")))((("genesis block")))((("parent blocks")))Each block
((("blocks",
"parent blocks")))Each block
within the blockchain is identified by a hash, generated using the
SHA256 cryptographic hash algorithm on the header of the block. Each
block also commits to the previous block, known as the _parent_ block,
@ -58,7 +58,7 @@ years. In the blockchain, the most recent few blocks might be revised if
there is a chain reorganization due to a fork. The top six blocks are
like a few inches of topsoil. But once you go more deeply into the
blockchain, beyond six blocks, blocks are less and less likely to
change. ((("transactions", "coinbase transactions")))((("coinbase
change. ((("coinbase
transactions")))After 100 blocks back there is so much stability that
the coinbase transaction--the transaction containing the reward in
bitcoin for creating a new block--can be spent.
@ -70,7 +70,7 @@ infinitesimal.
=== Structure of a Block
((("blocks", "structure of")))((("blockchain (the)", "block
((("blockchain (the)", "block
structure")))A block is a container data structure that aggregates
transactions for inclusion in the blockchain. The
block is made of a header, containing metadata, followed by a long list
@ -95,8 +95,8 @@ header. <<block_structure1>> describes how Bitcoin Core stores the structure of
[[block_header]]
=== Block Header
((("blocks", "headers")))((("blockchain (the)", "block
headers")))((("headers")))The block header consists of
((("blockchain (the)", "block
headers")))The block header consists of
block metadata as shown in <<block_header_structure_ch09>>.
[[block_header_structure_ch09]]
@ -118,8 +118,8 @@ process and will be discussed in more detail in <<mining>>.
[[block_hash]]
=== Block Identifiers: Block Header Hash and Block Height
((("blockchain (the)", "block identifiers")))((("blocks", "block
height")))((("blocks", "block hash")))The primary identifier of a block
((("blocks", "block
height")))The primary identifier of a block
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
@ -178,7 +178,7 @@ the blockchain.
=== The Genesis Block
((("blocks", "genesis block")))((("blockchain (the)", "genesis
((("blockchain (the)", "genesis
block")))The first block in the blockchain is called the _genesis block_
and was created in 2009. It is the common ancestor of all the blocks in
the blockchain, meaning that if you start at any block and follow the
@ -250,7 +250,7 @@ first block by Satoshi Nakamoto, Bitcoin's creator.
=== Linking Blocks in the Blockchain
((("blocks", "linking blocks in the blockchain")))((("blockchain (the)",
((("blockchain (the)",
"linking blocks in the blockchain")))Bitcoin full nodes validate every
block in the blockchain after the genesis block. Their local view of
the blockchain is constantly updated as new blocks are found and used to
@ -307,11 +307,11 @@ image::images/mbc2_0901.png[]
[[merkle_trees]]
=== Merkle Trees
((("merkle trees", id="merkle09")))((("blockchain (the)", "merkle
((("blockchain (the)", "merkle
trees", id="BCTmerkle09")))Each block in the Bitcoin blockchain contains
a summary of all the transactions in the block using a _merkle tree_.
((("binary hash trees", see="merkle trees")))A _merkle tree_, also known
A _merkle tree_, also known
as a _binary hash tree_, is a data structure used for efficiently
summarizing and verifying the integrity of large sets of data. Merkle
trees are binary trees containing cryptographic hashes. The term "tree"
@ -369,7 +369,7 @@ of the nodes.
.Calculating the nodes in a merkle tree
image::images/mbc2_0902.png["merkle_tree"]
((("balanced trees")))Because the merkle tree is a binary tree, it needs
Because the merkle tree is a binary tree, it needs
an even number of leaf nodes. If there is an odd number of transactions
to summarize, the last transaction hash will be duplicated to create an
even number of leaf nodes, also known as a _balanced tree_. This is
@ -434,7 +434,7 @@ size, just 32 bytes. Whether there is one transaction or ten
thousand transactions in the block, the merkle root always summarizes
them into 32 bytes.
((("authentication paths")))To prove that a specific transaction is
To prove that a specific transaction is
included in a block, a node only needs to produce approximately +log~2~(N)+ 32-byte
hashes, constituting an _authentication path_ or _merkle path_
connecting the specific transaction to the root of the tree. This is
@ -497,18 +497,18 @@ transaction is recorded in the blockchain. All in all, the lightweight client wi
have received less than a kilobyte of data for the block header and
merkle path, an amount of data that is more than a thousand times less
than a full block (about 2 megabytes currently).((("",
startref="BCTmerkle09")))((("", startref="merkle09")))
startref="BCTmerkle09")))
=== Bitcoin's Test Blockchains
((("blockchain (the)", "test blockchains",
id="BCTtest09")))((("mainnet", seealso="blockchain (the)")))You might be
id="BCTtest09")))You might be
surprised to learn that there is more than one blockchain used with Bitcoin. The
"main" Bitcoin blockchain, the one created by Satoshi Nakamoto on
January 3rd, 2009, the one with the genesis block we studied in this
chapter, is called _mainnet_. There are other Bitcoin blockchains that
are used for testing purposes: at this time _testnet_, _signet_, and
_regtest_. Let's look at each in turn.((("testnet", id="testnet09")))
_regtest_. Let's look at each in turn.
==== Testnet: Bitcoin's Testing Playground
@ -588,7 +588,7 @@ experiment and learn in other programming languages and frameworks.
Testnet3 supports all the features of mainnet, including
Segregated Witness v0 and v1 (see <<segwit>> and <<taproot>>). Therefore, testnet3 can also be
used to test Segregated Witness features.((("", startref="testnet09")))
used to test Segregated Witness features.
===== Problems With Testnet
@ -695,7 +695,7 @@ $ bitcoin-cli -signet getblockchaininfo
==== Regtest&#x2014;The Local Blockchain
((("regtest (Regression Testing)")))Regtest, which stands for
Regtest, which stands for
"Regression Testing," is a Bitcoin Core feature that allows you to
create a local blockchain for testing purposes. Unlike signet and testnet3, which
are a public and shared test blockchain, the regtest blockchains are
@ -767,7 +767,7 @@ $ bitcoin-cli -regtest getbalance
=== Using Test Blockchains for Development
((("development environment", "test blockchains and")))Bitcoin's various
Bitcoin's various
blockchains (+regtest+, +signet+, +testnet3+, +mainnet+) offer a range
of testing environments for bitcoin development. Use the test
blockchains whether you are developing for Bitcoin Core, or another
@ -783,7 +783,7 @@ applications. Finally, once you are confident your code works as
expected, switch to +mainnet+ to deploy it in production. As you make
changes, improvements, bug fixes, etc., start the pipeline again,
deploying each change first on +regtest+, then on +signet+ or +testnet+, and finally
into production.((("", startref="BCTtest09")))
into production.
Now that we know what data the blockchain contains and how cryptographic
commitments securely tie the various parts together, we will look at the

@ -611,7 +611,7 @@ and make a miner very happy, this is probably not what you intended.
[WARNING]
====
((("warnings and cautions", "change outputs")))If you forget to add a
If you forget to add a
change output in a manually constructed transaction, you will be paying
the change as a transaction fee. "Keep the change!" might not be what
you intended.
@ -622,8 +622,8 @@ you intended.
((("scripting", "timelocks", "defense against
fee-sniping")))((("timelocks", "defense against
fee-sniping")))((("fees", "fee sniping")))((("security", "defense
against fee-sniping")))((("sniping")))Fee-sniping is a theoretical
fee-sniping")))((("security", "defense
against fee-sniping")))Fee-sniping is a theoretical
attack scenario, where miners attempting to rewrite past blocks "snipe"
higher-fee transactions from future blocks to maximize their
profitability.

@ -192,7 +192,7 @@ RIPEMD-160::
RIPEMD-160 is a 160-bit cryptographic hash function. RIPEMD-160 is a strengthened version of RIPEMD with a 160-bit hash result, and is expected to be secure for the next ten years or more.
satoshi::
A satoshi is the smallest denomination of bitcoin that can be recorded on the blockchain. It is the equivalent of 0.00000001 bitcoin and is named after the creator of Bitcoin, Satoshi Nakamoto. ((("satoshi")))
A satoshi is the smallest denomination of bitcoin that can be recorded on the blockchain. It is the equivalent of 0.00000001 bitcoin and is named after the creator of Bitcoin, Satoshi Nakamoto.
Satoshi Nakamoto::
Satoshi Nakamoto is the name used by the person or people who designed Bitcoin and created its original reference implementation, Bitcoin Core. As a part of the implementation, they also devised the first blockchain database. In the process they were the first to solve the double-spending problem for digital currency. Their real identity remains unknown.

@ -2,7 +2,7 @@
[[ch01_intro_what_is_bitcoin]]
== Introduction
((("bitcoin", "defined", id="GSdefine01")))Bitcoin is a collection of concepts and technologies that form the basis of a digital money ecosystem. Units of currency called bitcoin are used to store and transmit value among participants in the Bitcoin network. Bitcoin users communicate with each other using the Bitcoin protocol primarily via the internet, although other transport networks can also be used. The Bitcoin protocol stack, available as open source software, can be run on a wide range of computing devices, including laptops and smartphones, making the technology easily accessible.
Bitcoin is a collection of concepts and technologies that form the basis of a digital money ecosystem. Units of currency called bitcoin are used to store and transmit value among participants in the Bitcoin network. Bitcoin users communicate with each other using the Bitcoin protocol primarily via the internet, although other transport networks can also be used. The Bitcoin protocol stack, available as open source software, can be run on a wide range of computing devices, including laptops and smartphones, making the technology easily accessible.
[TIP]
====
@ -71,18 +71,18 @@ Behind the scenes, Bitcoin is also the name of the protocol, a peer-to-peer netw
* A decentralized peer-to-peer network (the Bitcoin protocol)
* 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 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)
As a developer, I see Bitcoin as akin to the internet of money, a network for propagating value and securing the ownership of digital assets via distributed computation. There's a lot more to Bitcoin than first meets the eye.
In this chapter we'll get started by explaining some of the main concepts and terms, getting the necessary software, and using Bitcoin for simple transactions. In the following chapters, we'll start unwrapping the layers of technology that make Bitcoin possible and examine the inner workings of the Bitcoin network and protocol.((("", startref="GSdefine01")))
In this chapter we'll get started by explaining some of the main concepts and terms, getting the necessary software, and using Bitcoin for simple transactions. In the following chapters, we'll start unwrapping the layers of technology that make Bitcoin possible and examine the inner workings of the Bitcoin network and protocol.
[role="pagebreak-before less_space"]
.Digital Currencies Before Bitcoin
****
((("digital currencies", "prior to bitcoin")))The emergence of viable digital money is closely linked to developments in cryptography. This is not surprising when one considers the fundamental challenges involved with using bits to represent value that can be exchanged for goods and services. Three basic questions for anyone accepting digital money are:
The emergence of viable digital money is closely linked to developments in cryptography. This is not surprising when one considers the fundamental challenges involved with using bits to represent value that can be exchanged for goods and services. Three basic questions for anyone accepting digital money are:
1. Can I trust that the money is authentic and not counterfeit?
2. Can I trust that the digital money can only be spent once (known as the “double-spend” problem)?
@ -92,13 +92,13 @@ Issuers of paper money are constantly battling the counterfeiting problem by usi
When cryptography started becoming more broadly available and understood in the late 1980s, many researchers began trying to use cryptography to build digital currencies. These early digital currency projects issued digital money, usually backed by a national currency or precious metal such as gold.
((("decentralized systems", "vs. centralized", secondary-sortas="centralized")))Although these earlier digital currencies worked, they were centralized and, as a result, were easy to attack by governments and hackers. Early digital currencies used a central clearinghouse to settle all transactions at regular intervals, just like a traditional banking system. Unfortunately, in most cases these nascent digital currencies were targeted by worried governments and eventually litigated out of existence. Some failed in spectacular crashes when the parent company liquidated abruptly. To be robust against intervention by antagonists, whether legitimate governments or criminal elements, a _decentralized_ digital currency was needed to avoid a single point of attack. Bitcoin is such a system, decentralized by design, and free of any central authority or point of control that can be attacked or corrupted.
Although these earlier digital currencies worked, they were centralized and, as a result, were easy to attack by governments and hackers. Early digital currencies used a central clearinghouse to settle all transactions at regular intervals, just like a traditional banking system. Unfortunately, in most cases these nascent digital currencies were targeted by worried governments and eventually litigated out of existence. Some failed in spectacular crashes when the parent company liquidated abruptly. To be robust against intervention by antagonists, whether legitimate governments or criminal elements, a _decentralized_ digital currency was needed to avoid a single point of attack. Bitcoin is such a system, decentralized by design, and free of any central authority or point of control that can be attacked or corrupted.
****
=== History of Bitcoin
((("Nakamoto, Satoshi")))((("distributed computing")))((("bitcoin",
((("bitcoin",
"history of")))Bitcoin was first described in 2008 with the publication of a
paper titled "Bitcoin: A Peer-to-Peer Electronic Cash
System,"footnote:["Bitcoin: A Peer-to-Peer Electronic Cash System,"
@ -107,13 +107,13 @@ alias of Satoshi Nakamoto (see <<satoshi_whitepaper>>). Nakamoto
combined several prior inventions such as digital signatures and Hashcash to create
a completely decentralized electronic cash system that does not rely on
a central authority for currency issuance or settlement and validation
of transactions. ((("Proof-of-Work algorithm")))((("decentralized
of transactions. ((("decentralized
systems", "consensus in")))((("mining and consensus", "Proof-of-Work
algorithm")))A key innovation was to use a distributed computation
system (called a "Proof-of-Work" algorithm) to conduct a global
lottery every 10 minutes on average, allowing the decentralized network to
arrive at _consensus_ about the state of transactions. ((("double-spend
problem")))((("spending bitcoin", "double-spend problem")))This
problem")))This
elegantly solves the issue of double-spend where a single currency unit
can be spent twice. Previously, the double-spend problem was a weakness
of digital currency and was addressed by clearing all transactions
@ -127,12 +127,12 @@ increased exponentially, and their combined computational power now
exceeds the combined number of computing operations of the
world's top supercomputers.
Satoshi Nakamoto withdrew from the public in April 2011, leaving the responsibility of developing the code and network to a thriving group of volunteers. The identity of the person or people behind Bitcoin is still unknown. ((("open source licenses")))However, neither Satoshi Nakamoto nor anyone else exerts individual control over the Bitcoin system, which operates based on fully transparent mathematical principles, open source code, and consensus among participants. The invention itself is groundbreaking and has already spawned new science in the fields of distributed computing, economics, and econometrics.
Satoshi Nakamoto withdrew from the public in April 2011, leaving the responsibility of developing the code and network to a thriving group of volunteers. The identity of the person or people behind Bitcoin is still unknown. However, neither Satoshi Nakamoto nor anyone else exerts individual control over the Bitcoin system, which operates based on fully transparent mathematical principles, open source code, and consensus among participants. The invention itself is groundbreaking and has already spawned new science in the fields of distributed computing, economics, and econometrics.
.A Solution to a Distributed Computing Problem
****
((("Byzantine Generals&#x27; Problem")))Satoshi Nakamoto's invention is
Satoshi Nakamoto's invention is
also a practical and novel solution to a problem in distributed
computing, known as the "Byzantine Generals' Problem." Briefly, the
problem consists of trying to get multiple participants without a leader
@ -162,7 +162,7 @@ derived from the original implementation written by Satoshi Nakamoto.
==== Choosing a Bitcoin Wallet
((("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.
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.
===== Types of Bitcoin wallets
Bitcoin wallets can be categorized as follows, according to the platform:
@ -204,7 +204,7 @@ 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:
Full-node:: ((("full-node")))A full node is a program that validates the
Full-node:: A full node is a program that validates the
entire history of Bitcoin transactions (every transaction by every user,
ever). Optionally, full nodes can also store previously validated
transactions and serve data to other Bitcoin programs, either on the
@ -213,14 +213,14 @@ computer resources--about the same as watching an hour-long streaming
video for each day of Bitcoin transactions--but the full node offers
complete autonomy to its users.
Lightweight client:: ((("lightweight clients")))
Lightweight client::
A lightweight client, also known as a simplified-payment-verification (SPV) client,
connects to a full node or other remote server for receiving and sending
Bitcoin transaction information, but stores the user wallet locally,
partially validates the transactions it receives, and independently
creates outgoing transactions.
Third-party API client:: ((("third-party API clients")))A third-party
Third-party API client:: A third-party
API client is one that interacts with Bitcoin through a third-party
system of application programming interfaces (APIs), rather than by
connecting to the Bitcoin network directly. The wallet may be stored by
@ -363,11 +363,11 @@ 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. 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
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 bitcoins directly to your wallet. You can share
@ -402,7 +402,7 @@ bitcoin-accepting charity.
[[getting_first_bitcoin]]
==== Getting Your First Bitcoin
((("getting started", "acquiring bitcoin")))The first task for new users is to acquire some bitcoin.
The first task for new users is to acquire some bitcoin.
Bitcoin transactions are irreversible. Most electronic payment networks such as credit cards, debit cards, PayPal, and bank account transfers are reversible. For someone selling bitcoin, this difference introduces a very high risk that the buyer will reverse the electronic payment after they have received bitcoin, in effect defrauding the seller. To mitigate this risk, companies accepting traditional electronic payments in return for bitcoin usually require buyers to undergo identity verification and credit-worthiness checks, which may take several days or weeks. As a new user, this means you cannot buy bitcoin instantly with a credit card. With a bit of patience and creative thinking, however, you won't need to.
@ -411,15 +411,15 @@ Here are some methods for acquiring bitcoin as a new user:
* 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.
* Use a Bitcoin ATM in your city. A Bitcoin ATM is a machine that accepts cash and sends bitcoins to your smartphone Bitcoin wallet.
* 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]
====
((("privacy, maintaining")))((("security", "maintaining
privacy")))((("digital currencies", "currency exchanges")))((("currency
((("security", "maintaining
privacy")))((("currency
exchanges")))((("digital currencies", "benefits of
bitcoin")))((("bitcoin", "benefits of")))One of the advantages of
bitcoin")))One of the advantages of
Bitcoin over other payment systems is that, when used correctly, it
affords users much more privacy. Acquiring, holding, and spending
bitcoin does not require you to divulge sensitive and personally
@ -440,14 +440,14 @@ Alice was introduced to Bitcoin by a friend so she has an easy way to acquire he
[[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 price
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 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).
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://bitcoinaverage.com/[Bitcoin Average]:: A site that provides a simple view of the volume-weighted-average for each currency.
https://coincap.io/[CoinCap]:: A service listing the market capitalization and exchange rates of hundreds of 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.
@ -460,7 +460,7 @@ currencies.
((("getting started", "sending and receiving bitcoin",
id="GSsend01")))((("spending bitcoin", "bitcoin wallet quick start
example")))((("spending bitcoin", see="also transactions")))Alice has
example")))Alice has
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
@ -511,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 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>>.
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.

@ -29,7 +29,7 @@ the addresses used by modern Bitcoin software.
=== Public Key Cryptography
((("keys and addresses", "overview of", "public key
cryptography")))((("digital currencies", "cryptocurrency")))Public key
cryptography")))Public key
cryptography was invented in the 1970s and is a mathematical foundation
for modern computer and information security.
@ -56,14 +56,14 @@ revealing the private key.
[TIP]
====
((("keys and addresses", "overview of", "key pairs")))In some wallet
In some wallet
implementations, the private and public keys are stored together as a
_key pair_ for convenience. However, the public key can be calculated
from the private key, so storing only the private key is also possible.
====
((("keys and addresses", "overview of", "private and public key
pairs")))((("elliptic curve cryptography")))((("cryptography", "elliptic
pairs")))((("cryptography", "elliptic
curve cryptography")))A Bitcoin wallet contains a collection of key
pairs, each consisting of a private key and a public key. The private
key (k) is a number, usually derived from a number picked at random.
@ -73,8 +73,8 @@ generate a public key (K).
.Why Use Asymmetric Cryptography (Public/Private Keys)?
****
((("cryptography", "asymmetric")))((("digital signatures", "asymmetric
cryptography and")))((("asymmetric cryptography")))Why is asymmetric
((("digital signatures", "asymmetric
cryptography and")))Why is asymmetric
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
@ -92,7 +92,7 @@ signatures.
==== Private Keys
((("keys and addresses", "overview of", "private key
generation")))((("warnings and cautions", "private key protection")))A
generation")))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
@ -136,7 +136,7 @@ Otherwise, we simply try again with another random number.
[WARNING]
====
((("random numbers", "random number generation")))((("entropy", "random
((("entropy", "random
number generation")))Do not write your own code to create a random
number or use a "simple" random number generator offered by your
programming language. Use a cryptographically secure pseudorandom number
@ -288,13 +288,13 @@ Now that we have defined addition, we can define multiplication in the
standard way that extends addition. For a point P on the elliptic curve,
if k is a whole number, then kP = P + P + P + ... + P (k times). Note
that k is sometimes confusingly called an "exponent" in this case.((("",
startref="eliptic04")))((("", startref="Celliptic04")))
startref="eliptic04")))
[[public_key_derivation]]
==== Public Keys
((("keys and addresses", "overview of", "public key
calculation")))((("generator point")))The public key is calculated from
calculation")))The public key is calculated from
the private key using elliptic curve multiplication, which is
irreversible: _K_ = _k_ * _G_, where _k_ is the private key, _G_ is a
constant point called the _generator point_, and _K_ is the resulting
@ -317,7 +317,7 @@ signatures that prove control over bitcoin funds.
====
((("keys and addresses", "overview of", "public key
generation")))((("generator point")))Starting with a private key in the
generation")))Starting with a private key in the
form of a randomly generated number _k_, we multiply it by a
predetermined point on the curve called the _generator point_ _G_ to
produce another point somewhere else on the curve, which is the
@ -379,7 +379,7 @@ geometric operation on the curve.
[TIP]
====
((("OpenSSL cryptographic library")))Many Bitcoin implementations use
Many Bitcoin implementations use
the https://github.com/bitcoin-core/secp256k1[libsecp256k1 crytographic
library] to do the elliptic curve math.
====
@ -727,7 +727,7 @@ image::images/mbc2_0405.png["pubkey_to_address"]
//https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2011-November/000778.html
((("public and private keys", "compressed public keys")))
When Bitcoin was first authored, its developers only knew how to create
65-byte public keys. However, a later developer became aware of an
alternative encoding for public keys that used only 33 bytes and which
@ -1375,7 +1375,7 @@ support for new Bitcoin features as soon as they become available.
[[priv_formats]]
==== Private key formats
((("public and private keys", "private key formats")))The private key
The private key
can be represented in a number of different formats, all of which
correspond to the same 256-bit number. <<table_4-2>> shows several common
formats used to represent private keys. Different formats are used in
@ -1438,7 +1438,7 @@ can easily be converted to any other format.
[[comp_priv]]
===== Compressed private keys
((("public and private keys", "compressed private keys")))
the commonly used term "compressed private key" is a misnomer, because when a private
key is exported as WIF-compressed it is actually one byte _longer_ than
an "uncompressed" private key. That is because the private key has an
@ -1500,14 +1500,14 @@ from older wallets.
=== Advanced Keys and Addresses
((("keys and addresses", "advanced forms", id="KAadvanced04")))In the
In the
following sections we will look at advanced forms of keys and addresses,
such as vanity addresses and paper wallets.
==== Vanity Addresses
((("keys and addresses", "advanced forms", "vanity
addresses")))((("vanity addresses", id="vanity04")))((("addresses",
addresses")))((("addresses",
"vanity addresses", id="Avanity04")))Vanity addresses are valid Bitcoin
addresses that contain human-readable messages. For example,
+1LoveBPzzD72PUXLzCkYAtGFYmK5vYNR33+ is a valid address that contains
@ -1603,7 +1603,7 @@ repeat until successful.
===== Vanity address security and privacy
((("security", "vanity addresses")))Vanity addresses were popular in the
Vanity addresses were popular in the
early years of Bitcoin but have almost entirely disappeared from use as
of 2023. There are two likely causes for this trend:
@ -1634,7 +1634,7 @@ the future unless the above problems are solved.
[[paper_wallets]]
==== Paper Wallets
((("keys and addresses", "advanced forms", "paper wallets")))((("paper
((("paper
wallets", id="paperw04")))((("wallets", "types of", "paper wallets",
id="Wpaper04")))Paper wallets are private keys printed on paper.
Often the paper wallet also includes the corresponding Bitcoin address
@ -1679,8 +1679,8 @@ opaque scratch-off stickers, or folded and sealed with tamper-proof
adhesive foil. Other designs feature additional copies of the key and
address, in the form of detachable stubs similar to ticket stubs,
allowing you to store multiple copies to protect against fire, flood, or
other natural disasters.((("", startref="KAadvanced04")))((("",
startref="Wpaper04")))((("", startref="paperw04")))
other natural disasters.((("",
startref="Wpaper04")))
[[paper_wallet_spw]]
.An example of a paper wallet with additional copies of the keys on a backup "stub"

@ -1,7 +1,7 @@
[[mining]]
== Mining and Consensus
((("mining and consensus", "purpose of")))The word "mining" is somewhat
The word "mining" is somewhat
misleading. By evoking the extraction of precious metals, it focuses our
attention on the reward for mining, the new bitcoins created in each
block. Although mining is incentivized by this reward, the primary
@ -13,17 +13,17 @@ transactions are validated and cleared. Mining is one of the inventions that
makes Bitcoin special, a decentralized consensus mechanism that is the
basis for P2P digital cash.
((("mining and consensus", "decentralized consensus")))((("central
((("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 bitcoins and
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.
[TIP]
====
((("decentralized systems", "bitcoin mining and")))
Mining
is one of the mechanisms by which Bitcoin's _consensus security_ is _decentralized_.
====
@ -52,8 +52,8 @@ In some protocols built on top of Bitcoin, the topological order of
Bitcoin transactions is also used to establish a sequence of events;
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",
((("mining and consensus", "mining rewards
and fees")))((("mining and consensus",
"Proof-of-Work algorithm")))Miners receive two types of rewards in
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
@ -103,7 +103,7 @@ consensus.
=== Bitcoin Economics and Currency Creation
((("mining and consensus", "bitcoin economics and currency
creation")))((("currency creation")))((("money supply")))((("issuance
creation")))((("issuance
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 bitcoins, created from nothing. Every
@ -168,7 +168,7 @@ to inflate the supply of bitcoin.
.Deflationary Money
****
((("deflationary money")))The most important and debated consequence of
The most important and debated consequence of
fixed and diminishing monetary issuance is that the currency tends to be
inherently _deflationary_. Deflation is the phenomenon of appreciation
of value due to a mismatch in supply and demand that drives up the value
@ -206,7 +206,7 @@ outweighs the risks of deflation.
=== Decentralized Consensus
((("mining and consensus", "decentralized consensus")))((("decentralized
((("decentralized
systems", "consensus in")))In the previous chapter we looked at the
blockchain, the global list of all transactions, which
everyone in the Bitcoin network accepts as the authoritative record of
@ -226,7 +226,7 @@ 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
((("mining and consensus", "emergent
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
@ -261,7 +261,7 @@ trusted, public, global blockchain.
=== Independent Verification of Transactions
((("mining and consensus", "independent transaction
verification")))((("transactions", "independent verification of")))In
verification")))In
<<c_transactions>>, we saw how wallet software creates transactions by
collecting UTXOs, providing the appropriate authentication data, and then
constructing new outputs assigned to a new owner. The resulting
@ -316,7 +316,7 @@ _mempool_.
=== Mining Nodes
((("mining and consensus", "mining nodes")))((("Bitcoin nodes", "mining
((("Bitcoin nodes", "mining
nodes")))Some of the nodes on the Bitcoin network are specialized nodes
called _miners_. Jing is a
Bitcoin miner; he
@ -334,7 +334,7 @@ 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
Alice buys something, Jing's
node is caught up with the chain of blocks with the most proof-of-work.
Jing's node is listening
for transactions, trying to mine a new block and also listening for
@ -352,7 +352,7 @@ transactions in the memory pool and remove any that were included in
that block. Whatever transactions remain in the memory pool are
unconfirmed and are waiting to be recorded in a new block.
((("Proof-of-Work algorithm")))((("mining and consensus", "Proof-of-Work
((("mining and consensus", "Proof-of-Work
algorithm")))Jing's node immediately constructs a new partial block, a
candidate for the next block. This block is called a _candidate block_
because it is not yet a valid block, as it does not contain a valid
@ -365,7 +365,7 @@ transaction fees he'll attempt to claim.
==== The Coinbase Transaction
((("coinbase transactions", id="coinbtrans10")))((("transactions",
((("transactions",
"coinbase transactions", id="Tcoinb10")))The first transaction in any
block is a special transaction, called a _coinbase transaction_. This
transaction is constructed by Jing's node and pays out his _reward_ for
@ -389,8 +389,8 @@ reward.
==== Coinbase Reward and Fees
((("coinbase transactions", "rewards and fees")))((("fees", "transaction
fees")))((("mining and consensus", "rewards and fees")))To construct the
((("fees", "transaction
fees")))To construct the
coinbase transaction, Jing's node first calculates the total amount of
transaction fees:
@ -430,7 +430,7 @@ The initial subsidy is calculated in satoshis by multiplying 50 with the
+COIN+ constant (100,000,000 satoshis). This sets the initial reward
(+nSubsidy+) at 5 billion satoshis.
((("halvings")))Next, the function calculates the number of +halvings+
Next, the function calculates the number of +halvings+
that have occurred by dividing the current block height by the halving
interval (+SubsidyHalvingInterval+).
@ -458,7 +458,7 @@ only gets to spend the reward if the block is accepted by everyone.
==== Structure of the Coinbase Transaction
((("coinbase transactions", "structure of")))With these calculations,
With these calculations,
Jing's node then constructs the coinbase transaction to pay himself
the block reward.
@ -504,14 +504,14 @@ the miners, as we will see next.
[[duplicate_transactions]]
==== Coinbase Data
((("coinbase transactions", "coinbase data")))Coinbase transactions do
Coinbase transactions do
not have an input script field. Instead, this
field is replaced by coinbase data, which must be between 2 and 100
bytes. Except for the first few bytes, the rest of the coinbase data can
be used by miners in any way they want; it is arbitrary data.
((("nonce values")))((("blocks", "genesis block")))((("blockchain
(the)", "genesis block")))((("genesis block")))In the genesis block, for
((("blockchain
(the)", "genesis block")))In the genesis block, for
example, Satoshi Nakamoto added the text "The Times 03/Jan/2009
Chancellor on brink of second bailout for banks" in the coinbase data,
using it as a proof of the earliest date this block chould have been
@ -526,8 +526,8 @@ version field set to 2 or higher) must contain the block height as a script
=== Constructing the Block Header
((("mining and consensus", "constructing block headers")))((("blocks",
"headers")))((("headers")))((("blockchain (the)", "block headers")))To
((("blocks",
"headers")))To
construct the block header, the mining node needs to fill in six fields,
as listed in <<block_header_structure_ch10>>.
@ -564,7 +564,7 @@ Today, VersionBits field has no meaning unless there's an attempt to
upgrade the consensus protocol underway, in which case you will need to
read its documentation to determine how it is using VersionBits.
((("blocks", "parent blocks")))((("parent blocks")))Next, the mining
Next, the mining
node needs to add the "Previous Block Hash" (also known as +prevhash+).
That is the hash of the block header of the previous block
received from the network, which Jing's node has accepted and
@ -577,7 +577,7 @@ Block Hash field in the candidate block header, Jing is committing his
mining power to extending the chain that ends in that specific block.
====
((("merkle trees")))((("blockchain (the)", "merkle trees")))The next
The next
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
@ -622,15 +622,15 @@ the header before a version is found that satisfies the requirement.
=== Mining the Block
((("mining and consensus", "mining the block", id="MACmining10")))Now
Now
that a candidate block has been constructed by Jing's node, it is time
for Jing's hardware mining rig to "mine" the block, to find a solution
to the Proof-of-Work algorithm that makes the block valid. Throughout
this book we have studied cryptographic hash functions as used in
various aspects of the Bitcoin system. The hash function SHA256 is the
function used in Bitcoin's mining process.((("", startref="jingten")))
function used in Bitcoin's mining process.
((("mining and consensus", "defined")))In the simplest terms, mining is
In the simplest terms, mining is
the process of hashing the candidate block header repeatedly, changing one
parameter, until the resulting hash matches a specific target. The hash
function's result cannot be determined in advance, nor can a pattern be
@ -641,14 +641,14 @@ until the desired hash result appears by chance.
==== Proof-of-Work Algorithm
((("Proof-of-Work algorithm", id="proof10")))((("mining and consensus",
((("mining and consensus",
"Proof-of-Work algorithm", id="Cproof10")))A hash algorithm takes an
arbitrary-length data input and produces a fixed-length deterministic
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")))A key characteristic of a cryptographic hash
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
@ -753,7 +753,7 @@ the target. A lower target means it is more difficult to find a hash
below the target. The target and difficulty are inversely related.
====
((("targets")))Bitcoin's Proof-of-Work is very similar to the challenge
Bitcoin's Proof-of-Work is very similar to the challenge
shown in <<sha256_example_generator_output>>. The miner constructs a
candidate block filled with transactions. Next, the miner calculates the
hash of this block's header and sees if it is smaller than the current
@ -769,7 +769,7 @@ enough block header hash.
//TODO:use visual representation like I did on bitcoin.org
((("mining and consensus", "mining the block", "target
representation")))((("targets", id="targets10")))
representation")))
Block headers contain the target in a notation called "target
bits" or just "bits," which in block 277,316 has the value of
+0x1903a30c+. This notation expresses the Proof-of-Work target as a
@ -929,7 +929,7 @@ electricity into hashing computation at the highest rate possible. The
primary influence on the mining market is the price of one kilowatt-hour
of electricity in bitcoin, because that determines the profitability of
mining and therefore the incentives to enter or exit the mining
market.((("", startref="targets10")))
market.
[[mtp]]
=== Median Time Past (MTP)
@ -988,7 +988,7 @@ sequence, +CLTV+, and +CSV+.
=== Successfully Mining the Block
((("mining and consensus", "mining the block", "successful
completion")))((("use cases", "mining for bitcoin", id="jingtentwo")))As
completion")))As
we saw earlier, Jing's node has constructed a candidate block and
prepared it for mining. Jing has several hardware mining rigs with
application-specific integrated circuits, where hundreds of thousands of
@ -1021,12 +1021,12 @@ chain it extends.
In the next section, we'll look at the process each node uses to
validate a block and select the most-work chain, creating the consensus
that forms the decentralized blockchain.((("",
startref="MACmining10")))((("", startref="jingtentwo")))
startref="MACmining10")))
=== Validating a New Block
((("mining and consensus", "new block validation")))((("blocks", "new
block validation")))((("validation")))The third step in Bitcoin's
((("blocks", "new
block validation")))The third step in Bitcoin's
consensus mechanism is independent validation of each new block by every
node on the network. As the newly solved block moves across the network,
each node performs a series of tests to validate it.
@ -1154,8 +1154,8 @@ forks (in addition to other problems), so many people prefer Bitcoin's
====
((("",
startref="Bassemble10")))((("", startref="MACassembling10")))((("",
startref="forks10")))((("", startref="BCTfork10")))
startref="Bassemble10")))((("",
startref="forks10")))
=== Mining and the Hash Lottery
@ -1181,7 +1181,7 @@ a rapid pace.
[[extra_nonce]]
==== The Extra Nonce Solution
((("nonce values")))Since 2012, mining has evolved to resolve a
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
the nonce until the resulting hash was below the target. As difficulty
@ -1222,7 +1222,7 @@ entire left flank of the merkle tree up to the root.
[[mining_pools]]
==== Mining Pools
((("mining pools", id="MACoverpool10")))((("mining pools", "benefits
((("mining pools", "benefits
of")))In this highly competitive environment, individual miners working
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
@ -1263,7 +1263,7 @@ the miners' Bitcoin addresses, once their share of the rewards has
reached a certain threshold. Typically, the pool server charges a
percentage fee of the rewards for providing the pool-mining service.
((("mining pools", "operation of")))Miners participating in a pool split
Miners participating in a pool split
the work of searching for a solution to a candidate block, earning
"shares" for their mining contribution. The mining pool sets a higher
target (lower difficulty) for earning a share, typically more than 1,000
@ -1322,7 +1322,7 @@ whole pool wins.
===== Managed pools
((("mining pools", "managed pools")))((("pool operators",
((("pool operators",
seealso="mining pools")))Most mining pools are "managed," meaning that
there is a company or individual running a pool server. The owner of the
pool server is called the _pool operator_, and he charges pool miners a
@ -1356,7 +1356,7 @@ using their own full node.
===== Peer-to-peer mining pool (P2Pool)
((("mining pools", "peer-to-peer pools (P2Pool)")))((("peer-to-peer
((("peer-to-peer
pools (P2Pool)")))Managed pools using Stratum v1 create the possibility of cheating by
the pool operator, who might direct the pool effort to double-spend
transactions or invalidate blocks (see <<consensus_attacks>>).
@ -1403,7 +1403,7 @@ robust overall, as part of a diversified mining ecosystem. As of this
writing, P2Pool has fallen into disuse, but new protocols such as
Stratum v2 can allow individual miners to choose the transactions they
include in their blocks.((("",
startref="MAChash10")))((("", startref="MACoverpool10")))
startref="MAChash10")))
[[consensus_attacks]]
=== Hashrate Attacks
@ -1486,7 +1486,7 @@ original payment to Carol. Carol is now missing the three paintings and
also has no payment. Throughout all this activity, Paul's mining
pool participants might remain blissfully unaware of the double-spend
attempt, because they mine with automated miners and cannot monitor
every transaction or block.((("", startref="carolten")))
every transaction or block.
((("confirmations", "of large-value transactions",
secondary-sortas="large-value transactions")))To protect against this
@ -1575,7 +1575,7 @@ between all participants.
[[hard_forks]]
==== Hard Forks
((("forks", "changing consensus rules", id="forks10a")))((("forks",
((("forks",
"changing consensus rules", "hard forks")))In <<forks>> we looked at how
the Bitcoin network may briefly diverge, with two parts of the network
following two different branches of the blockchain for a short time. We
@ -1644,7 +1644,7 @@ valid block.
==== Hard Forks: Software, Network, Mining, and Chain
((("forks", "changing consensus rules", "software forks")))For software
For software
developers, the term "fork" has another meaning, adding confusion to the
term "hard fork." In open source software, a fork occurs when a group of
developers choose to follow a different software roadmap and start a
@ -1740,7 +1740,7 @@ transactions.
==== Contentious Hard Forks
((("forks", "changing consensus rules", "contentious hard
forks")))((("hard forks")))This is the dawn of the development of software
forks")))This is the dawn of the development of software
for decentralized consensus. Just as other innovations in development changed both the methods
and products of software and created new methodologies, new tools, and
new communities in its wake, consensus software development also
@ -1765,7 +1765,7 @@ consensus modifications.
==== Soft Forks
((("forks", "changing consensus rules", "soft forks")))((("soft forks",
((("soft forks",
"defined")))Not all consensus rule changes cause a hard fork. Only
consensus changes that are forward-incompatible cause a fork. If the
change is implemented in such a way that an unmodified client still sees
@ -1792,7 +1792,7 @@ nonupgraded nodes out of consensus.
===== Soft forks redefining NOP opcodes
((("opcodes", "redefinition by soft forks")))((("soft forks",
((("soft forks",
"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
@ -1811,7 +1811,7 @@ the old clients, the script contains an NOP code, which is ignored.
==== Criticisms of Soft Forks
((("forks", "changing consensus rules", "soft fork drawbacks")))((("soft
((("soft
forks", "drawbacks of")))Soft forks based on the NOP opcodes are
relatively uncontroversial. The NOP opcodes were placed in Bitcoin
Script with the explicit goal of allowing non-disruptive upgrades.
@ -1840,13 +1840,13 @@ a loss of funds under the old rules. For example, if a CLTV transaction
is evaluated under the old rules, there is no timelock constraint and it
can be spent at any time. Therefore, critics contend that a failed soft
fork that had to be reversed because of a bug would almost certainly
lead to loss of funds.((("", startref="Crule10")))
lead to loss of funds.
[[softforksignaling]]
=== Soft Fork Signaling with Block Version
((("forks", "changing consensus rules", "soft fork
activation")))((("soft forks", "activation")))Since soft forks allow
activation")))Since soft forks allow
unmodified clients to continue to operate within consensus, one
mechanism for "activating" a soft fork is through miners signaling that
they are ready and willing to enforce the new consensus rules. If
@ -2006,7 +2006,7 @@ image::images/mbc2_1010.png[BIP9 Proposal State Transition Diagram]
BIP9 was first implemented for the activation of +CHECKSEQUENCEVERIFY+
and associated BIPs (68, 112, 113). The proposal named "csv" was
activated successfully in July of 2016.((("", startref="forks10a")))
activated successfully in July of 2016.
The standard is defined in
https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki[BIP9
@ -2117,7 +2117,7 @@ state of this system with only a few changes possible if there is strong
consensus by a very large majority. The 95% threshold for soft forks is
reflective of this reality.
((("hard forks")))It is important to recognize that there is no perfect
It is important to recognize that there is no perfect
solution for consensus development. Both hard forks and soft forks
involve tradeoffs. For some types of changes, soft forks may be a better
choice; for others, hard forks may be a better choice. There is no

@ -1,7 +1,7 @@
[[bitcoin_network_ch08]]
== The Bitcoin Network
((("Bitcoin network", "peer-to-peer architecture")))((("peer-to-peer
((("peer-to-peer
(P2P)")))Bitcoin is structured as a peer-to-peer network architecture on
top of the internet. The term peer-to-peer, or P2P, means that the
full nodes which participate in the network are peers to each other, that
@ -26,7 +26,7 @@ characteristic. Decentralization of control is a core design principle
that can only be achieved and maintained by a flat and decentralized P2P
consensus network.
((("Bitcoin network", "defined")))The term "Bitcoin network" refers to
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 wallets. These additional
@ -55,8 +55,8 @@ only a subset of the blockchain and partly verify transactions using a method
called _simplified payment verification_, or SPV. ((("lightweight
clients")))These clients are known as lightweight clients.
((("Bitcoin nodes", "mining nodes")))((("mining and consensus", "mining
nodes")))((("Proof-of-Work algorithm")))((("mining and consensus",
((("mining and consensus", "mining
nodes")))((("mining and consensus",
"Proof-of-Work algorithm")))Miners compete to create new blocks by
running specialized hardware to solve the Proof-of-Work algorithm. Some
miners operate full nodes, validating every block on the
@ -74,7 +74,7 @@ mining pool protocols and lightweight client-access protocols.
=== The Network
((("", startref="BNnode08")))((("", startref="BNtype08")))((("Bitcoin
((("Bitcoin
network", "extended network activities")))As of this writing, the main Bitcoin network,
running the Bitcoin P2P protocol, consists of about 10,000
listening nodes running various versions of Bitcoin Core and a few
@ -249,7 +249,7 @@ several Virtual Private Servers (VPSes) hosted on
infrastructure around the world and served to connect the majority of
miners and mining pools.
((("Fast Internet Bitcoin Relay Engine (FIBRE)")))((("Compact Block
((("Compact Block
optimization")))The original Bitcoin Relay Network was replaced in 2016
with the introduction of the _Fast Internet Bitcoin Relay Engine_ or
https://bitcoinfibre.org[_FIBRE_], also created by developer Matt
@ -419,14 +419,14 @@ connection for too long, it is assumed to be disconnected
and a new peer will be sought. Thus, the network dynamically adjusts to
transient nodes and network problems, and can organically grow and
shrink as needed without any central control.((("",
startref="BNextend08")))((("", startref="BNodiscover08")))
startref="BNextend08")))
=== Full Nodes
Full nodes are nodes that verify every transaction in every block on the
valid blockchain with the most proof of work.
((("blocks", "genesis block")))((("genesis block")))((("blockchain
((("blockchain
(the)", "genesis block")))Full nodes
independently process every block, starting after the very first
block (genesis block) and building up to the latest known block in the
@ -437,11 +437,11 @@ receive updates about new blocks of transactions, which it then verifies
and incorporates into its local view of which scripts control which
bitcoins, called the set of _unspent transaction outputs_ (UTXOs).
((("Bitcoin nodes", "full nodes")))Running a full node gives
Running a full node gives
you the pure Bitcoin experience: independent verification of all
transactions without the need to rely on, or trust, any other systems.
((("Satoshi client")))There are a few alternative implementations of
There are a few alternative implementations of
full nodes, built using different programming
languages and software architectures, or which made different design
decisions. However, the most common
@ -453,7 +453,7 @@ command +getpeerinfo+ as we saw earlier; for example, +/Satoshi:24.0.1/+.
=== Exchanging "Inventory"
((("Bitcoin network", "syncing the blockchain")))The first thing a full
The first thing a full
node will do once it connects to peers is try to construct a complete
chain of block headers. If it is a brand-new node and has no blockchain at all, it
only knows one block, the genesis block, which is statically embedded in
@ -461,7 +461,7 @@ the client software. Starting after block #0 (the genesis block), the new
node will have to download hundreds of thousands of blocks to
synchronize with the network and reestablish the full blockchain.
((("blockchain (the)", "syncing the blockchain")))((("syncing")))The
The
process of syncing the blockchain starts with the +version+ message,
because that contains +BestHeight+, a node's current blockchain height
(number of blocks). A node will see the +version+ messages from its
@ -607,13 +607,13 @@ incoming and outgoing transactions.
Bloom filters allow lightweight clients to receive a subset of
the transactions without directly revealing precisely which addresses they are
interested in, through a filtering mechanism that uses probabilities
rather than fixed patterns.((("", startref="BNspvnodes08")))((("",
rather than fixed patterns.((("",
startref="simple08")))
[[bloom_filters]]
=== Bloom Filters
((("bitcoin network", "bloom filters", id="BNebloom08")))((("bloom
((("bloom
filters", id="bloom08")))((("privacy, maintaining",
id="privacy08")))((("security", "maintaining privacy",
id="Sprivacy08")))A bloom filter is a probabilistic search filter, a way
@ -742,7 +742,7 @@ them) that a lightweight client receives from its peers, selecting only
transactions of interest to the lightweight client without revealing exactly which
addresses or keys it is interested in.
((("transaction IDs (txid)")))A lightweight client will initialize a bloom filter
A lightweight client will initialize a bloom filter
as "empty"; in that state the bloom filter will not match any patterns.
The lightweight client will then make a list of all the addresses, keys, and
hashes that it is interested in. It will do this by extracting the
@ -751,7 +751,7 @@ controlled by its wallet. The lightweight client then adds each of these to the
bloom filter, so that the bloom filter will "match" if these patterns
are present in a transaction, without revealing the patterns themselves.
((("Bitcoin nodes", "full nodes")))The lightweight client will then send a
The lightweight client will then send a
+filterload+ message to the peer, containing the bloom filter to use on
the connection. On the peer, bloom filters are checked against each
incoming transaction. The full node checks several parts of the
@ -1139,7 +1139,7 @@ client.
=== Encrypted and Authenticated Connections
((("Bitcoin network", "encrypted
connections")))((("encryption")))((("authentication")))Most new users of
connections")))Most new users of
Bitcoin assume that the network communications of a Bitcoin node are
encrypted. In fact, the original implementation of Bitcoin communicates
entirely in the clear, as does the modern implementation of Bitcoin Core
@ -1151,7 +1151,7 @@ communications: _Tor Transport_.
==== Tor Transport
((("Tor network")))((("The Onion Routing network (Tor)")))Tor, which
Tor, which
stands for _The Onion Routing network_, is a software project and
network that offers encryption and encapsulation of data through
randomized network paths that offer anonymity, untraceability and
@ -1183,8 +1183,8 @@ online tutorials.
[[mempool]]
=== Mempools and orphan pools
((("Bitcoin network", "transaction pools")))((("transaction
pools")))((("memory pools (mempools)")))Almost every node on the Bitcoin
((("transaction
pools")))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
@ -1194,7 +1194,7 @@ As unconfirmed transactions are received and verified, they are added to the
mempool and relayed to the neighboring nodes to propagate on
the network.
((("orphan pools")))((("transactions", "orphaned")))Some node
Some node
implementations also maintain a separate pool of orphaned transactions.
If a transaction's inputs refer to a transaction that is not yet known,
such as a missing parent, the orphan transaction will be stored

@ -1,7 +1,7 @@
[[ch02_bitcoin_overview]]
== How Bitcoin Works
((("bitcoin", "overview of", id="BCover02")))((("central trusted
((("central trusted
authority")))((("decentralized systems", "bitcoin overview",
id="DCSover02")))The Bitcoin system, unlike traditional banking and
payment systems, does not require trust in third parties. Instead of a central
@ -22,7 +22,7 @@ transactions that are propagated across the network, and miners who
produce (through competitive computation) the consensus blockchain,
which is the authoritative journal of all transactions.
((("blockchain explorer sites")))Each example in this chapter is based
Each example in this chapter is based
on an actual transaction made on the Bitcoin network, simulating the
interactions between several users by sending
funds from one wallet to another. While tracking a transaction through
@ -36,7 +36,7 @@ relationships and flows between them.
.Bitcoin overview
image::images/mbc2_0201.png["Bitcoin Overview"]
((("Bitcoin Block Explorer")))Popular blockchain explorers include:
Popular blockchain explorers include:
* https://blockstream.info/[Blockstream Explorer]
* https://mempool.space[Mempool.Space]
@ -81,7 +81,7 @@ Alice is offered the option to pay with bitcoin, in addition to the
usual options. The checkout cart displays the price in US dollars and
also in bitcoin (BTC), at Bitcoin's prevailing exchange rate.
((("payment requests")))((("QR codes", "payment requests")))Bob's
Bob's
e-commerce system will automatically create a QR code containing an
_invoice_ (<<invoice-QR>>).
@ -103,7 +103,7 @@ image::images/mbc2_0202.png["payment-request"]
[TIP]
====
((("QR codes", "warnings and cautions")))((("transactions", "warnings
((("transactions", "warnings
and cautions")))((("warnings and cautions", "avoid sending money to
addresses appearing in book")))Try to scan this with your wallet to see
the address and amount but DO NOT SEND MONEY.
@ -131,7 +131,7 @@ register.
[NOTE]
====
((("fractional values")))((("milli-bitcoin")))((("satoshis")))The
The
Bitcoin network can transact in fractional values, e.g., from
millibitcoin (1/1000th of a bitcoin) down to 1/100,000,000th of a
bitcoin, which is known as a satoshi. This book uses the same
@ -160,7 +160,7 @@ can spend that amount in subsequent transactions.
=== Bitcoin Transactions
((("transactions", "defined")))In simple terms, a transaction tells the
In simple terms, a transaction tells the
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
@ -168,12 +168,12 @@ owner, and so on, in a chain of ownership.
==== Transaction Inputs and Outputs
((("transactions", "overview of", id="Tover02")))((("outputs and
((("outputs and
inputs", "basics of")))Transactions are like lines in a double-entry
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.
((("fees", "transaction fees")))The inputs
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
@ -184,7 +184,7 @@ blockchain. A Bitcoin transaction is shown as a bookkeeping ledger entry in
The transaction also contains proof of ownership for each amount of
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. 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.
@ -194,7 +194,7 @@ image::images/mbc2_0203.png["Transaction Double-Entry"]
==== Transaction Chains
((("chain of transactions")))Alice's payment to Bob's Store uses a
Alice's payment to Bob's Store uses a
previous transaction's output as its input. In the previous chapter,
Alice received bitcoins from her friend Joe in return for cash.
We've labeled that as _Transaction 1_ (Tx1) in <<transaction-chain>>.
@ -252,7 +252,7 @@ that's what the protocol itself uses.
==== Making Change
((("change, making")))((("change addresses")))((("addresses", "change
((("addresses", "change
addresses")))In addition to one or more outputs that pay the receiver of
bitcoins, many transactions will also include an output that pays the
spender of the bitcoins, called a _change_ output.
@ -327,7 +327,7 @@ 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
employees.((("", startref="Tover02")))
employees.
[[transaction-distributing]]
.Batch transaction distributing funds
@ -335,7 +335,7 @@ image::images/mbc2_0207.png["Distributing Transaction"]
=== Constructing a Transaction
((("transactions", "constructing", id="Tconstruct02")))((("wallets",
((("wallets",
"constructing transactions")))Alice's wallet application contains all
the logic for selecting inputs and generating outputs to build a
transaction to Alice's specification. Alice only needs to choose a
@ -349,7 +349,7 @@ while connected to the Bitcoin network.
==== Getting the Right Inputs
((("outputs and inputs", "locating and tracking inputs")))Alice's wallet
Alice's wallet
application will first have to find inputs that can pay the amount she
wants to send to Bob. Most wallets keep track of all the available
outputs belonging to addresses in the wallet. Therefore, Alice's wallet
@ -373,7 +373,7 @@ wallet application creates the transaction outputs (payments).
==== Creating the Outputs
((("outputs and inputs", "creating outputs")))A transaction output is
A transaction output is
created with a
script that says something like, "This output is paid to whoever can
present a signature from the key corresponding to Bob's public address."
@ -416,7 +416,7 @@ blocks are added.
===== Transmitting the transaction
((("propagation", "process of")))Because the transaction contains all
Because the transaction contains all
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
@ -425,7 +425,7 @@ network is to propagate transactions and blocks to all participants.
===== How it propagates
((("Bitcoin nodes", "defined")))((("nodes", see="Bitcoin nodes")))
Peers in the Bitcoin peer-to-peer network are programs that have both
the software logic and the data necessary for them to fully verify the
correctness of a new transaction. The connections between peers are
@ -441,7 +441,7 @@ 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
technique")))Any Bitcoin node that receives a
valid transaction it has not seen before will forward it to
all other nodes to which it is connected, a propagation technique known
as _gossiping_. Thus, the transaction rapidly propagates out across the
@ -478,7 +478,7 @@ computation to verify as correct.
The mining process serves two purposes in Bitcoin:
* ((("mining and consensus", "consensus rules", "security provided
by")))((("consensus", see="mining and consensus")))Miners can only
by")))Miners can only
receive honest income from creating blocks that follow all of Bitcoin's
_consensus rules_. Therefore, miners are normally incentivized to
only include valid transactions in their blocks and the blocks they
@ -541,7 +541,7 @@ software to create candidate blocks that assign the reward to a pool address.
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
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 candidate block.
@ -583,7 +583,7 @@ You can see the block that includes
https://blockstream.info/block/000000000000000000027d39da52dd790d98f85895b02e764611cb7acf552e90[Alice's transaction].
====
((("confirmations", "role in transactions")))Approximately 19 minutes
Approximately 19 minutes
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
@ -596,7 +596,7 @@ transaction counts as an additional confirmation. As the blocks pile on
top of each other, it becomes harder to reverse the transaction, thereby
giving Bob more and more confidence that Alice's payment is secure.
((("genesis block")))((("blocks", "genesis block")))((("blockchain
((("blockchain
(the)", "genesis block")))In <<block-alice1>>, we can
the block which contains Alice's transaction. Below it are
hundreds of thousands of blocks, linked to each other in a chain of
@ -607,7 +607,7 @@ By convention, any block with more than six confirmations
is considered very hard to change, because it would require an immense amount of
computation to recalculate six blocks (plus one new block). We will examine
the process of mining and the way it builds confidence in more detail in
<<mining>>.((("", startref="BToverview02")))((("",
<<mining>>.((("",
startref="MACover02")))
[[block-alice1]]

@ -3,27 +3,27 @@
=== Writing the Bitcoin Book
((("bitcoin", "benefits of", id="BCbasicbenefits0")))((("decentralized systems", "bitcoin as")))I (Andreas) first stumbled upon Bitcoin in mid-2011. My immediate reaction was more or less "Pfft! Nerd money!" and I ignored it for another six months, failing to grasp its importance. This is a reaction that I have seen repeated among many of the smartest people I know, which gives me some consolation. The second time I came across Bitcoin, in a mailing list discussion, I decided to read the whitepaper written by Satoshi Nakamoto and see what it was all about. ((("digital currencies", "bitcoin vs. others")))I still remember the moment I finished reading those nine pages, when I realized that Bitcoin was not simply a digital currency, but a network of trust that could also provide the basis for so much more than just currencies. The realization that "this isn't money, it's a decentralized trust network," started me on a four-month journey to devour every scrap of information about Bitcoin I could find. I became obsessed and enthralled, spending 12 or more hours each day glued to a screen, reading, writing, coding, and learning as much as I could. I emerged from this state of fugue, more than 20 pounds lighter from lack of consistent meals, determined to dedicate myself to working on Bitcoin.
I (Andreas) first stumbled upon Bitcoin in mid-2011. My immediate reaction was more or less "Pfft! Nerd money!" and I ignored it for another six months, failing to grasp its importance. This is a reaction that I have seen repeated among many of the smartest people I know, which gives me some consolation. The second time I came across Bitcoin, in a mailing list discussion, I decided to read the whitepaper written by Satoshi Nakamoto and see what it was all about. I still remember the moment I finished reading those nine pages, when I realized that Bitcoin was not simply a digital currency, but a network of trust that could also provide the basis for so much more than just currencies. The realization that "this isn't money, it's a decentralized trust network," started me on a four-month journey to devour every scrap of information about Bitcoin I could find. I became obsessed and enthralled, spending 12 or more hours each day glued to a screen, reading, writing, coding, and learning as much as I could. I emerged from this state of fugue, more than 20 pounds lighter from lack of consistent meals, determined to dedicate myself to working on Bitcoin.
Two years later, after creating a number of small startups to explore various Bitcoin-related services and products, I decided that it was time to write my first book. Bitcoin was the topic that had driven me into a frenzy of creativity and consumed my thoughts; it was the most exciting technology I had encountered since the internet. It was now time to share my passion about this amazing technology with a broader audience.
=== 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.
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?
((("decentralized systems", "in nature")))The leafcutter ant is a species that exhibits highly complex behavior in a colony super-organism, but each individual ant operates on a set of simple rules driven by social interaction and the exchange of chemical scents (pheromones). Per Wikipedia: "Next to humans, leafcutter ants form the largest and most complex animal societies on Earth." Leafcutter ants don't actually eat leaves, but rather use them to farm a fungus, which is the central food source for the colony. Get that? These ants are farming!
The leafcutter ant is a species that exhibits highly complex behavior in a colony super-organism, but each individual ant operates on a set of simple rules driven by social interaction and the exchange of chemical scents (pheromones). Per Wikipedia: "Next to humans, leafcutter ants form the largest and most complex animal societies on Earth." Leafcutter ants don't actually eat leaves, but rather use them to farm a fungus, which is the central food source for the colony. Get that? These ants are farming!
Although ants form a caste-based society and have a queen for producing offspring, there is no central authority or leader in an ant colony. The highly intelligent and sophisticated behavior exhibited by a multimillion-member colony is an emergent property from the interaction of the individuals in a social network.
Nature demonstrates that decentralized systems can be resilient and can produce emergent complexity and incredible sophistication without the need for a central authority, hierarchy, or complex parts.
((("decentralized systems", "benefits of")))Bitcoin is a highly sophisticated decentralized trust network that can support myriad financial processes. Yet, each node in the Bitcoin network follows a few simple rules. The interaction between many nodes is what leads to the emergence of the sophisticated behavior, not any inherent complexity or trust in any single node. Like an ant colony, the Bitcoin network is a resilient network of simple nodes following simple rules that together can do amazing things without any central coordination.((("", startref="BCbasicbenefits0")))
Bitcoin is a highly sophisticated decentralized trust network that can support myriad financial processes. Yet, each node in the Bitcoin network follows a few simple rules. The interaction between many nodes is what leads to the emergence of the sophisticated behavior, not any inherent complexity or trust in any single node. Like an ant colony, the Bitcoin network is a resilient network of simple nodes following simple rules that together can do amazing things without any central coordination.
=== Conventions Used in This Book
((("typographical conventions")))The following typographical conventions are used in this book:
The following typographical conventions are used in this book:
_Italic_:: Indicates new terms, URLs, email addresses, filenames, and file extensions.
@ -61,9 +61,9 @@ All the code snippets use real values and calculations where possible, so that y
This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless youre 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 OReilly 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 products 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 (OReilly). Copyright 2023, ISBN 978-1-491-95438-6.”
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 (OReilly). 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.
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.
If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at pass:[<a href="mailto:permissions@oreilly.com">permissions@oreilly.com</a>].
@ -73,13 +73,13 @@ include::meta/third_edition_changes.asciidoc[]
=== Bitcoin Addresses and Transactions in This Book
((("getting started", "warnings and cautions")))((("warnings and cautions", "avoid sending money to addresses appearing in book")))((("keys and addresses", "warnings and cautions")))((("transactions", "warnings and cautions")))((("blockchain applications", "warnings and cautions")))((("QR codes", "warnings and cautions")))The Bitcoin addresses, transactions, keys, QR codes, and blockchain data used in this book are, for the most part, real. That means you can browse the blockchain, look at the transactions offered as examples, retrieve them with your own scripts or programs, etc.
The Bitcoin addresses, transactions, keys, QR codes, and blockchain data used in this book are, for the most part, real. That means you can browse the blockchain, look at the transactions offered as examples, retrieve them with your own scripts or programs, etc.
However, note that the private keys used to construct addresses are either printed in this book, or have been "burned." That means that if you send money to any of these addresses, the money will either be lost forever, or in some cases everyone who can read the book can take it using the private keys printed in here.
[WARNING]
====
DO NOT SEND MONEY TO ANY OF THE ADDRESSES IN THIS BOOK. Your money will be taken by another reader, or lost forever.((("", startref="codeuse00")))
DO NOT SEND MONEY TO ANY OF THE ADDRESSES IN THIS BOOK. Your money will be taken by another reader, or lost forever.
====
=== O'Reilly Safari
@ -96,7 +96,7 @@ For more information, please visit pass:[<a href="https://oreilly.com/safari" cl
=== How to Contact Us
((("comments and questions")))((("contact information")))Please address comments and questions concerning this book to the publisher:
Please address comments and questions concerning this book to the publisher:
++++
<ul class="simplelist">
@ -146,7 +146,7 @@ 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.
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.

@ -20,7 +20,7 @@ need to think about securing your bitcoins in a novel way too.
=== Security Principles
((("security", "security principles", id="Sprinc11")))((("decentralized
((("decentralized
systems", "security of")))The core principle in Bitcoin is
decentralization and it has important implications for security. A
centralized model, such as a traditional bank or payment network,
@ -63,7 +63,7 @@ able to adequately secure their keys and get hacked, one by one.
==== Developing Bitcoin Systems Securely
((("decentralized systems", "bitcoin as")))A critical principle
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.
@ -93,7 +93,7 @@ ultimately subvert Bitcoin's security.
==== The Root of Trust
((("root of trust concept")))Traditional security architecture is based
Traditional security architecture is based
upon a concept called the _root of trust_, which is a trusted core used
as the foundation for the security of the overall system or application.
Security architecture is developed around the root of trust as a series
@ -112,7 +112,7 @@ of a single system, then extending that root of trust through the
operating system to higher-level system services, and finally across
many servers layered in concentric circles of diminishing trust.
((("mining and consensus", "security and consensus")))Bitcoin security
Bitcoin security
architecture is different. In Bitcoin, the consensus system creates a
trusted blockchain that is completely decentralized. A correctly
validated blockchain uses the genesis block as the root of trust,
@ -146,7 +146,7 @@ startref="Sprinc11")))
=== User Security Best Practices
((("security", "user security best practices", id="Suser11")))((("use
((("use
cases", "user security best practices", id="UCsecurity11")))Humans have
used physical security controls for thousands of years. By comparison,
our experience with digital security is less than 50 years old. Modern
@ -193,8 +193,8 @@ we will examine various best practices for practical user security.
==== Physical Bitcoin Storage
((("storage", "physical bitcoin storage")))((("paper
wallets")))((("wallets", "types of", "paper wallets")))((("paper
((("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 bitcoins is to convert them into physical
@ -225,7 +225,7 @@ signing devices may become the predominant method of storing bitcoins.
==== Ensuring Your Access
((("risk, balancing and diversifying", seealso="security")))Although
Although
most users are rightly concerned about theft of thir bitcoins, there is an even
bigger risk. Data files get lost all the time. If they contain Bitcoin keys,
the loss is much more painful. In the effort to secure their Bitcoin
@ -262,7 +262,7 @@ storage).
==== Multisig and Governance
((("multisig addresses")))((("addresses", "multisig
((("addresses", "multisig
addresses")))Whenever a company or individual stores large amounts of
bitcoins, they should consider using a multisignature Bitcoin address.
Multisignature addresses secure funds by requiring more than one
@ -277,8 +277,8 @@ stored in different locations.
==== Survivability
((("survivability")))((("digital asset executors")))((("passwords",
"survivability and")))((("security", "passwords")))One important
((("passwords",
"survivability and")))One important
security consideration that is often overlooked is availability,
especially in the context of incapacity or death of the key holder.
Bitcoin users are told to use complex passwords and keep their keys
@ -292,7 +292,7 @@ If you have a lot of bitcoins, you should consider sharing access details
with a trusted relative or lawyer. A more complex survivability scheme
can be set up with multi-signature access and estate planning through a
lawyer specialized as a "digital asset executor."((("",
startref="Suser11")))((("", startref="UCsecurity11")))
startref="Suser11")))
Bitcoin is a completely new, unprecedented, and complex technology. Over
time we will develop better security tools and practices that are easier

@ -1,7 +1,7 @@
[[c_signatures]]
== Digital Signatures
((("digital signatures", "algorithm used")))((("Elliptic Curve Digital
((("Elliptic Curve Digital
Signature Algorithm (ECDSA)")))Two signature algorithms are currently
used in Bitcoin, the _schnorr signature algorithm_ and the _Elliptic
Curve Digital Signature Algorithm_ (_ECDSA_).
@ -14,7 +14,7 @@ keypath spending, and by the script functions +OP_CHECKSIG+,
Any time one of those is executed, a signature must be
provided.
((("digital signatures", "purposes of")))A digital signature serves
A digital signature serves
three purposes in Bitcoin. First, the
signature proves that the controller of a private key, who is by
implication the owner of the funds, has _authorized_ the spending of
@ -38,7 +38,7 @@ key.
=== How Digital Signatures Work
((("digital signatures", "how they work")))A digital signature
A digital signature
consists of two parts. The first part is an algorithm for creating a
signature for a message (the transaction) using a private key (the
signing key). The second part is an algorithm
@ -70,7 +70,7 @@ In both schnorr and ECDSA signatures, the function _F_~_sig_~ produces a signatu
two values. There are differences between the two values in the
different algorithms, which we'll explore later.
((("Distinguished Encoding Rules (DER)")))After the two values
After the two values
are calculated, they are serialized into a byte-stream. For ECDSA
signatures, the encoding uses an international standard encoding scheme
called the
@ -79,7 +79,7 @@ simpler serialization format is used.
==== Verifying the Signature
((("digital signatures", "verifying"))) The signature verification
The signature verification
algorithm takes the message (a hash of parts of the transaction and
related data), the signer's public key and the signature, and returns
TRUE if the signature is valid for this message and public key.
@ -95,7 +95,7 @@ signature on this transaction."
==== Signature Hash Types (SIGHASH)
((("digital signatures", "signature hash
types")))((("commitment")))Digital signatures apply to messages,
types")))Digital signatures apply to messages,
which in the case of Bitcoin, are the transactions themselves. The
signature prove a _commitment_ by the signer to specific transaction
data. In the simplest form, the signature applies to almost the entire
@ -104,7 +104,7 @@ transaction fields. However, a signature can commit to only a subset of
the data in a transaction, which is useful for a number of scenarios as
we will see in this section.
((("SIGHASH flags")))Bitcoin signatures have a way of indicating which
Bitcoin signatures have a way of indicating which
part of a transaction's data is included in the hash signed by the
private key using a +SIGHASH+ flag. The +SIGHASH+ flag is a single byte
that is appended to the signature. Every signature has either an
@ -176,7 +176,7 @@ of all inputs and outputs. This is the most common signature form.
Let's look at some of the other +SIGHASH+ types and how they can be used
in practice:
+ALL|ANYONECANPAY+ :: ((("charitable donations")))((("use cases",
+ALL|ANYONECANPAY+ :: ((("use cases",
"charitable donations")))This construction can be used to make a
"crowdfunding&#x201d;-style transaction. Someone attempting to raise
funds can construct a transaction with a single output. The single
@ -209,7 +209,7 @@ without the cost in fees exceeding the value of the UTXO, see
of signature, the uneconomical UTXOs can be donated for anyone to aggregate and
spend whenever they want.
((("Bitmask Sighash Modes")))There are some proposals to modify or
There are some proposals to modify or
expand the +SIGHASH+ system. The most widely discussed proposal as of
this writing is BIP118, which proposes to add two
new sighash flags. A signature using +SIGHASH_ANYPREVOUT+ would not
@ -886,7 +886,7 @@ as follows:
[[nonce_warning]]
=== The Importance of Randomness in Signatures
((("digital signatures", "randomness in")))As we saw in <<schnorr_signatures>> and <<ecdsa_signatures>>,
As we saw in <<schnorr_signatures>> and <<ecdsa_signatures>>,
the signature generation algorithm uses a random number _k_, as the basis
for a private/public nonce pair. The value of _k_ is not
important, _as long as it is random_. If signatures from the same
@ -898,7 +898,7 @@ key!
[WARNING]
====
((("warnings and cautions", "digital signatures")))If the same value _k_
If the same value _k_
is used in the signing algorithm on two different transactions, the
private key can be calculated and exposed to the world!
====
@ -910,8 +910,8 @@ because of inadvertent reuse of a _k_ value. The most common reason for
reuse of a _k_ value is an improperly initialized random-number
generator.
((("random numbers", "random number generation")))((("entropy", "random
number generation")))((("deterministic initialization")))To avoid this
((("entropy", "random
number generation")))To avoid this
vulnerability, the industry best practice is to not generate _k_ with a
random-number generator seeded only with entropy, but instead to use a
process seeded in part with the transaction data itself plus the

@ -20,7 +20,7 @@ In those cases, we'll describe the various options available.
=== Independent Key Generation
((("wallets", "contents of")))Wallets for physical cash hold that cash,
Wallets for physical cash hold that cash,
so it's unsurprising that many people mistakenly believe that
bitcoin wallets contain bitcoins. In fact, what many people call a
Bitcoin wallet--which we call a _wallet database_ to distinguish it
@ -211,7 +211,7 @@ We'll provide a detailed exploration of HD wallets in <<hd_wallet_details>>.
==== Seeds and Recovery Codes
((("wallets", "technology of", "seeds and recovery codes")))((("recovery
((("recovery
code words")))((("bitcoin improvement proposals", "Recovery Code Words
(BIP39)")))HD wallets are a very powerful mechanism for managing many
keys all derived from a single seed. If your wallet database
@ -624,7 +624,7 @@ modern standards that may provide additional features or safety.
[[recovery_code_words]]
==== BIP39 Recovery Codes
((("wallets", "technology of", "recovery code words")))((("recovery code
((("recovery code
words", id="mnemonic05")))((("bitcoin improvement proposals", "Recovery
Code Words (BIP39)", id="BIP3905")))BIP39 recovery codes are word
sequences that represent (encode) a random number used as a seed to
@ -640,7 +640,7 @@ transcribe.
[TIP]
====
((("brainwallets")))Recovery codes are often confused with
Recovery codes are often confused with
"brainwallets." They are not the same. The primary difference is that a
brainwallet consists of words chosen by the user, whereas recovery codes
are created randomly by the wallet and presented to the user. This
@ -705,13 +705,13 @@ data and the length of recovery code in words.
[[recovery_to_seed]]
===== From recovery code to seed
((("key-stretching function")))((("PBKDF2 function")))The recovery code
The recovery code
represents entropy with a length of 128 to 256 bits. The entropy is then
used to derive a longer (512-bit) seed through the use of the
key-stretching function PBKDF2. The seed produced is then used to build
a deterministic wallet and derive its keys.
((("salts")))((("passphrases")))The key-stretching function takes two
The key-stretching function takes two
parameters: the entropy and a _salt_. The purpose of a salt in a
key-stretching function is to make it difficult to build a lookup table
enabling a brute-force attack. In the BIP39 standard, the salt has
@ -858,7 +858,7 @@ recovery codes (or a value near 128, such as Electrum v2's 132 bits).
[[recovery_passphrase]]
===== Optional passphrase in BIP39
((("passphrases")))The BIP39 standard allows the use of an optional
The BIP39 standard allows the use of an optional
passphrase in the derivation of the seed. If no passphrase is used, the
recovery code is stretched with a salt consisting of the constant string
+"mnemonic"+, producing a specific 512-bit seed from any given recovery code.
@ -904,7 +904,7 @@ her family to recover the cryptocurrency estate.
==== Creating an HD Wallet from the Seed
((("wallets", "technology of", "creating HD wallets from root
seed")))((("root seeds")))((("hierarchical deterministic (HD)
seed")))((("hierarchical deterministic (HD)
wallets")))HD wallets are created from a single _root seed_, which is a
128-, 256-, or 512-bit random number. Most commonly, this seed is
generated by or decrypted from a _recovery code_ as detailed in the previous section.
@ -936,7 +936,7 @@ creates child keys from parent keys, as we will see in the next section.
===== Private child key derivation
((("child key derivation (CKD)")))((("public and private keys", "child
((("public and private keys", "child
key derivation (CKD)")))HD wallets use a _child key derivation_ (CKD)
function to derive child keys from parent keys.
@ -1008,7 +1008,7 @@ operate exactly as "normal" keys.
===== Extended keys
((("public and private keys", "extended keys")))((("extended keys")))As
As
we saw earlier, the key derivation function can be used to create
children at any level of the tree, based on the three inputs: a key, a
chain code, and the index of the desired child. The two essential
@ -1055,7 +1055,7 @@ xpub67xpozcx8pe95XVuZLHXZeG6XWXHpGq6Qv5cmNfi7cS5mtjJ2tgypeQbBs2UAR6KECeeMVKZBPLr
[[public__child_key_derivation]]
===== Public child key derivation
((("public and private keys", "public child key derivation")))As
As
mentioned previously, a very useful characteristic of HD wallets is the
ability to derive public child keys from public parent keys, _without_
having the private keys. This gives us two ways to derive a child public
@ -1133,7 +1133,7 @@ address for the actual transaction. However, these other solutions have
not been used in production as of this writing.
****
((("cold storage")))((("storage", "cold storage")))((("hardware
((("hardware
wallets")))Another common application of this solution is for
cold-storage or hardware signing devices. In that scenario, the extended
private key can be stored on a paper wallet or hardware device, while
@ -1152,7 +1152,7 @@ image::images/mbc2_0511.png["ChildPublicDerivation"]
((("wallets", "technology of", "using extended public keys on web
stores")))Let's see how HD wallets are used by looking at
Gabriel's web store.((("use cases", "web store", id="gabrielfivetwo")))
Gabriel's web store.
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
@ -1206,7 +1206,7 @@ software, such as the widely used open source BTCPay Server.
===== Hardened child key derivation
((("public and private keys", "hardened child key
derivation")))((("hardened derivation")))The ability to derive a branch
derivation")))The ability to derive a branch
of public keys from an xpub is very useful, but it comes with a
potential risk. Access to an xpub does not give access to child private
keys. However, because the xpub contains the chain code, if a child
@ -1273,7 +1273,7 @@ has special meaning, using the letter _h_ is recommended.
===== HD wallet key identifier (path)
((("hierarchical deterministic (HD) wallets")))Keys in an HD wallet are
Keys in an HD wallet are
identified using a "path" naming convention, with each level of the tree
separated by a slash (/) character (see <<table_4-8>>). Private keys
derived from the master private key start with "m." Public keys derived
@ -1344,7 +1344,7 @@ 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.
((("keys and addresses", see="also public and private keys")))On the
On the
fourth level, "change," an HD wallet has two subtrees, one for creating
receiving addresses and one for creating change addresses. Note that
whereas the previous levels used hardened derivation, this level uses

@ -4,7 +4,7 @@
[NOTE]
====
((("whitepaper", id="whitethirteen")))((("bitcoin whitepaper", id="BCwhitethirteen")))((("Nakamoto, Satoshi", id="nakamatothirteen")))This is the original whitepaper, reproduced in its entirety exactly as it was published by Satoshi Nakamoto in October 2008.
This is the original whitepaper, reproduced in its entirety exactly as it was published by Satoshi Nakamoto in October 2008.
====
=== Bitcoin - A Peer-to-Peer Electronic Cash System
@ -450,7 +450,7 @@ We have proposed a system for electronic transactions without relying on trust.
=== License
((("open source licenses")))This whitepaper was published in October 2008 by Satoshi Nakamoto. It was later (2009) added as supporting documentation to the bitcoin software and carries the same MIT license. It has been reproduced in this book, without modification other than formatting, under the terms of the MIT license:
This whitepaper was published in October 2008 by Satoshi Nakamoto. It was later (2009) added as supporting documentation to the bitcoin software and carries the same MIT license. It has been reproduced in this book, without modification other than formatting, under the terms of the MIT license:
The MIT License (MIT)
Copyright (c) 2008 Satoshi Nakamoto
@ -459,4 +459,4 @@ Permission is hereby granted, free of charge, to any person obtaining a copy of
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS," WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.((("", startref="whitethirteen")))((("", startref="nakamatothirteen")))((("", startref="BCwhitethirteen")))
THE SOFTWARE IS PROVIDED "AS IS," WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Loading…
Cancel
Save