From: Dario Sneidermanis <dario@muun•com>
To: Antoine Riard <antoine.riard@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Analysis of full-RBF deployment methods
Date: Fri, 21 Oct 2022 18:13:41 -0300 [thread overview]
Message-ID: <CAKiPDnQ68HgVYxB5nyJ+XQzs1L1KBqiuxFpnk3eqv3egEWziaA@mail.gmail.com> (raw)
In-Reply-To: <CALZpt+FPWSFbr6r-5J0YO1o3SvMQC4Gyj-QWTJ4yA3ZbJtOUxQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3593 bytes --]
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: 4061 bytes --]
next prev parent reply other threads:[~2022-10-21 21:13 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 [this message]
2022-10-23 23:10 ` Antoine Riard
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=CAKiPDnQ68HgVYxB5nyJ+XQzs1L1KBqiuxFpnk3eqv3egEWziaA@mail.gmail.com \
--to=dario@muun$(echo .)com \
--cc=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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