Date: Tue, 08 Nov 2022 09:28:44 +0000
To: Anthony Towns <aj@erisian.com.au>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <jzS-a7kpDwvAhO4TJiTgtpsP95Zi8BRvIgUqjOs3hEVI_Uu-ey1LfCnN2D8wkG21yfVPGIujbiDXCfFAyfW56gPtvd8p3SrsOmOE22IWAuA=@protonmail.com>
In-Reply-To: <Y1q+MedepB1qUpBP@erisian.com.au>
References: <mailman.38435.1666828344.956.bitcoin-dev@lists.linuxfoundation.org>
 <CAHTn92wfjTCF5UtbjezbEYWTUQ7t6FNZu1ow0pirJXGFoXJxCA@mail.gmail.com>
 <Y1q+MedepB1qUpBP@erisian.com.au>
Feedback-ID: 11565511:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] On mempool policy consistency
Precedence: list

Hi aj and list,
(questions inline)


------- Original Message -------
On Thursday, October 27th, 2022 at 18:21, Anthony Towns via bitcoin-dev <bi=
tcoin-dev@lists.linuxfoundation.org> wrote:

>=20
> 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.
>=20
> [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/00=
3033.html
>=20
> The scenario he describes is: A, B, C create a tx:
>=20
> inputs: A1, B1, C1 [opts in to RBF]
> fees: normal
> outputs:
> [lightning channel, DLC, etc, who knows]
>=20
> 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:
>=20
> inputs: A1 [does not opt in to RBF]
> fees: low
> outputs: A
>=20
> 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:
>=20
> inputs: B1, C1 [opts in to RBF]
> fees: 50% above normal
> outputs:
> [smaller channel, refund, whatever]
>=20
> and might instead waste time trying to fee bump the tx to get it mined,
> or similar.
>=20
> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
> solve that problem if they have only opt-in RBF available?
>=20
<snip>
>=20

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

About this general flavour of attack, it's never been a *big* concern in Jo=
inmarket imo (though, we did until recently have a bug that made this happe=
n *by accident*, i.e. people double spending an input out of a negotiated j=
oin, albeit it was rare; but it's ofc definitely *possible* to 'grief' like=
 this, given the ordering of events; maker sends signature, maker broadcast=
s 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 i=
s 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', comb=
ined with 'there really isn't any economic incentive for an attacker' (i.e.=
 ignoring griefing) might sound crappy but it's probably just being realist=
ic.

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

Cheers,
AdamISZ/waxwing