Hi aj and list,
(questions inline)


------- Original Message -------
On Thursday, October 27th, 2022 at 18:21, 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?

<snip>
I read Antoine's original post on this and got the general gist, and
here also, it makes sense, but I'd like to ask: is it necessary that
(B, C) in the above not *see* A's opt-out "pre-replacement" (inputs:
A1, outputs: A, fees: low; call it TX_2)? I get that they cannot
replace it, but the idea that they suffer financial loss from
"ignorant" fee bumping is the part that seems weird to me. Clearly
TX_2 gets gossiped to other mempools; and understood that it does not
replace the TX_1 (the 3-input) in B's mempool, say, but why should
they not even hear about it? Is it just a matter of engineering, or is
there some deeper problem with that.

About this general flavour of attack, it's never been a *big* concern
in Joinmarket imo (though, we did until recently have a bug that made
this happen *by accident*, i.e. people double spending an input out of
a negotiated join, albeit it was rare; but it's ofc definitely
*possible* to 'grief' like this, given the ordering of events; maker
sends signature, maker broadcasts double spend - 95% of the time they
will be first). Interactive protocols are yucky and I think there'll
always be griefing possibilities; designing around multiple-rounds of
negotiation amongst not always-on participants is even more yucky, so
just having a 'taker is in charge of network fee; if it's slow or gets
double spent out causing time delay then just wait', combined with
'there really isn't any economic incentive for an attacker' (i.e.
ignoring griefing) might sound crappy but it's probably just being
realistic.

Of course, off-chain contracting has more sophisticated considerations
than this.

Cheers,
AdamISZ/waxwing

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev