On 7/10/22 4:43 AM, Joost Jager wrote:
It can also be considered a bad thing that DoS ability is not based on a number of messages. It means that for the one time cost of channel open/close, the attacker can generate spam forever if they stay right below the rate limit.
I don't see why this is a problem? This seems to assume some kind of per-message cost that nodes have to bear, but there is simply no such thing. Indeed, if message spam causes denial of service to other network participants, this would be an issue, but an attacker generating spam from one specific location within the network should not cause that, given some form of backpressure within the network.
Suppose the attacker has enough channels to hit the rate limit on an important connection some hops away from themselves. They can then sustain that attack indefinitely, assuming that they stay below the rate limit on the routes towards the target connection. What will the response be in that case? Will node operators work together to try to trace back to the source and take down the attacker? That requires operators to know each other.
No it doesn't, backpressure works totally fine and automatically applies pressure backwards until nodes, in an automated fashion, are appropriately ratelimiting the source of the traffic.
Maybe this is a difference between lightning network and the internet that is relevant for this discussion. That routers on the internet know each other and have physical links between them, where as in lightning ties can be much looser.
No? The internet does not work by ISPs calling each other up on the phone to apply backpressure manually whenever someone sends a lot of traffic? If anything lightning ties between nodes are much, much stronger than ISPs on the internet - you generally are at least loosely trusting your peer with your money, not just your customer's customer's bits.
Matt _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
