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.