Personally I don't think this is a very interesting attack.
Basically, using a clever series of replacements, it lets attackers remove a target transaction from mempools (and thus miner block templates). But the target transaction remains valid, so anyone can rebroadcast it. Which means that anyone can altruistically re-broadcast those transactions to fix the issue. Additionally, Lightning implementations already do this rebroadcasting, both of the original transaction, and fee-bumped versions.
Meanwhile, every time the attacker needs to perform the attack to remove the target from mempools yet again, they're spending money.
I've actually gotten some tentative interest from a funding source to write an altruistic rebroadcaster to "once and for all" fix this issue. I'm currently busy with more important (paid) work on OpenTimestamps, among other things. But if I don't do it I'm sure someone else. It's not a very hard problem to solve.
Meanwhile, every time the attacker needs to perform the attack to remove the target from mempools yet again, they're spending money.
Have a look on the second trick playing on mempool expiration time (CtxMemPool::Expire()) that allows an attacker to dwarf the money spent to almost none. This is more severe than one thing at first sight.
I’m still very doubtful on altruistic re-broadcasting to solve that kind of issues, namely due to the open nature of the altruistic bandwidth being also abused by an adversarial LN counterparty or miner. Though yes I forgot to mention altruistic re-broadcasting in the report as one line of solution that deserves more analysis in being able to fix or not RCA-like issues.
You mention expiration exactly one in the above write-up, and you fail to make a case for it being important.
Mempool expiration is just a local, per-node, thing they kicks out transactions after a few weeks (two IIRC). How exactly is that relevant to an HTLC, which typically expires in a day or so max?
Secondly, I don't see any way that rebroadcasting could be abused. The attacker triggering the cycling attack has to broadcast fee paying transactions, just like any other replacement. It's no different than using up bandwidth in any other way.
You mention expiration exactly one in the above write-up, and you fail to make a case for it being important.
Mempool expiration is just a local, per-node, thing they kicks out transactions after a few weeks (two IIRC). How exactly is that relevant to an HTLC, which typically expires in a day or so max?
Secondly, I don't see any way that rebroadcasting could be abused. The attacker triggering the cycling attack has to broadcast fee paying transactions, just like any other replacement. It's no different than using up bandwidth in any other way.
I know the write-up itself is not super explicit on expiration. There is a section "Another Attack Vector: Transaction Expiration Time" in the paper.
When you write a disclosure report on an unfixed vuln, the goal is not to come with a complete handbock for script kiddies on how to exploit it. The goal is to point out what is broken.
Let's re-explain a replacement cycling attack on a Lightning channel, with Alice and Bob.
Alice broadcasts her commitment tx with an outbound HTLC and a 2nd stage timeout tx.
Bob replaces out Alice's timeout with a preimage tx. Then replaces the preimage tx with another tx (let's call it the "sweep") on top of an UTXO unrelated to the chan.
If the "sweep" is on top of a soon-to-be-expired parent tx (2 weeks by default), all the contributed fees to kickout Alice's timeout tx is gone out of the mempool.
Bob does not pay anymore for each replacement of Alice’s timeout tx.
Rebroacasting can be abused in the miner-setting, as whatever the altruistic rebroadcast timing, the junk branch can still be there and a better replacement included in the adversary's block template.
Bob does not pay anymore for each replacement of Alice’s timeout tx.
As with Alice's transaction, Bob's transactions can also be rebroadcast by anyone after they expire from mempools. Mempool expiration is an entirely optional, node-local, feature, and I'm sure plenty of miners have disabled it for obvious economic reasons.
Also, transaction expiration should be based on the oldest transaction in a group of dependent transactions. IIUC, Core does not do this already. But if it did, that attack wouldn't work as using the about-to-expire transaction would reset the expiration timer.
As with Alice's transaction, Bob's transactions can also be rebroadcast by anyone after they expire from mempools.
Yes for sure, Bob's transactions can be rebroadcast by anyone. Yet any node doing is still facing some "efficient selection" of package to rebroacast issue in a world of limited bandwidth / cache space, easy inadvertently to increase DoS surface.
Mempool expiration is an entirely optional, node-local, feature, and I'm sure plenty of miners have disabled it for obvious economic reasons.
I hope so, I think the presence or absence of expiration in a miner mempool one can probe it from the outside. I don't remember that mempoolexpiry can be turn off completely without custom patchset.
Also, transaction expiration should be based on the oldest transaction in a group of dependent transactions. IIUC, Core does not do this already. But if it did, that attack wouldn't work as using the about-to-expire transaction would reset the expiration timer.
No, I think it should be the most recent transaction in a group of dependent transaction.
Though yes, that variant of the attack wouldn't work anymore as the "group" the expiration timer at each replacement-in of Bob's transaction(s) would be reset. The other variants of the attacks would be still plausible, however the one based on expiration time is by far the dumbest one.
CtxMemPool::Expire()) that allows an attacker to dwarf the money spent to almost none. This is more severe than one thing at first sight.mempoolexpirycan be turn off completely without custom patchset.