Archives/lnbook
2
0
Fork 0
mirror of https://github.com/lnbook/lnbook synced 2024-11-15 00:15:05 +00:00
Code Issues Projects Releases Wiki Activity

Edited 08_routing_htlcs.asciidoc with Atlas code editor

Browse Source
This commit is contained in:
kristen@oreilly.com 2021-10-27 17:29:07 -07:00
parent e13a07fa09
commit 3f3d2d3441
1 changed files with 13 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
08_routing_htlcs.asciidoc
View File

@ -128,16 +128,16 @@ In practice, this secret would be a random number that is large enough to preven
Dina generates this secret value +R+ from a random number generator.
The secret could then be committed to the contract by including the SHA256 hash of the secret in the contract itself, as follows:
The secret could then be committed to the contract by including the SHA-256 hash of the secret in the contract itself, as follows:
latexmath:[\(H = SHA256(R)\)]
latexmath:[\(H = SHA-256(R)\)]
We call this hash of the payment's secret the _payment hash_.
The secret that "unlocks" the payment is called the _payment secret_.
For now, we keep things simple and assume that Dina's secret is simply the text line: `Dinas secret`. This secret message is called the _payment secret_ or _payment preimage_.
To "commit" to this secret, Dina computes the SHA256 hash, which when encoded in hexadecimal, can be displayed as follows: `0575965b3b44be51e8057d551c4016d83cb1fba9ea8d6e986447ba33fe69f6b3`.
To "commit" to this secret, Dina computes the SHA-256 hash, which when encoded in hexadecimal, can be displayed as follows: `0575965b3b44be51e8057d551c4016d83cb1fba9ea8d6e986447ba33fe69f6b3`.
To facilitate Alice's payment, Dina will create the payment secret and the payment hash and send the payment hash to Alice. In <<alice_dina_routing_3>> we see that Dina sends the payment hash to Alice via some external channel (dashed line), such as an email or text message:
@ -325,17 +325,17 @@ In <<alice_dina_invoice_2>> we see Alice getting a Lightning invoice from Dina.
.Alice gets a payment hash from Dina
image::images/mtln_0808.png["Alice gets a payment hash from Dina"]
In the Lightning Network, Dina's payment preimage won't be a phrase like +Dinas secret+ but a random number generated by Dina's node. Let's call that random number +R+.
In the Lightning Network, Dina's payment preimage won't be a phrase like +Dinas secret+ but a random number generated by Dina's node. Let's call that random number _R_.
Dina's node will calculate a cryptographic hash of +R+, such that:
Dina's node will calculate a cryptographic hash of _R_, such that:
[[payment_hash_and_preimage]]
.Calculating the payment hash
----
H = SHA256(R)
----
++++
<ul class="simplelist">
<li><em>H</em> = SHA-256(<em>R</em>)</li>
</ul>
++++
In this code, +H+ is the hash, or _payment hash_ and +R+ is the secret or _payment preimage_.
In this equation, _H_ is the hash, or _payment hash_ and _R_ is the secret or _payment preimage_.
The use of a cryptographic hash function is one element that guarantees _trustless operation_. The payment intermediaries do not need to trust each other because they know that no one can guess the secret or fake it.
@ -534,9 +534,9 @@ In hexadecimal encoding, +OP_SHA256+ is +a8+ and +OP_EQUALVERIFY+ is +88+. The t
As we've mentioned previously, any participant in the Lightning Network should be able to take an off-chain transaction they hold and put it on-chain if they need to enforce their claim to funds. To take a transaction on-chain, they'd have to pay transaction fees to the miners, and these fees are proportional to the size in bytes of the transaction.
Therefore, we want to find ways to minimize the on-chain "weight" of transactions by optimizing the script as much as possible. One way to do that is to add another hash function on top of the SHA256 algorithm, one that produces smaller hashes. The Bitcoin Script language provides the +OP_HASH160+ operator that "double hashes" a preimage: first the preimage is hashed with SHA256, and then the resulting hash is hashed again with the RIPEMD160 hash algorithm. The hash resulting from RIPEMD160 is 160 bits or 20 bytes--much more compact. In Bitcoin Script this is a very common optimization that is used in many of the common address formats.
Therefore, we want to find ways to minimize the on-chain "weight" of transactions by optimizing the script as much as possible. One way to do that is to add another hash function on top of the SHA-256 algorithm, one that produces smaller hashes. The Bitcoin Script language provides the +OP_HASH160+ operator that "double hashes" a preimage: first the preimage is hashed with SHA-256, and then the resulting hash is hashed again with the RIPEMD160 hash algorithm. The hash resulting from RIPEMD160 is 160 bits or 20 bytes--much more compact. In Bitcoin Script this is a very common optimization that is used in many of the common address formats.
So, let's use that optimization instead. Our SHA256 hash is +057596...69f6b3+. Putting that through another round of hashing with RIPEMD160 gives us the result:
So, let's use that optimization instead. Our SHA-256 hash is +057596...69f6b3+. Putting that through another round of hashing with RIPEMD160 gives us the result:
----
R = "Dinas secret"