path: root/fd/bb84f39b0be844fd06a345c053107e3d99b315

Return-Path: <email@yancy.lol>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8A15BC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <AdamISZ@protonmail.com>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <jzS-a7kpDwvAhO4TJiTgtpsP95Zi8BRvIgUqjOs3hEVI_Uu-ey1LfCnN2D8wkG21yfVPGIujbiDXCfFAyfW56gPtvd8p3SrsOmOE22IWAuA=@protonmail.com>
References: <mailman.38435.1666828344.956.bitcoin-dev@lists.linuxfoundation.org>
 <CAHTn92wfjTCF5UtbjezbEYWTUQ7t6FNZu1ow0pirJXGFoXJxCA@mail.gmail.com>
 <Y1q+MedepB1qUpBP@erisian.com.au>
 <jzS-a7kpDwvAhO4TJiTgtpsP95Zi8BRvIgUqjOs3hEVI_Uu-ey1LfCnN2D8wkG21yfVPGIujbiDXCfFAyfW56gPtvd8p3SrsOmOE22IWAuA=@protonmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <bitcoin-dev@lists.linuxfoundation.org> 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?
> <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


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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=
eva,sans-serif'>
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
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</div>
</blockquote>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
Is it actually true that they cannot replace it? &nbsp;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?</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
the idea that they suffer financial loss from<br />"ignorant" fee bumping i=
s the part that seems weird to me.</div>
</blockquote>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
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.</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
Cheers,</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
-Yancy</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
&nbsp;</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
On 2022-11-08 10:28, AdamISZ via bitcoin-dev wrote:
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">Hi aj and list,<br />(questions inline)<br /><br /><br=
 />------- Original Message -------<br />On Thursday, October 27th, 2022 at=
 18:21, Anthony Towns via<br />bitcoin-dev &lt;<a href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; =
wrote:<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0"><br />Is that true? Antoine claims [<a href=3D"https:/=
/lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html" ta=
rget=3D"_blank" rel=3D"noopener noreferrer">1</a>] that opt-in RBF isn't en=
ough to avoid<br />a DoS issue when utxos are jointly funded by untrusting =
partners, and,<br />aiui, that's the main motivation for addressing this no=
w.<br /><br />[1] <a href=3D"https://lists.linuxfoundation.org/pipermail/li=
ghtning-dev/2021-May/003033.html" target=3D"_blank" rel=3D"noopener norefer=
rer">https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003=
033.html</a><br /><br />The scenario he describes is: A, B, C create a tx:<=
br /><br />inputs: A1, B1, C1 [opts in to RBF]<br />fees: normal<br />outpu=
ts:<br />[lightning channel, DLC, etc, who knows]<br /><br />they all analy=
se the tx, and agree it looks great; however just before<br />publishing it=
, A spams the network with an alternative tx, double<br />spending her inpu=
t:<br /><br />inputs: A1 [does not opt in to RBF]<br />fees: low<br />outpu=
ts: A<br /><br />If A gets the timing right, that's bad for B and C because=
 they've<br />populated their mempool with the 1st transaction, while every=
one else<br />sees the 2nd one instead; and neither tx will replace the oth=
er. B and<br />C can't know that they should just cancel their transaction,=
 eg:<br /><br />inputs: B1, C1 [opts in to RBF]<br />fees: 50% above normal=
<br />outputs:<br />[smaller channel, refund, whatever]<br /><br />and migh=
t instead waste time trying to fee bump the tx to get it mined,<br />or sim=
ilar.<br /><br />What should folks wanting to do coinjoins/dualfunding/dlcs=
/etc do to<br />solve that problem if they have only opt-in RBF available?<=
br /><br /></blockquote>
&lt;snip&gt;<br />I read Antoine's original post on this and got the genera=
l gist, and<br />here also, it makes sense, but I'd like to ask: is it nece=
ssary that<br />(B, C) in the above not *see* A's opt-out "pre-replacement"=
 (inputs:<br />A1, outputs: A, fees: low; call it TX_2)? I get that they ca=
nnot<br />replace it, but the idea that they suffer financial loss from<br =
/>"ignorant" fee bumping is the part that seems weird to me. Clearly<br />T=
X_2 gets gossiped to other mempools; and understood that it does not<br />r=
eplace the TX_1 (the 3-input) in B's mempool, say, but why should<br />they=
 not even hear about it? Is it just a matter of engineering, or is<br />the=
re some deeper problem with that.<br /><br />About this general flavour of =
attack, it's never been a *big* concern<br />in Joinmarket imo (though, we =
did until recently have a bug that made<br />this happen *by accident*, i.e=
=2E people double spending an input out of<br />a negotiated join, albeit i=
t was rare; but it's ofc definitely<br />*possible* to 'grief' like this, g=
iven the ordering of events; maker<br />sends signature, maker broadcasts d=
ouble spend - 95% of the time they<br />will be first). Interactive protoco=
ls are yucky and I think there'll<br />always be griefing possibilities; de=
signing around multiple-rounds of<br />negotiation amongst not always-on pa=
rticipants is even more yucky, so<br />just having a 'taker is in charge of=
 network fee; if it's slow or gets<br />double spent out causing time delay=
 then just wait', combined with<br />'there really isn't any economic incen=
tive for an attacker' (i.e.<br />ignoring griefing) might sound crappy but =
it's probably just being<br />realistic.<br /><br />Of course, off-chain co=
ntracting has more sophisticated considerations<br />than this.<br /><br />=
Cheers,<br />AdamISZ/waxwing<br /><br />___________________________________=
____________<br />bitcoin-dev mailing list<br /><a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br =
/><a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev=
" target=3D"_blank" rel=3D"noopener noreferrer">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a></blockquote>
</div>
</body></html>

--=_1c8466be80e51f8af8e7c7d2b825c923--