While the MPFT is being created, a malicious party can double spends their input to prevent the MPFT from being broadcast. This double spend can include a different input with an RBF-enabled unconfirmed parent, which allows the double spend to be easily invalidated in the future.
I see the problem. The CoinJoin makers have to either bump their fees with CPFP or have their CoinJoin rejected. So, how does mandatory RBF help the situation? The attacker wants to make us spend more in fees or delay our mixing.
- Suppose we have Alice, Bob and Carol, with their respective inputs A, B and C.
- Carol is the attacker.
- Alice, Bob and Carol sign the CoinJoin transaction, and it's ready to be broadcasted.
- Carol has signed a transaction wherein she replaced CoinJoin with her reversal.
- Both are broadcasted, but Carol's transaction replaces the CoinJoin.
- Alice and Bob can either raise their fees or let Carol's replacement transaction become confirmed and create another CoinJoin later.
Can't we implement some sort of OP_IF, OP_ELSE penalty mechanism for this matter? It'd increase the transaction fee, though.