rich1.0npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxhttps://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxnjumphttps://nostr.ae📅 Original date posted:2020-10-12 📝 Original message: Hello list, Many discussions have taken place on this list on how to prevent undesired use of the Lightning network. Spamming the network with HTLCs (for probing purposes or otherwise) or holding HTLCs to incapacitate channels can be done on today's network at very little cost to an attacker. So far this doesn't seem to be happening in practice, but I believe that it is only a matter of time before it will become a real issue. Rate limits and other limits such as the maximum number of in-flight HTLCs increase the cost of an attack, but may also limit the capabilities of honest users. It works as a mitigation, but it doesn't seem to be the ideal solution. We've looked at all kinds of trustless payment schemes to keep users honest, but it appears that none of them is satisfactory. Maybe it is even theoretically impossible to create a scheme that is trustless and has all the properties that we're looking for. (A proof of that would also be useful information to have.) Perhaps a small bit of trust isn't so bad. There is trust in Lightning already. For example when you open a channel, you trust (or hope) that your peer remains well connected, keeps charging reasonable fees, doesn't force-close in a bad way, etc. What I can see working is a system where peers charge each other a hold fee for forwarded HTLCs based on the actual lock time (not the maximum lock time) and the htlc value. This is just for the cost of holding and separate from the routing fee that is earned when the payment settles. This hold fee could be: lock_time * (fee_base + fee_rate * htlc_value). fee_base is in there to compensate for the usage of an htlc slot, which is a scarce resource too. I think the implementation of this is less interesting at this stage, but some ideas are: A. Prepayment: node pays an amount to its channel peer (for example via keysend) and the channel peer deducts the hold fees from that prepaid balance until it is at zero. At that point it somehow (in the htlc fail message?) communicates Lightning's version of http 402 to ask for more money. B. Tightly integrated with the htlc add/fail/settle messages. When an htlc is added, the maximum cost (based on maximum lock time) for holding is deducted from the sender's channel balance. When the htlc settles, a refund is given based on the actual lock time. An additional `update_fee`-like message is added for peers to update their hold fee parameters (fee_base and fee_rate). In both cases the sender needs to trust its peer to not steal the payment and/or artificially delay the forwarding to inflate the hold fee. I think that is acceptable given that there is a trust relation between peers already anyway. A crucial thing is that these hold fees don't need to be symmetric. A new node for example that opens a channel to a well-known, established routing node will be forced to pay a hold fee, but won't see any traffic coming in anymore if it announces a hold fee itself. Nodes will need to build a reputation before they're able to command hold fees. Similarly, routing nodes that have a strong relation may decide to not charge hold fees to each other at all. This asymmetry is what is supposed to prevent channel jamming attacks. The attacker needs to pay hold fees to send out the payment, but when it comes back to the attacker after traversing a circular route, they won't be able to charge a hold fee to cancel out the hold fee paid at the start of the route. (Assuming the attacker node is not trusted.) A consequence for honest users is that payment attempts are no longer free. The cost should however be negligible for fast-failing attempts. Also senders will have to be a lot more selective when building a route. Selecting a 'black hole' hop (hop that doesn't forward nor fail) can be costly. The hold fee scheme is a bit looser compared to previously proposed schemes (as far as I know...). It is purely an arrangement between channel peers and doesn't try to exactly compensate every hop for its costs. Instead trust relations that arguably exist already are leveraged to present a bill to the actor who deserves it. Interested to hear opinions about this proposal. I'd also like to encourage everyone to prioritize this spam/jam issue and dedicate more time to solving it. Obviously there is a lot more to do in Lightning, but I am not sure if we can afford to wait for the real adversaries to show up on this one. Cheers, Joost -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201012/c7943c5e/attachment.html>