Personally, I would have wait a bit before to go public on this, like letting some implementations
increasing their CLTV deltas, but anyway, it's here now.
Mempool-pinning attacks were already discussed on this list [0], but what we found is you
can _reverse_ the scenario, where it's not the malicious party delaying confirmation of honest
party transactions but malicious deliberately stucking its own transactions in the mempool to avoid
confirmation of timeout. And therefore gaming inter-link timelock to provoke an unbalanced
settlement for the victim ("aka you pay forward, but don't get pay backward").
How much attacks are practical is based on how you can leverage mempool rules to pin your own
transaction. What you're looking for is a _mempool-obstruction_ trick, i.e a way to get honest party
transaction being bounce off due to your transaction being already there.
Beyond disabling RBF on your transaction (with current protocol, not anchor proposal), there is
two likely candidates:
* BIP 125 rule 3: "The replacement transaction pays an absolute fee of at least the sum paid by the original transactions."
* BIP 125 rule 5: "The number of original transactions to be replaced and their descendant transactions which will be evicted from the mempool must not exceed a total of 100 transactions."
Let's go through whole scenario:
* Mallory and Eve are colluding
* Eve and Mallory are opening channels with Alice, Mallory do a bit of rebalancing
to get full incoming capacity, like receiving funds on an onchain address through another Alice
link
* Eve send a HTLC #1 to Mallory through Alice expirying at block 100
* Eve send a second HTLC #2 to Mallory through Alice, expirying at block 110 on outgoing link
(A<->M), 120 on incoming link (E<->A)
* Before block 100, without cancellation from Mallory, Alice will force-close channel and broadcast
her local commitment and HTLC-timeout to get back HTLC #1
* Alice can't broadcast HTLC-timeout for HTLC #2 as it's only expires at 110
* Mallory can broadcast its Pinning Preimage Tx on offered HTLC #2 output on Alice's transaction,
feerate is maliciously chosen to get in network mempools but never to confirm. Absolute fee must
be higher than HTLC-timeout #2, a fact known to Mallory. There is no p2p race.
* As Alice doesn't watch the mempool, she is never going to learn the preimage to redeeem incoming
HTLC #2
* At block 110, Alice is going to broadcast HTLC-timeout #2, feerate may be higher but as absolute
fee is lower, it's going to be rejected from network mempools as replacement for Pinning Preimage
Tx (BIP 125 rule 3)
* At block 120, Eve closes channel and HTLC-timeout HTLC #2
* Mallory can RBF its Pinning Preimage Tx by a high-feerate one and get it confirmed
New anchor_output proposal, by disabling RBF, forces attacker to bid on the absolute fee. It may
be now a risk to loose the fee if Pinning Tx is confirming. You may extend your "pinning
lease" by ejecting your malicious tx, like conflicting or trimming out of the mempool one of its
parents. And then reannounce your preimage tx with a lower-feerate-but-still-high-fee before a
new block and a honest HTLC-timeout rebroadcast.
AFAICT, even with anchor_output deployed, even assuming empty mempools, success rate and economic
rationality of attacks is finding such cheap, reliable "pinning lease extension" trick.
I think any mempool watching mitigation is at best a cat-and-mouse hack. Contrary to node
advancing towards a global blockchain view thanks to PoW, network mempools don't have a convergence
guarantee. This means, in a distributed system like bitcoin, node don't see events in the same
order, Alice may observe tx X, tx Y, tx Z and Bob may observe tx Z, tx X, tx Y. And order of events
affects if a future event is going to be rejected or not, like if tx Z disable-RBF and tx X try to
replace Z, Alice accepts X and Bob rejects it. And this divergence may perserve until a new block.
Practically, it means an attacker can provoke a local conflict to bounce off HTLC preimage tx out
of your mempool while broadcasting preimage tx without conflict to the rest of the network by
tweaking tx-relay protocol and so easily manipulating order of events for every node. A local
conflict is easy to provoke, just make tx A double-spent by both HTLC-preimage-tx and non-RBF-tx-B.
Announce txA+txB to mempool victim and txA+HTLC-preimage-tx to rest of network. When rest of
network announce HTLC-preimage-tx, it's going to rejected by your mempool.
Provoking local conflict assumes of course _interlayer_ mapping by an attacker, i.e mapping your LN
node to your full-node(s). Last time, we check, there was 982 match by IP for 4,500 LN/52,000
full-node. Mapping heuristics is an ongoing research subject and sadly seems affordable.
Yes a) you can enable full-RBF on your local node but blinding conflicting may still be with higher
feerate as everything is attacker malleable b) you may want to catch tx and extract preimage
on the p2p wire, but processing raw transaction would be such a DoS vector...
Overall, I think we all agree on the long term direction to get a Contracting-Protocols-Enhanced
mempool with a multiparty-safe-API, bundled with package relay deployment. Even if there is current
move toward this direction, this may take longer than expected as with any critical-safety
component in Core.
A temporary fix could be to resuscitate old work to ensure peering through a full-RBF propagation path,
but p2p implications are hard to gauge, like wouldn't guarantee p2p censorship resistance of this...
It's quite a tangled issue, with a good deal of both bitcoin and lightning knowledge so feel free