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.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev