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