path: root/78/90722812bfc04b118a9078aefc766f6b2a2b4a

Return-Path: <jlrubin@mit.edu>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 99C82C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 19:00:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 71A7C4037A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 19:00:19 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level: 
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id UKHgv35mZFR5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 19:00:16 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 968E94036D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 19:00:16 +0000 (UTC)
Received: from mail-io1-f49.google.com (mail-io1-f49.google.com
 [209.85.166.49]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 15QJ0EgU030572
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 26 Jun 2021 15:00:14 -0400
Received: by mail-io1-f49.google.com with SMTP id a6so16809438ioe.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Jun 2021 12:00:14 -0700 (PDT)
X-Gm-Message-State: AOAM531egv6ZLheJg9TqLp0RIBsw2TVAYUISpcnDjj9DiaMCPLGg5zZv
 +TvS4fTEctH/fmaNPGznbs59GS8dG5z61cJBrZw=
X-Google-Smtp-Source: ABdhPJzF0aJZKz84JTclWqLznIyifh40L6HTrtRRAMUQex7RrNfYK6xYKW8fdzGyrzO70pGZtX6zVIbJZ/8nnsajYPg=
X-Received: by 2002:a05:6602:737:: with SMTP id
 g23mr2228874iox.49.1624734014104; 
 Sat, 26 Jun 2021 12:00:14 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+F2b3tdu1+kLZiBPCH2O-pDzZytoRFtX6X0a8UX4OBrDQ@mail.gmail.com>
 <CAGpPWDbpg=sLN9rNze+mYaWP=0_Q64neh-Hj1V-=vU6NdEr__Q@mail.gmail.com>
 <CALZpt+FuoVPt_GeT6_MSSpTJ9H1XqqVzDmviYcdJF_AuRNQTfA@mail.gmail.com>
 <CAGpPWDZDhusi0Dq_LLmvXG=Ef6fUX4Xw_7DTBTWiGgDwxBQ_AQ@mail.gmail.com>
In-Reply-To: <CAGpPWDZDhusi0Dq_LLmvXG=Ef6fUX4Xw_7DTBTWiGgDwxBQ_AQ@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Sat, 26 Jun 2021 12:00:02 -0700
X-Gmail-Original-Message-ID: <CAD5xwhiH19VYNQoT03JNfgetRcU82cEW1sR2CmatRKoQ7jWoCA@mail.gmail.com>
Message-ID: <CAD5xwhiH19VYNQoT03JNfgetRcU82cEW1sR2CmatRKoQ7jWoCA@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c3ec8405c5afddc7"
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: Sat, 26 Jun 2021 19:00:19 -0000

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

If the parties trust each other, rbf is still opt-in. Just don't do it?

On Sat, Jun 26, 2021, 9:30 AM Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> >  services providers are offering zero-conf channels, where you can star=
t
> to spend instantly [0]. I believe that's an interesting usage
>
> I agree those are interesting and useful cases. I suppose I should clarif=
y
> that when I asked if bitcoin should continue supporting 0-conf
> transactions, I meant: should we make design decisions based on whether i=
t
> makes raw 0-conf transactions more or less difficult to double spend on? =
I
> do think 0-conf transactions can be useful in situations where there is
> some level of trust (either direct trust between the interacting parties,
> or disperse trust that most people won't try to double spend, perhaps
> because the transaction is small or their identity is tied to it). Fideli=
ty
> bonds sound like an interesting way to mitigate sybil attacks in a
> reputation system.
>
> On Thu, Jun 24, 2021 at 5:23 PM Antoine Riard <antoine.riard@gmail.com>
> wrote:
>
>> > Do we as a community want to support 0-conf payments in any way at thi=
s
>> > 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).
>>
>> Well, we have zero-conf LN channels ? Actually, Lightning channel fundin=
g
>> transactions should be buried under a few blocks, though few services
>> providers are offering zero-conf channels, where you can start to spend
>> instantly [0]. I believe that's an interesting usage, though IMHO as
>> mentioned we can explore different security models to make 0-conf safe
>> (reputation/fidelity-bond).
>>
>> > One question I have is: how does software generally inform the user
>> about
>> 0-conf payment detection?
>>
>> Yes generally it's something like an "Unconfirmed" annotation on incomin=
g
>> txn, though at least this is what Blockstream Green or Electrum are doin=
g.
>>
>> > 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.
>>
>> There are few Bitcoin services well-known to rely on 0-conf. Beyond how
>> much of the Bitcoin traffic is tied to a 0-conf is a hard question, a lo=
t
>> of 0-confs service providers are going to be reluctant to share the
>> information, for a really good reason you will learn a subset of their
>> business volumes.
>>
>> I'll see if I can come up with some Fermi estimation on this front.
>>
>> [0] https://www.bitrefill.com/thor-turbo-channels/
>>
>> Le mer. 16 juin 2021 =C3=A0 20:58, Billy Tetrud <billy.tetrud@gmail.com>=
 a
>> =C3=A9crit :
>>
>>> Russel O'Connor recently opined
>>> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/0190=
61.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 b=
e
>>> 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 wea=
k
>>> defense, and at worst it's simply a false sense of security that is lik=
ely
>>> 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 confirmatio=
n,
>>> and most recipients should wait for 6 confirmations" ? I think unless w=
e
>>> pressure software to be very explicit about what counts as finality, us=
ers
>>> 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 r=
ush.
>>> But I suppose it would depend on how often 0-conf is used in the bitcoi=
n
>>> 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 p=
hase
>>>> a year from now.
>>>>
>>>> Even if this replacement policy has been deemed as highly controversia=
l
>>>> a few years ago, ongoing and anticipated changes in the Bitcoin ecosys=
tem
>>>> 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-part=
y
>>>> 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 atta=
cker
>>>> 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 beco=
me
>>>> 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 the=
re 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, simpl=
y
>>>> broadcasting a double-spend with a feerate equivalent to the honest
>>>> transaction. However, it tightens the attack scenario to a scorched ea=
rth
>>>> approach, where the attacker has to commit equivalent fee-bumping rese=
rve
>>>> 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, wher=
e
>>>> an attacker exploits network topology or divergence in mempools polici=
es to
>>>> partition network mempools in different subsets. From then a wide rang=
e 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 rel=
ies
>>>> on block confirmation, though other fee estimators designs deployed ac=
ross
>>>> 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, deploym=
ent
>>>> of second-layer
>>>> protocols, heavily relying on sanity of a local mempool for
>>>> fee-estimation and robust propagation of their time-sensitive transact=
ions
>>>> might lead to reconsider this position. Acknowledging this, RBF opt-ou=
t 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 deser=
ve
>>>> 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 qual=
ity
>>>> 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 su=
bset,
>>>> announce txA' to the
>>>> merchant. TxA' propagation will be encumbered by the privacy-preservin=
g
>>>> inventory timers (`OUTBOUND_INVENTORY_BROADCAST_INTERVAL`), of which a=
n
>>>> 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 f=
rom
>>>> 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 resour=
ces
>>>> (bandwidth, connection slots, ...), it does procure a security advanta=
ge 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. Expe=
cted
>>>> deployment of package-relay as a p2p mechanism/mempool policy in Bitco=
in
>>>> 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 ha=
s
>>>> 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 t=
here
>>>> but I foresee those trust-minimized, decentralized solutions being ado=
pted
>>>> by the LN ecosystem to patch the risks when you enter in a channel/HTL=
C
>>>> 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 transact=
ion
>>>> 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 upcomin=
g
>>>> interests of fancy L2s to flourish is a good conversation to have. I t=
hink.
>>>>
>>>> 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 h=
as 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 fol=
ks as
>>>> we can.
>>>>
>>>> Cheers,
>>>> Antoine
>>>>
>>>> [0]
>>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003=
033.html
>>>>
>>>> [1] See scenario 3 :
>>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/00=
2758.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
>

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

<div dir=3D"auto">If the parties trust each other, rbf is still opt-in. Jus=
t don&#39;t do it?</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Sat, Jun 26, 2021, 9:30 AM Billy Tetrud via bitcoin-de=
v &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@=
lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">&gt;=C2=A0

services providers are offering zero-conf channels, where you can start to =
spend instantly [0]. I believe that&#39;s an interesting usage<div><br></di=
v><div>I agree those are interesting and useful cases. I suppose I should c=
larify that when I asked if bitcoin should continue supporting 0-conf trans=
actions, I meant: should we make design decisions based on whether it makes=
 raw 0-conf transactions more or less difficult to double spend on? I do th=
ink 0-conf transactions=C2=A0can be useful in situations where there is som=
e level of trust (either direct trust between the interacting parties, or d=
isperse trust that most people won&#39;t try to double spend, perhaps becau=
se the transaction is small or their identity is tied to it). Fidelity bond=
s sound like an interesting way to mitigate=C2=A0sybil attacks in a reputat=
ion system.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Thu, Jun 24, 2021 at 5:23 PM Antoine Riard &lt;<a href=
=3D"mailto:antoine.riard@gmail.com" target=3D"_blank" rel=3D"noreferrer">an=
toine.riard@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr">&gt; Do we as a community want to sup=
port 0-conf payments in any way at this<br>&gt; point? It seems rather sill=
y to make software design decisions to<br>&gt; accommodate 0-conf payments =
when there are better mechanisms for fast<br>&gt; payments (ie lightning).<=
br><br>Well, we have zero-conf LN channels ? Actually, Lightning channel fu=
nding transactions should be buried under a few blocks, though few services=
 providers are offering zero-conf channels, where you can start to spend in=
stantly [0]. I believe that&#39;s an interesting usage, though IMHO as ment=
ioned we can explore different security models to make 0-conf safe (reputat=
ion/fidelity-bond).<br><br>&gt; One question I have is: how does software g=
enerally inform the user about<br>0-conf payment detection?<br><br>Yes gene=
rally it&#39;s something like an &quot;Unconfirmed&quot; annotation on inco=
ming txn, though at least this is what Blockstream Green or Electrum are do=
ing.<br><br>&gt; But I<br>suppose it would depend on how often 0-conf is us=
ed in the bitcoin<br>ecosystem at this point, which I don&#39;t have any da=
ta on.<br><br>There are few Bitcoin services well-known to rely on 0-conf. =
Beyond how much of the Bitcoin traffic is tied to a 0-conf is a hard questi=
on, a lot of 0-confs service providers are going to be reluctant to share t=
he information, for a really good reason you will learn a subset of their b=
usiness volumes.<br><br>I&#39;ll see if I can come up with some Fermi estim=
ation on this front.<br><br>[0] <a href=3D"https://www.bitrefill.com/thor-t=
urbo-channels/" target=3D"_blank" rel=3D"noreferrer">https://www.bitrefill.=
com/thor-turbo-channels/</a><br></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer. 16 juin 2021 =C3=A0=C2=A020:58=
, Billy Tetrud &lt;<a href=3D"mailto:billy.tetrud@gmail.com" target=3D"_bla=
nk" rel=3D"noreferrer">billy.tetrud@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-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" rel=3D"noreferrer">rec=
ently opined</a> that RBF should=C2=A0be standard treatment of all transact=
ions, rather than as a transaction opt-in/out. I agree with that. Any confi=
guration in a transaction that has not been committed into a block yet simp=
ly can&#39;t be relied upon. Miners also have a clear incentive to ignore R=
BF 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 of security =
that is likely to actively=C2=A0lead to theft events.=C2=A0<br><div><br></d=
iv><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 decisions to=
 accommodate=C2=A00-conf payments when there are better mechanisms for fast=
 payments (ie lightning).=C2=A0</div><div><br></div><div>One question I hav=
e is: how does software generally inform the user about 0-conf payment dete=
ction? Does software generally tell the user something along the lines of &=
quot;This payment has not been finalized yet. All recipients should wait un=
til the transaction has at least 1 confirmation, and most recipients should=
 wait for 6 confirmations&quot; ? I think unless we pressure software 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 c=
ourse 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&#39;t have any data on.=C2=A0</div></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jun 15, 2021 at 10:0=
0 AM Antoine Riard via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists=
.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"ltr"><div>Hi,<br><br>I&#39;m writing to pro=
pose 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 reminder, the next rele=
ase is 22.0, aimed for August 1st, assuming agreement is reached, this poli=
cy change would enter into deployment phase a year from now. <br><br>Even i=
f this replacement policy has been deemed as highly controversial a few yea=
rs ago, ongoing and anticipated changes in the Bitcoin ecosystem are motiva=
ting this proposal.<br><br># RBF opt-out as a DoS Vector against Multi-Part=
y Funded Transactions<br><br>As explained in &quot;On Mempool Funny Games a=
gainst Multi-Party Funded Transactions&#39;&#39;, 2nd issue [0], an attacke=
r can easily DoS a multi-party funded transactions by propagating an RBF op=
t-out double-spend of its contributed input before the honest transaction i=
s broadcasted by the protocol orchester. DoSes are qualified in the sense o=
f either an attacker wasting timevalue of victim&#39;s inputs or forcing ex=
haustion of the fee-bumping =C2=A0reserve.<br><br>This affects a series of =
Bitcoin protocols such as Coinjoin, onchain DLCs and dual-funded LN channel=
s. As 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, cons=
idering 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 ma=
ture phase. At that point, it should become economically rational for liqui=
dity service providers to launch those DoS attacks against their competitor=
s to hijack user traffic.<br><br>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&#39;t affec=
ted as there is a preliminary stage where batch participants are locked-in =
their funds within an account witnessScript shared with the orchestrer.<br>=
<br>Of course, even assuming full-rbf, propagation of the multi-party funde=
d transactions can still be interfered with by an attacker, simply broadcas=
ting a double-spend with a feerate equivalent to the honest transaction. Ho=
wever, it tightens the attack scenario to a scorched earth approach, where =
the attacker has to commit equivalent fee-bumping reserve to maintain the p=
inning and might lose the &quot;competing&quot; fees to miners.<br><br># RB=
F opt-out 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 i=
n different subsets. From then a wide range of attacks can be envisioned su=
ch as package pinning [1], artificial congestion to provoke LN channels clo=
sure or manipulation of fee-estimator&#39;s feerate (the Core&#39;s one wou=
ldn&#39;t be affected as it relies on block confirmation, though other fee =
estimators designs deployed across the ecosystem are likely going to be aff=
ected).<br><br>Traditionally, mempools partitions have been gauged as a spo=
ntaneous outcome of a distributed systems like Bitcoin p2p network and I&#3=
9;m not aware it has been studied in-depth for adversarial purposes. Though=
, deployment of second-layer<br>protocols, heavily relying on sanity of a l=
ocal mempool for fee-estimation and robust propagation of their time-sensit=
ive transactions might lead to reconsider this position. Acknowledging this=
, RBF opt-out is a low-cost partitioning tool, of which the existence nulli=
fies most of potential progresses to mitigate malicious partitioning.<br><b=
r><br>To resume, opt-in RBF doesn&#39;t suit well deployment of robust seco=
nd-layers protocol, even if those issues are still early and deserve more r=
esearch. 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 h=
arming their quality of services and should be<br>weighed carefully. On the=
 other hand, it would be great to nudge them towards more secure handling o=
f their 0-confs flows [3]<br><br>Let&#39;s examine what could be deployed e=
cosystem-wise as enhancements to the 0-confs security model.<br><br># Proac=
tive security models : Double-spend Monitoring/Receiver-side Fee-Topping wi=
th 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 =
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 care to respect.<br><br>=
To detect a successful double-spend attempt, a Bitcoin service should run f=
ew full-nodes with well-spread connection graphs and unlinkable between the=
m, to avoid being identified then maliciously partitioned from the rest of =
the network.<br><br>I believe this tactic is already deployed by few Bitcoi=
n services, and even one can throw flame at it because it over consumes net=
work resources (bandwidth, connection slots, ...), it does procure a securi=
ty advantage to the ones doing it.<br><br>One further improvement on top of=
 this protection could be to react after the double-spend detection by atta=
ching a CPFP to the merchant transaction, with a higher package feerate tha=
n the double-spend. Expected deployment of package-relay as a p2p mechanism=
/mempool policy in Bitcoin Core should enable it to do so.<br><br># Reactiv=
e security models : EconomicReputation-based Compensations<br><br>Another a=
pproach could be to react after the fact if a double-spend has been qualifi=
ed. If the sender is already known to the service provider, the service acc=
ount can be slashed.=C2=A0 If the sender is a low-trusted counterparty to t=
he merchant, &quot;side-trust&quot; models could be relied on. For e.g a LN=
 pubkey with a stacked reputation from your autopilot, LSATs, stake certifi=
cates, a HTLC-as-a-fidelity-bond, ... The space is quite wide there but I f=
oresee 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. <br><br></div><div>What other cool new tool=
s could be considered to enhance 0-confs security ?<br></div><div><br>To co=
nclude, let&#39;s avoid replaying the contentious threads of a few years ag=
o. What this new thread highlights is the fact that a transaction relay/mem=
pool acceptance policy might be beneficial to some class of already-deploye=
d <br>Bitcoin applications while being detrimental to newer ones. How do we=
 preserve the current interests of 0-confs users while enabling upcoming in=
terests of fancy L2s to flourish is a good conversation to have. I think.<b=
r><br>If there is ecosystem agreement on switching to full-RBF, but 0.24 so=
unds 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-o=
n by Bitcoin users, if we do so let sets a precedent satisfying as many fol=
ks 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" rel=3D"noreferrer">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" rel=3D"noreferrer">https://lists.linuxfoundatio=
n.org/pipermail/lightning-dev/2020-June/002758.html</a><br><br>[2] <a href=
=3D"https://github.com/bitcoin/bitcoin/pull/10823#issuecomment-466485121" t=
arget=3D"_blank" rel=3D"noreferrer">https://github.com/bitcoin/bitcoin/pull=
/10823#issuecomment-466485121</a><br><br></div>[3] And the LN ecosystem doe=
s 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" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000c3ec8405c5afddc7--