{"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-12\n📝 Original message:\nHello list,\n\nMany discussions have taken place on this list on how to prevent undesired\nuse of the Lightning network. Spamming the network with HTLCs (for probing\npurposes or otherwise) or holding HTLCs to incapacitate channels can be\ndone on today's network at very little cost to an attacker. So far this\ndoesn't seem to be happening in practice, but I believe that it is only a\nmatter of time before it will become a real issue.\n\nRate limits and other limits such as the maximum number of in-flight HTLCs\nincrease the cost of an attack, but may also limit the capabilities of\nhonest users. It works as a mitigation, but it doesn't seem to be the ideal\nsolution.\n\nWe've looked at all kinds of trustless payment schemes to keep users\nhonest, but it appears that none of them is satisfactory. Maybe it is even\ntheoretically impossible to create a scheme that is trustless and has all\nthe properties that we're looking for. (A proof of that would also be\nuseful information to have.)\n\nPerhaps a small bit of trust isn't so bad. There is trust in Lightning\nalready. For example when you open a channel, you trust (or hope) that your\npeer remains well connected, keeps charging reasonable fees, doesn't\nforce-close in a bad way, etc.\n\nWhat I can see working is a system where peers charge each other a hold fee\nfor forwarded HTLCs based on the actual lock time (not the maximum lock\ntime) and the htlc value. This is just for the cost of holding and separate\nfrom the routing fee that is earned when the payment settles.\n\nThis hold fee could be: lock_time * (fee_base + fee_rate * htlc_value).\nfee_base is in there to compensate for the usage of an htlc slot, which is\na scarce resource too.\n\nI think the implementation of this is less interesting at this stage, but\nsome ideas are:\n\nA. Prepayment: node pays an amount to its channel peer (for example via\nkeysend) and the channel peer deducts the hold fees from that prepaid\nbalance until it is at zero. At that point it somehow (in the htlc fail\nmessage?) communicates Lightning's version of http 402 to ask for more\nmoney.\n\nB. Tightly integrated with the htlc add/fail/settle messages. When an htlc\nis added, the maximum cost (based on maximum lock time) for holding is\ndeducted from the sender's channel balance. When the htlc settles, a refund\nis given based on the actual lock time. An additional `update_fee`-like\nmessage is added for peers to update their hold fee parameters (fee_base\nand fee_rate).\n\nIn both cases the sender needs to trust its peer to not steal the payment\nand/or artificially delay the forwarding to inflate the hold fee. I think\nthat is acceptable given that there is a trust relation between peers\nalready anyway.\n\nA crucial thing is that these hold fees don't need to be symmetric. A new\nnode for example that opens a channel to a well-known, established routing\nnode will be forced to pay a hold fee, but won't see any traffic coming in\nanymore if it announces a hold fee itself. Nodes will need to build a\nreputation before they're able to command hold fees. Similarly, routing\nnodes that have a strong relation may decide to not charge hold fees to\neach other at all.\n\nThis asymmetry is what is supposed to prevent channel jamming attacks. The\nattacker needs to pay hold fees to send out the payment, but when it comes\nback to the attacker after traversing a circular route, they won't be able\nto charge a hold fee to cancel out the hold fee paid at the start of the\nroute. (Assuming the attacker node is not trusted.)\n\nA consequence for honest users is that payment attempts are no longer free.\nThe cost should however be negligible for fast-failing attempts. Also\nsenders will have to be a lot more selective when building a route.\nSelecting a 'black hole' hop (hop that doesn't forward nor fail) can be\ncostly.\n\nThe hold fee scheme is a bit looser compared to previously proposed schemes\n(as far as I know...). It is purely an arrangement between channel peers\nand doesn't try to exactly compensate every hop for its costs. Instead\ntrust relations that arguably exist already are leveraged to present a bill\nto the actor who deserves it.\n\nInterested to hear opinions about this proposal.\n\nI'd also like to encourage everyone to prioritize this spam/jam issue and\ndedicate more time to solving it. Obviously there is a lot more to do in\nLightning, but I am not sure if we can afford to wait for the real\nadversaries to show up on this one.\n\nCheers,\nJoost\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201012/c7943c5e/attachment.html\u003e"}