From: email@yancy•lol
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Greg Sanders <gsanders87@gmail•com>
Subject: Re: [bitcoin-dev] On mempool policy consistency
Date: Fri, 04 Nov 2022 11:28:17 +0100 [thread overview]
Message-ID: <d98309a7388a23f5600b7cf76d9a08f6@yancy.lol> (raw)
In-Reply-To: <Y2ALDu36tMQxVr/i@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 3253 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 5477 bytes --]
next prev parent reply other threads:[~2022-11-04 10:28 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
2022-11-04 10:28 ` email [this message]
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=d98309a7388a23f5600b7cf76d9a08f6@yancy.lol \
--to=email@yancy$(echo .)lol \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gsanders87@gmail$(echo .)com \
--cc=pete@petertodd$(echo .)org \
/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