[Lightning-dev] [1.1] Proposed `funding_cancelled` message

[7riw77 at gmail.com]

> Yes, but it still limits how much damage each peer can do to the node.
> And I think you overstate the ease of distributed denial of service attacks,
> and the relative resource consumption differences on an attacker simulating
> multiple nodes versus one simulating a single node.

So assume the following situation: Someone has gotten a "bum deal" on their pizza (or thinks they have), and they want to take down their pizza provider. They note the lightning node the pizza provider uses happens to be some particular address, so they hire out a 10k node botnet (rather small in the real world), and ask each bot to open as many transactions as possible, as fast as possible, without completing any of them, with the ip address of the node in question. The server eventually says "I'm not accepting any more connections, because I have too many outstanding connections right now," which effectively takes it off line for new transactions, blocking anyone who uses that node from any sort of transaction. How long can this last? So long as the botnet continues asking for new connections. 

There are ways around this on the network side -- specifically using anycast, like DNS does, to spread the attack around -- but I'm not certain anycast would work in this case because of the state issues involved in lightning. 

When I was at Verisign, we figured a 100g link was enough to block any sort of DDoS against the DNS root servers. The attack against Krebs shows just how silly this line of thinking is today. 

There is no perfect defense, but it might be useful to think about these things, and how to solve them, now, rather than once they happen, particularly when the trust of the overall network is in play. This might mean several things, such as --

1. The closer you can come to stateless on the server side during session setup, before you know the request is going to be followed through/is legitimate, the less chance this sort of thing will happen
2. The more you have the ability to shift a transaction from one server to another without losing some essential state, the more a network of devices can be designed to handle such problems

There may be other solutions, as well; just throwing some ideas out there.

😊 /r