From dave at dtrt.org Mon Jun 22 14:19:20 2020 From: dave at dtrt.org (David A. Harding) Date: Mon, 22 Jun 2020 10:19:20 -0400 Subject: [Lightning-dev] Disclosure of a fee blackmail attack that can make a victim loose almost all funds of a non Wumbo channel and potential fixes In-Reply-To: References: Message-ID: <20200622141920.5xks3347ybca4xro@ganymede> On Sun, Jun 21, 2020 at 06:09:28PM -0700, Olaoluwa Osuntokun wrote: > IMO this is mostly mitigated by anchor commitments. The impact of this > attack is predicated on the "victim" paying 5x on-chain fees (for their > confirmation target) to sweep all their HTLCs. I think the attack is more clearly stated in absolute terms. An attacker can force a victim to pay for 483 P2WSH outputs (each 43 vbytes), or a total of about 20,000 vbytes (plus regular overhead). 20769 = 43 * 483 During the post-halving feerate spike just a few weeks ago, paying 100 base units ("satoshis") per vbyte was plausible to ensure the commitment transaction confirmed quickly. At $9,500 USD/BTC, that's almost $200 USD. 197.3055 = 20769 * 100 / 1e8 * 9500 With a 5x multiplier, that's horrible, but even with no multiplier, it's not good. Moreover, a patient attacker can wait for a fee spike and then attack multiple channels at once so that they compete against each other for block space, potentially raising feerates even higher. > In addition to being able to pay much lower fees ("just enough" to get into > the chain), anchor commitments allow second-level HTLC _aggregation_, This > means that for HTLCs with the same expiry height, a peer is able to _batch_ > them all into a single transaction, further saving on fees. (I was initially confused by this, so for anyone else confused by this, the batching being described here is sort of the inverse of normal payment batching. Normally when you batch together multiple payments, you use one input to pay more outputs than you would with separate transactions. Here, you still need to use the same number of inputs you would to resolve HTLCs in separate ransactions (because each HTLC is a separate UTXO), but you pay a single output. This works and is indeed a nice optimization.) > Alternatively, they could use something like Lightning Loop to gain the > _outbound_ bandwidth (Loop In) I don't think the attacker needs outbound bandwidth. As implied in Ren?'s post ("achieved with circular onions"), if the attacker is Mallory and the victim is Bob, there just needs to be a circuit like: Mallory ? Alice ? Bob ? Mallory Mallory can always settle with Alice offchain after Bob's timeout, preventing Mallory from losing any money in the attack or from having to pay for liquidity. IIUC, Mallory's only cost would be paying for LN routing fees and the time value of locking up her money until the settlement. > No, the attacker is the one that needs to sweep these HTLCs, since they > offered them. This adds to their costs. As described above, the attacker doesn't need to offer the HTLCs, they can simply route a payment through any of the victim's other channels. If the attacker does that, then the victim needs to pay onchain fees to recover any remaining value in those HTLCs, potentially making this attack two or three times more costly for the victim. > > 1. The current solution is to just not use up the max value of htlc's. > > Eclaire and c-lightning by default only use up to 30 htlcs. > > IMO, this isn't a solution. Lowering the max number of HTLCs in-flight just > makes it easier (lowers the capital costs) to jam a channel. It looks to me like an easy and effective solution to turn a ~$200 downside into a ~$20 downside (at 100 base units/vbyte). It's certainly has other downsides too, but I'm personally more concerned about losing money than I am about having my channel jammed (and if jamming at 483 HTLCs is an issue, then hopefully the mitigation for that (e.g. upfront fees) will make jamming at HTLCs a non-issue as well). -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: