From: Antoine Riard <antoine.riard@gmail•com>
To: Dario Sneidermanis <dario@muun•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Analysis of full-RBF deployment methods
Date: Sun, 23 Oct 2022 19:10:16 -0400 [thread overview]
Message-ID: <CALZpt+GQ_aEA8LOzr7E_dHwWDZveKGyXw5cAvc5JvBnTocwsJQ@mail.gmail.com> (raw)
In-Reply-To: <CAKiPDnQ68HgVYxB5nyJ+XQzs1L1KBqiuxFpnk3eqv3egEWziaA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6782 bytes --]
Hi Dario,
Thanks for providing more thoughts to the discussion!
> Notice that #26323 (option 5 in the OP) has the advantage of getting us
to a
> reliable full-RBF network the fastest (in particular, much faster than the
> current opt-in deployment) while not threatening zero-conf applications
> until
> the activation time. That is, #26323 gives us a way in which we don't need
> to
> choose between the security of one use case versus the other. We can have
> both.
For sure, contracting protocols and multi-party applications exposed by the
lack of full-rbf are still young overall, though as they attract more
volume they're also likely to become honeypots for any competing services
providers interested to hijack economic traffic (kinda the same concern
than channel jamming...) At the same time, we still have 0confs services
more exposed by full-rbf, a bit stuck between Scylla and Charybdis.
As commented on #26323, I'm personally fine with this approach, and I fully
opine that providing a clear and predictable time point to 0confs operators
is very valuable. Even more, I think May 1st 2023, is a bit too early,
10-12 months sounds more reasonable.
At the same time, I believe it's the opinion of a few developers and other
Bitcoin service operators that the Core project is taking too much
responsibility in taking for the network by shipping full-rbf=true.
(Really I'm 50/50 between those 2 opinions, as I'm the author of both
#26305 and #25600 and concept ACK on #26323, and any process forward would
sounds good to me)
> I don't think asking for a predictable deployment timeline for a change
that
> would put some applications at increased risk could be described as
> burdening
> the developers with solving every operational risk. This deployment method
> comparison's goal was precisely to soften the burden on core devs.
I can understand the confusion here. As it has been discussed on your
original thread, from my comprehension, the idea has been raised of a
optech working group or something to build collaboration between wallet
devs, merchant devs and protocol devs around "Bitcoin payment" issues like
FX risk, additional layers of security for 0confs, RBF and CPFP, etc [0].
While again, I reassert that such a multi-stakeholder forum could be really
fruitful for the ecosystem at large, I don't know if it should be a
prerequisite that we solve all the potential payment issues before
proceeding with full-rbf deployment. However I'm keeping aware about the
interdependency between full-rbf and operational, legal and business issues
that one encounters running a Bitcoin merchant/service, not easy to make
everything works I can guess.
[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021076.html
Best,
Antoine
Le ven. 21 oct. 2022 à 17:13, Dario Sneidermanis <dario@muun•com> a écrit :
> Hello Antoine,
>
> Thanks for taking the time to answer every email with detailed analysis! I
> can
> see it's a lot of work. I'll answer inline.
>
> On Thu, Oct 20, 2022 at 10:50 PM Antoine Riard <antoine.riard@gmail•com>
> wrote:
> > Personally, I still think deferring full-rbf deployment, while it sounds
> > reasonable to let existing services and applications adapt their
> software and
> > business models, doesn't come risk-free for the contracting protocols and
> > multi-party applications affected by the pinning DoS vector. Deferring ad
> > vitam aeternam left them exposed to disruptions when their traffic volume
> > would start to be significant. While those use-cases
> > (splicing/dual-channels/collaborative constructions) were mostly
> vaporware a
> > year ago when I raised the issue, it turns out they have become a far
> more
> > tangible reality today. Beyond the 3 coinjoins services
> > (Wasabi/Joinmarket/Whirlpool), we have new things like ln-vortex, or
> Phoenix
> > wallet and some LDK users planning to use dual-funded soon.
>
> To solve the attack you described in [0], collaborative transaction
> protocols
> (such as dual-funded channels) need a *reliable* way to replace
> transactions.
> Otherwise, protocol parties using full-RBF may see replacements succeed in
> their
> own mempool, only to find out they weren't relayed to a miner once it's
> too late
> (ie. once the replacement that won is mined).
>
> I'm calling a full-RBF deployment reliable to the point at which any
> full-RBF-enabled node can broadcast a replacement and get it relayed all
> the way
> to a miner in a reliable manner (ie. with high-enough probability).
>
> Even if we deployed opt-out (or mandatory!) full-RBF now and miners
> adopted it
> immediately, it would take almost a year (assuming normal deployment
> times) for
> it to be sufficiently deployed in the relaying layer to be considered
> reliable.
> An opt-in full-RBF deployment, as currently proposed (ie. without #25600),
> has
> very little chance of getting us nowhere near that kind of adoption.
>
> Notice that #26323 (option 5 in the OP) has the advantage of getting us to
> a
> reliable full-RBF network the fastest (in particular, much faster than the
> current opt-in deployment) while not threatening zero-conf applications
> until
> the activation time. That is, #26323 gives us a way in which we don't need
> to
> choose between the security of one use case versus the other. We can have
> both.
>
> > I'm still looking forward to having more forums and communication
> channels
> > between business/services operators and protocol developers, it sounds
> like
> > functional responsibilities between protocol and application layers
> could be
> > better clarified. However, I don't know if it should be the
> responsibility of
> > developers to solve every operational risk encumbered by a Bitcoin
> business,
> > like FX risk. I don't deny the interdependency between network policy
> rules
> > and business risk, I'm just saying Bitcoin protocol developers have
> already
> > heavily loaded engineering priorities between solving the half of dozen
> of
> > Lightning vulnerabilities, working on the next consensus changes or
> reviewing
> > modularity refactoring of Bitcoin Core to extend the feature set in a
> soft way
> > (among tons of other examples).
>
> I don't think asking for a predictable deployment timeline for a change
> that
> would put some applications at increased risk could be described as
> burdening
> the developers with solving every operational risk. This deployment method
> comparison's goal was precisely to soften the burden on core devs.
>
> Cheers,
> Dario
>
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>
[-- Attachment #2: Type: text/html, Size: 7509 bytes --]
prev parent reply other threads:[~2022-10-23 23:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-20 16:51 Dario Sneidermanis
2022-10-21 1:50 ` Antoine Riard
2022-10-21 21:13 ` Dario Sneidermanis
2022-10-23 23:10 ` Antoine Riard [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALZpt+GQ_aEA8LOzr7E_dHwWDZveKGyXw5cAvc5JvBnTocwsJQ@mail.gmail.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dario@muun$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox