mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-11-21 23:58:09 +00:00
QC1 and math check
This commit is contained in:
Clare Laylock
parent
48cd7ae0b1
commit
b4576263bb
@ -36,12 +36,12 @@ occurred in July 2010, long after Bitcoin’s initial release:
|
||||
- if (pindexNew->nHeight > nBestHeight)
|
||||
+ if (pindexNew->bnChainWork > bnBestChainWork)
|
||||
----
|
||||
* *Terminology change:* General CPUs were used to generate the POW for
|
||||
the earliest Bitcoin blocks, but POW generation today is mostly performed
|
||||
* *Terminology change:* General CPUs were used to generate the PoW for
|
||||
the earliest Bitcoin blocks, but PoW generation today is mostly performed
|
||||
by specialist Application Specific Integrated Circuits (ASICs), so
|
||||
instead of saying "CPU power" it is perhaps more correct to say
|
||||
"computational power" or, simply, "hash rate" for the hashing used
|
||||
in generating the POW.
|
||||
in generating the PoW.
|
||||
|
||||
____
|
||||
"As long as a majority of CPU power is controlled by nodes that are not
|
||||
|
||||
@ -133,7 +133,7 @@ computing, known as the "Byzantine Generals' Problem." Briefly, the
|
||||
problem consists of trying to get multiple participants without a leader
|
||||
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
|
||||
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.
|
||||
****
|
||||
|
||||
|
||||
@ -14,8 +14,7 @@ transactions, the network, and mining.
|
||||
|
||||
=== 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
|
||||
Bitcoin system consists of users with wallets containing keys,
|
||||
The ((("Bitcoin", "operational overview", id="bitcoin-operational-overview-ch2")))((("blockchain explorers", id="blockchain-explorers")))Bitcoin system consists of users with wallets containing keys,
|
||||
transactions that are propagated across the network, and miners who
|
||||
produce (through competitive computation) the consensus blockchain,
|
||||
which is the authoritative 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
|
||||
relationships and flows between them.
|
||||
|
||||
[[bitcoin-overview]]
|
||||
.Bitcoin overview
|
||||
image::images/mbc3_0201.png["Bitcoin Overview"]
|
||||
|
||||
Popular blockchain explorers include:
|
||||
|
||||
* https://blockstream.info[Blockstream Explorer]
|
||||
|
||||
@ -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
|
||||
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
|
||||
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)?
|
||||
****
|
||||
@ -118,15 +118,15 @@ or repeatable. Bitcoin software uses cryptographically secure random
|
||||
number generators to produce 256 bits of entropy.
|
||||
|
||||
More precisely, the private key can be any number between 0 and n -
|
||||
1 inclusive, where n is a constant (n = 1.1578 × 10^77^, slightly less
|
||||
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
|
||||
(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,
|
||||
collected from a cryptographically secure source of randomness, into the
|
||||
SHA256 hash algorithm, which will conveniently produce a 256-bit value
|
||||
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.
|
||||
|
||||
[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.
|
||||
====
|
||||
|
||||
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
|
||||
bits):
|
||||
|
||||
@ -167,7 +167,7 @@ curve.
|
||||
by Bitcoin.
|
||||
|
||||
[[ecc-curve]]
|
||||
[role="width-80"]
|
||||
[role="width-50"]
|
||||
.An elliptic 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
|
||||
find the public key _K_:
|
||||
|
||||
[latexmath]
|
||||
++++
|
||||
\begin{equation}
|
||||
{K = 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD \times G}
|
||||
\end{equation}
|
||||
++++
|
||||
[source, python]
|
||||
----
|
||||
K = 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD * G
|
||||
----
|
||||
|
||||
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
|
||||
====
|
||||
Address:
|
||||
bc1p9nh05ha8wrljf7ru236aw**n**4t2x0d5ctkkywm**v**9sclnm4t0av2vgs4k3au7
|
||||
bc1p9nh05ha8wrljf7ru236awpass:[<u>n</u>]4t2x0d5ctkkywm**v**9sclnm4t0av2vgs4k3au7
|
||||
|
||||
Detected errors shown in bold. Generated using the
|
||||
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
|
||||
in exactly the same way as any other address. Vanity addresses are no
|
||||
less or more secure than any other address. They depend on the same
|
||||
elliptic curve cryptography (ECC) and SHA as any other address. You can
|
||||
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
|
||||
pattern than you can any other address.
|
||||
|
||||
|
||||
@ -141,7 +141,7 @@ simply adding the same value to both sides of the equation:
|
||||
[latexmath]
|
||||
++++
|
||||
\begin{equation}
|
||||
K + (123 \times G) == (k + 123) \times G
|
||||
K + (123 \times G) =\!= (k + 123) \times G
|
||||
\end{equation}
|
||||
++++
|
||||
|
||||
@ -149,13 +149,13 @@ K + (123 \times G) == (k + 123) \times G
|
||||
[TIP]
|
||||
====
|
||||
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
|
||||
equation are equivalent, or that an operation should return false (not
|
||||
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
|
||||
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
|
||||
@ -1053,7 +1053,7 @@ hash is used to create a _master private key_ (m) and a _master chain
|
||||
code_ (c).
|
||||
|
||||
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>>.
|
||||
|
||||
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
|
||||
for the public keys to be exported. Note that most hardware signing devices will
|
||||
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
|
||||
software, such as the widely used open source BTCPay Server.
|
||||
|
||||
@ -228,22 +228,22 @@ unsigned integers:
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><p>>= <code>0</code> && <= <code>252</code> (<code>0xfc</code>)</p></td>
|
||||
<td><p>≥ <code>0</code> && ≤ <code>252</code> (<code>0xfc</code>)</p></td>
|
||||
<td><p><code>1</code></p></td>
|
||||
<td><p><code>uint8_t</code></p></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><p>>= <code>253</code> && <= <code>0xffff</code></p></td>
|
||||
<td><p>≥ <code>253</code> && ≤ <code>0xffff</code></p></td>
|
||||
<td><p>3</p></td>
|
||||
<td><p><code>0xfd</code> followed by the number as <code>uint16_t</code></p></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><p>>= <code>0x10000</code> && <= <code>0xffffffff</code></p></td>
|
||||
<td><p>≥ <code>0x10000</code> && ≤ <code>0xffffffff</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>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><p>>= <code>0x100000000</code> && <= <code>0xffffffffffffffff</code></p></td>
|
||||
<td><p>≥ <code>0x100000000</code> && ≤ <code>0xffffffffffffffff</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>
|
||||
</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
|
||||
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.
|
||||
This txid is in Bitcoin's internal byte order for hashes; see
|
||||
<<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
|
||||
currently uses the solution believed to be most effective at retaining
|
||||
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
|
||||
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
|
||||
@ -986,23 +986,23 @@ be received to witness programs and spent with the witness structure. The terms
|
||||
<tr>
|
||||
<th/>
|
||||
<th><p>Authorization</p></th>
|
||||
<th><p>Authentication</p></th>
|
||||
<th class="right"><p>Authentication</p></th>
|
||||
</tr></thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td class="fakeheader"><p><strong>Whitepaper</strong></p></td>
|
||||
<td><p>Public key</p></td>
|
||||
<td><p>Signature</p></td>
|
||||
<td class="right"><p>Signature</p></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="fakeheader"><p><strong>Original (Legacy)</strong></p></td>
|
||||
<td><p>Output script</p></td>
|
||||
<td><p>Input script</p></td>
|
||||
<td class="right"><p>Input script</p></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="fakeheader"><p><strong>Segwit</strong></p></td>
|
||||
<td><p>Witness program</p></td>
|
||||
<td><p>Witness structure</p></td>
|
||||
<td class="right"><p>Witness structure</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
@ -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.
|
||||
If Mohammed's customers were using a segwit-compatible wallet, they
|
||||
would make a payment, creating a pay to witness script hash (P2WSH)
|
||||
output that would look like this:
|
||||
would make a payment, creating a P2WSH output that would look like this:
|
||||
|
||||
.Example P2WSH output script
|
||||
----
|
||||
|
||||
@ -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
|
||||
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
|
||||
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_),
|
||||
@ -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
|
||||
<<nonce_warning>> for more details.
|
||||
|
||||
The challenge scalar ([.plain]#e#)::
|
||||
The challenge scalar (e)::
|
||||
Bob waits to receive Alice's public nonce
|
||||
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.
|
||||
@ -674,8 +674,7 @@ MuSig2::
|
||||
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
|
||||
significantly speed up signing for certain protocols, such as how
|
||||
scriptless multisignatures are planned to be used in the Lightning
|
||||
Network. MuSig2 is specified in BIP327 (the only scriptless
|
||||
scriptless multisignatures are planned to be used in the LN. MuSig2 is specified in BIP327 (the only scriptless
|
||||
multisignature protocol that has a BIP as of this writing).
|
||||
|
||||
MuSig-DN::
|
||||
@ -903,7 +902,7 @@ the following DER-encoded signature:
|
||||
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
|
||||
to spend an output. The serialization format consists of nine elements
|
||||
as follows:
|
||||
|
||||
@ -590,7 +590,7 @@ miners:
|
||||
[latexmath]
|
||||
++++
|
||||
\begin{equation}
|
||||
{Fees = Sum(Inputs) – Sum(Outputs)}
|
||||
{Fees = Sum(Inputs) - Sum(Outputs)}
|
||||
\end{equation}
|
||||
++++
|
||||
|
||||
|
||||
@ -385,7 +385,7 @@ transaction fees:
|
||||
[latexmath]
|
||||
++++
|
||||
\begin{equation}
|
||||
Total Fees = Sum(Inputs) - Sum(Outputs)
|
||||
Total\:Fees = Sum(Inputs) - Sum(Outputs)
|
||||
\end{equation}
|
||||
++++
|
||||
|
||||
@ -866,9 +866,7 @@ Using that formula, and the difficulty bits value 0x1903a30c, we get:
|
||||
|
||||
++++
|
||||
<ul class="simplelist">
|
||||
<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>
|
||||
<li>target = 0x03a30c × 2<sup>0x08 × (0x19 - 0x03)</sup></li>
|
||||
</ul>
|
||||
++++
|
||||
|
||||
@ -876,16 +874,15 @@ which in decimal is:
|
||||
|
||||
++++
|
||||
<ul class="simplelist">
|
||||
<li>=> target = 238,348 * 2<sup>176</sup></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>
|
||||
<li>22,829,202,948,393,929,850,749,706,076,701,368,331,072,452,018,388,575,715,328</li>
|
||||
</ul>
|
||||
++++
|
||||
|
||||
switching back to hexadecimal:
|
||||
Or, in hexadecimal:
|
||||
|
||||
++++
|
||||
<ul class="simplelist">
|
||||
<li>=> target = <br/>0x0000000000000003A30C00000000000000000000000000000000000000000000</li>
|
||||
<li>0x0000000000000003A30C00000000000000000000000000000000000000000000</li>
|
||||
</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]]
|
||||
.Retargeting the proof of work—[.plain]#++CalculateNextWorkRequired()++# in pow.cpp
|
||||
.Retargeting the proof of work—[.plain]#++CalculateNextWorkRequired()++# in pow.cpp
|
||||
====
|
||||
[source,cpp]
|
||||
----
|
||||
|
||||
@ -339,9 +339,8 @@ Translated forwarding::
|
||||
support forwarding bitcoin payments.
|
||||
|
||||
Native forwarding is conceptually simpler but essentially requires a
|
||||
separate Lightning Network for every asset. Translated forwarding
|
||||
allows building on the economies of scale of the Bitcoin Lightning
|
||||
Network, but it may be vulnerable to a problem called((("free American call option"))) the _free American
|
||||
separate LN for every asset. Translated forwarding
|
||||
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
|
||||
call option_, where a receiver may selectively accept or reject certain
|
||||
payments depending on recent changes to the exchange rate in order to
|
||||
siphon money from the hop next to them. Although there's no known
|
||||
@ -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
|
||||
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
|
||||
commitment transactions was first proposed as part of the Lightning
|
||||
Network.
|
||||
commitment transactions was first proposed as part of the LN.
|
||||
|
||||
To explain revocation keys, we will construct a more complex payment
|
||||
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
|
||||
innovation in this technology. With this construct, the channel can
|
||||
remain open indefinitely and can have billions of intermediate
|
||||
commitment transactions. In implementations of Lightning
|
||||
Network, the commitment state is identified by a 48-bit index, allowing
|
||||
commitment transactions. In implementations of LN, 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
|
||||
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
|
||||
capacity of 4 bitcoins in each channel.
|
||||
|
||||
<<lightning_network_fig>> shows five participants in a Lightning
|
||||
Network, connected by bidirectional payment channels that can be linked
|
||||
<<lightning_network_fig>> shows five participants in an LN, connected by bidirectional payment channels that can be linked
|
||||
to make a payment from Alice to Eric (see <<lightning_network>>).
|
||||
|
||||
[[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"]
|
||||
|
||||
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.
|
||||
|
||||
[[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"]
|
||||
|
||||
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
|
||||
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
|
||||
@ -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 fees they charge to route payments. The routing information can be
|
||||
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
|
||||
route discovery use a P2P model where nodes propagate channel
|
||||
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
|
||||
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,
|
||||
censorship, or blacklists. But how does Alice establish this payment
|
||||
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
|
||||
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
|
||||
information and find the next hop.
|
||||
@ -1192,40 +1188,39 @@ hops to go.
|
||||
|
||||
==== 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
|
||||
that supports some basic capabilities, such as multisignature
|
||||
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,
|
||||
granularity, and speed, without sacrificing the principles of trustless
|
||||
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
|
||||
a route can see payments propagated across their channels, they do not
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
Trustless Operation:: A Lightning Network uses Bitcoin transactions
|
||||
between nodes that operate as peers without trusting each other. Thus, a
|
||||
Lightning Network preserves the principles of the Bitcoin system, while
|
||||
Trustless Operation:: An LN uses Bitcoin transactions
|
||||
between nodes that operate as peers without trusting each other. Thus, an LN 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.
|
||||
|
||||
We have examined just a few of the emerging applications that can be
|
||||
|
||||
@ -125,7 +125,7 @@ Watch us on YouTube: link:$$https://youtube.com/oreillymedia$$[].
|
||||
|
||||
=== Contacting the Authors
|
||||
|
||||
[.align]
|
||||
[role="align"]
|
||||
You can contact Andreas M. Antonopoulos on his personal site:
|
||||
[.keep-together]#link:$$https://antonopoulos.com$$[].#
|
||||
|
||||
|
||||
@ -5,3 +5,6 @@ td.fakeheader {
|
||||
background-color: Black !important;
|
||||
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%); }
|
||||
|
||||
@ -18,6 +18,10 @@ pre[data-type="programlisting"] {
|
||||
font-style: normal;
|
||||
}
|
||||
|
||||
/*--Table lines--*/
|
||||
table td.right, th.right { border-right: 0.25pt solid cmyk(0%,0%,0%,100%); }
|
||||
|
||||
|
||||
td.fakeheader {
|
||||
font-family: "MyriadPro-SemiboldCond" !important;
|
||||
font-weight: 600 !important;
|
||||
|
||||
Loading…
Reference in New Issue
Block a user