Good afternoon list,
I have touched on Link MPP over alternative routes before [0]. The idea is that a node inside a payment route finds an alternative route to the next node via one (or more) intermediary nodes. ZmnSCPxj and Christian Decker were kind enough to discuss the topic with me a bit more, and since it seemed feasible I went ahead and made a proof of concept by developing a core-lighting plugin called Payment Splitting & Switching (PSS) [1]. There is also a screencast showing the plugin in action. [2] The plugin works as follows. The plugin announces its support for PSS at `init`. If Alice and Bob both support PSS, and Alice receives a payment to be relayed to Bob, she can decide to split up the payment into multiple parts. One part will follow the original route and use the original onion, but it will commit to an HTLC that carries an amount less than the intended amount. Upon receiving that HTLC Bob receives the onion that allows him to forward the payment, but because the HTLC carries less than expected, he will wait for another payment from Alice. Alice sends that payment like a normal payment to Bob over an alternative route, e.g. via a single intermediary node, but contingent on the payment hash of the original payment. Bob does a little bit of housekeeping to check if the combined HTLCs are enough for him to forward the payment, and if so, the payment is forwarded as normal. My interest in Link MPP and PSS (which is basically Link MPP combined with JIT-routing [3]) arose through my research in the Balance Discovery Attack (BDA), aka the probing attack. From the perspective of that attack it is interesting to note that PSS allows for route changes and amount changes *without the sender knowing about it*. So when an attacker has to assume that PSS is used, its interpretation of information obtained through a BDA changes completely. Using real-world data in an LN simulator I saw up to a 62% drop in information gain when PSS is deployed compared to earlier work (Alex Biryukov et al.) without PSS [4]. For details I refer to my preprint on the Cryptology ePrint Archive [5]. Any feedback on it would be highly appreciated. I would also love to hear your thoughts on what role PSS could play, if any, in mitigating probing and/or jamming. Because the paper is at times quite technical, I have also written a set of blog posts introducing the research. [7][8] Finally, I think PSS would also work with PTLC, but because this post is long enough as is, I will leave that for another time. Thank you for your time, Gijs van Dam https://www.gijsvandam.nl [0]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-August/003144.html [1]: https://github.com/gijswijs/plugins/tree/master/pss [2]: https://asciinema.org/a/520416 [3]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-March/001891.html [4]: https://link.springer.com/book/9783031182846 [5]: https://eprint.iacr.org/2023/1360 [7]: https://www.gijsvandam.nl/post/all-types-of-multi-part-payments-in-lightning-network-explained/ [8]: https://www.gijsvandam.nl/post/the-effect-of-multi-part-payments-on-the-balance-disovery-attack/
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
