rich1.0npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxhttps://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxnjumphttps://nostr.ae📅 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>