From: Peter Todd <pete@petertodd•org>
To: email@yancy•lol,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Greg Sanders <gsanders87@gmail•com>
Subject: Re: [bitcoin-dev] On mempool policy consistency
Date: Mon, 31 Oct 2022 13:51:10 -0400 [thread overview]
Message-ID: <Y2ALDu36tMQxVr/i@petertodd.org> (raw)
In-Reply-To: <23dac89d36c356b9266db07e09c2de8e@yancy.lol>
[-- Attachment #1: Type: text/plain, Size: 2414 bytes --]
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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-10-31 17:51 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-26 23:52 Anthony Towns
2022-10-27 12:36 ` Gloria Zhao
2022-10-27 15:37 ` Anthony Towns
2022-10-27 18:17 ` Luke Dashjr
2022-10-27 13:49 ` Greg Sanders
2022-10-27 15:00 ` Peter Todd
2022-10-27 20:29 ` Antoine Riard
2022-10-30 2:24 ` Anthony Towns
2022-10-29 7:45 ` David A. Harding
2022-10-30 1:02 ` Anthony Towns
2022-10-30 2:40 ` Anthony Towns
2022-10-30 11:06 ` email
2022-10-31 13:02 ` Suhas Daftuar
2022-10-31 16:25 ` Greg Sanders
2022-10-31 17:21 ` email
2022-10-31 17:51 ` Peter Todd [this message]
2022-11-04 10:28 ` email
2022-11-02 3:07 ` Anthony Towns
2022-11-02 13:32 ` Greg Sanders
2022-11-02 19:50 ` Antoine Riard
2022-11-05 2:35 ` Peter Todd
[not found] <mailman.38435.1666828344.956.bitcoin-dev@lists.linuxfoundation.org>
2022-10-27 9:56 ` John Carvalho
2022-10-27 17:21 ` Anthony Towns
2022-10-27 17:35 ` Suhas Daftuar
2022-10-27 17:44 ` Greg Sanders
2022-10-27 19:00 ` Greg Sanders
2022-11-08 9:28 ` AdamISZ
2022-11-10 14:38 ` email
2022-11-03 21:06 email
2022-11-07 14:32 ` Peter Todd
2022-11-07 14:47 ` Erik Aronesty
2022-11-08 14:54 ` email
2022-11-09 12:05 ` email
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y2ALDu36tMQxVr/i@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=email@yancy$(echo .)lol \
--cc=gsanders87@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox