MIME-Version: 1.0
References: <CALZpt+F2b3tdu1+kLZiBPCH2O-pDzZytoRFtX6X0a8UX4OBrDQ@mail.gmail.com>
 <CAGpPWDbpg=sLN9rNze+mYaWP=0_Q64neh-Hj1V-=vU6NdEr__Q@mail.gmail.com>
In-Reply-To: <CAGpPWDbpg=sLN9rNze+mYaWP=0_Q64neh-Hj1V-=vU6NdEr__Q@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Fri, 18 Jun 2021 06:28:45 +0800
Message-ID: <CAB3F3DtTh7CxGK426MvT0frPPW2kLkPqqDMkaGRt2fac7W5Dtw@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000009c6ad705c4fdbb28"
Subject: Re: [bitcoin-dev] Proposal: Full-RBF in Bitcoin Core 24.0
Precedence: list

--0000000000009c6ad705c4fdbb28
Content-Type: text/plain; charset="UTF-8"

Transaction analysis tools do take the signal into account, but I'm unsure
if retail, non-custodial wallets use this information.

Historically the biggest pushback has been from services like Bitrefill
which have had quite a bit of success with 0-conf payments, but perhaps LN
adoption is at a point where it's less of an impact?

On Fri, Jun 18, 2021 at 4:15 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Russel O'Connor recently opined
> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019061.html>
> that RBF should be standard treatment of all transactions, rather than as a
> transaction opt-in/out. I agree with that. Any configuration in a
> transaction that has not been committed into a block yet simply can't be
> relied upon. Miners also have a clear incentive to ignore RBF rules and
> mine anything that passes consensus. At best opting out of RBF is a weak
> defense, and at worst it's simply a false sense of security that is likely
> to actively lead to theft events.
>
> Do we as a community want to support 0-conf payments in any way at this
> point? It seems rather silly to make software design decisions to
> accommodate 0-conf payments when there are better mechanisms for fast
> payments (ie lightning).
>
> One question I have is: how does software generally inform the user about
> 0-conf payment detection? Does software generally tell the user something
> along the lines of "This payment has not been finalized yet. All recipients
> should wait until the transaction has at least 1 confirmation, and most
> recipients should wait for 6 confirmations" ? I think unless we pressure
> software to be very explicit about what counts as finality, users will
> simply continue to do what they've always done. Rolling out this policy
> change over the course of a year or two seems fine, no need to rush. But I
> suppose it would depend on how often 0-conf is used in the bitcoin
> ecosystem at this point, which I don't have any data on.
>
> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">Transaction analysis tools do take the signal into account=
, but I&#39;m unsure if retail, non-custodial wallets use this information.=
<div><br></div><div>Historically the biggest pushback has been from service=
s like Bitrefill which have had quite a bit of success with 0-conf payments=
, but perhaps LN adoption is at a point where it&#39;s less of an impact?</=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Fri, Jun 18, 2021 at 4:15 AM Billy Tetrud via bitcoin-dev &lt;<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxf=
oundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr">Russel O&#39;Connor <a href=3D"https://lists.=
linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019061.html" target=3D"=
_blank">recently opined</a> that RBF should=C2=A0be standard treatment of a=
ll transactions, rather than as a transaction opt-in/out. I agree with that=
. Any configuration in a transaction that has not been committed into a blo=
ck yet simply can&#39;t be relied upon. Miners also have a clear incentive =
to ignore RBF rules and mine anything that passes consensus. At best opting=
 out of RBF is a weak defense, and at worst it&#39;s simply a false sense o=
f security that is likely to actively=C2=A0lead to theft events.=C2=A0<br><=
div><br></div><div>Do we as a community want to support 0-conf payments in =
any way at this point? It seems rather silly=C2=A0to make software design d=
ecisions to accommodate=C2=A00-conf payments when there are better mechanis=
ms for fast payments (ie lightning).=C2=A0</div><div><br></div><div>One que=
stion I have is: how does software generally inform the user about 0-conf p=
ayment detection? Does software generally tell the user something along the=
 lines of &quot;This payment has not been finalized yet. All recipients sho=
uld wait until the transaction has at least 1 confirmation, and most recipi=
ents should wait for 6 confirmations&quot; ? I think unless we pressure sof=
tware to be very explicit about what counts as finality, users will simply =
continue to do what they&#39;ve always done. Rolling out this policy change=
 over the course of a year or two seems fine, no need to rush. But I suppos=
e it would depend on how often 0-conf is used in the bitcoin ecosystem at t=
his point, which I don&#39;t have any data on.=C2=A0</div></div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jun 15, 2=
021 at 10:00 AM Antoine Riard via bitcoin-dev &lt;<a href=3D"mailto:bitcoin=
-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><div>Hi,<br><br>I&#39;m writing to propose dep=
recation of opt-in RBF in favor of full-RBF as the Bitcoin Core&#39;s defau=
lt replacement policy in version 24.0. As a reminder, the next release is 2=
2.0, aimed for August 1st, assuming agreement is reached, this policy chang=
e would enter into deployment phase a year from now. <br><br>Even if this r=
eplacement policy has been deemed as highly controversial a few years ago, =
ongoing and anticipated changes in the Bitcoin ecosystem are motivating thi=
s proposal.<br><br># RBF opt-out as a DoS Vector against Multi-Party Funded=
 Transactions<br><br>As explained in &quot;On Mempool Funny Games against M=
ulti-Party Funded Transactions&#39;&#39;, 2nd issue [0], an attacker can ea=
sily DoS a multi-party funded transactions by propagating an RBF opt-out do=
uble-spend of its contributed input before the honest transaction is broadc=
asted by the protocol orchester. DoSes are qualified 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 dual-funded LN channels. As th=
ose protocols are still in the early phase of deployment, it doesn&#39;t se=
em to have been executed in the wild for now.=C2=A0 That said, considering =
that dual-funded are more efficient from a liquidity standpoint, we can exp=
ect them to be widely relied on, once Lightning enters in a more mature pha=
se. At that point, it should become economically rational for liquidity ser=
vice providers to launch those DoS attacks against their competitors to hij=
ack user traffic.<br><br>Beyond that, presence of those DoSes will complica=
te the design and deployment of multi-party Bitcoin protocols such as payme=
nt pools/multi-party channels. Note, Lightning Pool isn&#39;t affected as t=
here is a preliminary stage where batch participants are locked-in their fu=
nds within an account witnessScript shared with the orchestrer.<br><br>Of c=
ourse, even assuming full-rbf, propagation of the multi-party funded transa=
ctions can still be interfered with by an attacker, simply broadcasting a d=
ouble-spend with a feerate equivalent to the honest transaction. However, i=
t tightens the attack scenario to a scorched earth approach, where the atta=
cker has to commit equivalent fee-bumping reserve to maintain the pinning a=
nd might lose the &quot;competing&quot; fees to miners.<br><br># RBF opt-ou=
t as a Mempools Partitions Vector<br><br>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 differ=
ent subsets. From then a wide range of attacks can be envisioned such as pa=
ckage 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 estimato=
rs designs deployed across the ecosystem are likely going to be affected).<=
br><br>Traditionally, mempools partitions have been gauged as a spontaneous=
 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, deploy=
ment of second-layer<br>protocols, heavily relying on sanity of a local mem=
pool for fee-estimation and robust propagation of their time-sensitive tran=
sactions might lead to reconsider this position. Acknowledging this, RBF op=
t-out is a low-cost partitioning tool, of which the existence nullifies mos=
t of potential progresses to mitigate malicious partitioning.<br><br><br>To=
 resume, opt-in RBF doesn&#39;t suit well deployment of robust second-layer=
s protocol, even if those issues are still early and deserve more research.=
 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 relyin=
g on far weaker assumptions (opt-in RBF rule is a policy rule, not a consen=
sus one) [2] A rapid change of Core&#39;s mempool rules would be harming th=
eir quality of services and should be<br>weighed carefully. On the other ha=
nd, it would be great to nudge them towards more secure handling of their 0=
-confs flows [3]<br><br>Let&#39;s examine what could be deployed ecosystem-=
wise as enhancements to the 0-confs security model.<br><br># Proactive secu=
rity models : Double-spend Monitoring/Receiver-side Fee-Topping with Packag=
e Relay<br><br>From an attacker viewpoint, opt-in RBF isn&#39;t a big block=
er to successful double-spends. Any motivated attacker can modify Core to m=
ass-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 encumber=
ed by the privacy-preserving inventory timers (`OUTBOUND_INVENTORY_BROADCAS=
T_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-n=
odes with well-spread connection graphs and unlinkable between them, to avo=
id being identified then maliciously partitioned from the rest of the netwo=
rk.<br><br>I believe this tactic is already deployed by few Bitcoin service=
s, and even one can throw flame at it because it over consumes network reso=
urces (bandwidth, connection slots, ...), it does procure a security advant=
age to the ones doing it.<br><br>One further improvement on top of this pro=
tection could be to react after the double-spend detection by attaching a C=
PFP to the merchant transaction, with a higher package feerate than the dou=
ble-spend. Expected deployment of package-relay as a p2p mechanism/mempool =
policy in Bitcoin Core should enable it to do so.<br><br># Reactive securit=
y models : EconomicReputation-based Compensations<br><br>Another approach c=
ould be to react after the fact if a double-spend has been qualified. If th=
e sender is already known to the service provider, the service account can =
be slashed.=C2=A0 If the sender is a low-trusted counterparty to the mercha=
nt, &quot;side-trust&quot; models could be relied on. For e.g a LN pubkey w=
ith a stacked reputation from your autopilot, LSATs, stake certificates, a =
HTLC-as-a-fidelity-bond, ... The space is quite wide there but I foresee th=
ose trust-minimized, decentralized solutions being adopted by the LN ecosys=
tem to patch the risks when you enter in a channel/HTLC operation with an a=
nonymous counterparty. <br><br></div><div>What other cool new tools could b=
e considered to enhance 0-confs security ?<br></div><div><br>To conclude, l=
et&#39;s avoid replaying the contentious threads of a few years ago. What t=
his new thread highlights is the fact that a transaction relay/mempool acce=
ptance policy might be beneficial to some class of already-deployed <br>Bit=
coin applications while being detrimental to newer ones. How do we preserve=
 the current interests of 0-confs users while enabling upcoming interests o=
f 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 sounds too =
early, let&#39;s defer it to 0.25 or 0.26. I don&#39;t think Core has a con=
sistent deprecation process w.r.t to policy rules heavily relied-on by Bitc=
oin 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.linuxfou=
ndation.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.linuxfoundati=
on.org/pipermail/lightning-dev/2020-June/002758.html" target=3D"_blank">htt=
ps://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.htm=
l</a><br><br>[2] <a href=3D"https://github.com/bitcoin/bitcoin/pull/10823#i=
ssuecomment-466485121" target=3D"_blank">https://github.com/bitcoin/bitcoin=
/pull/10823#issuecomment-466485121</a><br><br></div>[3] And the LN ecosyste=
m does have an interest to fix zero-confs security, if &quot;turbo-channels=
&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>
_______________________________________________<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>

--0000000000009c6ad705c4fdbb28--