arno/bitcoinbook
1
0
Fork 0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2024-11-21 23:58:09 +00:00
Code Issues Releases Wiki Activity

QC1 and math check

Browse Source
This commit is contained in:
Clare Laylock 2023-10-25 13:40:02 -04:00
parent 48cd7ae0b1
commit b4576263bb
14 changed files with 75 additions and 90 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
appb_errata.adoc
View File

@ -36,12 +36,12 @@ occurred in July 2010, long after Bitcoin’s initial release:
- if (pindexNew->nHeight > nBestHeight) - if (pindexNew->nHeight > nBestHeight)
+ if (pindexNew->bnChainWork > bnBestChainWork) + if (pindexNew->bnChainWork > bnBestChainWork)
---- ----
* *Terminology change:* General CPUs were used to generate the POW for * *Terminology change:* General CPUs were used to generate the PoW for
the earliest Bitcoin blocks, but POW generation today is mostly performed the earliest Bitcoin blocks, but PoW generation today is mostly performed
by specialist Application Specific Integrated Circuits (ASICs), so by specialist Application Specific Integrated Circuits (ASICs), so
instead of saying "CPU power" it is perhaps more correct to say instead of saying "CPU power" it is perhaps more correct to say
"computational power" or, simply, "hash rate" for the hashing used "computational power" or, simply, "hash rate" for the hashing used
in generating the POW. in generating the PoW.
____ ____
"As long as a majority of CPU power is controlled by nodes that are not "As long as a majority of CPU power is controlled by nodes that are not

2
ch01_intro.adoc
View File

@ -133,7 +133,7 @@ computing, known as the "Byzantine Generals' Problem." Briefly, the
problem consists of trying to get multiple participants without a leader problem consists of trying to get multiple participants without a leader
to agree on a course of action by exchanging information over an to agree on a course of action by exchanging information over an
unreliable and potentially compromised network. Satoshi Nakamoto's solution, which uses the concept of unreliable and potentially compromised network. Satoshi Nakamoto's solution, which uses the concept of
Proof-of-Work to achieve consensus _without a central trusted proof of work to achieve consensus _without a central trusted
authority_, represents a breakthrough in distributed computing. authority_, represents a breakthrough in distributed computing.
**** ****

7
ch02_overview.adoc
View File

@ -14,8 +14,7 @@ transactions, the network, and mining.
=== Bitcoin Overview === Bitcoin Overview
In the ((("Bitcoin", "operational overview", id="bitcoin-operational-overview-ch2")))((("blockchain explorers", id="blockchain-explorers")))overview diagram shown in <<bitcoin-overview>>, we see that the The ((("Bitcoin", "operational overview", id="bitcoin-operational-overview-ch2")))((("blockchain explorers", id="blockchain-explorers")))Bitcoin system consists of users with wallets containing keys,
Bitcoin system consists of users with wallets containing keys,
transactions that are propagated across the network, and miners who transactions that are propagated across the network, and miners who
produce (through competitive computation) the consensus blockchain, produce (through competitive computation) the consensus blockchain,
which is the authoritative journal of all transactions. which is the authoritative journal of all transactions.
@ -30,10 +29,6 @@ application that operates as a Bitcoin search engine, in that it allows
you to search for addresses, transactions, and blocks and see the you to search for addresses, transactions, and blocks and see the
relationships and flows between them. relationships and flows between them.
[[bitcoin-overview]]
.Bitcoin overview
image::images/mbc3_0201.png["Bitcoin Overview"]
Popular blockchain explorers include: Popular blockchain explorers include:
* https://blockstream.info[Blockstream Explorer] * https://blockstream.info[Blockstream Explorer]

28
ch04_keys.adoc
View File

@ -63,10 +63,10 @@ from the private key, so storing only the private key is also possible.
A Bitcoin wallet contains a collection of key A Bitcoin wallet contains a collection of key
pairs, each consisting of a private key and a public key. The private 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. key (_k_) is a number, usually derived from a number picked at random.
From the private key, we From the private key, we
use elliptic curve multiplication, a one-way cryptographic function, to use elliptic curve multiplication, a one-way cryptographic function, to
generate a public((("public key cryptography", startref="pub-key")))((("key pairs", startref="key-pair"))) key (K). generate a public((("public key cryptography", startref="pub-key")))((("key pairs", startref="key-pair"))) key (_K_).
.Why Use Asymmetric Cryptography (Public/Private Keys)? .Why Use Asymmetric Cryptography (Public/Private Keys)?
**** ****
@ -118,15 +118,15 @@ 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,
this is usually achieved by feeding a larger string of random bits, this is usually achieved by feeding a larger string of random bits,
collected from a cryptographically secure source of randomness, into the collected from a cryptographically secure source of randomness, into the
SHA256 hash algorithm, which will conveniently produce a 256-bit value SHA256 hash algorithm, which will conveniently produce a 256-bit value
that can be interpreted as a number. that can be interpreted as a number.
If the result is less than +n+, we have a suitable private key. If the result is less than _n_, we have a suitable private key.
Otherwise, we simply try again with another random number. Otherwise, we simply try again with another random number.
[WARNING] [WARNING]
@ -140,7 +140,7 @@ choose to make sure it is cryptographically secure. Correct
implementation of the CSPRNG is critical to the security of the keys. implementation of the CSPRNG is critical to the security of the keys.
==== ====
The following is a randomly generated private key (k) shown in The following is a randomly generated private key (_k_) shown in
hexadecimal format (256 bits shown as 64 hexadecimal digits, each 4 hexadecimal format (256 bits shown as 64 hexadecimal digits, each 4
bits): bits):
@ -167,7 +167,7 @@ curve.
by Bitcoin. by Bitcoin.
[[ecc-curve]] [[ecc-curve]]
[role="width-80"] [role="width-50"]
.An elliptic curve .An elliptic curve
image::images/mbc3_0402.png["ecc-curve"] image::images/mbc3_0402.png["ecc-curve"]
@ -341,12 +341,10 @@ Implementing the elliptic curve multiplication, we take the private key
_k_ generated previously and multiply it with the generator point _G_ to _k_ generated previously and multiply it with the generator point _G_ to
find the public key _K_: find the public key _K_:
[latexmath] [source, python]
++++ ----
\begin{equation} K = 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD * G
{K = 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD \times G} ----
\end{equation}
++++
Public key _K_ is defined as a point K = (x, y): Public key _K_ is defined as a point K = (x, y):
@ -1087,7 +1085,7 @@ The "32" stands for the number of characters in the bech32 alphabet
.Bech32 typo detection .Bech32 typo detection
==== ====
Address: Address:
bc1p9nh05ha8wrljf7ru236aw**n**4t2x0d5ctkkywm**v**9sclnm4t0av2vgs4k3au7 bc1p9nh05ha8wrljf7ru236awpass:[<u>n</u>]4t2x0d5ctkkywm**v**9sclnm4t0av2vgs4k3au7
Detected errors shown in bold. Generated using the Detected errors shown in bold. Generated using the
https://oreil.ly/paWIx[bech32 address decoder demo]. https://oreil.ly/paWIx[bech32 address decoder demo].
@ -1633,7 +1631,7 @@ Once a vanity address matching the desired pattern is found, the private
key from which it was derived can be used by the owner to spend bitcoins key from which it was derived can be used by the owner to spend bitcoins
in exactly the same way as any other address. Vanity addresses are no in exactly the same way as any other address. Vanity addresses are no
less or more secure than any other address. They depend on the same less or more secure than any other address. They depend on the same
elliptic curve cryptography (ECC) and SHA as any other address. You can elliptic curve cryptography (ECC) and secure hash algorithm (SHA) as any other address. You can
no more easily find the private key of an address starting with a vanity no more easily find the private key of an address starting with a vanity
pattern than you can any other address. pattern than you can any other address.

13
ch05_wallets.adoc
View File

@ -141,7 +141,7 @@ simply adding the same value to both sides of the equation:
[latexmath] [latexmath]
++++ ++++
\begin{equation} \begin{equation}
K + (123 \times G) == (k + 123) \times G K + (123 \times G) =\!= (k + 123) \times G
\end{equation} \end{equation}
++++ ++++
@ -149,13 +149,13 @@ K + (123 \times G) == (k + 123) \times G
[TIP] [TIP]
==== ====
In equations throughout this book, we use a single equals sign for In equations throughout this book, we use a single equals sign for
operations such as K = k × G where the value of a variable is operations such as _K_ = _k_ × _G_ where the value of a variable is
calculated. We use a double equals sign to show both sides of an calculated. We use a double equals sign to show both sides of an
equation are equivalent, or that an operation should return false (not equation are equivalent, or that an operation should return false (not
true) if the two sides aren't equivalent. true) if the two sides aren't equivalent.
==== ====
An interesting consequence of this is that adding `123` to the public An interesting consequence of this is that adding 123 to the public
key can be done using entirely public information. For example, Alice key can be done using entirely public information. For example, Alice
generates public key _K_ and gives it to Bob. Bob doesn't know the generates public key _K_ and gives it to Bob. Bob doesn't know the
private key, but he does know the global constant _G_, so he can add any private key, but he does know the global constant _G_, so he can add any
@ -1053,7 +1053,7 @@ hash is used to create a _master private key_ (m) and a _master chain
code_ (c). code_ (c).
The master private key (m) then generates a corresponding master public The master private key (m) then generates a corresponding master public
key (M) using the normal elliptic curve multiplication process __m × G__ key (M) using the normal elliptic curve multiplication process m × _G_
that we saw in <<public_key_derivation>>. that we saw in <<public_key_derivation>>.
The chain code (c) is used to introduce entropy in the function that The chain code (c) is used to introduce entropy in the function that
@ -1318,11 +1318,6 @@ To export the xpub from his Trezor hardware signing device, Gabriel uses
the web-based Trezor wallet application. The Trezor device must be plugged in the web-based Trezor wallet application. The Trezor device must be plugged in
for the public keys to be exported. Note that most hardware signing devices will for the public keys to be exported. Note that most hardware signing devices will
never export private keys--those always remain on the device. never export private keys--those always remain on the device.
<<export_xpub>> shows the web interface Gabriel uses to export the xpub.
[[export_xpub]]
.Exporting an xpub from a Trezor hardware signing device
image::images/mbc3_0509.png["Exporting the xpub from the Trezor"]
Gabriel copies the xpub to his web store's Bitcoin payment processing Gabriel copies the xpub to his web store's Bitcoin payment processing
software, such as the widely used open source BTCPay Server. software, such as the widely used open source BTCPay Server.

20
ch06_transactions.adoc
View File

@ -228,22 +228,22 @@ unsigned integers:
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td><p>&gt;= <code>0</code> &amp;&amp; &lt;= <code>252</code> (<code>0xfc</code>)</p></td> <td><p>≥ <code>0</code> &amp;&amp; ≤ <code>252</code> (<code>0xfc</code>)</p></td>
<td><p><code>1</code></p></td> <td><p><code>1</code></p></td>
<td><p><code>uint8_t</code></p></td> <td><p><code>uint8_t</code></p></td>
</tr> </tr>
<tr> <tr>
<td><p>&gt;= <code>253</code> &amp;&amp; &lt;= <code>0xffff</code></p></td> <td><p>≥ <code>253</code> &amp;&amp; ≤ <code>0xffff</code></p></td>
<td><p>3</p></td> <td><p>3</p></td>
<td><p><code>0xfd</code> followed by the number as <code>uint16_t</code></p></td> <td><p><code>0xfd</code> followed by the number as <code>uint16_t</code></p></td>
</tr> </tr>
<tr> <tr>
<td><p>&gt;= <code>0x10000</code> &amp;&amp; &lt;= <code>0xffffffff</code></p></td> <td><p>≥ <code>0x10000</code> &amp;&amp; ≤ <code>0xffffffff</code></p></td>
<td><p><code>5</code></p></td> <td><p><code>5</code></p></td>
<td><p><code>0xfe</code> followed by the number as <code>uint32_t</code></p></td> <td><p><code>0xfe</code> followed by the number as <code>uint32_t</code></p></td>
</tr> </tr>
<tr> <tr>
<td><p>&gt;= <code>0x100000000</code> &amp;&amp; &lt;= <code>0xffffffffffffffff</code></p></td> <td><p>≥ <code>0x100000000</code> &amp;&amp; ≤ <code>0xffffffffffffffff</code></p></td>
<td><p><code>9</code></p></td> <td><p><code>9</code></p></td>
<td><p><code>0xff</code> followed by the number as <code>uint64_t</code></p></td> <td><p><code>0xff</code> followed by the number as <code>uint64_t</code></p></td>
</tr> </tr>
@ -276,7 +276,7 @@ control over bitcoins is assigned in transaction outputs, Alice _points_
to the previous _output_ using an _outpoint_ field. Each input must to the previous _output_ using an _outpoint_ field. Each input must
contain a single outpoint. contain a single outpoint.
The outpoint contains a 32-byte transaction identifier (_txid_) for the The outpoint contains a 32-byte txid for the
transaction where Alice received the bitcoins she now wants to spend. transaction where Alice received the bitcoins she now wants to spend.
This txid is in Bitcoin's internal byte order for hashes; see This txid is in Bitcoin's internal byte order for hashes; see
<<internal_and_display_order>>. <<internal_and_display_order>>.
@ -325,7 +325,7 @@ Different approaches to tracking previous outputs have been tried by
different full node implementations at various times. Bitcoin Core different full node implementations at various times. Bitcoin Core
currently uses the solution believed to be most effective at retaining currently uses the solution believed to be most effective at retaining
all necessary information while minimizing disk space: it keeps a all necessary information while minimizing disk space: it keeps a
database that stores every unspent transaction output (UTXO) and database that stores every UTXO and
essential metadata about it (like its confirmation block height). Each essential metadata about it (like its confirmation block height). Each
time a new block of transactions arrives, all of the outputs they spend time a new block of transactions arrives, all of the outputs they spend
are removed from the UTXO database and all of the outputs they create are removed from the UTXO database and all of the outputs they create
@ -986,23 +986,23 @@ be received to witness programs and spent with the witness structure. The terms
<tr> <tr>
<th/> <th/>
<th><p>Authorization</p></th> <th><p>Authorization</p></th>
<th><p>Authentication</p></th> <th class="right"><p>Authentication</p></th>
</tr></thead> </tr></thead>
<tbody> <tbody>
<tr> <tr>
<td class="fakeheader"><p><strong>Whitepaper</strong></p></td> <td class="fakeheader"><p><strong>Whitepaper</strong></p></td>
<td><p>Public key</p></td> <td><p>Public key</p></td>
<td><p>Signature</p></td> <td class="right"><p>Signature</p></td>
</tr> </tr>
<tr> <tr>
<td class="fakeheader"><p><strong>Original (Legacy)</strong></p></td> <td class="fakeheader"><p><strong>Original (Legacy)</strong></p></td>
<td><p>Output script</p></td> <td><p>Output script</p></td>
<td><p>Input script</p></td> <td class="right"><p>Input script</p></td>
</tr> </tr>
<tr> <tr>
<td class="fakeheader"><p><strong>Segwit</strong></p></td> <td class="fakeheader"><p><strong>Segwit</strong></p></td>
<td><p>Witness program</p></td> <td><p>Witness program</p></td>
<td><p>Witness structure</p></td> <td class="right"><p>Witness structure</p></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>

3
ch07_authorization-authentication.adoc
View File

@ -1383,8 +1383,7 @@ satisfy that redeem script, all inside the transaction input:
Now, let's look at how this entire example would be upgraded to segwit v0. Now, let's look at how this entire example would be upgraded to segwit v0.
If Mohammed's customers were using a segwit-compatible wallet, they If Mohammed's customers were using a segwit-compatible wallet, they
would make a payment, creating a pay to witness script hash (P2WSH) would make a payment, creating a P2WSH output that would look like this:
output that would look like this:
.Example P2WSH output script .Example P2WSH output script
---- ----

9
ch08_signatures.adoc
View File

@ -409,7 +409,7 @@ brute force is easy; the numbers used in Bitcoin are much larger.
Let's discuss some of the features of the interactive schnorr Let's discuss some of the features of the interactive schnorr
identity protocol that make it secure: identity protocol that make it secure:
The nonce ([.plain]#k#):: The nonce (k)::
In step 1, ((("digital signatures", "schnorr signature algorithm", "security features")))((("schnorr signature algorithm", "security features")))Alice chooses a number that Bob doesn't In step 1, ((("digital signatures", "schnorr signature algorithm", "security features")))((("schnorr signature algorithm", "security features")))Alice chooses a number that Bob doesn't
know and can't guess and gives him the scaled form of that number, know and can't guess and gives him the scaled form of that number,
_kG_. At that point, Bob also already has her public key (_xG_), _kG_. At that point, Bob also already has her public key (_xG_),
@ -424,7 +424,7 @@ In step 1, ((("digital signatures", "schnorr signature algorithm", "security fea
be able to leverage that into figuring out Alice's private key. See be able to leverage that into figuring out Alice's private key. See
<<nonce_warning>> for more details. <<nonce_warning>> for more details.
The challenge scalar ([.plain]#e#):: The challenge scalar (e)::
Bob waits to receive Alice's public nonce Bob waits to receive Alice's public nonce
and then proceeds in step 2 to give her a number (the challenge and then proceeds in step 2 to give her a number (the challenge
scalar) that Alice didn't previously know and couldn't have guessed. scalar) that Alice didn't previously know and couldn't have guessed.
@ -674,8 +674,7 @@ MuSig2::
This only ((("MuSig2 protocol")))requires two rounds of communication and can sometimes allow This only ((("MuSig2 protocol")))requires two rounds of communication and can sometimes allow
one of the rounds to be combined with key exchange. This can one of the rounds to be combined with key exchange. This can
significantly speed up signing for certain protocols, such as how significantly speed up signing for certain protocols, such as how
scriptless multisignatures are planned to be used in the Lightning scriptless multisignatures are planned to be used in the LN. MuSig2 is specified in BIP327 (the only scriptless
Network. MuSig2 is specified in BIP327 (the only scriptless
multisignature protocol that has a BIP as of this writing). multisignature protocol that has a BIP as of this writing).
MuSig-DN:: MuSig-DN::
@ -903,7 +902,7 @@ the following DER-encoded signature:
b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e381301 b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e381301
---- ----
That signature is a serialized byte stream of the +R+ and _s_ values That signature is a serialized byte stream of the _R_ and _s_ values
produced by the signer to prove control of the private key authorized produced by the signer to prove control of the private key authorized
to spend an output. The serialization format consists of nine elements to spend an output. The serialization format consists of nine elements
as follows: as follows:

2
ch09_fees.adoc
View File

@ -590,7 +590,7 @@ miners:
[latexmath] [latexmath]
++++ ++++
\begin{equation} \begin{equation}
{Fees = Sum(Inputs) – Sum(Outputs)} {Fees = Sum(Inputs) - Sum(Outputs)}
\end{equation} \end{equation}
++++ ++++

17
ch12_mining.adoc
View File

@ -385,7 +385,7 @@ transaction fees:
[latexmath] [latexmath]
++++ ++++
\begin{equation} \begin{equation}
Total Fees = Sum(Inputs) - Sum(Outputs) Total\:Fees = Sum(Inputs) - Sum(Outputs)
\end{equation} \end{equation}
++++ ++++
@ -858,7 +858,7 @@ is:
++++ ++++
<ul class="simplelist"> <ul class="simplelist">
<li>target = coefficient * 2<sup>(8*(exponent–3))</sup></li> <li>target = coefficient * 2<sup>(8*(exponent – 3))</sup></li>
</ul> </ul>
++++ ++++
@ -866,9 +866,7 @@ Using that formula, and the difficulty bits value 0x1903a30c, we get:
++++ ++++
<ul class="simplelist"> <ul class="simplelist">
<li>target = 0x03a30c * 2<sup>0x08*(0x19-0x03)</sup></li> <li>target = 0x03a30c × 2<sup>0x08 × (0x19 - 0x03)</sup></li>
<li>=> target = 0x03a30c * 2<sup>(0x08*0x16)</sup></li>
<li>=> target = 0x03a30c * 2<sup>0xB0</sup></li>
</ul> </ul>
++++ ++++
@ -876,16 +874,15 @@ which in decimal is:
++++ ++++
<ul class="simplelist"> <ul class="simplelist">
<li>=> target = 238,348 * 2<sup>176</sup></li> <li>22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,575,715,328</li>
<li>=> target = <br/>22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,575,715,328</li>
</ul> </ul>
++++ ++++
switching back to hexadecimal: Or, in hexadecimal:
++++ ++++
<ul class="simplelist"> <ul class="simplelist">
<li>=> target = <br/>0x0000000000000003A30C00000000000000000000000000000000000000000000</li> <li>0x0000000000000003A30C00000000000000000000000000000000000000000000</li>
</ul> </ul>
++++ ++++
@ -944,7 +941,7 @@ resulting in a retargeting bias toward higher difficulty by 0.05%.
<<retarget_code>> shows the code used in the Bitcoin Core client. <<retarget_code>> shows the code used in the Bitcoin Core client.
[[retarget_code]] [[retarget_code]]
.Retargeting the proof of work&#x2014;[.plain]#++CalculateNextWorkRequired()++# in pow.cpp .Retargeting the proof of work—[.plain]#++CalculateNextWorkRequired()++# in pow.cpp
==== ====
[source,cpp] [source,cpp]
---- ----

47
ch14_applications.adoc
View File

@ -339,9 +339,8 @@ Translated forwarding::
support forwarding bitcoin payments. support forwarding bitcoin payments.
Native forwarding is conceptually simpler but essentially requires a Native forwarding is conceptually simpler but essentially requires a
separate Lightning Network for every asset. Translated forwarding separate LN for every asset. Translated forwarding
allows building on the economies of scale of the Bitcoin Lightning allows building on the economies of scale of the Bitcoin LN, but it may be vulnerable to a problem called((("free American call option"))) the _free American
Network, but it may be vulnerable to a problem called((("free American call option"))) the _free American
call option_, where a receiver may selectively accept or reject certain call option_, where a receiver may selectively accept or reject certain
payments depending on recent changes to the exchange rate in order to payments depending on recent changes to the exchange rate in order to
siphon money from the hop next to them. Although there's no known siphon money from the hop next to them. Although there's no known
@ -712,8 +711,7 @@ Even though a transaction cannot be canceled, it can be constructed in
such a way as to make it undesirable to use. The way we do that is by such a way as to make it undesirable to use. The way we do that is by
giving each party a _revocation key_ that can be used to punish the giving each party a _revocation key_ that can be used to punish the
other party if they try to cheat. This mechanism for revoking prior other party if they try to cheat. This mechanism for revoking prior
commitment transactions was first proposed as part of the Lightning commitment transactions was first proposed as part of the LN.
Network.
To explain revocation keys, we will construct a more complex payment To explain revocation keys, we will construct a more complex payment
channel between two exchanges run by Hitesh and Irene. Hitesh and Irene channel between two exchanges run by Hitesh and Irene. Hitesh and Irene
@ -909,8 +907,7 @@ Asymmetric revocable commitments with relative time locks (+CSV+) are a
much better way to implement payment channels and a very significant much better way to implement payment channels and a very significant
innovation in this technology. With this construct, the channel can innovation in this technology. With this construct, the channel can
remain open indefinitely and can have billions of intermediate remain open indefinitely and can have billions of intermediate
commitment transactions. In implementations of Lightning commitment transactions. In implementations of LN, the commitment state is identified by a 48-bit index, allowing
Network, the commitment state is identified by a 48-bit index, allowing
more than 281 trillion (2.8 × 10^14^) state transitions in ((("payment channels", "asymmetric revocable commitments", startref="payment-channel-revoke")))((("asymmetric revocable commitments", startref="asymmetric-revoke-commit")))((("commitment transactions", "asymmetric revocable commitments", startref="commit-revoke")))((("revocable commitments", startref="revoke-commit")))any single more than 281 trillion (2.8 × 10^14^) state transitions in ((("payment channels", "asymmetric revocable commitments", startref="payment-channel-revoke")))((("asymmetric revocable commitments", startref="asymmetric-revoke-commit")))((("commitment transactions", "asymmetric revocable commitments", startref="commit-revoke")))((("revocable commitments", startref="revoke-commit")))any single
channel. channel.
@ -996,12 +993,11 @@ to Carol, Carol to Diana, and Diana to Eric. For simplicity let's assume
each channel is funded with 2 bitcoins by each participant, for a total each channel is funded with 2 bitcoins by each participant, for a total
capacity of 4 bitcoins in each channel. capacity of 4 bitcoins in each channel.
<<lightning_network_fig>> shows five participants in a Lightning <<lightning_network_fig>> shows five participants in an LN, connected by bidirectional payment channels that can be linked
Network, connected by bidirectional payment channels that can be linked
to make a payment from Alice to Eric (see <<lightning_network>>). to make a payment from Alice to Eric (see <<lightning_network>>).
[[lightning_network_fig]] [[lightning_network_fig]]
.A series of bidirectional payment channels linked to form a Lightning Network that can route a payment from Alice to Eric .A series of bidirectional payment channels linked to form an LN that can route a payment from Alice to Eric
image::images/mbc3_1406.png["A series of bi-directional payment channels linked to form a Lightning Network"] image::images/mbc3_1406.png["A series of bi-directional payment channels linked to form a Lightning Network"]
Alice wants to pay Eric 1 bitcoin. However, Alice is not connected to Alice wants to pay Eric 1 bitcoin. However, Alice is not connected to
@ -1015,10 +1011,10 @@ payment from Alice to Eric, through a series of HTLC commitments on the
payment channels connecting the participants. payment channels connecting the participants.
[[ln_payment_process]] [[ln_payment_process]]
.Step-by-step payment routing through a Lightning Network .Step-by-step payment routing through an LN
image::images/mbc3_1407.png["Step-by-step payment routing through a Lightning Network"] image::images/mbc3_1407.png["Step-by-step payment routing through a Lightning Network"]
Alice is running a Lightning Network (LN) node that is keeping track of Alice is running an LN node that is keeping track of
her payment channel to Bob and has the ability to discover routes her payment channel to Bob and has the ability to discover routes
between payment channels. Alice's LN node also has the ability to between payment channels. Alice's LN node also has the ability to
connect over the internet to Eric's LN node. Eric's LN node creates a connect over the internet to Eric's LN node. Eric's LN node creates a
@ -1114,7 +1110,7 @@ with sufficient capacity. Nodes advertise routing information, including
what channels they have open, how much capacity each channel has, and what channels they have open, how much capacity each channel has, and
what fees they charge to route payments. The routing information can be what fees they charge to route payments. The routing information can be
shared in a variety of ways, and different pathfinding protocols have shared in a variety of ways, and different pathfinding protocols have
emerged as Lightning Network technology has advanced. emerged as LN technology has advanced.
Current implementations of Current implementations of
route discovery use a P2P model where nodes propagate channel route discovery use a P2P model where nodes propagate channel
announcements to their peers in a "flooding" model, similar to how announcements to their peers in a "flooding" model, similar to how
@ -1132,15 +1128,15 @@ Carol's perspective, this looks like a payment from Bob to Diana. Carol
does not know that Bob is actually relaying a payment from Alice. She does not know that Bob is actually relaying a payment from Alice. She
also doesn't know that Diana will be relaying a payment to Eric. also doesn't know that Diana will be relaying a payment to Eric.
This is a critical feature of the Lightning Network because it ensures This is a critical feature of the LN because it ensures
privacy of payments and makes it difficult to apply surveillance, privacy of payments and makes it difficult to apply surveillance,
censorship, or blacklists. But how does Alice establish this payment censorship, or blacklists. But how does Alice establish this payment
path without revealing anything to the intermediary nodes? path without revealing anything to the intermediary nodes?
The Lightning Network implements an onion-routed protocol based on a The LN implements an onion-routed protocol based on a
scheme called https://oreil.ly/fuCiK[Sphinx]. This routing protocol scheme called https://oreil.ly/fuCiK[Sphinx]. This routing protocol
ensures that a payment sender can construct and communicate a path ensures that a payment sender can construct and communicate a path
through the Lightning Network such that: through the LN such that:
- Intermediate nodes can verify and decrypt their portion of route - Intermediate nodes can verify and decrypt their portion of route
information and find the next hop. information and find the next hop.
@ -1192,40 +1188,39 @@ hops to go.
==== Lightning Network Benefits ==== Lightning Network Benefits
A((("payment channels", "Lightning Network", "benefits of", id="payment-channel-ln-benefits")))((("Lightning Network", "benefits of", id="lightning-benefits"))) Lightning Network is a An((("payment channels", "Lightning Network", "benefits of", id="payment-channel-ln-benefits")))((("Lightning Network", "benefits of", id="lightning-benefits"))) LN is a
second-layer routing technology. It can be applied to any blockchain second-layer routing technology. It can be applied to any blockchain
that supports some basic capabilities, such as multisignature that supports some basic capabilities, such as multisignature
transactions, timelocks, and basic smart contracts. transactions, timelocks, and basic smart contracts.
Lightning Network is layered on top of the Bitcoin network, giving LN is layered on top of the Bitcoin network, giving
Bitcoin a significant increase in capacity, privacy, Bitcoin a significant increase in capacity, privacy,
granularity, and speed, without sacrificing the principles of trustless granularity, and speed, without sacrificing the principles of trustless
operation without intermediaries: operation without intermediaries:
Privacy:: Lightning Network payments are much more private than payments Privacy:: LN payments are much more private than payments
on the Bitcoin blockchain, as they are not public. While participants in on the Bitcoin blockchain, as they are not public. While participants in
a route can see payments propagated across their channels, they do not a route can see payments propagated across their channels, they do not
know the sender or recipient. know the sender or recipient.
Fungibility:: A Lightning Network makes it much more difficult to apply Fungibility:: An LN makes it much more difficult to apply
surveillance and blacklists on Bitcoin, increasing the fungibility of surveillance and blacklists on Bitcoin, increasing the fungibility of
the currency. the currency.
Speed:: Bitcoin transactions using Lightning Network are settled in Speed:: Bitcoin transactions using LN are settled in
milliseconds, rather than minutes or hours, as HTLCs are cleared without milliseconds, rather than minutes or hours, as HTLCs are cleared without
committing transactions to a block. committing transactions to a block.
Granularity:: A Lightning Network can enable payments at least as small Granularity:: An LN can enable payments at least as small
as the Bitcoin "dust" limit, perhaps even smaller. as the Bitcoin "dust" limit, perhaps even smaller.
Capacity:: A Lightning Network increases the capacity of the Bitcoin Capacity:: An LN increases the capacity of the Bitcoin
system by several orders of magnitude. The upper bound system by several orders of magnitude. The upper bound
to the number of payments per second that can be routed over a Lightning to the number of payments per second that can be routed over a Lightning
Network depends only on the capacity and speed of each node. Network depends only on the capacity and speed of each node.
Trustless Operation:: A Lightning Network uses Bitcoin transactions Trustless Operation:: An LN uses Bitcoin transactions
between nodes that operate as peers without trusting each other. Thus, a between nodes that operate as peers without trusting each other. Thus, an LN preserves the principles of the Bitcoin system, while
Lightning Network preserves the principles of the Bitcoin system, while
expanding its operating parameters ((("Bitcoin", "as application platform", "routed payment channels (Lightning Network)", secondary-sortas="application platform", startref="bitcoin-app-platform-ln")))((("application platform, Bitcoin as", "routed payment channels (Lightning Network)", startref="app-platform-ln")))((("payment channels", "Lightning Network", startref="payment-channel-ln")))((("Lightning Network", startref="lightning")))((("payment channels", "Lightning Network", "benefits of", startref="payment-channel-ln-benefits")))((("Lightning Network", "benefits of", startref="lightning-benefits")))significantly. expanding its operating parameters ((("Bitcoin", "as application platform", "routed payment channels (Lightning Network)", secondary-sortas="application platform", startref="bitcoin-app-platform-ln")))((("application platform, Bitcoin as", "routed payment channels (Lightning Network)", startref="app-platform-ln")))((("payment channels", "Lightning Network", startref="payment-channel-ln")))((("Lightning Network", startref="lightning")))((("payment channels", "Lightning Network", "benefits of", startref="payment-channel-ln-benefits")))((("Lightning Network", "benefits of", startref="lightning-benefits")))significantly.
We have examined just a few of the emerging applications that can be We have examined just a few of the emerging applications that can be

2
preface.asciidoc
View File

@ -125,7 +125,7 @@ Watch us on YouTube: link:$$https://youtube.com/oreillymedia$$[].
=== Contacting the Authors === Contacting the Authors
[.align] [role="align"]
You can contact Andreas M. Antonopoulos on his personal site: You can contact Andreas M. Antonopoulos on his personal site:
[.keep-together]#link:$$https://antonopoulos.com$$[].# [.keep-together]#link:$$https://antonopoulos.com$$[].#

5
theme/epub/epub.css
View File

@ -4,4 +4,7 @@ td.fakeheader {
color: White !important; color: White !important;
background-color: Black !important; background-color: Black !important;
border: 0pt solid cmyk(0%,0%,0%,100%); border: 0pt solid cmyk(0%,0%,0%,100%);
} }
/*--Table lines--*/
table td.right, th.right { border-right: 0.25pt solid cmyk(0%,0%,0%,100%); }

4
theme/pdf/pdf.css
View File

@ -18,6 +18,10 @@ pre[data-type="programlisting"] {
font-style: normal; font-style: normal;
} }
/*--Table lines--*/
table td.right, th.right { border-right: 0.25pt solid cmyk(0%,0%,0%,100%); }
td.fakeheader { td.fakeheader {
font-family: "MyriadPro-SemiboldCond" !important; font-family: "MyriadPro-SemiboldCond" !important;
font-weight: 600 !important; font-weight: 600 !important;