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
