I have more to say on this broader topic, but since you've brought up this particular example I think it's worth commenting:
On Thu, Oct 27, 2022 at 1:23 PM Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Is that true? Antoine claims [1] that opt-in RBF isn't enough to avoid > a DoS issue when utxos are jointly funded by untrusting partners, and, > aiui, that's the main motivation for addressing this now. > > [1] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html > > The scenario he describes is: A, B, C create a tx: > > inputs: A1, B1, C1 [opts in to RBF] > fees: normal > outputs: > [lightning channel, DLC, etc, who knows] > > they all analyse the tx, and agree it looks great; however just before > publishing it, A spams the network with an alternative tx, double > spending her input: > > inputs: A1 [does not opt in to RBF] > fees: low > outputs: A > > If A gets the timing right, that's bad for B and C because they've > populated their mempool with the 1st transaction, while everyone else > sees the 2nd one instead; and neither tx will replace the other. B and > C can't know that they should just cancel their transaction, eg: > > inputs: B1, C1 [opts in to RBF] > fees: 50% above normal > outputs: > [smaller channel, refund, whatever] > > and might instead waste time trying to fee bump the tx to get it mined, > or similar. > > What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to > solve that problem if they have only opt-in RBF available? > I think this is not a real example of a DoS vector that is available because we support non-rbf signaling transactions. Even in a world where all transactions are replaceable, person A could double-spend their input in a way that is annoying for B and C. For instance, the double-spend could be low-feerate and large, and effectively pin any attempt to replace it. Or it could be higher feerate and confirm and B/C have to start all over. Or, A could stall things in the signing phase and B/C have to figure out when to give up on the channel with A. So I find this example to be unconvincing. Are there any other examples where having a non-replacement policy for some transactions causes problems for protocols people are trying to build? Thanks, Suhas
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
