235 sats \ 7 replies \ @vijo 8 Aug 2022 \ on: Mass Exit Attacks on the Lightning Network [PDF] bitcoin
what's the eli5 on this?
Attack 1. Bad guys maneuver themselves into key positions in LN and then suddenly turn off their nodes. Result: LN will experience problems for a short time until somebody opens new channels to fix the problem. Also it's not like maneuvering into key positions is an easy feat to accomplish.
Attack 2: Bad guys open a $100 channel, pay $100 to their other node but then close the $100 channel pretending that they never paid the $100. Watchtowers must slash the bad guys. The point of the paper is that if the bad guys do this a lot and if the watchtowers are not ready to pay higher fees then some stupid watchtowers might fail to slash before the deadline. This raises 2 questions:
- why is the window to slash is currently just 3 days? it should be about 2 weeks at least
- why the watchtowers are not prepared to pay a higher fee if they're about to lose $100?
reply
So basically this is the same as Flood and loot described in some paper 1 or 2 years ago.
reply
Yes, and authors say
The exploited mechanisms partially differ from those used by the attacks presented in this paper, since we do not make use of multi-hop payments, but rather direct channels between nodes.
Translation from academic: we confirm Flood & Loot scheme. However, this attack was being discussed once with Anton Kumaigorodsky who was quite skeptic about attack trade-offs by itself. Attacker has to spend a lot of money to cause congestion and after attack the outcome is not clear.
Looking deeper into history there where 3 papers about LN attacks which released simultaneously, these are:
š Counting Down Thunder: Timing Attacks on Privacy in Payment Channel Networks
š Flood & Loot: A Systemic Attack On The Lightning Network
š Time-Dilation Attacks on the Lightning Network
reply
Are node operators supposed to run their own watchtowers? Or, do you pay a third party to manage a watchtower for you? I think I'm not understanding where a watchtower sits in the lightning network.
reply
- if you run a node on a desktop or a server, you'd normally have the watchtower built in
- if you have a mobile node that only turns on temporarily, then you might want to run a separate watchtower; but if your setup includes both a desktop and a mobile then you probably want to run a normal node on the desktop and Zeus on the mobile
- older incarnation of SBW was called BLW and offered watchtowers for rent, I'm not sure what SBW does
- Phoenix would connect to a random Electrum server and would remind you to run the app periodically
- Breez by default connects to Bitcoin server of Breez itself so the user just has to trust Breez not to steal
reply
IMO there's not much to see here.
Attack 1: If a set of zombie nodes stop operating in the lightning network, the network can be severed. If you coordinate it for maximum impact, the time it would take for all the affected parties to close their channels and open them with non-zombie nodes would be longer than the channel closing locktime because of chain congestion.
Attack 2: If you close a channel with an old state, the other party can submit a follow up transaction to take all of the funds in the channel. This doubles the amount of chain congestion you can cause. And if you can cause enough congestion, maybe you can close some channels with old states because the other party can't get their revocation tx added in time. Thus allowing you to double spend the coins.
Not too worried. The first attack boils down to throwing away a central position in the network and gaining nothing.
The second attack is like launching your money in the air and hoping in the commotion that you find a sat on the ground.
reply
From my understanding, it's a DDoS attack that must be executed during a high fee event.
Attackers create multiple LN channels before the attack, bait people to route balance in the channel from them, then wait until a congestion happen and double spend their balance.
This will force their honest LN partners to force close the channels, at the cost of 1 onchain tx per partner, during a congestion.
reply