{"type":"rich","version":"1.0","author_name":"npub139lamalg6mww4czepk75anugudczcglp8p9ej9kafmkvgxyk4uus7mvj0j","author_url":"https://nostr.ae/npub139lamalg6mww4czepk75anugudczcglp8p9ej9kafmkvgxyk4uus7mvj0j","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-04-23\n📝 Original message:\nI propose a simple mitigation to increase the capital requirement of\nchannel-jamming attacks. This would prevent an unsophisticated attacker\nwith low capital from jamming a target channel.  It seems to me that this\nis a *free* mitigation without any downsides (besides code-writing), so I'd\nlike to hear other opinions.\n\nIn a commitment transaction, we trim dust HTLC outputs.  I believe that the\nreason for the 483 HTLC limit each side has in the spec is to prevent\ncommitment tx's from growing unreasonably large, and to ensure they are\nstill valid tx's that can be included in a block.  If we don't include dust\nHTLCs in this calculation, since they are not on the commitment tx, we\nstill allow 483 (x2) non-dust HTLCs to be included on the commitment tx.\nThere could be a configurable limit on the number of outstanding dust\nHTLCs, but the point is that it doesn't affect the non-dust throughput of\nthe channel.  This raises the capital requirement of channel-jamming so\nthat each HTLC must be non-dust, rather than spamming 1 sat payments.\n\nInterested in others' thoughts.\n\nEugene (Crypt-iQ)\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210423/28a7f555/attachment.html\u003e"}