David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2020-06-22 📝 Original message: On Sun, Jun 21, 2020 at ...

📅 Original date posted:2020-06-22
📝 Original message:
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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200622/77824e91/attachment.sig>;