MIME-Version: 1.0
References: <CALZpt+F2b3tdu1+kLZiBPCH2O-pDzZytoRFtX6X0a8UX4OBrDQ@mail.gmail.com>
In-Reply-To: <CALZpt+F2b3tdu1+kLZiBPCH2O-pDzZytoRFtX6X0a8UX4OBrDQ@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Sat, 18 Dec 2021 08:51:46 -0800
Message-ID: <CAD5xwhjVkxgu2+M+Ft576GYM6Tv=ZEwtV82v1cLeYaoU5mSRnA@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003964ef05d36e7990"
Subject: Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0
Precedence: list

--0000000000003964ef05d36e7990
Content-Type: text/plain; charset="UTF-8"

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 phase
> 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 attacker
> 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 DLCs
> 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 for
> 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 DoS
> 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 earth
> approach, where the attacker has to commit equivalent fee-bumping reserve
> 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 relies
> on block confirmation, though other fee estimators designs deployed across
> 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 aware
> it has been studied in-depth for adversarial purposes. Though, deployment
> of second-layer
> protocols, heavily relying on sanity of a local mempool for fee-estimation
> and robust propagation of their time-sensitive transactions 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 run
> few full-nodes with well-spread connection graphs and unlinkable between
> them, to avoid being identified then maliciously partitioned from the rest
> 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 resources
> (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 after
> the double-spend detection by attaching a CPFP to the merchant transaction,
> 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. 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 quite 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 channel/HTLC
> operation with an anonymous counterparty.
>
> What other cool new tools could be considered to enhance 0-confs security ?
>
> To conclude, let's avoid replaying the contentious threads 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 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 think.
>
> If there is ecosystem agreement on switching to full-RBF, but 0.24 sounds
> 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 by
> 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/003033.html
>
> [1] See scenario 3 :
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.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
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Small idea:</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:#000000">ease in=
to getting rid of full-rbf by keeping the flag working, but make enforcemen=
t of non-replaceability something that happens n seconds after first seen.<=
/div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00=
0000">this reduces the ability to partition the mempools by broadcasting ir=
replaceable=C2=A0conflicts all at once, and slowly eases clients off of rel=
ying on non-RBF.</div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000">we might start with 60 seconds, and then double ever=
y release till we get to 600 at which point we disable it.</div><div><div d=
ir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><di=
v dir=3D"ltr">--<br><a href=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"gmail_attr">On Tue, Jun 15, 2021 at 10:00 AM Anto=
ine Riard via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoun=
dation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-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 d=
efault 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 c=
hange would enter into deployment phase a year from now. <br><br>Even if th=
is replacement policy has been deemed as highly controversial a few years a=
go, ongoing and anticipated changes in the Bitcoin ecosystem are motivating=
 this proposal.<br><br># RBF opt-out as a DoS Vector against Multi-Party Fu=
nded Transactions<br><br>As explained in &quot;On Mempool Funny Games again=
st Multi-Party Funded Transactions&#39;&#39;, 2nd issue [0], an attacker ca=
n easily DoS a multi-party funded transactions by propagating an RBF opt-ou=
t double-spend of its contributed input before the honest transaction is br=
oadcasted by the protocol orchester. DoSes are qualified in the sense of ei=
ther an attacker wasting timevalue of victim&#39;s inputs or forcing exhaus=
tion of the fee-bumping =C2=A0reserve.<br><br>This affects a series of Bitc=
oin protocols such as Coinjoin, onchain DLCs and dual-funded LN channels. A=
s those protocols are still in the early phase of deployment, it doesn&#39;=
t seem to have been executed in the wild for now.=C2=A0 That said, consider=
ing 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 DoS attacks against their competitors to=
 hijack user traffic.<br><br>Beyond that, presence of those DoSes will comp=
licate the design and deployment of multi-party Bitcoin protocols such as p=
ayment pools/multi-party channels. Note, Lightning Pool isn&#39;t affected =
as there is a preliminary stage where batch participants are locked-in thei=
r funds within an account witnessScript shared with the orchestrer.<br><br>=
Of course, even assuming full-rbf, propagation of the multi-party funded tr=
ansactions can still be interfered with by an attacker, simply broadcasting=
 a double-spend with a feerate equivalent to the honest transaction. Howeve=
r, it tightens the attack scenario to a scorched earth approach, where the =
attacker has to commit equivalent fee-bumping reserve to maintain the pinni=
ng and might lose the &quot;competing&quot; fees to miners.<br><br># RBF op=
t-out as a Mempools Partitions Vector<br><br>A longer-term issue is the ris=
k of mempools malicious partitions, where an attacker exploits network topo=
logy or divergence in mempools policies to partition network mempools in di=
fferent subsets. From then a wide range of attacks can be envisioned such a=
s package pinning [1], artificial congestion to provoke 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 confirmation, though other fee esti=
mators designs deployed across the ecosystem are likely going to be affecte=
d).<br><br>Traditionally, mempools partitions have been gauged as a spontan=
eous outcome of a distributed systems like Bitcoin p2p network and I&#39;m =
not aware it has been studied in-depth for adversarial purposes. Though, de=
ployment of second-layer<br>protocols, heavily relying on sanity of a local=
 mempool for fee-estimation and robust propagation of their time-sensitive =
transactions might lead to reconsider this position. Acknowledging this, RB=
F opt-out is a low-cost partitioning tool, of which the existence nullifies=
 most of potential progresses to mitigate malicious partitioning.<br><br><b=
r>To resume, opt-in RBF doesn&#39;t suit well deployment of robust second-l=
ayers protocol, even if those issues are still early and deserve more resea=
rch. At the same time, I believe a meaningful subset of the ecosystem =C2=
=A0are still relying<br>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&#39;s mempool rules would be harm=
ing their quality of services and should be<br>weighed carefully. On the ot=
her hand, it would be great to nudge them towards more secure handling of t=
heir 0-confs flows [3]<br><br>Let&#39;s examine what could be deployed ecos=
ystem-wise as enhancements to the 0-confs security model.<br><br># Proactiv=
e security models : Double-spend Monitoring/Receiver-side Fee-Topping with =
Package Relay<br><br>From an attacker viewpoint, opt-in RBF isn&#39;t a big=
 blocker to successful double-spends. Any motivated attacker can modify Cor=
e to mass-connect to a wide portion of the network, announce txA to this su=
bset, announce txA&#39; to the<br>merchant. TxA&#39; propagation will be en=
cumbered by the privacy-preserving inventory timers (`OUTBOUND_INVENTORY_BR=
OADCAST_INTERVAL`), of which an attacker has no care 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 unlinkable between them, =
to avoid being identified then maliciously partitioned from the rest of the=
 network.<br><br>I believe this tactic is already deployed by few Bitcoin s=
ervices, and even one can throw flame at it because it over consumes networ=
k resources (bandwidth, connection slots, ...), it does procure a security =
advantage to the ones doing it.<br><br>One further improvement on top of th=
is protection could be to react after the double-spend detection by attachi=
ng a CPFP to the merchant transaction, with a higher package feerate than t=
he double-spend. Expected deployment of package-relay as a p2p mechanism/me=
mpool policy in Bitcoin Core should enable it to do so.<br><br># Reactive s=
ecurity models : EconomicReputation-based Compensations<br><br>Another appr=
oach 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 accoun=
t can be slashed.=C2=A0 If the sender is a low-trusted counterparty to the =
merchant, &quot;side-trust&quot; models could be relied on. For e.g a LN pu=
bkey with a stacked reputation from your autopilot, LSATs, stake certificat=
es, a HTLC-as-a-fidelity-bond, ... The space is quite wide there but I fore=
see those trust-minimized, decentralized solutions being adopted by the LN =
ecosystem to patch the risks when you enter in a channel/HTLC operation wit=
h an anonymous counterparty. <br><br></div><div>What other cool new tools c=
ould be considered to enhance 0-confs security ?<br></div><div><br>To concl=
ude, let&#39;s avoid replaying the contentious threads of a few years ago. =
What this new thread highlights is the fact that a transaction relay/mempoo=
l acceptance policy might be beneficial to some class of already-deployed <=
br>Bitcoin applications while being detrimental to newer ones. How do we pr=
eserve the current interests of 0-confs users while enabling upcoming inter=
ests of fancy L2s to flourish is a good conversation to have. I think.<br><=
br>If there is ecosystem agreement on switching to full-RBF, but 0.24 sound=
s 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 rules heavily relied-on b=
y Bitcoin users, if we do so let sets a precedent satisfying as many folks =
as we can.<br><br>Cheers,<br>Antoine<br><br>[0] <a href=3D"https://lists.li=
nuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html" target=3D"_=
blank">https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/0=
03033.html</a><br><br>[1] See scenario 3 : <a href=3D"https://lists.linuxfo=
undation.org/pipermail/lightning-dev/2020-June/002758.html" target=3D"_blan=
k">https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/0027=
58.html</a><br><br>[2] <a href=3D"https://github.com/bitcoin/bitcoin/pull/1=
0823#issuecomment-466485121" target=3D"_blank">https://github.com/bitcoin/b=
itcoin/pull/10823#issuecomment-466485121</a><br><br></div>[3] And the LN ec=
osystem does have an interest to fix zero-confs security, if &quot;turbo-ch=
annels&quot;-like become normalized for mobile nodes<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>

--0000000000003964ef05d36e7990--