pull down to refresh

Its already constantly being "attacked" with probes. As the number of attackers scales linearly, the number of probes scales exponentially. Nodes running old version of LND are already crashing because of a bloated channels.db from all the failed route events.
The bandwidth consumed is still relatively low, but it won't be long before many node's connections are saturated with bogus forward requests.
Bandwidth isn't even the limiting factor. More likely its the number of in flight HTLC slots on a channel. If these probes are designed to not fail quickly, then the ability to DOS the network is even easier.
appreciate the insight. what is the worst-case scenario if an attacker tries to harm the lightning network?
said differently, if you were trying to inflict the most damage possible, how would you attack the lightning network?
reply
A single actor could disable a few high throughput channels and increase average fee for everyone transacting during the attack.
If the attacker could specifically target nodes known to run LND, then they could sustain a constant probe attack, forcing the node to log every attempt until the node's disk filled up causing a system crash.
Repeat until a majority of nodes are offline. However, sophisticated node operators can defend this attack.
The systemic issue is that every actor on the network is incentiviced to attack it in order to build a higher resolution map of the network (one that includes channel balance estimates). This additional data gained from spamming could be used to make payment routes more efficiently or to surveil the network and identify payment flows.
IMO the protocol needs to allow charging a fee for attempted payments, not just successful ones.
That way, nodes that charge an "attempt fee" would be probed less. However, it creates a new dynamic where honest senders want to prioritize routes that they think will succeed, instead of just brute-forcing routes until success. Or maybe they just avoid nodes charging attempt fees altogether.
Nodes could adopt a change to their channel policy where they dynamically set MAX_HTLC depending on the local balance in their channel. This would let the network know an estimate of their true balance without needing to be probed. Its a voluntary disclosure that could result in more routes if peers are trying to avoid fees from attempted routes.
But updating the MAX_HTLC policy too frequently will contribute to gossip spam (another DOS vector).
If gossip is spammed too much, payments could fail because the sender did not include adequate fees to pay intermediate nodes along a route. This is because the fee policy change was delayed in propagating thru the network and the sender was using the old fee when they built the onion.
It already takes about 10 minutes for a policy change to propagate. When you change your channel policy, you're effectively disabling it for up to 10 mins. Its currently free to spam gossip as much as you want, thus increasing this "cooldown" time for everyone.
IMO the gossip protocol should limit the relaying of policy updates if the node is updating too frequently. Maybe a node should be allowed 1 batch update per day, for example.
Each solution has a whole set of new issues it introduces. Nothing is likely to change until DOS becomes a common occurance. Even then, Tor gets DOS'd all the time and the maintainers have expressed no desire to address it.
LN is still nascent. If an attacker wanted to cause as much chaos as possible, they would wait until major institutions and global trade depends on LN, then attack.
I'll argue that, as early adopters, its our duty to exploit the network in any way we can while its young and still capable of change.
reply
incredibly thorough response, take my sats!
reply
Top comment two years ago!
reply
Two days in a row!
reply
Thanks, never knew about this.
reply