path: root/43/22f69fde36cf502248fab609879f0a5273fb53

Return-Path: <email@yancy.lol>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D57F9C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  4 Nov 2022 10:28:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id A382881FE3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  4 Nov 2022 10:28:22 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org A382881FE3
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 smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id W0pIrDGgIImC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  4 Nov 2022 10:28:21 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 3239781F97
Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net
 [217.70.183.200])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 3239781F97
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  4 Nov 2022 10:28:20 +0000 (UTC)
Received: (Authenticated sender: email@yancy.lol)
 by mail.gandi.net (Postfix) with ESMTPA id D038E20010;
 Fri,  4 Nov 2022 10:28:17 +0000 (UTC)
MIME-Version: 1.0
Date: Fri, 04 Nov 2022 11:28:17 +0100
From: email@yancy.lol
To: Peter Todd <pete@petertodd.org>
In-Reply-To: <Y2ALDu36tMQxVr/i@petertodd.org>
References: <Y1nIKjQC3DkiSGyw@erisian.com.au>
 <CAFp6fsFm06J2G1=3ojQvcL9gbEbQ41C4rmf3=Jkm9Qm0VBhhKw@mail.gmail.com>
 <CAB3F3Dt=2hDXXw6Jz9QwnotkNLyGdZn9GZLHFXu0Dnyz3tsc0w@mail.gmail.com>
 <23dac89d36c356b9266db07e09c2de8e@yancy.lol>
 <Y2ALDu36tMQxVr/i@petertodd.org>
Message-ID: <d98309a7388a23f5600b7cf76d9a08f6@yancy.lol>
X-Sender: email@yancy.lol
Content-Type: multipart/alternative;
 boundary="=_3dd49c158d29b0011788b524f2e81c17"
X-Mailman-Approved-At: Fri, 04 Nov 2022 11:27:02 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Greg Sanders <gsanders87@gmail.com>
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: Fri, 04 Nov 2022 10:28:22 -0000

--=_3dd49c158d29b0011788b524f2e81c17
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII;
 format=flowed



Peter,

> There's nothing special about a "full-rbf transaction" other than the 
> fact
> that it's replacing a previously broadcast transaction that didn't 
> signal
> replacement.

Thanks, this is a piece I haven't seen.  It sounds like "full-rbf" 
policy is fundamentally different from BIP125, where in BIP125 a 
transaction must signal that it can be replaced.  If I'm reading what 
you said correctly, then "full-rbf" policy will allow the replacement of 
any transaction, whether it's signaled or not..

> Since all the machinery to do replacemnt already exists, adding a 
> full-rbf
> config flag is particularly trivial. It requires just a single line in 
> the
> mempool code.

Agree the flag is trivial.  The interplay between mempool policies may 
not be trivial.

Cheers,
-Yancy

On 2022-10-31 18:51, Peter Todd wrote:

> On Mon, Oct 31, 2022 at 06:21:08PM +0100, yancy via bitcoin-dev wrote:
> 
>> Protocol Devs,
>> 
>> After reading through this email thread and BIP125, I'm curious if 
>> non-rbf
>> nodes will relay full-rbf transactions and vice versa.  That is to 
>> say, if
>> only one non-rbf node exists on the network, however, every other node
>> implements full-rbf, will the transaction still be propagated?  IE can 
>> we
>> always guarantee a path through the network for either transaction 
>> type no
>> matter what the combination of network policies are?
> 
> 1) There are nodes that signal full-rbf, and preferentially peer to 
> each other,
> thus ensuring good transaction propagation. The most recent patch to 
> implement
> this is: https://github.com/bitcoin/bitcoin/pull/25600
> 
> There's enough peers running full-rbf that the last time I started up a 
> new
> node on a fresh IP address, it happened to have a peer relaying 
> full-rbf
> replacements to it. And of course, if people want full-rbf to work more
> reliably, it's very easy to just run some nodes with a large number of 
> outgoing
> peers. Changing the hard-coded 8 outgoing peers to, say, 800, isn't 
> very hard.
> 
> 2) There's nothing special about a "full-rbf transaction" other than 
> the fact
> that it's replacing a previously broadcast transaction that didn't 
> signal
> replacement. There is not consensus over the mempool, so in certain 
> cases
> non-full-rbf nodes will in fact broadcast replacements when they didn't 
> happen
> to receive the "first" transaction first.
> 
> The latter makes testing full-rbf a bit problematic, as if you don't 
> take
> special measures to ensure good propagation a small % of the time the
> "replacement" transaction will in fact be the one that gets gets mined.
> 
> Does fullrbf offer any benefits other than breaking zeroconf
> business practices?  If so, what are they?
> I think AJ mentioned this earlier, but adding more configuration 
> options
> always increases code complexity, and with that, there is likely more
> unforeseen bugs.  However, there is a section of network participants 
> that
> rely on both types of transaction policy, so from my limited 
> view-point, it
> seems worth accommodating if possible.

Since all the machinery to do replacemnt already exists, adding a 
full-rbf
config flag is particularly trivial. It requires just a single line in 
the
mempool code.
--=_3dd49c158d29b0011788b524f2e81c17
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'>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">
<div class=3D"v1pre" style=3D"margin: 0; padding: 0; font-family: monospace=
;">Peter,</div>
<div class=3D"v1pre" style=3D"margin: 0; padding: 0; font-family: monospace=
;">&nbsp;</div>
<blockquote style=3D"padding: 0 0.4em; border-left: #1010ff 2px solid; marg=
in: 0;">
<div class=3D"v1pre" style=3D"margin: 0; padding: 0; font-family: monospace=
;">There's nothing special about a "full-rbf transaction" other than the fa=
ct<br />that it's replacing a previously broadcast transaction that didn't =
signal<br />replacement.</div>
</blockquote>
<div class=3D"v1pre" style=3D"margin: 0; padding: 0; font-family: monospace=
;">&nbsp;</div>
<div class=3D"v1pre" style=3D"margin: 0; padding: 0; font-family: monospace=
;">Thanks, this is a piece I haven't seen. &nbsp;It sounds like "full-rbf" =
policy is fundamentally different from BIP125, where in BIP125 a transactio=
n must signal that it can be replaced. &nbsp;If I'm reading what you said c=
orrectly, then "full-rbf" policy will allow the replacement of any transact=
ion, whether it's signaled or not..</div>
<div class=3D"v1pre" style=3D"margin: 0; padding: 0; font-family: monospace=
;">&nbsp;</div>
<blockquote style=3D"padding: 0 0.4em; border-left: #1010ff 2px solid; marg=
in: 0;">
<div class=3D"v1pre" style=3D"margin: 0; padding: 0; font-family: monospace=
;">Since all the machinery to do replacemnt already exists, adding a full-r=
bf<br />config flag is particularly trivial. It requires just a single line=
 in the<br />mempool code.</div>
</blockquote>
<div class=3D"v1pre" style=3D"margin: 0; padding: 0; font-family: monospace=
;">&nbsp;</div>
<div class=3D"v1pre" style=3D"margin: 0; padding: 0; font-family: monospace=
;">Agree the flag is trivial. &nbsp;The interplay between mempool policies =
may not be trivial.</div>
<div class=3D"v1pre" style=3D"margin: 0; padding: 0; font-family: monospace=
;">&nbsp;</div>
<div class=3D"v1pre" style=3D"margin: 0; padding: 0; font-family: monospace=
;">Cheers,</div>
<div class=3D"v1pre" style=3D"margin: 0; padding: 0; font-family: monospace=
;">-Yancy</div>
<div class=3D"v1pre" style=3D"margin: 0; padding: 0; font-family: monospace=
;">&nbsp;</div>
</div>
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
On 2022-10-31 18:51, Peter Todd wrote:
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">On Mon, Oct 31, 2022 at 06:21:08PM +0100, yancy via bi=
tcoin-dev wrote:
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0"><br />Protocol Devs,<br /><br />After reading through =
this email thread and BIP125, I'm curious if non-rbf<br />nodes will relay =
full-rbf transactions and vice versa. &nbsp;That is to say, if<br />only on=
e non-rbf node exists on the network, however, every other node<br />implem=
ents full-rbf, will the transaction still be propagated? &nbsp;IE can we<br=
 />always guarantee a path through the network for either transaction type =
no<br />matter what the combination of network policies are?</blockquote>
<br />1) There are nodes that signal full-rbf, and preferentially peer to e=
ach other,<br />thus ensuring good transaction propagation. The most recent=
 patch to implement<br />this is: <a href=3D"https://github.com/bitcoin/bit=
coin/pull/25600" target=3D"_blank" rel=3D"noopener noreferrer">https://gith=
ub.com/bitcoin/bitcoin/pull/25600</a><br /><br />There's enough peers runni=
ng full-rbf that the last time I started up a new<br />node on a fresh IP a=
ddress, it happened to have a peer relaying full-rbf<br />replacements to i=
t. And of course, if people want full-rbf to work more<br />reliably, it's =
very easy to just run some nodes with a large number of outgoing<br />peers=
=2E Changing the hard-coded 8 outgoing peers to, say, 800, isn't very hard.=
<br /><br />2) There's nothing special about a "full-rbf transaction" other=
 than the fact<br />that it's replacing a previously broadcast transaction =
that didn't signal<br />replacement. There is not consensus over the mempoo=
l, so in certain cases<br />non-full-rbf nodes will in fact broadcast repla=
cements when they didn't happen<br />to receive the "first" transaction fir=
st.<br /><br />The latter makes testing full-rbf a bit problematic, as if y=
ou don't take<br />special measures to ensure good propagation a small % of=
 the time the<br />"replacement" transaction will in fact be the one that g=
ets gets mined.<br /><br />
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">Does fullrbf offer any benefits other than breaking ze=
roconf<br />business practices? &nbsp;If so, what are they?</blockquote>
<br />I think AJ mentioned this earlier, but adding more configuration opti=
ons<br />always increases code complexity, and with that, there is likely m=
ore<br />unforeseen bugs. &nbsp;However, there is a section of network part=
icipants that<br />rely on both types of transaction policy, so from my lim=
ited view-point, it<br />seems worth accommodating if possible.</blockquote>
<br />Since all the machinery to do replacemnt already exists, adding a ful=
l-rbf<br />config flag is particularly trivial. It requires just a single l=
ine in the<br />mempool code.</blockquote>
</div>
</body></html>

--=_3dd49c158d29b0011788b524f2e81c17--