pull down to refresh

120 sats \ 2 replies \ @theariard OP 28 Jan \ parent \ on: [FULL DISCLOSURE] Replacement Cycling Attacks on Bitcoin Miners Block Templates bitcoin
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.
write
preview
129 sats \ 1 reply \ @petertodd 28 Jan
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.
reply
100 sats \ 0 replies \ @theariard OP 29 Jan
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.
reply