email at yancy.lol [ARCHIVE] on Nostr: 📅 Original date posted:2022-11-04 📝 Original message:Peter, > There's nothing ...
📅 Original date posted:2022-11-04
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221104/e8a258ae/attachment.html>;
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221104/e8a258ae/attachment.html>;