Tony Giorgio PM [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2023-07-27 to 2023-09-26
💬 Posted a total of 3 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-10-18 13:02:07

- reply

📅 Original date posted:2023-09-26
🗒️ Summary of this message: The sender discusses the concept of decorrelated payments and suggests that the research on Payment Splitting & Switching (PSS) could help with this. PSS allows for route and amount changes without the sender's knowledge, which could mitigate probing and jamming attacks. The sender provides a link to the research write-up for more information.
📝 Original message:
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/
>