> 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.

I just realized I made a mistake.  RBF will always mine the higher fee 
transaction, so in this case, full-rbf would prevent a transaction from 
being pinned.

On 2022-11-08 15:54, yancy via bitcoin-dev wrote:

> 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
>> <bitcoin-dev@lists.linuxfoundation.org> 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.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev