📅 Original date posted:2020-10-20
📝 Original message:
Hi Bastien,
Thanks for creating the summary!
While doing this exercise, I couldn't find a reason why the `reverse
> upfront payment` proposal
> would be broken (notice that I described it using a flat amount after a
> grace period, not an amount
> based on the time HTLCs are held). Can someone point me to the most
> obvious attacks on it?
>
> It feels to me that its only issue is that it still allows spamming for
> durations smaller than the
> grace period; my gut feeling is that if we add a smaller forward direction
> upfront payment to
> complement it it could be a working solution.
>
The 'uncontrolled spamming' as you called it in your doc is pretty serious.
If you want to have fun, you should really try to spin up a bunch of
threads and keep your outgoing channels fully saturated with max length
routes going nowhere. I tried it on testnet and it was quite bad. All that
traffic is fighting for resources which makes it take even longer to unlock
the htlcs again.
I think that any solution should definitely address this case too.
Your proposal to add a small upfront payment, wouldn't that allow the
(arbitrary) grace period to be removed? It would mean that routing nodes
always need to pay something for forwarding spam, but if they do it quick
enough (honest nodes) that expense is covered by the upfront payment.
- Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201020/0861166d/attachment-0001.html>;
Joost Jager [ARCHIVE] /
npub1as…wfqmx
2023-06-09 13:01:14
in reply to nevent1q…6u5v
Author Public Key
npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxPublished at
2023-06-09 13:01:14Event JSON
{
"id": "c356d8dd3b236cf6a2cd5de9eca5dc8fcb963e36f1158dc5913ef3fd8fa1a769",
"pubkey": "ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3",
"created_at": 1686315674,
"kind": 1,
"tags": [
[
"e",
"2e5ffd65d86c5774dbb4381933898049e781bd6e8719e31c24e98ee704e67d6e",
"",
"root"
],
[
"e",
"a36601ed3549a225925901c57ec7f613f371a83312b56fa2a9bd7977b83acc09",
"",
"reply"
],
[
"p",
"f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb"
]
],
"content": "📅 Original date posted:2020-10-20\n📝 Original message:\nHi Bastien,\n\nThanks for creating the summary!\n\nWhile doing this exercise, I couldn't find a reason why the `reverse\n\u003e upfront payment` proposal\n\u003e would be broken (notice that I described it using a flat amount after a\n\u003e grace period, not an amount\n\u003e based on the time HTLCs are held). Can someone point me to the most\n\u003e obvious attacks on it?\n\u003e\n\u003e It feels to me that its only issue is that it still allows spamming for\n\u003e durations smaller than the\n\u003e grace period; my gut feeling is that if we add a smaller forward direction\n\u003e upfront payment to\n\u003e complement it it could be a working solution.\n\u003e\n\nThe 'uncontrolled spamming' as you called it in your doc is pretty serious.\nIf you want to have fun, you should really try to spin up a bunch of\nthreads and keep your outgoing channels fully saturated with max length\nroutes going nowhere. I tried it on testnet and it was quite bad. All that\ntraffic is fighting for resources which makes it take even longer to unlock\nthe htlcs again.\n\nI think that any solution should definitely address this case too.\n\nYour proposal to add a small upfront payment, wouldn't that allow the\n(arbitrary) grace period to be removed? It would mean that routing nodes\nalways need to pay something for forwarding spam, but if they do it quick\nenough (honest nodes) that expense is covered by the upfront payment.\n\n- Joost\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201020/0861166d/attachment-0001.html\u003e",
"sig": "8bd8f7b3aa0872d6bb8bb3059b03f6acce217ee0fb9130931d32c56cb9f050570636dc191d7d4b8d6a9d925995c979fd94552a3cbcaec5ad3fffa8ed00dc5672"
}