Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8A15BC002D for ; Thu, 10 Nov 2022 14:38:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 59C6C60B21 for ; Thu, 10 Nov 2022 14:38:33 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 59C6C60B21 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KX7nIb0IBAdz for ; Thu, 10 Nov 2022 14:38:31 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org EC61960AC1 Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by smtp3.osuosl.org (Postfix) with ESMTPS id EC61960AC1 for ; Thu, 10 Nov 2022 14:38:30 +0000 (UTC) Received: (Authenticated sender: email@yancy.lol) by mail.gandi.net (Postfix) with ESMTPA id C58641BF20C; Thu, 10 Nov 2022 14:38:27 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 10 Nov 2022 15:38:27 +0100 From: email@yancy.lol To: AdamISZ , Bitcoin Protocol Discussion In-Reply-To: References: Message-ID: <7ce4313f6d586ced1643b1624acf81bb@yancy.lol> X-Sender: email@yancy.lol Content-Type: multipart/alternative; boundary="=_1c8466be80e51f8af8e7c7d2b825c923" X-Mailman-Approved-At: Thu, 10 Nov 2022 14:48:59 +0000 Subject: Re: [bitcoin-dev] On mempool policy consistency X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2022 14:38:33 -0000 --=_1c8466be80e51f8af8e7c7d2b825c923 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed > 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 Is it actually true that they cannot replace it? If miners and node operators collude and have the incentive to run a patched version of core, is it still technically impossible to replace? > the idea that they suffer financial loss from > "ignorant" fee bumping is the part that seems weird to me. Even if they waste resources trying to fee-bump, I agree that this does not appear to be a catastrophe.There doesn't seem to be any technical reason why improvements can't be made to allow B and C to have a better view. Cheers, -Yancy On 2022-11-08 10:28, AdamISZ via bitcoin-dev wrote: > Hi aj and list, > (questions inline) > > ------- Original Message ------- > On Thursday, October 27th, 2022 at 18:21, Anthony Towns via > bitcoin-dev wrote: > >> Is that true? Antoine claims [1 [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 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 Links: ------ [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html --=_1c8466be80e51f8af8e7c7d2b825c923 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
= 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
=  
= Is it actually true that they cannot replace it?  If miners and node o= perators collude and have the incentive to run a patched version of core, i= s it still technically impossible to replace?
=  
= the idea that they suffer financial loss from
"ignorant" fee bumping i= s the part that seems weird to me.
=  
= Even if they waste resources trying to fee-bump, I agree that this does not= appear to be a catastrophe.There doesn't seem to be any technical reason w= hy improvements can't be made to allow B and C to have a better view.
=  
= Cheers,
= -Yancy
=  
= On 2022-11-08 10:28, AdamISZ via bitcoin-dev wrote:
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 en= ough to avoid
a DoS issue when utxos are jointly funded by untrusting = partners, and,
aiui, that's the main motivation for addressing this no= w.

[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003= 033.html

The scenario he describes is: A, B, C create a tx:<= br />
inputs: A1, B1, C1 [opts in to RBF]
fees: normal
outpu= ts:
[lightning channel, DLC, etc, who knows]

they all analy= se the tx, and agree it looks great; however just before
publishing it= , A spams the network with an alternative tx, double
spending her inpu= t:

inputs: A1 [does not opt in to RBF]
fees: low
outpu= ts: 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 every= one else
sees the 2nd one instead; and neither tx will replace the oth= er. 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 migh= t instead waste time trying to fee bump the tx to get it mined,
or sim= ilar.

What should folks wanting to do coinjoins/dualfunding/dlcs= /etc do to
solve that problem if they have only opt-in RBF available?<= br />
<snip>
I read Antoine's original post on this and got the genera= l gist, and
here also, it makes sense, but I'd like to ask: is it nece= ssary 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 ca= nnot
replace it, but the idea that they suffer financial loss from
"ignorant" fee bumping is the part that seems weird to me. Clearly
T= X_2 gets gossiped to other mempools; and understood that it does not
r= eplace 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
the= re 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= =2E people double spending an input out of
a negotiated join, albeit i= t was rare; but it's ofc definitely
*possible* to 'grief' like this, g= iven the ordering of events; maker
sends signature, maker broadcasts d= ouble spend - 95% of the time they
will be first). Interactive protoco= ls are yucky and I think there'll
always be griefing possibilities; de= signing around multiple-rounds of
negotiation amongst not always-on pa= rticipants 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 incen= tive for an attacker' (i.e.
ignoring griefing) might sound crappy but = it's probably just being
realistic.

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

= Cheers,
AdamISZ/waxwing

___________________________________= ____________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--=_1c8466be80e51f8af8e7c7d2b825c923--