<unnamed>

Public Key

npub1c3j2v4ws7hf9sj2xkr4dale0z4htw7lup37qeh2wxll4pcvlg03qe2aw73

Profile Code

nprofile1qqsvge9x2hg0t5jcf9rtp6k7luh32m4h007qclqvm48r0l6sux058cspz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qtslmkj

Publishing to

relay.nostr.net

Last Notes

2023-06-08 01:14:19 CEST

- reply

📅 Original date posted:2022-10-12
📝 Original message:Hello Pieter,
Thanks for taking the time to comment! I'll answer inline.
On Wed, Oct 12, 2022 at 2:51 PM Pieter Wuille <bitcoin-dev at wuille.net>
wrote:
> 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.
As stated in the original posting, I believe too that a full-RBF network is
not
only inevitable but also desirable. Miner incentives will eventually win,
so we
should address them before they fully kick in (ie. before transaction fees
become a meaningful portion of the block reward).
> 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.
Notice that I'm not saying this changes anything immediately on the network
at
large. In fact, it is unlikely that the opt-in flag alone would be enough to
migrate the network at large to full-RBF.
There's a real possibility that, after deployment of the opt-in flag,
either no
meaningful hashing power adopts it or no connected component of
transaction-relaying nodes adopts it. If that's the case, the deployment
won't
help nodes participating in multi-party funded transactions protect against
the
class of attacks described in [1] (which was, as I understand, the original
intention of #25353).
If that's not the case, it means that at least some meaningful hashing power
adopted it and that there exist some connected components of
transaction-relaying nodes that adopted it. This is certainly far from
having
wide adoption of full-RBF in the network at large. However, once we reach
that
minimal level of adoption in the mining and relaying layers, any node on a
full-RBF connected component can send an on-chain payment to an application
and
then get a replacement mined. That is, applications that accept incoming
on-chain payments from untrusted parties can be immediately exposed to
full-RBF
transaction replacements, even if they didn't opt into full-RBF in their
nodes.
In an adversarial setting, such as the one for zero-conf applications (as
defined in the original posting), this increases the risk of an attack
substantially, making the entire strategy moot.
> 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.
Those are worthy goals. I believe we can design a deployment strategy for
full-RBF that takes them into account and, at the same time, gives a clear
timeline for any affected application to adapt.
This could be one such proposal:
1. We activate opt-in full-RBF on testnet now.
2. We commit now (in the code) to a block height in the future at which
opt-out
full-RBF will activate on mainnet.
The first point will allow for experimentation and give a testing ground to
all
affected applications. The second point socializes the notion that
developers
believe it is time, giving a clear message and timeline for anyone affected
to
adapt. It also has the benefit that many more nodes will have upgraded by
the
time we reach the activation block height, making the transition to a
full-RBF
network much more predictable and easy to reason about.
There's an argument to be made that the miner incentive incompatibility
problem
of a non-full-RBF network gets measurably worse at the time of the next
halving.
To fix this, we could choose any block height before that, giving a clear
and
predictable transition timeline.
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
On Wed, Oct 12, 2022 at 1:11 PM Pieter Wuille <bitcoin-dev at wuille.net>
wrote:
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221012/5280640b/attachment-0001.html>