Peter, It sounds like there are two attack vectors; neither of which require full-rbf (correct me if I'm wrong). 1) Bob has staked liquidity in a payment channel with Alice who later double spends the same inputs (at a very low feerate) resulting in a stalemate where neither can spend the UTXOs. The TX that creates the payment channel with Bob will never be mined since the mining pool sees the double spend? 2) Alice spams the network with a double spend wide enough that the double spend makes it into a block before the remainder of the network sees the first spend. In that case of 1), what if Bob required a opt-in rbf? Wouldn't that solve the issue? Bob could just create a replacement transaction with enough fee to get back his UTXO? For 2) it seems to me that neither full-rbf or opt-in rbf resolves this, although it's a probabilistic attack and requires spamming many nodes. Cheers, -Yancy On 2022-11-07 15:32, Peter Todd wrote: > On November 3, 2022 5:06:52 PM AST, yancy via bitcoin-dev > wrote: > AJ/Antoine et al > > What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to > solve that problem if they have only opt-in RBF available? > Assuming Alice is a well funded advisory, with enough resources to spam > the network so that enough nodes see her malicious transaction first, > how does full-rbf solve this vs. opt-in rbf? First of all, to make things clear, remember that the attacks were talking about are aimed at _preventing_ a transaction from getting mined. Alice wants to cheaply broadcast something with low fees that won't get mined soon (if ever), that prevents a protocol from making forward progress. With full-rbf, who saw what transaction first doesn't matter: the higher fee paying transaction will always(*) replace the lower fee one. With opt-in RBF, spamming the network can beat out the alternative. *) So what's the catch? Well, due to limitations in today's mempool implementation, sometimes we can't fully evaluate which tx pays the higher fee. For example, if Alice spams the network with very _large_ numbers transactions spending that input, the current mempool code doesn't even try to figure out if a replacement is better. But those limitations are likely to be fixable. And even right now, without fixing them, Alice still has to use a lot more money to pull off these attacks with full-rbf. So full-rbf definitely improves the situation even if it doesn't solve the problem completely.