[anchors] HTLC update fee clamp

[halseth]

Mitigation for anchor channel attack brought up by @ariard in https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-September/002796.html

We check that the maximum HTLC timeout fees paid (and can potentially be siphoned off as described in the attack), is always less than the channel reserve of the party. This should ensure that whatever state the channel currently is in, the party won't have an incentive to breach using this "siphoned state", since it can gain at most the channel reserve.

There is a case where the party still hasn't received a balance above the channel reserve (this is the case if the party is channel responder). But we can note that these "HTLC timeout fees" always comes from the offering party's balance, and the party cannot offer HTLCs as long as the balance is below the channel reserve.

With this change a party won't attempt to send an update_add or update_fee that would violate this check on the receiver side.

Since this new condition makes the channel close to unusable in certain fee conditions (small reserve, high fee rate, many HTLCs), we add a new option --max-anchor-commit-feerate that defaults to 10 sat/vbyte. This ensures the initiator won't ever try to send a fee update above this.

Since for anchor channels the important thing is to get the channel to propagate, we could possibly default this to an even lower value.

[Roasbeef]

I'm on board with the fee leak heuristic, it's pretty simple and rests on the existing assumptions surrounding the reserve value itself. However, I'm worried that this can cripple smaller channels that regularly make payments (or forward payments) that are above the local dust limit. Left some thought in-line where applicable.

[Roasbeef]

In practice, do you have some rough figures for the impact here? I wonder if we should expose this as a config option to avoid potentially obstructing certain services/use-cases over night with the update.

[halseth]

You mean an option to skip the siphon check? That's not a bad idea..

[halseth]

I realized that a problem with having the option to skip the fee leak check only works if both parties skip it. Otherwise the receiver will close the channel if the sender has disabled it and violates the invariant.

[Roasbeef]

Potentially move this check into validateFeeRate?

[halseth]

I found it most natural to do it here, similar to other methods validating updates, and since we need the paymentDescriptor

[Roasbeef]

Comment re config option observance applies here as well.

[Roasbeef]

Ahh, this is nice in that it'll just show up as us having no bandwidth to service a new payment from the PoV of HTLC forwarding. However users may get confused when their payment fails even though the posted channel balance should allow it....🤔

[Roasbeef]

This'll also cause "silent failures" from the PoV of receivers with this clamp code connected to early adopter nodes that may already be running the existing anchor logic in the wild. However, I guess we can assume that this pairing will be rare in practice, since this upcoming release will be the first one that "enables" anchors network wide from the PoV of lnd.

[Roasbeef]

I think one other failure mode of this that we'll need to consider, is that until the second-level HTLCs are 1 sat/byte each, then rising fees can end up soft borking a channel until the fee wave subsides. However this is already more or less possible today if the fee estimate rises to a point that lnd considered excessive, as even before that most of the initiator's balance ill have been bled over to fees.

[Roasbeef]

I guess this is only the case if HTLCs regularly stagnate on the commitment transaction.

One other more common impact of this change would be reducing the efficacy of MPP for smaller channels since at most (for all active concurrent payments), they'll be able to use only a handful of slots. It's difficult to try and have a better "risk assessment" based on the size of the channel itself, as then we'd also need to factor in exactly how the node is used as well.

[Roasbeef]

While we're here, maybe also reduce this to 6-18 confs? As lately the 3 block estimate can be rather high

[halseth]

You mean for all channel types, or only for anchors?

If it is for the general case, I would prefer to do it in a separate PR. Maybe even make it a config option?

[halseth]

However, I'm worried that this can cripple smaller channels that regularly make payments (or forward payments) that are above the local dust limit.

Yes, this can definitely cripple smaller channels, however it will only be for anchor channels, so we can expect no existing channels to be affected

A way to mitigate this before zero-fee 2nd level transactions, is to require channels to be of a certain size, or decrease the default max fee rate even more.

We can do a sanity check at channel opening, something like chanSize * reserve / (htlcFee*defaultMaxFeeRate) > X number of HTLC slots.

[Roasbeef]

So thought about this a bit more, and I don't think we need it after all given:

• The HTLC fee leak can only be exploited by the responder of a channel funding given it wants to use the fact that the initiator pays for fees to steal funds from them.
• The attacker sits and waits until a commitment has a very high fee rate (say 150 sat/byte, etc), then later in the future breaches back to that state. This lets them siphon off the funds from HTLCs to themselves since the initiator is paying for fees.
• With the current version of anchors we're shooting for, we'll always clamp the fee rate at ~10-20 sat/byte.
• Therefore, assuming an lnd node is the initiator, they're protected from this attack, as they'll never create a commitment with a 500 sat/byte fee rate or w/e.

[Roasbeef]

OK so I was wrong with that scenario above, in that ofc the fee for the HTLC output on the commitment is paid by the initiator, but the fees for the second level are taken from the HTLC value itself.

[halseth]

Replaced by #4855 and the new channel type introduced in #4840