Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2022-10-12 📝 Original message:On Wednesday, October ...
📅 Original date posted:2022-10-12
📝 Original message:On Wednesday, October 12th, 2022 at 1:42 AM, Anthony Towns <aj at erisian.com.au> wrote:
> On Tue, Oct 11, 2022 at 04:18:10PM +0000, Pieter Wuille via bitcoin-dev wrote:
>
> > On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
> >
> > > Thanks for the fast answer! It seems I missed the link to the PR, sorry for the
> > > confusion. I'm referring to the opt-in flag for full-RBF from #25353
> > > (https://github.com/bitcoin/bitcoin/pull/25353).
> > > It is not clear to me why you believe the merging of this particular pull request poses an immediate risk to you.
>
>
> Did you see the rest of Dario's reply, bottom-posted after the quoted
> text? Namely:
Oh, my mail client for some reason chose to hide all that. Dario, I'm sorry for missing this; I see now that you were certainly aware of what the PR under consideration did.
Further comments inline.
> On Fri, Oct 07, 2022 at 06:37:38PM -0300, Dario Sneidermanis via
> > The question then is whether an opt-in flag for full-RBF will have enough
> > adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its
> > objective of allowing nodes participating in multi-party funding protocols
> > to assume that they can rely on full-RBF. If it is, then zero-conf applications
> > will be at severe risk (per the logic in the initial email).
>
>
> That logic seems reasonably sound to me:
>
> - if adding the option does nothing, then there's no point adding it,
> and no harm in restricting it to test nets only
>
> - if adding the option does do something, then businesses using zero-conf
> need to react immediately, or will go from approximately zero risk of
> losing funds, to substantial risk
>
> (I guess having the option today may allow you to manually switch your
> node over to supporting fullrbf in future when the majority of the network
> supports it, without needing to do an additional upgrade in the meantime;
> but that seems like a pretty weak benefit)
I certainly recognize that adding the flag is a likely step towards, over time, the full RBF policy becoming more widely adopted on the network. That is presumably the reason why people are in favor of having the flag, even default off - including me. I believe that policy's adoption is inevitable eventually, but the speed at which that is achieved is certainly a function of availability and adopted of software which provides the option.
That said, I think it's a bit of a jump to conclude that the only two options are that either the existence of the flag either has no effect at all, or poses an immediate threat to those relying on its absence. In my view, it is just what I said: a step towards getting full RBF on the network, by allowing experimentation and socializing the notion that developers believe it is time. So I have a hard time imagining how it would change anything *immediately* on the network at large (without things like default on and/or preferential peering, ...), but I still believe it's an important step.
Cheers,
--
Pieter
📝 Original message:On Wednesday, October 12th, 2022 at 1:42 AM, Anthony Towns <aj at erisian.com.au> wrote:
> On Tue, Oct 11, 2022 at 04:18:10PM +0000, Pieter Wuille via bitcoin-dev wrote:
>
> > On Friday, October 7th, 2022 at 5:37 PM, Dario Sneidermanis via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
> >
> > > Thanks for the fast answer! It seems I missed the link to the PR, sorry for the
> > > confusion. I'm referring to the opt-in flag for full-RBF from #25353
> > > (https://github.com/bitcoin/bitcoin/pull/25353).
> > > It is not clear to me why you believe the merging of this particular pull request poses an immediate risk to you.
>
>
> Did you see the rest of Dario's reply, bottom-posted after the quoted
> text? Namely:
Oh, my mail client for some reason chose to hide all that. Dario, I'm sorry for missing this; I see now that you were certainly aware of what the PR under consideration did.
Further comments inline.
> On Fri, Oct 07, 2022 at 06:37:38PM -0300, Dario Sneidermanis via
> > The question then is whether an opt-in flag for full-RBF will have enough
> > adoption to get us from 1 to 2. If it isn't, then #25353 won't meet its
> > objective of allowing nodes participating in multi-party funding protocols
> > to assume that they can rely on full-RBF. If it is, then zero-conf applications
> > will be at severe risk (per the logic in the initial email).
>
>
> That logic seems reasonably sound to me:
>
> - if adding the option does nothing, then there's no point adding it,
> and no harm in restricting it to test nets only
>
> - if adding the option does do something, then businesses using zero-conf
> need to react immediately, or will go from approximately zero risk of
> losing funds, to substantial risk
>
> (I guess having the option today may allow you to manually switch your
> node over to supporting fullrbf in future when the majority of the network
> supports it, without needing to do an additional upgrade in the meantime;
> but that seems like a pretty weak benefit)
I certainly recognize that adding the flag is a likely step towards, over time, the full RBF policy becoming more widely adopted on the network. That is presumably the reason why people are in favor of having the flag, even default off - including me. I believe that policy's adoption is inevitable eventually, but the speed at which that is achieved is certainly a function of availability and adopted of software which provides the option.
That said, I think it's a bit of a jump to conclude that the only two options are that either the existence of the flag either has no effect at all, or poses an immediate threat to those relying on its absence. In my view, it is just what I said: a step towards getting full RBF on the network, by allowing experimentation and socializing the notion that developers believe it is time. So I have a hard time imagining how it would change anything *immediately* on the network at large (without things like default on and/or preferential peering, ...), but I still believe it's an important step.
Cheers,
--
Pieter