AdamISZ [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-08 📝 Original message:Hi aj and list, (questions ...

📅 Original date posted:2022-11-08
📝 Original message:Hi aj and list,
(questions inline)


------- Original Message -------
On Thursday, October 27th, 2022 at 18:21, Anthony Towns via bitcoin-dev <bitcoin-dev at 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