đź“… 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/
>
Tony Giorgio PM [ARCHIVE] /
npub1er…60a6n
2023-10-18 13:02:07
in reply to nevent1q…2uf9
Author Public Key
npub1erc4qwsluhd7utrc028243jyv5veflq32hjpfzgvxvh8uh4h34tsv60a6nPublished at
2023-10-18 13:02:07Event JSON
{
"id": "03da166e1eb623286c20a69775f62fbc68d07cdeb09a644b02db823436307ebd",
"pubkey": "c8f1503a1fe5dbee2c787a8eaac644651994fc1155e414890c332e7e5eb78d57",
"created_at": 1697634127,
"kind": 1,
"tags": [
[
"e",
"576d8a396c0f06821519cea3b725dedde2e65e50e0251a32997e7be9fa0d7a93",
"",
"root"
],
[
"e",
"9368f2c4e7bf05f3272816b699acc5e015d8d28a897b441c69cd9e5b6cbc1b86",
"",
"reply"
],
[
"p",
"bca62914d6266e52b5f5a14597991874e884635a9df737f2beb05e5c33ccc5ef"
]
],
"content": "📅 Original date posted:2023-09-26\n🗒️ Summary of this message: The sender discusses the concept of decorrelated payments and suggests that the research on Payment Splitting \u0026 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.\n📝 Original message:\nGijs,\n\nI love the concept, will have to look at it more. One thought I have had \non this subject is that it can also help decorrelated payments on an \namount analysis level. It's a step up after we have PTLC's and more \ntiming analysis protections. Curious if you see that as being a \npossibility with this research write up we did last year:\n\nhttps://lightningprivacy.com/en/routing-analysis#splintered-payments\n\nTony Giorgio\n\nOn 9/22/23 09:53, Gijs van Dam wrote:\n\u003e Good afternoon list,\n\u003e\n\u003e\n\u003e I have touched on Link MPP over alternative routes before [0]. The \n\u003e idea is that a node inside a payment route finds an alternative route \n\u003e to the next node via one (or more) intermediary nodes. ZmnSCPxj and \n\u003e Christian Decker were kind enough to discuss the topic with me a bit \n\u003e more, and since it seemed feasible I went ahead and made a proof of \n\u003e concept by developing a core-lighting plugin called Payment Splitting \n\u003e \u0026 Switching (PSS) [1]. There is also a screencast showing the plugin \n\u003e in action. [2]\n\u003e\n\u003e The plugin works as follows. The plugin announces its support for PSS \n\u003e at `init`. If Alice and Bob both support PSS, and Alice receives a \n\u003e payment to be relayed to Bob, she can decide to split up the payment \n\u003e into multiple parts. One part will follow the original route and use \n\u003e the original onion, but it will commit to an HTLC that carries an \n\u003e amount less than the intended amount. Upon receiving that HTLC Bob \n\u003e receives the onion that allows him to forward the payment, but because \n\u003e the HTLC carries less than expected, he will wait for another payment \n\u003e from Alice. Alice sends that payment like a normal payment to Bob over \n\u003e an alternative route, e.g. via a single intermediary node, but \n\u003e contingent on the payment hash of the original payment. Bob does a \n\u003e little bit of housekeeping to check if the combined HTLCs are enough \n\u003e for him to forward the payment, and if so, the payment is forwarded as \n\u003e normal.\n\u003e\n\u003e My interest in Link MPP and PSS (which is basically Link MPP combined \n\u003e with JIT-routing [3]) arose through my research in the Balance \n\u003e Discovery Attack (BDA), aka the probing attack. From the perspective \n\u003e of that attack it is interesting to note that PSS allows for route \n\u003e changes and amount changes *without the sender knowing about it*. So \n\u003e when an attacker has to assume that PSS is used, its interpretation of \n\u003e information obtained through a BDA changes completely. Using \n\u003e real-world data in an LN simulator I saw up to a 62% drop in \n\u003e information gain when PSS is deployed compared to earlier work (Alex \n\u003e Biryukov et al.) without PSS [4].\n\u003e\n\u003e For details I refer to my preprint on the Cryptology ePrint Archive \n\u003e [5]. Any feedback on it would be highly appreciated. I would also love \n\u003e to hear your thoughts on what role PSS could play, if any, in \n\u003e mitigating probing and/or jamming.\n\u003e\n\u003e Because the paper is at times quite technical, I have also written a \n\u003e set of blog posts introducing the research. [7][8]\n\u003e\n\u003e Finally, I think PSS would also work with PTLC, but because this post \n\u003e is long enough as is, I will leave that for another time.\n\u003e\n\u003e Thank you for your time,\n\u003e\n\u003e Gijs van Dam\n\u003e https://www.gijsvandam.nl\n\u003e\n\u003e\n\u003e [0]: \n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-August/003144.html\n\u003e [1]: https://github.com/gijswijs/plugins/tree/master/pss\n\u003e [2]: https://asciinema.org/a/520416\n\u003e [3]: \n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-March/001891.html\n\u003e [4]: https://link.springer.com/book/9783031182846\n\u003e [5]: https://eprint.iacr.org/2023/1360\n\u003e [7]: \n\u003e https://www.gijsvandam.nl/post/all-types-of-multi-part-payments-in-lightning-network-explained/\n\u003e [8]: \n\u003e https://www.gijsvandam.nl/post/the-effect-of-multi-part-payments-on-the-balance-disovery-attack/\n\u003e",
"sig": "e3727cfd314f8502f918e318d92862bdfc600b78672f711a499dd67a6e3ac849862c7b651f9a16b06ac55b44a94a018ead8e90f4b25bfe8f4aa01ec2aea5878c"
}