path: root/20/a0b3f030feb792aaa83036b36cd7d80e387f6a

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 A99C9C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Jun 2021 00:23:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 8BF1583BD5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Jun 2021 00:23:16 +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 PIiNslz-u0Bu
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Jun 2021 00:23:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com
 [IPv6:2a00:1450:4864:20::32f])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 7F5A783BD3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Jun 2021 00:23:14 +0000 (UTC)
Received: by mail-wm1-x32f.google.com with SMTP id w13so5135316wmc.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 24 Jun 2021 17:23:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=qgcO5FKe3DqrvPf6sa/gvPa3E9Ro6Lwc8c1mKLkI5kA=;
 b=XkDLe3Q/VDGQrPexjly8t6r3zziTnYKXfAB1B8+Vml2fwlT4hlTIbAGqcHzU5riG2z
 O/NcO4uBYCF2+Mz7ej4fLEDY0HjFotu+RrMkV2Z/zAU+lbFHtDxsKPW02mzLwJfmG4dk
 gz4ctdI/1kZv4kSjipTKuCpbP0sNw5r2qx9WueZQpj2X/bpr6LRMH+k5D/6DQ5Fn+FKd
 YSreripsFXU6UygdC98sZgpnnmNqHvI9gmFB3cXjjlHM25Xq8JN559yddUMQDggRrVlI
 w/4OrbrIqbcjhMV1IXrwOw4z34tWsUaCaY9L/atBWgYj2uFY/zERSWv+mubShjt/VcWp
 dQVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=qgcO5FKe3DqrvPf6sa/gvPa3E9Ro6Lwc8c1mKLkI5kA=;
 b=Juh8jg/FuAiSQKoAd/JGCWn/QZ7WZprmf1HmO2VojB+9aQ3ZGrSY3sgYzhrneFblUL
 6RJFL0ia/92HJespg+VVbIyXvo6gdZWh2TfWB8eWY8AcXef09CkNnfgNpko6to1Yz1+v
 TgwCiInqjOW8KXpGvgbJDIJZ4D/wAwT0vQLZnwwxyTxBAW7m4LgEvpZEhJm0gqeHBQVn
 qT+aJK8lmMTHmyHqqg/l5YHipvbXmOioyZI6nNdUu4fyp+4uAeNIrsyIceJ2hnt1J/pj
 FpBF4iJZXWhefoZ01QsDyfntbggMuM2dNeHkHp3fROzlHbexOndSbvFzSZg/28lkmtte
 TR6A==
X-Gm-Message-State: AOAM532JvwI8TsZqkfQS1Bxe1fFV9SWWia9A4EZ38YWrCxMdcha+31wN
 zEPCWcQlw2naeYAMCXZ9Yp51Ld9KQCe/AMqBNXs=
X-Google-Smtp-Source: ABdhPJw1pt53kFNmvf9wlcOw6Ozpxmp6JfC4Ajbsj3nVkBf8Tsmpvn/M0RD/irKX1tSIfzw3ahAq/iiO4lSZ932U1KI=
X-Received: by 2002:a05:600c:22cf:: with SMTP id
 15mr7293371wmg.177.1624580592742; 
 Thu, 24 Jun 2021 17:23:12 -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>
In-Reply-To: <CAGpPWDbpg=sLN9rNze+mYaWP=0_Q64neh-Hj1V-=vU6NdEr__Q@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Thu, 24 Jun 2021 20:23:01 -0400
Message-ID: <CALZpt+FuoVPt_GeT6_MSSpTJ9H1XqqVzDmviYcdJF_AuRNQTfA@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000023b3ad05c58c2546"
X-Mailman-Approved-At: Fri, 25 Jun 2021 07:29:02 +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: Fri, 25 Jun 2021 00:23:16 -0000

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

> 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).

Well, we have zero-conf LN channels ? Actually, Lightning channel funding
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 incoming
txn, though at least this is what Blockstream Green or Electrum are doing.

> 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 lot
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/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 likel=
y
> 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 recipien=
ts
> 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 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
>>
>

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

<div dir=3D"ltr">&gt; Do we as a community want to support 0-conf payments =
in any way at this<br>&gt; point? It seems rather silly to make software de=
sign 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 funding transactions sh=
ould be buried under a few blocks, though few services providers are offeri=
ng zero-conf channels, where you can start to spend instantly [0]. I believ=
e that&#39;s an interesting usage, though IMHO as mentioned we can explore =
different security models to make 0-conf safe (reputation/fidelity-bond).<b=
r><br>&gt; One question I have is: how does software generally inform the u=
ser about<br>0-conf payment detection?<br><br>Yes generally it&#39;s someth=
ing like an &quot;Unconfirmed&quot; annotation on incoming txn, though at l=
east this is what Blockstream Green or Electrum are doing.<br><br>&gt; But =
I<br>suppose it would depend on how often 0-conf is used in the bitcoin<br>=
ecosystem at this point, which I don&#39;t have any data on.<br><br>There a=
re few Bitcoin services well-known to rely on 0-conf. Beyond how much of th=
e Bitcoin traffic is tied to a 0-conf is a hard question, a lot 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.<br><=
br>I&#39;ll see if I can come up with some Fermi estimation on this front.<=
br><br>[0] <a href=3D"https://www.bitrefill.com/thor-turbo-channels/">https=
://www.bitrefill.com/thor-turbo-channels/</a><br></div><br><div class=3D"gm=
ail_quote"><div dir=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.co=
m">billy.tetrud@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id 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-Jun=
e/019061.html" target=3D"_blank">recently opined</a> that RBF should=C2=A0b=
e 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&#39;t be relied upon. Miners als=
o 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 of 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 su=
pport 0-conf payments in any way at this point? It seems rather silly=C2=A0=
to make software design decisions to accommodate=C2=A00-conf payments when =
there are better mechanisms for fast payments (ie lightning).=C2=A0</div><d=
iv><br></div><div>One question I have is: how does software generally infor=
m the user about 0-conf payment detection? Does software generally tell the=
 user something along the lines of &quot;This payment has not been finalize=
d yet. All recipients should wait until the transaction has at least 1 conf=
irmation, and most recipients should wait for 6 confirmations&quot; ? I thi=
nk unless we pressure software to be very explicit about what counts as fin=
ality, users will simply continue to do what they&#39;ve always done. Rolli=
ng out this policy change over the course of a year or two seems fine, no n=
eed to rush. But I suppose it would depend on how often 0-conf is used in t=
he bitcoin ecosystem at this point, which I don&#39;t have any data on.=C2=
=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma=
il_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"_blank"=
>bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi,<br><br>I&#3=
9;m writing to propose deprecation of opt-in RBF in favor of full-RBF as th=
e Bitcoin Core&#39;s default replacement policy in version 24.0. As a remin=
der, 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 n=
ow. <br><br>Even if this replacement policy has been deemed as highly contr=
oversial a few years ago, ongoing and anticipated changes in the Bitcoin ec=
osystem are motivating this proposal.<br><br># RBF opt-out as a DoS Vector =
against Multi-Party Funded Transactions<br><br>As explained in &quot;On Mem=
pool Funny Games against Multi-Party Funded Transactions&#39;&#39;, 2nd iss=
ue [0], an attacker can easily DoS a multi-party funded transactions by pro=
pagating an RBF opt-out double-spend of its contributed input before the ho=
nest transaction is broadcasted by the protocol orchester. DoSes are qualif=
ied in the sense of either an attacker wasting timevalue of victim&#39;s in=
puts or forcing exhaustion of the fee-bumping =C2=A0reserve.<br><br>This af=
fects 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 dep=
loyment, 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 liqui=
dity 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 again=
st their competitors to hijack user traffic.<br><br>Beyond that, presence o=
f those DoSes will complicate the design and deployment of multi-party Bitc=
oin protocols such as payment pools/multi-party channels. Note, Lightning P=
ool isn&#39;t affected as there is a preliminary stage where batch particip=
ants are locked-in their funds within an account witnessScript shared with =
the orchestrer.<br><br>Of course, even assuming full-rbf, propagation of th=
e multi-party funded transactions can still be interfered with by an attack=
er, simply broadcasting a double-spend with a feerate equivalent to the hon=
est transaction. However, it tightens the attack scenario to a scorched ear=
th approach, where the attacker has to commit equivalent fee-bumping reserv=
e 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 longe=
r-term issue is the risk of mempools malicious partitions, where an attacke=
r exploits network topology or divergence in mempools policies to partition=
 network mempools in different subsets. From then a wide range of attacks c=
an be envisioned such as package pinning [1], artificial congestion to prov=
oke 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 estimators designs deployed across the ecosystem are lik=
ely going to be affected).<br><br>Traditionally, mempools partitions have b=
een gauged as a spontaneous outcome of a distributed systems like Bitcoin p=
2p network and I&#39;m not aware it has been studied in-depth for adversari=
al purposes. Though, deployment of second-layer<br>protocols, heavily relyi=
ng on sanity of a local mempool for fee-estimation and robust propagation o=
f 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.<br><br><br>To resume, opt-in RBF doesn&#39;t suit well deploy=
ment 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 =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 mempoo=
l rules would be harming 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 of their 0-confs flows [3]<br><br>Let&#39;s examine what c=
ould be deployed ecosystem-wise as enhancements to the 0-confs security mod=
el.<br><br># Proactive security models : Double-spend Monitoring/Receiver-s=
ide Fee-Topping with Package Relay<br><br>From an attacker viewpoint, opt-i=
n RBF isn&#39;t a big blocker to successful double-spends. Any motivated at=
tacker can modify Core to mass-connect to a wide portion of the network, an=
nounce txA to this subset, announce txA&#39; to the<br>merchant. TxA&#39; p=
ropagation will be encumbered by the privacy-preserving inventory timers (`=
OUTBOUND_INVENTORY_BROADCAST_INTERVAL`), of which an attacker has no care t=
o respect.<br><br>To detect a successful double-spend attempt, a Bitcoin se=
rvice should run few full-nodes with well-spread connection graphs and unli=
nkable between them, to avoid being identified then maliciously partitioned=
 from the rest of the network.<br><br>I believe this tactic is already depl=
oyed by few Bitcoin services, and even one can throw flame at it because it=
 over consumes network resources (bandwidth, connection slots, ...), it doe=
s procure a security advantage to the ones doing it.<br><br>One further imp=
rovement 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 p=
ackage 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=
.<br><br># Reactive security models : EconomicReputation-based Compensation=
s<br><br>Another approach could be to react after the fact if a double-spen=
d has been qualified. If the sender is already known to the service provide=
r, the service account can be slashed.=C2=A0 If the sender is a low-trusted=
 counterparty to the merchant, &quot;side-trust&quot; models could be relie=
d on. For e.g a LN pubkey with a stacked reputation from your autopilot, LS=
ATs, stake certificates, a HTLC-as-a-fidelity-bond, ... The space is quite =
wide there but I foresee those trust-minimized, decentralized solutions bei=
ng adopted by the LN ecosystem to patch the risks when you enter in a chann=
el/HTLC operation with an anonymous counterparty. <br><br></div><div>What o=
ther cool new tools could be considered to enhance 0-confs security ?<br></=
div><div><br>To conclude, let&#39;s avoid replaying the contentious threads=
 of a few years ago. What this new thread highlights is the fact that a tra=
nsaction relay/mempool acceptance policy might be beneficial to some class =
of already-deployed <br>Bitcoin applications while being detrimental to new=
er ones. How do we preserve the current interests of 0-confs users while en=
abling upcoming interests of fancy L2s to flourish is a good conversation t=
o have. I think.<br><br>If there is ecosystem agreement on switching to ful=
l-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 rule=
s heavily relied-on by Bitcoin users, if we do so let sets a precedent sati=
sfying as many folks as we can.<br><br>Cheers,<br>Antoine<br><br>[0] <a hre=
f=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003=
033.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/lig=
htning-dev/2021-May/003033.html</a><br><br>[1] See scenario 3 : <a href=3D"=
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.=
html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/lightni=
ng-dev/2020-June/002758.html</a><br><br>[2] <a href=3D"https://github.com/b=
itcoin/bitcoin/pull/10823#issuecomment-466485121" target=3D"_blank">https:/=
/github.com/bitcoin/bitcoin/pull/10823#issuecomment-466485121</a><br><br></=
div>[3] And the LN ecosystem does have an interest to fix zero-confs securi=
ty, if &quot;turbo-channels&quot;-like become normalized for mobile nodes<b=
r></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>

--00000000000023b3ad05c58c2546--