@ -118,7 +118,7 @@ or repeatable. Bitcoin software uses cryptographically secure random
number generators to produce 256 bits of entropy.
number generators to produce 256 bits of entropy.
More precisely, the private key can be any number between +0+ and +n -
More precisely, the private key can be any number between +0+ and +n -
1+ inclusive, where n is a constant (n = 1.1578 * 10^77^, slightly less
1+ inclusive, where n is a constant (n = 1.1578 × 10^77^, slightly less
than 2^256^) defined as the order of the elliptic curve used in Bitcoin
than 2^256^) defined as the order of the elliptic curve used in Bitcoin
(see <<elliptic_curve>>). To create such a key, we randomly pick a
(see <<elliptic_curve>>). To create such a key, we randomly pick a
256-bit number and check that it is less than +n+. In programming terms,
256-bit number and check that it is less than +n+. In programming terms,
@ -208,7 +208,6 @@ grid. The +secp256k1+ Bitcoin elliptic curve can be thought of as a much
more complex pattern of dots on a unfathomably large grid.
more complex pattern of dots on a unfathomably large grid.
[[ecc-over-F17-math]]
[[ecc-over-F17-math]]
[role="smallersixty"]
.Elliptic curve cryptography: visualizing an elliptic curve over F(p), with p=17
.Elliptic curve cryptography: visualizing an elliptic curve over F(p), with p=17
image::images/mbc3_0403.png["ecc-over-F17-math"]
image::images/mbc3_0403.png["ecc-over-F17-math"]
@ -288,7 +287,7 @@ that k is sometimes confusingly called an "exponent" in ((("public key cryptogra
The ((("public keys", "generating", id="public-key-generate")))((("elliptic curve multiplication", id="elliptic-multiply")))public key is calculated from
The ((("public keys", "generating", id="public-key-generate")))((("elliptic curve multiplication", id="elliptic-multiply")))public key is calculated from
the private key using elliptic curve multiplication, which is
the private key using elliptic curve multiplication, which is
irreversible: _K_ = _k_ * _G_, where _k_ is the private key, _G_ is a
irreversible: _K_ = _k_ × _G_, where _k_ is the private key, _G_ is a
constant point called the _generator point_, and _K_ is the resulting
constant point called the _generator point_, and _K_ is the resulting
public key. The reverse operation, known as "finding the discrete
public key. The reverse operation, known as "finding the discrete
logarithm"—calculating _k_ if you know __K__—is as difficult as trying
logarithm"—calculating _k_ if you know __K__—is as difficult as trying
@ -319,7 +318,7 @@ bitcoin:
[latexmath]
[latexmath]
++++
++++
\begin{equation}
\begin{equation}
{K = k * G}
{K = k × G}
\end{equation}
\end{equation}
++++
++++
@ -829,7 +828,6 @@ addresses. However, the private key is identical for both Bitcoin
addresses.
addresses.
[[pubkey_compression]]
[[pubkey_compression]]
[role="smallerseventy"]
.Public key compression
.Public key compression
image::images/mbc3_0408.png["pubkey_compression"]
image::images/mbc3_0408.png["pubkey_compression"]
@ -1643,7 +1641,7 @@ represented by symbols in the base58 alphabet. The search for a pattern
like "1Kids" can be seen as searching for an address in the range from
like "1Kids" can be seen as searching for an address in the range from
+1Kids11111111111111111111111111111+ to
+1Kids11111111111111111111111111111+ to
+1Kidszzzzzzzzzzzzzzzzzzzzzzzzzzzzz+. There are approximately 58^29^
+1Kidszzzzzzzzzzzzzzzzzzzzzzzzzzzzz+. There are approximately 58^29^
(approximately 1.4 * 10^51^) addresses in that range, all starting with
(approximately 1.4 × 10^51^) addresses in that range, all starting with
"1Kids." <<table_4-11>> shows the range of addresses that have the
"1Kids." <<table_4-11>> shows the range of addresses that have the
@ -111,7 +110,6 @@ derived separately from their corresponding private keys, making it
possible to store private keys more securely than ((("wallets", "key generation", "deterministic", startref="wallet-keygen-determine")))((("key generation", "deterministic", startref="keygen-determine")))((("deterministic key generation", startref="determine-keygen")))((("hash functions", "deterministic key generation", startref="hash-determine")))public keys.
possible to store private keys more securely than ((("wallets", "key generation", "deterministic", startref="wallet-keygen-determine")))((("key generation", "deterministic", startref="keygen-determine")))((("deterministic key generation", startref="determine-keygen")))((("hash functions", "deterministic key generation", startref="hash-determine")))public keys.
[[Type1_wallet]]
[[Type1_wallet]]
[role="smallersixty"]
.Deterministic key generation: a deterministic sequence of keys derived from a seed for a wallet database
.Deterministic key generation: a deterministic sequence of keys derived from a seed for a wallet database
@ -898,7 +898,7 @@ constraint on one transaction that is dependent on the elapsed time from
the confirmation of a previous transaction. In other words, the clock
the confirmation of a previous transaction. In other words, the clock
doesn't start counting until the UTXO is recorded on the blockchain.
doesn't start counting until the UTXO is recorded on the blockchain.
This functionality is especially useful in bidirectional state channels
This functionality is especially useful in bidirectional state channels
and Lightning Networks, as we will see in <<state_channels>>.
and Lightning Networks (LNs), as we will see in <<state_channels>>.
Relative timelocks, like absolute timelocks, are implemented with both a
Relative timelocks, like absolute timelocks, are implemented with both a
transaction-level feature and a script-level opcode. The
transaction-level feature and a script-level opcode. The
@ -910,7 +910,7 @@ the +OP_CHECKSEQUENCEVERIFY+ (+OP_CSV+) opcode.
Relative timelocks are
Relative timelocks are
implemented according to the specifications in
implemented according to the specifications in
https://oreil.ly/ZuANb[BIP68,
https://oreil.ly/ZuANb[BIP68,
relative Lock-Time Using Consensus-Enforced Sequence Numbers] and
Relative Lock-Time Using Consensus-Enforced Sequence Numbers] and
https://oreil.ly/dLA2r[BIP112,
https://oreil.ly/dLA2r[BIP112,
+OP_CHECKSEQUENCEVERIFY+].
+OP_CHECKSEQUENCEVERIFY+].
@ -1257,7 +1257,7 @@ Try running the script on paper to see how it behaves on the stack.
Let’s look at ((("scripts", "segregated witness", id="script-segwit")))((("segregated witness (segwit)", "scripts and", id="segwit-script")))some of our example transactions and see how they would
Let’s look at ((("scripts", "segregated witness", id="script-segwit")))((("segregated witness (segwit)", "scripts and", id="segwit-script")))some of our example transactions and see how they would
change with segregated witness. We’ll first look at how a
change with segregated witness. We’ll first look at how a
pay to public key hash P2PKH payment can be accomplished as the
P2PKH payment can be accomplished as the
segregated witness program. Then, we’ll look at the segregated witness
segregated witness program. Then, we’ll look at the segregated witness
equivalent for P2SH scripts. Finally, we’ll look at
equivalent for P2SH scripts. Finally, we’ll look at
how both of the preceding segregated witness programs can be embedded
how both of the preceding segregated witness programs can be embedded
@ -267,7 +267,7 @@ output to the same destination (assuming the extra data for the second
output was known).
output was known).
The main expected use for the two ++SIGHASH_ANYPREVOUT++ opcodes is improved
The main expected use for the two ++SIGHASH_ANYPREVOUT++ opcodes is improved
payment channels, such as those used in the Lightning Network, although
payment channels, such as those used in the Lightning Network (LN), although
several other uses have been described.
several other uses have been described.
[NOTE]
[NOTE]
@ -275,7 +275,7 @@ several other uses have been described.
You will not often see +SIGHASH+ flags presented as an option in a user's
You will not often see +SIGHASH+ flags presented as an option in a user's
wallet application. Simple wallet applications
wallet application. Simple wallet applications
sign with [.keep-together]#+SIGHASH_ALL+# flags. More sophisticated applications, such as
sign with [.keep-together]#+SIGHASH_ALL+# flags. More sophisticated applications, such as
Lightning Network nodes, may use alternative +SIGHASH+ flags, but they
LN nodes, may use alternative +SIGHASH+ flags, but they
use protocols that have been extensively reviewed to understand the
use protocols that have been extensively reviewed to understand the
influence of the alternative ((("digital signatures", "SIGHASH flags", startref="digital-signature-sighash")))((("SIGHASH flags", startref="sighash")))flags.
influence of the alternative ((("digital signatures", "SIGHASH flags", startref="digital-signature-sighash")))((("SIGHASH flags", startref="sighash")))flags.
@ -437,7 +437,7 @@ limited early version of it may be available by the time this book is
published.
published.
Package relay is especially important for protocols based on
Package relay is especially important for protocols based on
time-sensitive presigned transactions, such as Lightning Network. In
time-sensitive presigned transactions, such as Lightning Network (LN). In
non-cooperative cases, some presigned transactions can't be fee bumped
non-cooperative cases, some presigned transactions can't be fee bumped
using RBF, forcing them to depend on CPFP. In those protocols, some
using RBF, forcing them to depend on CPFP. In those protocols, some
transactions may also be created long before they need to be broadcast,
transactions may also be created long before they need to be broadcast,
@ -517,7 +517,7 @@ To prevent these problems, and other related
Transaction pinning can happen by accident, but it also represents a
Transaction pinning can happen by accident, but it also represents a
serious vulnerability for multiparty time-sensitive protocols such as
serious vulnerability for multiparty time-sensitive protocols such as
Lightning Network. If your counterparty can prevent one of your
LN. If your counterparty can prevent one of your
transactions from confirming by a deadline, they may be able to steal
transactions from confirming by a deadline, they may be able to steal
money from you.
money from you.
@ -530,7 +530,7 @@ this writing—https://oreil.ly/300dv[ephemeral anchors].
[[cpfp_carve_out]]
[[cpfp_carve_out]]
=== CPFP Carve Out and Anchor Outputs
=== CPFP Carve Out and Anchor Outputs
In 2018, ((("transaction fees", "fee bumping", "CPFP carve outs", id="transaction-fee-bump-carveout")))((("fee bumping", "CPFP carve outs", id="fee-bump-carveout")))((("carve outs (CPFP)", id="carveout")))((("CPFP (child pays for parent) fee bumping", "carve outs", id="cpfp-carveout")))developers working on Lightning Network (LN) had a problem.
In 2018, ((("transaction fees", "fee bumping", "CPFP carve outs", id="transaction-fee-bump-carveout")))((("fee bumping", "CPFP carve outs", id="fee-bump-carveout")))((("carve outs (CPFP)", id="carveout")))((("CPFP (child pays for parent) fee bumping", "carve outs", id="cpfp-carveout")))developers working on LN had a problem.
Their protocol uses transactions that require signatures from two
Their protocol uses transactions that require signatures from two
different parties. Neither party wants to trust the other, so they sign
different parties. Neither party wants to trust the other, so they sign
transactions at a point in the protocol when trust isn't needed,
transactions at a point in the protocol when trust isn't needed,