diff --git a/ch08_signatures.adoc b/ch08_signatures.adoc index bfd598d0..46d1648d 100644 --- a/ch08_signatures.adoc +++ b/ch08_signatures.adoc @@ -875,7 +875,7 @@ integers are modulus p: [latexmath] ++++ \begin{equation} -s = k^-1^ (Hash(m) + x × R) +s = k^{-1} (Hash(m) + x \times R) \end{equation} ++++ _s_ = __k__^-1^ (__Hash__(__m__) + __x__ × __R__) @@ -893,6 +893,12 @@ the _R_, _s_ values and the public key to calculate a value _K_, which is a point on the elliptic curve (the public nonce used in signature creation): +[latexmath] +++++ +\begin{equation} +K = s^{-1} \times Hash(m) \times G + s^{-1} \times R \times X +\end{equation} +++++ _K_ = __s__^-1^ × __Hash__(__m__) × _G_ + __s__^-1^ × _R_ × _X_ where: diff --git a/ch14_applications.adoc b/ch14_applications.adoc index ca34bcff..667dfa85 100644 --- a/ch14_applications.adoc +++ b/ch14_applications.adoc @@ -926,16 +926,19 @@ time. This feature is called a _hash time lock contract_, or _HTLC_, and is used in both bidirectional and routed payment channels. Let's first explain the "hash" part of the HTLC. To create an HTLC, the -intended recipient of the payment will first create a secret +R+. They -then calculate the hash of this secret +H+: +intended recipient of the payment will first create a secret _R_. They +then calculate the hash of this secret _H_: ----- +[latexmath] +++++ +\begin{equation} H = Hash(R) ----- +\end{equation} +++++ -This produces a hash +H+ that can be included in an output's +This produces a hash _H_ that can be included in an output's script. Whoever knows the secret can use it to redeem the output. The -secret +R+ is also referred to as a _preimage_ to the hash function. The +secret _R_ is also referred to as a _preimage_ to the hash function. The preimage is just the data that is used as input to a hash function. [role="less_space pagebreak-before"] @@ -958,7 +961,7 @@ ELSE ENDIF ---- -Anyone who knows the secret +R+, which when hashed equals to +H+, can +Anyone who knows the secret _R_, which when hashed equals to _H_, can redeem this output by exercising the first clause of the +IF+ flow. If the secret is not revealed and the HTLC claimed after a certain @@ -966,11 +969,11 @@ number of blocks, the payer can claim a refund using the second clause in the +IF+ flow. This is a basic implementation of an HTLC. This type of HTLC can be -redeemed by _anyone_ who has the secret +R+. An HTLC can take many +redeemed by _anyone_ who has the secret _R_. An HTLC can take many different forms with slight variations to the script. For example, adding a +CHECKSIG+ operator and a public key in the first clause restricts redemption of the hash to a particular recipient, who must also -know the((("Bitcoin", "as application platform", "payment channels", secondary-sortas="application platform", startref="bitcoin-app-platform-payment")))((("application platform, Bitcoin as", "payment channels", startref="app-platform-payment")))((("payment channels", startref="payment-channel")))((("payment channels", "HTLC (Hash Time Lock Contract)", startref="payment-channel-htlc")))((("HTLC (Hash Time Lock Contract)", startref="htlc")))((("Hash Time Lock Contract (HTLC)", startref="hash-time-lock-contract"))) secret +R+. +know the((("Bitcoin", "as application platform", "payment channels", secondary-sortas="application platform", startref="bitcoin-app-platform-payment")))((("application platform, Bitcoin as", "payment channels", startref="app-platform-payment")))((("payment channels", startref="payment-channel")))((("payment channels", "HTLC (Hash Time Lock Contract)", startref="payment-channel-htlc")))((("HTLC (Hash Time Lock Contract)", startref="htlc")))((("Hash Time Lock Contract (HTLC)", startref="hash-time-lock-contract"))) secret _R_. [[lightning_network]] === Routed Payment Channels (Lightning Network)