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.