Gijs, I love the concept, will have to look at it more. One thought I have had on this subject is that it can also help decorrelated payments on an amount analysis level. It's a step up after we have PTLC's and more timing analysis protections. Curious if you see that as being a possibility with this research write up we did last year:
https://lightningprivacy.com/en/routing-analysis#splintered-payments Tony Giorgio On 9/22/23 09:53, Gijs van Dam wrote: > 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
