mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-11-25 17:38:26 +00:00
QC1 and math check
This commit is contained in:
parent
48cd7ae0b1
commit
b4576263bb
@ -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
|
||||||
|
@ -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.
|
||||||
****
|
****
|
||||||
|
|
||||||
|
@ -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]
|
||||||
|
@ -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.
|
||||||
|
|
||||||
|
@ -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.
|
||||||
|
@ -228,22 +228,22 @@ unsigned integers:
|
|||||||
</thead>
|
</thead>
|
||||||
<tbody>
|
<tbody>
|
||||||
<tr>
|
<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>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>>= <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>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>>= <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>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>>= <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>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>
|
||||||
|
@ -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
|
||||||
----
|
----
|
||||||
|
@ -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:
|
||||||
|
@ -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}
|
||||||
++++
|
++++
|
||||||
|
|
||||||
|
@ -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}
|
||||||
++++
|
++++
|
||||||
|
|
||||||
@ -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—[.plain]#++CalculateNextWorkRequired()++# in pow.cpp
|
.Retargeting the proof of work—[.plain]#++CalculateNextWorkRequired()++# in pow.cpp
|
||||||
====
|
====
|
||||||
[source,cpp]
|
[source,cpp]
|
||||||
----
|
----
|
||||||
|
@ -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
|
||||||
|
@ -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,3 +5,6 @@ td.fakeheader {
|
|||||||
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%); }
|
||||||
|
@ -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;
|
||||||
|
Loading…
Reference in New Issue
Block a user