20 sats \ 0 replies \ @LNAnon69420 13 Aug 2022 \ on: Bitcoin Lightning Network vulnerability claimed by researchers. bitcoin
There are a few assumptions that went into this paper to arrive at a rough ~750BTC number - the 'vulnerability' can be better described as an attack vector to steal sats from unwitting node ops. I'll try to boil it down
  1. First, a threat actor needs to own at least the 30 largest routers on the network
The top 30 nodes by capacity encompass something like half of network cap - remember, thats not just outbound sats but inbound sats. They need a significant portion of the network committed towards them
  1. They then flood the network with htlc's and make them unresolvable, triggering FC's
  2. They need to keep the btc mempool congested w/o clearing at over 10s/vb for at least 2 weeks
This is because a default configured watchtower defaults to 10s/vb and default TLV's of 2 weeks on FC's. If they can prevent you and your watch tower from broadcasting the closing state, they can publish it themselves, ascribing themselves the balance of that channel.
  1. The threat actor hopes he gains more BTC from vulnerable node ops than he does from triggering justice tx's from good node ops. You could even take into account the value of inbound liquidity and the assumed loss of fee revenue bc they were running a huge router network!
How to mitigate? Increase default config settings, currently this can mean paying more than you need to for closes. LND is putting effort into bettering fee estimator
Hopefully that helps y'all think on if this is an actionable vulnerability or not!
PS for nerds out there: the authors claim that their k lopsided weighted max cut problem hasn't been studied before... I found a stack exchange post giving a 1/2 approximation algorithm within 5 minutes of googling
write
preview