From c4394ea3d2db1abcc3e541aed6ff1d2dfff8105c Mon Sep 17 00:00:00 2001 From: Gijs van Dam Date: Fri, 15 Sep 2023 13:30:55 +0200 Subject: [PATCH] Typos --- _src/posts/payment-splitting-in-lightning-network.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/_src/posts/payment-splitting-in-lightning-network.md b/_src/posts/payment-splitting-in-lightning-network.md index 5240cd54..e306016a 100644 --- a/_src/posts/payment-splitting-in-lightning-network.md +++ b/_src/posts/payment-splitting-in-lightning-network.md @@ -35,13 +35,13 @@ AMP has one big downside. It is the sender who creates the secrets that XOR into PTLCs deserve their own write-up, which I will get to in time, but here is a crash course. Let's start with claiming that PTLCs are HTLCs that replace the payment hash with a payment point. A payment point is a point on an elliptic curve (the secp256k1 curve to be exact). A point on an elliptic curve is the multiplication of some secret number *x* between \\(0\\) and \\(\sim2^{256}\\) and a base point *G* that is specific to the curve you are using. The payment point P now becomes \\(P=xG\\). So *P* is the public key of the private key *x*. You can read more about elliptic curve cryptography in my post on [signature aggregation][sa-post], but remember this one thing: It is easy to create the payment point *P* if you know *x*, but it is impossible to create the value *x* if you know *P*. Another thing you need to know is that elliptic curve points has this nice addition preserving property: \\(xG + yG = (x+y)G\\). -With PTLC the pre-image is *z*, and its public key \\(Z=zG\\) is shared through the invoice. Now if a sender wants to pay said invoice, it finds a route and for each hop in that route it creates a random nonce (\\(x_1, x_2, \cdots , x_i\\)). For the first hop the sender uses \\(x_1G + Z = (x_1 + z)G\\) as payment point, and it shares \\(x_2\\) with the first routing node. The first routing node now adds \\(x_{2}G\\) to the payment point of the PTLC it received and uses that as the payment point for the following hop, so that payment point becomes \\((x_{1} + x_{2} + z)G\\). The next routing node receives (\\(x_3\\) from the sender, and adds \\(x_{3}G\\) to the payment point. This continues untill the receiver is reached with the payment point \\((x_1 + x_2 + \cdots + x_i + z)G\\). The sender shares \\((x_1 + x_2 + \cdots + x_i)\\) with the receiver. Note that this is different from what the routing nodes receive. They all received a single nonce, but the receiver gets the aggregate of all nonces. +With PTLC the pre-image is *z*, and its public key \\(Z=zG\\) is shared through the invoice. Now if a sender wants to pay said invoice, it finds a route and for each hop in that route it creates a random nonce (\\(x_1, x_2, \cdots , x_i\\)). For the first hop the sender uses \\(x_1G + Z = (x_1 + z)G\\) as payment point, and it shares \\(x_2\\) with the first routing node. The first routing node now adds \\(x_{2}G\\) to the payment point of the PTLC it received and uses that as the payment point for the following hop, so that payment point becomes \\((x_{1} + x_{2} + z)G\\). The next routing node receives (\\(x_3\\) from the sender, and adds \\(x_{3}G\\) to the payment point. This continues until the receiver is reached with the payment point \\((x_1 + x_2 + \cdots + x_i + z)G\\). The sender shares \\((x_1 + x_2 + \cdots + x_i)\\) with the receiver. Note that this is different from what the routing nodes receive. They all received a single nonce, but the receiver gets the aggregate of all nonces. -Because the receiver knows *z*, we can now start the reveal phase. The receiver adds *z* to the aggregrate of nonces it received from the sender. This is the secret it can use to collect the payment from the last routing node. The last routing node now learns \\((x_1 + x_2 + \cdots + x_i + z)\\) and already knows \\(x_i\\) (because the sender shared it) so it can substract its nonce from the secret and that's the secret the last routing node can use to collect its payment. This continues untill the sender learns the secret to the first payment point: \\((x_1 + z)\\). The sender knows all nonces, so it definitely knows \\(x_1\\) and uses it to learn *z*. What's cool about the reveal of *z* in payments using PTLC, is that only the sender learns *z*, but none of the routing nodes do. So it's an even better proof of payment than the pre-image to a payment hash, because with HTLCs all the routing nodes learn the pre-image as well. +Because the receiver knows *z*, we can now start the reveal phase. The receiver adds *z* to the aggregate of nonces it received from the sender. This is the secret it can use to collect the payment from the last routing node. The last routing node now learns \\((x_1 + x_2 + \cdots + x_i + z)\\) and already knows \\(x_i\\) (because the sender shared it) so it can subtract its nonce from the secret and that's the secret the last routing node can use to collect its payment. This continues untill the sender learns the secret to the first payment point: \\((x_1 + z)\\). The sender knows all nonces, so it definitely knows \\(x_1\\) and uses it to learn *z*. What's cool about the reveal of *z* in payments using PTLC, is that only the sender learns *z*, but none of the routing nodes do. So it's an even better proof of payment than the pre-image to a payment hash, because with HTLCs all the routing nodes learn the pre-image as well. With payments points and PTLCs out of the way, let's explain how we can use this to create High AMP, which is OG AMP without its downsides. In a way, High AMP is just the combination of OG AMP with PTLCs: -The sender creates the Base Secret just like before. Using the BS it creates a pre-image for each payment part, also just like before (\\( r_i = SHA256(BP || i) \\)). Now the sender uses those pre-images to create points on the elliptic curve: \\(r_{i}G\\). For payment part *i* it adds \\(r_{i}G\\) to the payment point for the first hop. Routing of the payment continues as with normal. So the receiver receives a payment with payment point \\((r_i + x_{i_1} + x_{i_2} + \cdots + x_{i_j} + z)G\\) for each of the payment parts. It can't collect any of them, because the receiver doesn't know \\(r_i\\). But just like with OG AMP, with each payment the payer also shares a secret \\(s_i\\) and the sequence number *i*. When the receiver has received all payment parts, it can construct the Base Secret *BS*, and can create all pre-images, and use them together with the knowlegde of *z* to collect each payment part. Once the first payment part is revealed to the sender, the sender learns *z*, but not any time before. So *z* retains it power as a proof of payment! High AMP is the best of both worlds, it doesn't resort to an economic incentive to make payments atomic, but it retains the power of a cryptographic proof of payment. +The sender creates the Base Secret just like before. Using the BS it creates a pre-image for each payment part, also just like before (\\( r_i = SHA256(BP || i) \\)). Now the sender uses those pre-images to create points on the elliptic curve: \\(r_{i}G\\). For payment part *i* it adds \\(r_{i}G\\) to the payment point for the first hop. Routing of the payment continues as normal. So the receiver receives a payment with payment point \\((r_i + x_{i_1} + x_{i_2} + \cdots + x_{i_j} + z)G\\) for each of the payment parts. It can't collect any of them, because the receiver doesn't know \\(r_i\\). But just like with OG AMP, with each payment the payer also shares a secret \\(s_i\\) and the sequence number *i*. When the receiver has received all payment parts, it can construct the Base Secret *BS*, and can create all pre-images, and use them together with the knowledge of *z* to collect each payment part. Once the first payment part is revealed to the sender, the sender learns *z*, but not any time before. So *z* retains it power as a proof of payment! High AMP is the best of both worlds, it doesn't resort to an economic incentive to make payments atomic, but it retains the power of a cryptographic proof of payment. [ln-post]: /post/how-do-payments-in-lightning-network-work/ "How do payments in Lightning Network work?" [optech]: https://bitcoinops.org/en/topics/multipath-payments/ "Bitcoin Optech: Multipath payments"