On Mempool-Pinning Commitment Transaction

[ariard]

Original mempool-pinning scenario was assuming a pin of the HTLC preimage transaction to obstrucate confirmation of a HTLC-timeout by a honest party.

A pinning is possible due to the malleability of the preimage tx, an attacker can setup at wish
feerate/absolute fee/ancestors/descendants, therefore easily leveraging Bicoin Core mempool rules. Sadly, commitment transaction present malleability vectors with regards to feerate/absolute fee.

By setting up a fine-grained dust_limit_satoshis and at same-time circulary routing HTLCs,
a party can inflate absolute fee while keeping feerate of its own commitment bounded. By breaking
channel in the middle of an update sequence, a malicious party can ensure its transaction to have
a quasi-same-feerate, higher-fee than the honest local commitment, therefore provoking another type of pin.

A more concering variation is crafting such malicious commitment during a period of low-feerate
while waiting for a period of fee spikes to launch attack. Such revoked commitment will likely have
a high probability to stuck in network mempools while at the same time can be ejected by a valid
attacker commitment at anytime, being aware of absolute fee and feerate.

Combined with mempool blinding or network-mempools partitions [0], such pinning revoked commitment may be based on any previous state, therefore making in practice impossible for a honest party to build a bumping CPFP on its anchor output. Further, this CPFP may never pay a package absolute fee high enough to confirm the malicious commitment or only too-late after fee bumping rounds. Even worst, an attacker can announce you revoked commitment X,Y,Z while broadcasting W that way you're broadcasting CPFP for wrong ones and locking for nothing fresh bumping utxo until to exhaust all of them.

Risks are quite scoped for an attacker, as malicious revoked commitment balance can be the same that channel state plus in-flight HTLC steal target. So attack failure will sold as loosing its
reserve.

If those scenarios are gauged plausible, as deployable mitigations we can a) increase channel
reserve b) increase HTLC timelocks delta/final-hop c) lower max_accepted_htlcs

Long-term mitigations:

1. Gets a feerate-based package-relay implementation in Core
2. Waiting for Eltoo

[t-bast]

Closing this issue, as we've settled on using package-relay / v3 txs to mitigate this in the short term, until cluster mempool potentially provides even better mitigations. Feel free to re-open if there is something actionable that I'm missing from this issue.

[ariard]

@t-bast can you re-open it unless you define the “we” ? Thanks you.

[t-bast]

The four implementations have signaled repeatedly interest in defining a new commitment format that relies on v3 txs to mitigate pinning (that's the "we").

As I said, we can re-open this is issue if there is something actionable that I'm missing, but I don't see anything actionable here? Also the issue ends by stating package-relay as a long-term mitigation, and that's what we're working on.

But I can re-open this if you consider this issue useful.

[ariard]

The four implementations have signaled repeatedly interest in defining a new commitment format that relies on v3 txs to mitigate pinning (that's the "we”).

As you’re pointing in your comment above, and without entering about bike-shedding on package-relay / v3, more likely that the solution space about pinning is wider. I fully understand that the four implementations are time-constrained to release stuff, however I don’t think the four implementations are fully representing the consensus of experts who have historically work on lightning. Especially one working on the protocol with wider time horizons than lightning maintainers.

As I said, we can re-open this is issue if there is something actionable that I'm missing, but I don't see anything actionable here?

Using APO to solve some cases of pinnings was talk among LDK a very while back. I don’t think, or I can’t remember if it the idea was fully flesh out anywhere. It’s obviously consensus change kind of thing so very long term, but imho let’s keep the solution toolbox open. I’ll check if it’s well documented already somewhere (e.g the apo bip). If not, do a good write-up about that and when it’s done close that issue.