PSS

_src/posts/payment-splitting-in-lightning-network.md

@@ -9,7 +9,7 @@ math: true
 Lightning Network uses source-based routing. What that means is that the sender is responsible for finding a route to the payee. But because the sender doesn't know the balances of all channels along a possible route, the proposed route can fail for lack of liquidity. So the sender is forced to try routes until it stumbles upon one that has enough liquidity to relay the payment; it's a process of trial and error. To increase the likelihood of success the idea of splitting up a payments into smaller parts was floated early on in the development of Lightning Network. The idea was that multiple smaller payments were more likely to succeed than one big payment. But you still want all separate parts of such a payment to act as one single atomic payment, that either succeeds completely or doesn't succeed at all.
 <!-- more -->
 
-This post assumes you have knowledge about how payments work in Lightning Network, especially HTLCs and pre-images. If you want to know more about how payments actually work in Lightning Network, you can check my other post on [Lightning Network payments][ln-post]. In this post I will dive into the specific types of multi-part payments, as they are called, and explain a new type of multi-part payment that I developed. Also, if you look at what has been written on multi-part payments, you will see that multi-part and multi-path are used interchangeably. I think multi-part better describes what is happening, so I'll stick to that.
+This post assumes you have knowledge about how payments work in Lightning Network, especially HTLCs and pre-images. If you want to know more about how payments actually work in Lightning Network, you can check my other post on [Lightning Network payments][ln-post]. In this post I will dive into the specific types of multi-part payments, as they are called, and explain a new type of multi-part payment that I developed. Also, if you look at what has been written on multi-part payments, you will see that multi-part and multi-path are used interchangeably. I think multi-part better describes what is happening, so I'll try to stick to that.
 
 ## Base MPP
 
@@ -43,10 +43,27 @@ With payments points and PTLCs out of the way, let's explain how we can use this
 
 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.
 
+But this is all still theoretical. PTLCs require adaptor signatures, and although it was already possible to do so, this was made a lot easier with the advent of Schnorr signatures in Bitcoin. Schnorr signatures were activated in Bitcoin in November 2021. Since then the LN community has focussed on other stuff first, but recently PTLCs were [put top-of-mind again][ln-dev2]. But for now they are still "just around the corner".
+
+## Payment Splitting & Switching (PSS)
+
+In November 2018, ZmnSCPxj proposed a combination of [Link-level payment splitting and via intermediary rendezvous nodes][ln-dev3]. The idea was that it would allow for "payment splitting over multiple hops" instead of payment splitting over parallel channels in the same hop. I liked the idea of it, but thought of it more as a combination of [Just In Time Routing][jit] and Link MPP. Both ZmnSCPxj and Christian Decker were willing to [discuss the idea][ln-dev4], and it sounded feasible at the time, so I went on and created a `core lightning` [plugin][pss-plugin] as a proof of concept.
+
+To understand what the PSS plugin does, and how it's different from Link MPP, you have to first remember that the type of source based routing that LN uses, makes it impossible for any node along the route to know anything more than the previous and the next node in the route. So an intermediary node can never change the payment path to use an alternative route to the destination, because it has no idea what the destination is. But it *does* know what the next node is, and quite often there is an alternative non-direct route to the next node, e.g. a route with a single intermediary node.
+
+PSS is similar to Link MPP in that two channel partners along a route agree to forward a payment in parts between them. One partner breaks up the payment in parts, the other reassembles them and forwards them as a single HTLC, as if nothing happened. Where PSS and Link MPP differ is that Link MPP only works with parallel channels, PSS also works with multi-hop routes.
+
+My plugin is just a proof of concept and should definitely not be used with an actual `core lightning` node, but it did allow me to use it for my research on Balance Discovery Attacks and it had some real interesting implications. More on that in my next post.
+
 [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"
 [boltmpp]: https://github.com/lightning/bolts/blob/master/04-onion-routing.md#basic-multi-part-payments "BOLT #4: Basic Multi-Part Payments"
 [bitcoinse1]: https://bitcoin.stackexchange.com/questions/98697/what-is-link-level-multiplexing "What is Link-Level Multiplexing?"
 [bitcoinse2]: https://bitcoin.stackexchange.com/questions/89475/what-are-atomic-multi-path-payments-amps-and-why-how-is-it-being-implemented-i "What are atomic multi path payments (AMPs) and why/how is it being implemented in Lightning Network?"
 [ln-dev]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html "AMP: Atomic Multi-Path Payments over Lightning"
 [sa-post]: /post/why-does-signature-half-aggregation-break-adaptor-signatures/ "Why does signature half aggregation break adaptor signatures?"
+[ln-dev2]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-September/004088.html "Practical PTLCs, a little more concretely"
+[ln-dev3]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001573.html "Link-level payment splitting via intermediary rendezvous nodes"
+[jit]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-March/001891.html "Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0"
+[ln-dev4]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-August/003144.html "Revisiting Link-level payment splitting via intermediary rendezvous nodes"
+[pss-plugin]: https://github.com/gijswijs/plugins/tree/master/pss "Payment Splitting & Switching plugin"