Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id D57F9C002D for ; 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 ; 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 ; 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 ; 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 In-Reply-To: References: <23dac89d36c356b9266db07e09c2de8e@yancy.lol> Message-ID: 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 , Greg Sanders 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: 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
Peter,
 
There's nothing special about a "full-rbf transaction" other than the fa= ct
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 transactio= n must signal that it can be replaced.  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..
 
Since all the machinery to do replacemnt already exists, adding a full-r= bf
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 bi= tcoin-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 on= e non-rbf node exists on the network, however, every other node
implem= ents full-rbf, will the transaction still be propagated?  IE can wealways 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 e= ach other,
thus ensuring good transaction propagation. The most recent= patch to implement
this is: https://gith= ub.com/bitcoin/bitcoin/pull/25600

There's enough peers runni= ng full-rbf that the last time I started up a new
node on a fresh IP a= ddress, it happened to have a peer relaying full-rbf
replacements to i= t. 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= =2E 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 mempoo= l, so in certain cases
non-full-rbf nodes will in fact broadcast repla= cements when they didn't happen
to receive the "first" transaction fir= st.

The latter makes testing full-rbf a bit problematic, as if y= ou don't take
special measures to ensure good propagation a small % of= the time the
"replacement" transaction will in fact be the one that g= ets gets mined.

Does fullrbf offer any benefits other than breaking ze= roconf
business practices?  If so, what are they?

I think AJ mentioned this earlier, but adding more configuration opti= ons
always increases code complexity, and with that, there is likely m= ore
unforeseen bugs.  However, there is a section of network part= icipants that
rely on both types of transaction policy, so from my lim= ited view-point, it
seems worth accommodating if possible.

Since all the machinery to do replacemnt already exists, adding a ful= l-rbf
config flag is particularly trivial. It requires just a single l= ine in the
mempool code.
--=_3dd49c158d29b0011788b524f2e81c17--