{"type":"rich","version":"1.0","author_name":"npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","author_url":"https://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 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"}