Post
Topic
Board Development & Technical Discussion
Re: Full RBF
by
DireWolfM14
on 23/06/2022, 17:54:27 UTC
Consider any transaction which requires inputs from more than one party. Coinjoins and Lightning channels are the most common examples. I can DoS such a transaction by providing my input, and then while all the other inputs are being collated, double spend that input in a non-RBF transaction, meaning the original transaction will fail and the other parties will all have wasted their time.
Why don't we utilize first-seen-safe RBF then? If the problem is to annoy the other party/parties by cancelling the CoinJoin or channel opening transaction, we can give a solution by accepting only transactions that spend to the same outputs, equal or greater amounts.

I might be missing something too, but I don't think the purpose it merely to annoy/harass the other parties, but to delay confirmations until the RBF/CPFP algorithm gets close to maximum fee range, then the attacker sends his own RBF transaction and forces everyone to pay that high fee.  The attack vector would require a a miner with a lot of hashing power to take advantage of attack.  I don't know how practical/profitable of an attack vector it really is, I mean if the miner's equipment is as finicky as mine, I'm sure he's got bigger fish to fry.