Gijs van Dam [ARCHIVE] on Nostr: 📅 Original date posted:2023-09-22 🗒️ Summary of this message: Gijs van Dam ...
📅 Original date posted:2023-09-22
🗒️ Summary of this message: Gijs van Dam has developed a proof of concept called Payment Splitting & Switching (PSS) that allows for route and amount changes in Lightning Network payments. PSS could potentially mitigate probing and jamming attacks.
📝 Original message:
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230922/0a2a7531/attachment.html>;
🗒️ Summary of this message: Gijs van Dam has developed a proof of concept called Payment Splitting & Switching (PSS) that allows for route and amount changes in Lightning Network payments. PSS could potentially mitigate probing and jamming attacks.
📝 Original message:
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230922/0a2a7531/attachment.html>;