path: root/a1/c59a63504b6eac57aeb7717e906c9fb8ccd1e7

Return-Path: <antoine.riard@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CD5BEC0072
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 19 Dec 2021 18:55:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id BB64182F31
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 19 Dec 2021 18:55:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id uRJb9wrPDZgD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 19 Dec 2021 18:55:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com
 [IPv6:2a00:1450:4864:20::333])
 by smtp1.osuosl.org (Postfix) with ESMTPS id ACBAC82BC3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 19 Dec 2021 18:55:15 +0000 (UTC)
Received: by mail-wm1-x333.google.com with SMTP id y196so5464664wmc.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 19 Dec 2021 10:55:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=lr/dvHZuLJ15I5IXI6BZTeZrAvnRLcc6+bKzYjP6yds=;
 b=mMj066RhfWseB6MYjMQB7YeqOsEJApqGCDunon+SD71MeZzxlS/rmwdjCULj5LIA3i
 /JCXZGw6/+tlcpGlTfKAU+CYhZgsgvagcaGNd1sY2K5yLY2Xg+wFys8cHhw3V5hrwizT
 jLZP0eqUoQ9mrolYp27+4OHh3IWLxIKnl/XlfOHIUCOTRTdT5xj8HTVabghvZW1V2VGm
 jiujmfV3tY6TW5DWM2l1YXSqndN+uN3KKOqSVPQUUzvqIdTwUEHLGa1s6cmANJ9D5Lwj
 OATlIiT8j4NZ6mz2hH7Tn7wXWCHOG6pjE8U/INwfSKmItZjWiy0ozb+DohtVdIiwdGfP
 KWvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=lr/dvHZuLJ15I5IXI6BZTeZrAvnRLcc6+bKzYjP6yds=;
 b=fvYcs/FQrmBoGz5+p9KGklToBTz51+BNj6Xy5ZFUEMpHWDGXzUvJ/vrBAYVYkVDpSP
 wsvjCC1NCsDBmJmJeFJV+Re2b2+go8uh0+dDsRsGjnlBDtPxnYChQs1OxNQJYITWbhBj
 wkyCmiMbcqHqRF80Mt5TPA9hd/WLVtXeBXA9XLI9Pf/vfvM1DhWSwIv8mVknzMGUn77B
 qIvFXIx4byh64ARQTSyRMLw5jFNrr6ole4Itgi0qNhbrVrkI+d4oyWRKgy0dpz4PUyOs
 G1JE2vZasVB2hv06iV8gEv+mH8/Nke3T/OBBa8CDw+Xb1GG49H3kYoLFsRAj8xZf8/Z7
 LO3w==
X-Gm-Message-State: AOAM532EKhjmkg7est1IEmXZekiNyD2Zlabt/4i/NZf/TwjKPXD63p4Y
 lqU4z2RbeX0mn9N/3+Y1+601egl2gik6qXhiLUYhuoWfBnpx9A==
X-Google-Smtp-Source: ABdhPJzJknMdM68O/DvaCgiKM6VrhiJ61+u+FKCGEz8ysNONNvqiQMphXKTOrOODfzxDCQW7ptA9gQeiOq1/iGhAgCI=
X-Received: by 2002:a1c:4d0d:: with SMTP id o13mr2471806wmh.70.1639940113914; 
 Sun, 19 Dec 2021 10:55:13 -0800 (PST)
MIME-Version: 1.0
References: <CALZpt+F2b3tdu1+kLZiBPCH2O-pDzZytoRFtX6X0a8UX4OBrDQ@mail.gmail.com>
 <CAD5xwhjVkxgu2+M+Ft576GYM6Tv=ZEwtV82v1cLeYaoU5mSRnA@mail.gmail.com>
In-Reply-To: <CAD5xwhjVkxgu2+M+Ft576GYM6Tv=ZEwtV82v1cLeYaoU5mSRnA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sun, 19 Dec 2021 13:55:01 -0500
Message-ID: <CALZpt+F9zgBNPzcmtN5HzkgUDkbXdkxhN2ksfo4uExB8jYEzjw@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="000000000000f15e1205d3844f22"
X-Mailman-Approved-At: Sun, 19 Dec 2021 19:03:51 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Dec 2021 18:55:17 -0000

--000000000000f15e1205d3844f22
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> we might start with 60 seconds, and then double every release till we get
to 600 at which point we disable it.

This is clearly new. However, I'm not sure if it's solving multi-party
funding transaction DoS, which was of the motivation to propose to
deprecate opt-in RBF. The malicious counterparty can broadcast its
low-feerate, opt-out spending of its own collateral input far before to
engage in the cooperative funding.

When the funding transaction starts to propagate, the opt-out has been
"first seen" for a while, the replaceability is turned off, the honest
funding is bounced off ?


Taking opportunity to laid out another proposal which has whispered to me
offline :

"(what) if the nversion of outputs (which is set by their creating
transaction) were inspected and
triggered any spend of the output to be required to be flagged to be
replaceable-- as a standardness rule?"

While working to solve the DoS, I believe this approach is introducing an
overhead cost in the funding of multi-party transactions, as from now on,
you have to sanitize your collateral inputs by sending them first to a
replaceable nVersion outputs ? (iirc, this is done by Lightning Pool, where
you have a first step where the inputs are locked in a 2-of-2 with the
orchester before to engage in the batch execution tx).

Current state of the discussion is to introduce a `fullrbf` config-knob
turned to false, see more context here :
https://gnusha.org/bitcoin-core-dev/2021-10-21.log. Proposing an
implementation soon.

Antoine

Le sam. 18 d=C3=A9c. 2021 =C3=A0 11:51, Jeremy <jlrubin@mit.edu> a =C3=A9cr=
it :

> Small idea:
>
> ease into getting rid of full-rbf by keeping the flag working, but make
> enforcement of non-replaceability something that happens n seconds after
> first seen.
>
> this reduces the ability to partition the mempools by broadcasting
> irreplaceable conflicts all at once, and slowly eases clients off of
> relying on non-RBF.
>
> we might start with 60 seconds, and then double every release till we get
> to 600 at which point we disable it.
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Tue, Jun 15, 2021 at 10:00 AM Antoine Riard via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi,
>>
>> I'm writing to propose deprecation of opt-in RBF in favor of full-RBF as
>> the Bitcoin Core's default replacement policy in version 24.0. As a
>> reminder, the next release is 22.0, aimed for August 1st, assuming
>> agreement is reached, this policy change would enter into deployment pha=
se
>> a year from now.
>>
>> Even if this replacement policy has been deemed as highly controversial =
a
>> few years ago, ongoing and anticipated changes in the Bitcoin ecosystem =
are
>> motivating this proposal.
>>
>> # RBF opt-out as a DoS Vector against Multi-Party Funded Transactions
>>
>> As explained in "On Mempool Funny Games against Multi-Party Funded
>> Transactions'', 2nd issue [0], an attacker can easily DoS a multi-party
>> funded transactions by propagating an RBF opt-out double-spend of its
>> contributed input before the honest transaction is broadcasted by the
>> protocol orchester. DoSes are qualified in the sense of either an attack=
er
>> wasting timevalue of victim's inputs or forcing exhaustion of the
>> fee-bumping  reserve.
>>
>> This affects a series of Bitcoin protocols such as Coinjoin, onchain DLC=
s
>> and dual-funded LN channels. As those protocols are still in the early
>> phase of deployment, it doesn't seem to have been executed in the wild f=
or
>> now.  That said, considering that dual-funded are more efficient from a
>> liquidity standpoint, we can expect them to be widely relied on, once
>> Lightning enters in a more mature phase. At that point, it should become
>> economically rational for liquidity service providers to launch those Do=
S
>> attacks against their competitors to hijack user traffic.
>>
>> Beyond that, presence of those DoSes will complicate the design and
>> deployment of multi-party Bitcoin protocols such as payment
>> pools/multi-party channels. Note, Lightning Pool isn't affected as there=
 is
>> a preliminary stage where batch participants are locked-in their funds
>> within an account witnessScript shared with the orchestrer.
>>
>> Of course, even assuming full-rbf, propagation of the multi-party funded
>> transactions can still be interfered with by an attacker, simply
>> broadcasting a double-spend with a feerate equivalent to the honest
>> transaction. However, it tightens the attack scenario to a scorched eart=
h
>> approach, where the attacker has to commit equivalent fee-bumping reserv=
e
>> to maintain the pinning and might lose the "competing" fees to miners.
>>
>> # RBF opt-out as a Mempools Partitions Vector
>>
>> A longer-term issue is the risk of mempools malicious partitions, where
>> an attacker exploits network topology or divergence in mempools policies=
 to
>> partition network mempools in different subsets. From then a wide range =
of
>> attacks can be envisioned such as package pinning [1], artificial
>> congestion to provoke LN channels closure or manipulation of
>> fee-estimator's feerate (the Core's one wouldn't be affected as it relie=
s
>> on block confirmation, though other fee estimators designs deployed acro=
ss
>> the ecosystem are likely going to be affected).
>>
>> Traditionally, mempools partitions have been gauged as a spontaneous
>> outcome of a distributed systems like Bitcoin p2p network and I'm not aw=
are
>> it has been studied in-depth for adversarial purposes. Though, deploymen=
t
>> of second-layer
>> protocols, heavily relying on sanity of a local mempool for
>> fee-estimation and robust propagation of their time-sensitive transactio=
ns
>> might lead to reconsider this position. Acknowledging this, RBF opt-out =
is
>> a low-cost partitioning tool, of which the existence nullifies most of
>> potential progresses to mitigate malicious partitioning.
>>
>>
>> To resume, opt-in RBF doesn't suit well deployment of robust
>> second-layers protocol, even if those issues are still early and deserve
>> more research. At the same time, I believe a meaningful subset of the
>> ecosystem  are still relying
>> on 0-confs transactions, even if their security is relying on far weaker
>> assumptions (opt-in RBF rule is a policy rule, not a consensus one) [2] =
A
>> rapid change of Core's mempool rules would be harming their quality of
>> services and should be
>> weighed carefully. On the other hand, it would be great to nudge them
>> towards more secure handling of their 0-confs flows [3]
>>
>> Let's examine what could be deployed ecosystem-wise as enhancements to
>> the 0-confs security model.
>>
>> # Proactive security models : Double-spend Monitoring/Receiver-side
>> Fee-Topping with Package Relay
>>
>> From an attacker viewpoint, opt-in RBF isn't a big blocker to successful
>> double-spends. Any motivated attacker can modify Core to mass-connect to=
 a
>> wide portion of the network, announce txA to this subset, announce txA' =
to
>> the
>> merchant. TxA' propagation will be encumbered by the privacy-preserving
>> inventory timers (`OUTBOUND_INVENTORY_BROADCAST_INTERVAL`), of which an
>> attacker has no care to respect.
>>
>> To detect a successful double-spend attempt, a Bitcoin service should ru=
n
>> few full-nodes with well-spread connection graphs and unlinkable between
>> them, to avoid being identified then maliciously partitioned from the re=
st
>> of the network.
>>
>> I believe this tactic is already deployed by few Bitcoin services, and
>> even one can throw flame at it because it over consumes network resource=
s
>> (bandwidth, connection slots, ...), it does procure a security advantage=
 to
>> the ones doing it.
>>
>> One further improvement on top of this protection could be to react afte=
r
>> the double-spend detection by attaching a CPFP to the merchant transacti=
on,
>> with a higher package feerate than the double-spend. Expected deployment=
 of
>> package-relay as a p2p mechanism/mempool policy in Bitcoin Core should
>> enable it to do so.
>>
>> # Reactive security models : EconomicReputation-based Compensations
>>
>> Another approach could be to react after the fact if a double-spend has
>> been qualified. If the sender is already known to the service provider, =
the
>> service account can be slashed.  If the sender is a low-trusted
>> counterparty to the merchant, "side-trust" models could be relied on. Fo=
r
>> e.g a LN pubkey with a stacked reputation from your autopilot, LSATs, st=
ake
>> certificates, a HTLC-as-a-fidelity-bond, ... The space is quite wide the=
re
>> but I foresee those trust-minimized, decentralized solutions being adopt=
ed
>> by the LN ecosystem to patch the risks when you enter in a channel/HTLC
>> operation with an anonymous counterparty.
>>
>> What other cool new tools could be considered to enhance 0-confs securit=
y
>> ?
>>
>> To conclude, let's avoid replaying the contentious threads of a few year=
s
>> ago. What this new thread highlights is the fact that a transaction
>> relay/mempool acceptance policy might be beneficial to some class of
>> already-deployed
>> Bitcoin applications while being detrimental to newer ones. How do we
>> preserve the current interests of 0-confs users while enabling upcoming
>> interests of fancy L2s to flourish is a good conversation to have. I thi=
nk.
>>
>> If there is ecosystem agreement on switching to full-RBF, but 0.24 sound=
s
>> too early, let's defer it to 0.25 or 0.26. I don't think Core has a
>> consistent deprecation process w.r.t to policy rules heavily relied-on b=
y
>> Bitcoin users, if we do so let sets a precedent satisfying as many folks=
 as
>> we can.
>>
>> Cheers,
>> Antoine
>>
>> [0]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/00303=
3.html
>>
>> [1] See scenario 3 :
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/0027=
58.html
>>
>> [2] https://github.com/bitcoin/bitcoin/pull/10823#issuecomment-466485121
>>
>> [3] And the LN ecosystem does have an interest to fix zero-confs
>> security, if "turbo-channels"-like become normalized for mobile nodes
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

--000000000000f15e1205d3844f22
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; we might start with 60 seconds, and then double every=
 release till we get<br>to 600 at which point we disable it.<br><br>This is=
 clearly new. However, I&#39;m not sure if it&#39;s solving multi-party fun=
ding transaction DoS, which was of the motivation to propose to deprecate o=
pt-in RBF. The malicious counterparty can broadcast its low-feerate, opt-ou=
t spending of its own collateral input far before to engage in the cooperat=
ive funding. <br><br>When the funding transaction starts to propagate, the =
opt-out has been &quot;first seen&quot; for a while, the replaceability is =
turned off, the honest funding is bounced off ?<br><br><br>Taking opportuni=
ty to laid out another proposal which has whispered to me offline :<br><br>=
&quot;(what) if the nversion of outputs (which is set by their creating tra=
nsaction) were inspected and<br>triggered any spend of the output to be req=
uired to be flagged to be replaceable-- as a standardness rule?&quot;<br><b=
r>While working to solve the DoS, I believe this approach is introducing an=
 overhead cost in the funding of multi-party transactions, as from now on, =
you have to sanitize your collateral inputs by sending them first to a repl=
aceable nVersion outputs ? (iirc, this is done by Lightning Pool, where you=
 have a first step where the inputs are locked in a 2-of-2 with the orchest=
er before to engage in the batch execution tx).<br><br>Current state of the=
 discussion is to introduce a `fullrbf` config-knob turned to false, see mo=
re context here : <a href=3D"https://gnusha.org/bitcoin-core-dev/2021-10-21=
.log">https://gnusha.org/bitcoin-core-dev/2021-10-21.log</a>. Proposing an =
implementation soon.<br><br>Antoine<br></div><br><div class=3D"gmail_quote"=
><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0sam. 18 d=C3=A9c. 2021 =C3=
=A0=C2=A011:51, Jeremy &lt;<a href=3D"mailto:jlrubin@mit.edu">jlrubin@mit.e=
du</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Small i=
dea:</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)">ease into getting rid of full-rbf by keeping the flag work=
ing, but make enforcement of non-replaceability something that happens n se=
conds after first seen.</div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)">this reduces the ability to partition t=
he mempools by broadcasting irreplaceable=C2=A0conflicts all at once, and s=
lowly eases clients off of relying on non-RBF.</div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">we might start w=
ith 60 seconds, and then double every release till we get to 600 at which p=
oint we disable it.</div><div><div dir=3D"ltr"><div dir=3D"ltr">--<br><a hr=
ef=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a=
 href=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div=
></div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">On Tue, Jun 15, 2021 at 10:00 AM Antoine Riard via bitcoin-dev &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi,<br><br>I&=
#39;m writing to propose deprecation of opt-in RBF in favor of full-RBF as =
the Bitcoin Core&#39;s default replacement policy in version 24.0. As a rem=
inder, the next release is 22.0, aimed for August 1st, assuming agreement i=
s reached, this policy change would enter into deployment phase a year from=
 now. <br><br>Even if this replacement policy has been deemed as highly con=
troversial a few years ago, ongoing and anticipated changes in the Bitcoin =
ecosystem are motivating this proposal.<br><br># RBF opt-out as a DoS Vecto=
r against Multi-Party Funded Transactions<br><br>As explained in &quot;On M=
empool Funny Games against Multi-Party Funded Transactions&#39;&#39;, 2nd i=
ssue [0], an attacker can easily DoS a multi-party funded transactions by p=
ropagating an RBF opt-out double-spend of its contributed input before the =
honest transaction is broadcasted by the protocol orchester. DoSes are qual=
ified in the sense of either an attacker wasting timevalue of victim&#39;s =
inputs or forcing exhaustion of the fee-bumping =C2=A0reserve.<br><br>This =
affects a series of Bitcoin protocols such as Coinjoin, onchain DLCs and du=
al-funded LN channels. As those protocols are still in the early phase of d=
eployment, it doesn&#39;t seem to have been executed in the wild for now.=
=C2=A0 That said, considering that dual-funded are more efficient from a li=
quidity standpoint, we can expect them to be widely relied on, once Lightni=
ng enters in a more mature phase. At that point, it should become economica=
lly rational for liquidity service providers to launch those DoS attacks ag=
ainst their competitors to hijack user traffic.<br><br>Beyond that, presenc=
e of those DoSes will complicate the design and deployment of multi-party B=
itcoin protocols such as payment pools/multi-party channels. Note, Lightnin=
g Pool isn&#39;t affected as there is a preliminary stage where batch parti=
cipants are locked-in their funds within an account witnessScript shared wi=
th the orchestrer.<br><br>Of course, even assuming full-rbf, propagation of=
 the multi-party funded transactions can still be interfered with by an att=
acker, simply broadcasting a double-spend with a feerate equivalent to the =
honest transaction. However, it tightens the attack scenario to a scorched =
earth approach, where the attacker has to commit equivalent fee-bumping res=
erve to maintain the pinning and might lose the &quot;competing&quot; fees =
to miners.<br><br># RBF opt-out as a Mempools Partitions Vector<br><br>A lo=
nger-term issue is the risk of mempools malicious partitions, where an atta=
cker exploits network topology or divergence in mempools policies to partit=
ion network mempools in different subsets. From then a wide range of attack=
s can be envisioned such as package pinning [1], artificial congestion to p=
rovoke LN channels closure or manipulation of fee-estimator&#39;s feerate (=
the Core&#39;s one wouldn&#39;t be affected as it relies on block confirmat=
ion, though other fee estimators designs deployed across the ecosystem are =
likely going to be affected).<br><br>Traditionally, mempools partitions hav=
e been gauged as a spontaneous outcome of a distributed systems like Bitcoi=
n p2p network and I&#39;m not aware it has been studied in-depth for advers=
arial purposes. Though, deployment of second-layer<br>protocols, heavily re=
lying on sanity of a local mempool for fee-estimation and robust propagatio=
n of their time-sensitive transactions might lead to reconsider this positi=
on. Acknowledging this, RBF opt-out is a low-cost partitioning tool, of whi=
ch the existence nullifies most of potential progresses to mitigate malicio=
us partitioning.<br><br><br>To resume, opt-in RBF doesn&#39;t suit well dep=
loyment of robust second-layers protocol, even if those issues are still ea=
rly and deserve more research. At the same time, I believe a meaningful sub=
set of the ecosystem =C2=A0are still relying<br>on 0-confs transactions, ev=
en if their security is relying on far weaker assumptions (opt-in RBF rule =
is a policy rule, not a consensus one) [2] A rapid change of Core&#39;s mem=
pool rules would be harming their quality of services and should be<br>weig=
hed carefully. On the other hand, it would be great to nudge them towards m=
ore secure handling of their 0-confs flows [3]<br><br>Let&#39;s examine wha=
t could be deployed ecosystem-wise as enhancements to the 0-confs security =
model.<br><br># Proactive security models : Double-spend Monitoring/Receive=
r-side Fee-Topping with Package Relay<br><br>From an attacker viewpoint, op=
t-in RBF isn&#39;t a big blocker to successful double-spends. Any motivated=
 attacker can modify Core to mass-connect to a wide portion of the network,=
 announce txA to this subset, announce txA&#39; to the<br>merchant. TxA&#39=
; propagation will be encumbered by the privacy-preserving inventory timers=
 (`OUTBOUND_INVENTORY_BROADCAST_INTERVAL`), of which an attacker has no car=
e to respect.<br><br>To detect a successful double-spend attempt, a Bitcoin=
 service should run few full-nodes with well-spread connection graphs and u=
nlinkable between them, to avoid being identified then maliciously partitio=
ned from the rest of the network.<br><br>I believe this tactic is already d=
eployed by few Bitcoin services, and even one can throw flame at it because=
 it over consumes network resources (bandwidth, connection slots, ...), it =
does procure a security advantage to the ones doing it.<br><br>One further =
improvement on top of this protection could be to react after the double-sp=
end detection by attaching a CPFP to the merchant transaction, with a highe=
r package feerate than the double-spend. Expected deployment of package-rel=
ay as a p2p mechanism/mempool policy in Bitcoin Core should enable it to do=
 so.<br><br># Reactive security models : EconomicReputation-based Compensat=
ions<br><br>Another approach could be to react after the fact if a double-s=
pend has been qualified. If the sender is already known to the service prov=
ider, the service account can be slashed.=C2=A0 If the sender is a low-trus=
ted counterparty to the merchant, &quot;side-trust&quot; models could be re=
lied on. For e.g a LN pubkey with a stacked reputation from your autopilot,=
 LSATs, stake certificates, a HTLC-as-a-fidelity-bond, ... The space is qui=
te wide there but I foresee those trust-minimized, decentralized solutions =
being adopted by the LN ecosystem to patch the risks when you enter in a ch=
annel/HTLC operation with an anonymous counterparty. <br><br></div><div>Wha=
t other cool new tools could be considered to enhance 0-confs security ?<br=
></div><div><br>To conclude, let&#39;s avoid replaying the contentious thre=
ads of a few years ago. What this new thread highlights is the fact that a =
transaction relay/mempool acceptance policy might be beneficial to some cla=
ss of already-deployed <br>Bitcoin applications while being detrimental to =
newer ones. How do we preserve the current interests of 0-confs users while=
 enabling upcoming interests of fancy L2s to flourish is a good conversatio=
n to have. I think.<br><br>If there is ecosystem agreement on switching to =
full-RBF, but 0.24 sounds too early, let&#39;s defer it to 0.25 or 0.26. I =
don&#39;t think Core has a consistent deprecation process w.r.t to policy r=
ules heavily relied-on by Bitcoin users, if we do so let sets a precedent s=
atisfying as many folks as we can.<br><br>Cheers,<br>Antoine<br><br>[0] <a =
href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/=
003033.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/=
lightning-dev/2021-May/003033.html</a><br><br>[1] See scenario 3 : <a href=
=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002=
758.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/lig=
htning-dev/2020-June/002758.html</a><br><br>[2] <a href=3D"https://github.c=
om/bitcoin/bitcoin/pull/10823#issuecomment-466485121" target=3D"_blank">htt=
ps://github.com/bitcoin/bitcoin/pull/10823#issuecomment-466485121</a><br><b=
r></div>[3] And the LN ecosystem does have an interest to fix zero-confs se=
curity, if &quot;turbo-channels&quot;-like become normalized for mobile nod=
es<br></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>

--000000000000f15e1205d3844f22--