path: root/79/7d7a2e6b2e1c4d4b1043adc3027808d6473142

Return-Path: <corey3@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 73F08C0022
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 14:07:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 515A940648
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 14:07:07 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level: 
X-Spam-Status: No, score=-1.849 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 Jmj3tP0Ek-VQ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 14:07:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com
 [IPv6:2607:f8b0:4864:20::b30])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 0D7334017A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 14:07:02 +0000 (UTC)
Received: by mail-yb1-xb30.google.com with SMTP id m9so5190318ybo.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Jun 2021 07:07:02 -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;
 bh=vlQTSWFTdP3jxv9o+cSsEzNdQj4Q5VrsbQlpi1vJDXk=;
 b=piDhLvoSSGgziqzJ44Wr+JbIyDOMq40Y9maDsMUiKMs4NrZrGP2XuswodvbRLZj1ZC
 xBcxcIpFp2MI4ylXlQl5vimEJnxv+nqVNiYwlLq+pEGyYO0dyN4joAphSAqaisTsEGV5
 7c27aQ9xwmhHOckRHpfdpkbxSFIrI2xoqYZkWXz+ObMppQ49l4Dk6BqkyYxkuHYKL69v
 Ftz3bS5jPPsBkgZy70ML3QdJ1BxmPTXjgpb621gpWf+5+G8spi1xWCLvUqC5MPWGD9ab
 wLYiLln4HX2ghGW1q6PT5FhuiEcGsL899kZ4i2hZQ8nfSt11x6SKAmar1+QMN+Br6jNh
 X+2w==
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;
 bh=vlQTSWFTdP3jxv9o+cSsEzNdQj4Q5VrsbQlpi1vJDXk=;
 b=AFkIhDY8ad2DbUVPZmMKcR3B5PROh6u6sMoi7btyFYtycxP48IA5//FDQpsJIy1yWc
 9nYp90aOahvKMlV8VUeTpeYBf+LoSD77aLG1GPTvJu66yXboXIwBi6xQD3sMdYf9aE78
 n5e8hmRIjxtbB5uHqTYeT+B/IVFQIDINaaXLhCPz//n0gKnRdNbznv2m9Kdl4+rqlgeT
 FNgiDYpBk7gXNBl0lLGDrOFwjqB9SODw/hyrO9KFtEa+yVCUz8x/+Fjj/WKRfmP1bw9f
 JlT1Vd/5z7PKCGNUEe5F4gJHiMkPl0S9CT3HcbmYGE+xvwC7kmgcJZ5v13w51Ai/HD98
 ytsw==
X-Gm-Message-State: AOAM532SXWx7kYBJtrPL2p/NaCXb3uomzlxBpCu4pP6ex0VNEgnZXlfP
 0u5dS9btN7EBtQBlK4SYPmysOLORpGqOS7uWqwE=
X-Google-Smtp-Source: ABdhPJy7GuPYeIQhl8IePTxoWRPMBsyrz0nyCrpPu3bLT5rfc8K/pI1trebubY49foN7Z288QWCH7nl0LcBN50Sn7EM=
X-Received: by 2002:a25:348f:: with SMTP id
 b137mr23330677yba.183.1625062021899; 
 Wed, 30 Jun 2021 07:07:01 -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>
 <CAD5xwhiH19VYNQoT03JNfgetRcU82cEW1sR2CmatRKoQ7jWoCA@mail.gmail.com>
In-Reply-To: <CAD5xwhiH19VYNQoT03JNfgetRcU82cEW1sR2CmatRKoQ7jWoCA@mail.gmail.com>
From: Corey Haddad <corey3@gmail.com>
Date: Wed, 30 Jun 2021 10:06:50 -0400
Message-ID: <CAK_HAC8ogK_1aT840_TFScHjVGdyu-ipmb5fqDy+CL-Y_RmfTQ@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000008da7f605c5fc3ce9"
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: Wed, 30 Jun 2021 14:07:07 -0000

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

We cannot prevent people from choosing to take an action based on an
unconfirmed transaction. Even though it is trivial to have a
double-spending transaction confirmed, accepting a 0-conf tx can be
rational in many cases.  0-conf can be interpreted as the customer
signaling their 'intent to pay', and where there is an established
relationship between customer and merchant, or where there merchant is
providing a cancelable e-service, signaling intent may be enough. These use
cases do not depend on making it difficult for the user to attempt to
double-spend the merchant.

Bitcoin is a system designed around a consensus on the blockchain, not the
mempool. I am in favor of providing the spender of bitcoins with all
possible tools and methods to help them submit their transactions -
double-spending or not - to miners for consideration. More than making RBF
the default, I would prefer to see nodes forward any transaction
conflicting transaction, so long as it has a higher fee. Is there a reason
this would be undesirable?

Corey

On Sat, Jun 26, 2021 at 3:00 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
>> start to spend instantly [0]. I believe that's an interesting usage
>>
>> I agree those are interesting and useful cases. I suppose I should
>> clarify that when I asked if bitcoin should continue supporting 0-conf
>> transactions, 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 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). Fidel=
ity
>> 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 th=
is
>>> > 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 Electru=
m
>>> 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 l=
ot
>>> 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/019=
061.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 an=
d
>>>> mine anything that passes consensus. At best opting out of RBF is a we=
ak
>>>> defense, and at worst it's simply a false sense of security that is li=
kely
>>>> to actively lead to theft events.
>>>>
>>>> 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).
>>>>
>>>> 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 confirmati=
on,
>>>> and most recipients should wait for 6 confirmations" ? I think unless =
we
>>>> pressure software to be very explicit about what counts as finality, u=
sers
>>>> 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 bitco=
in
>>>> 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-par=
ty
>>>>> 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 att=
acker
>>>>> 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 wil=
d 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 bec=
ome
>>>>> 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 th=
ere is
>>>>> a preliminary stage where batch participants are locked-in their fund=
s
>>>>> 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, simp=
ly
>>>>> broadcasting a double-spend with a feerate equivalent to the honest
>>>>> transaction. However, it tightens the attack scenario to a scorched e=
arth
>>>>> approach, where the attacker has to commit equivalent fee-bumping res=
erve
>>>>> 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 the=
n 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 re=
lies
>>>>> on block confirmation, though other fee estimators designs deployed a=
cross
>>>>> 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, deploy=
ment
>>>>> of second-layer
>>>>> protocols, heavily relying on sanity of a local mempool for
>>>>> fee-estimation and robust propagation of their time-sensitive transac=
tions
>>>>> might lead to reconsider this position. Acknowledging this, RBF opt-o=
ut is
>>>>> a low-cost partitioning tool, of which the existence nullifies most o=
f
>>>>> 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 dese=
rve
>>>>> 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 qua=
lity
>>>>> 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 t=
o
>>>>> 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 s=
ubset,
>>>>> 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 n=
o 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, an=
d
>>>>> even one can throw flame at it because it over consumes network resou=
rces
>>>>> (bandwidth, connection slots, ...), it does procure a security advant=
age 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. Exp=
ected
>>>>> deployment of package-relay as a p2p mechanism/mempool policy in Bitc=
oin
>>>>> 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 pro=
vider,
>>>>> 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 ad=
opted
>>>>> by the LN ecosystem to patch the risks when you enter in a channel/HT=
LC
>>>>> 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 transac=
tion
>>>>> 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 upcomi=
ng
>>>>> 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-o=
n by
>>>>> Bitcoin users, if we do so let sets a precedent satisfying as many fo=
lks as
>>>>> we can.
>>>>>
>>>>> Cheers,
>>>>> Antoine
>>>>>
>>>>> [0]
>>>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/00=
3033.html
>>>>>
>>>>> [1] See scenario 3 :
>>>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/0=
02758.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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">We cannot=C2=A0prevent people from choosing=C2=A0to take a=
n action based on an unconfirmed=C2=A0transaction. Even though it is trivia=
l to have a double-spending transaction confirmed, accepting a 0-conf tx ca=
n be rational in many cases.=C2=A0<span class=3D"gmail-Apple-converted-spac=
e">=C2=A0</span>0-conf can be interpreted as the customer signaling their &=
#39;intent to pay&#39;, and where there is an established relationship betw=
een customer and merchant, or where there merchant=C2=A0is providing a canc=
elable e-service, signaling intent may be enough. These use cases do not de=
pend on making it difficult for the user to attempt to double-spend the mer=
chant.<div><br></div><div>Bitcoin is a system designed around a consensus=
=C2=A0on the blockchain, not the mempool. I am in favor of providing the sp=
ender of bitcoins with all possible tools and methods to help them submit t=
heir transactions - double-spending or not - to miners for consideration. M=
ore than making RBF the default, I would prefer to see nodes forward=C2=A0a=
ny transaction conflicting transaction, so long as it has a higher fee. Is =
there a reason this would be undesirable?</div><div><br></div><div>Corey</d=
iv></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att=
r">On Sat, Jun 26, 2021 at 3:00 PM Jeremy via bitcoin-dev &lt;<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundati=
on.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;borde=
r-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"auto">If the pa=
rties trust each other, rbf is still opt-in. Just don&#39;t do it?</div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, J=
un 26, 2021, 9:30 AM Billy Tetrud via bitcoin-dev &lt;<a href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.lin=
uxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:s=
olid;border-left-color:rgb(204,204,204);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" rel=3D"noreferrer" target=3D"_blank">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-width:1px;border-left-st=
yle:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr">&gt; Do we as a community want to support 0-conf payments in any way a=
t this<br>&gt; point? It seems rather silly to make software design decisio=
ns 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 should be buri=
ed under a few blocks, though few services providers are offering zero-conf=
 channels, where you can start to spend instantly [0]. I believe that&#39;s=
 an interesting usage, though IMHO as mentioned we can explore different se=
curity models to make 0-conf safe (reputation/fidelity-bond).<br><br>&gt; O=
ne question I have is: how does software generally inform the user about<br=
>0-conf payment detection?<br><br>Yes generally it&#39;s something like an =
&quot;Unconfirmed&quot; annotation on incoming txn, though at least 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 are few Bitco=
in services well-known to rely on 0-conf. Beyond how much of the Bitcoin tr=
affic is tied to a 0-conf is a hard question, a lot of 0-confs service prov=
iders 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/" rel=3D"noreferrer=
" target=3D"_blank">https://www.bitrefill.com/thor-turbo-channels/</a><br><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">L=
e=C2=A0mer. 16 juin 2021 =C3=A0=C2=A020:58, Billy Tetrud &lt;<a href=3D"mai=
lto:billy.tetrud@gmail.com" rel=3D"noreferrer" target=3D"_blank">billy.tetr=
ud@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">Russel O&#39;Connor <a href=3D"https://lists.linuxfoundation.org/p=
ipermail/bitcoin-dev/2021-June/019061.html" rel=3D"noreferrer" target=3D"_b=
lank">recently opined</a> that RBF should=C2=A0be 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 also have a clear incentive to=
 ignore RBF rules and mine anything that passes consensus. At best opting o=
ut 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><di=
v><br></div><div>Do we as a community want to support 0-conf payments in an=
y way at this point? It seems rather silly=C2=A0to make software design dec=
isions to accommodate=C2=A00-conf payments when there are better mechanisms=
 for fast payments (ie lightning).=C2=A0</div><div><br></div><div>One quest=
ion I have is: how does software generally inform the user about 0-conf pay=
ment detection? Does software generally tell the user something along the l=
ines of &quot;This payment has not been finalized yet. All recipients shoul=
d wait until the transaction has at least 1 confirmation, and most recipien=
ts should wait for 6 confirmations&quot; ? I think unless we pressure softw=
are to be very explicit about what counts as finality, users will simply co=
ntinue to do what they&#39;ve always done. Rolling out this policy change o=
ver 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 thi=
s point, which I don&#39;t have any data on.=C2=A0</div></div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jun 15, 202=
1 at 10:00 AM Antoine Riard via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org" rel=3D"noreferrer" 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-width:1px;border=
-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div=
 dir=3D"ltr"><div>Hi,<br><br>I&#39;m writing to propose deprecation of opt-=
in RBF in favor of full-RBF as the Bitcoin Core&#39;s default replacement p=
olicy in version 24.0. As a reminder, the next release is 22.0, aimed for A=
ugust 1st, assuming agreement is reached, this policy change would enter in=
to deployment phase a year from now. <br><br>Even if this replacement polic=
y has been deemed as highly controversial a few years ago, ongoing and anti=
cipated changes in the Bitcoin ecosystem 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 Mempool Funny Games against Multi-Party Funde=
d Transactions&#39;&#39;, 2nd issue [0], an attacker can easily DoS a multi=
-party funded transactions by propagating an RBF opt-out double-spend of it=
s contributed input before the honest transaction is broadcasted by the pro=
tocol orchester. DoSes are qualified in the sense of either an attacker was=
ting timevalue of victim&#39;s inputs or forcing exhaustion of the fee-bump=
ing =C2=A0reserve.<br><br>This affects a series of Bitcoin protocols such a=
s Coinjoin, onchain DLCs and dual-funded LN channels. As those protocols ar=
e 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, considering that dual-funded=
 are more efficient from a liquidity standpoint, we can expect them to be w=
idely relied on, once Lightning enters in a more mature phase. At that poin=
t, it should become economically rational for liquidity service providers t=
o launch those DoS attacks against their competitors to hijack user traffic=
.<br><br>Beyond that, presence of those DoSes will complicate the design an=
d deployment of multi-party Bitcoin protocols such as payment pools/multi-p=
arty channels. Note, Lightning Pool isn&#39;t affected as there is a prelim=
inary stage where batch participants are locked-in their funds within an ac=
count witnessScript shared with the orchestrer.<br><br>Of course, even assu=
ming 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 a=
ttack scenario to a scorched earth approach, where the attacker has to comm=
it equivalent fee-bumping reserve to maintain the pinning and might lose th=
e &quot;competing&quot; fees to miners.<br><br># RBF opt-out as a Mempools =
Partitions Vector<br><br>A longer-term issue is the risk of mempools malici=
ous partitions, where an attacker exploits network topology or divergence i=
n mempools policies to partition network mempools in different subsets. Fro=
m 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&#39;s feerate (the Core&#39;s one wouldn&#39;t be affected as=
 it relies on block confirmation, though other fee estimators designs deplo=
yed across the ecosystem are likely going to be affected).<br><br>Tradition=
ally, mempools partitions have been gauged as a spontaneous outcome of a di=
stributed systems like Bitcoin p2p network and I&#39;m not aware it has bee=
n studied in-depth for adversarial purposes. Though, deployment of second-l=
ayer<br>protocols, heavily relying on sanity of a local mempool for fee-est=
imation and robust propagation of their time-sensitive transactions might l=
ead to reconsider this position. Acknowledging this, RBF opt-out is a low-c=
ost partitioning tool, of which the existence nullifies most of potential p=
rogresses to mitigate malicious partitioning.<br><br><br>To resume, opt-in =
RBF doesn&#39;t suit well deployment of robust second-layers protocol, even=
 if those issues are still early and deserve more research. At the same tim=
e, I believe a meaningful subset of the ecosystem =C2=A0are still relying<b=
r>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 r=
apid change of Core&#39;s mempool rules would be harming their quality of s=
ervices 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 could be deployed ecosystem-wise as enhancem=
ents to the 0-confs security model.<br><br># Proactive security models : Do=
uble-spend Monitoring/Receiver-side Fee-Topping with Package Relay<br><br>F=
rom 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 privac=
y-preserving inventory timers (`OUTBOUND_INVENTORY_BROADCAST_INTERVAL`), of=
 which an attacker has no care to respect.<br><br>To detect a successful do=
uble-spend attempt, a Bitcoin service should run few full-nodes with well-s=
pread connection graphs and unlinkable between them, to avoid being identif=
ied then maliciously partitioned from the rest of the network.<br><br>I bel=
ieve 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.<br><br>One further improvement on top of this protection could be=
 to react after the double-spend detection by attaching a CPFP to the merch=
ant transaction, with a higher package feerate than the double-spend. Expec=
ted deployment of package-relay as a p2p mechanism/mempool policy in Bitcoi=
n Core should enable it to do so.<br><br># Reactive security models : Econo=
micReputation-based Compensations<br><br>Another approach could be to react=
 after the fact if a double-spend has been qualified. If the sender is alre=
ady known to the service provider, 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 relied on. For e.g a LN pubkey with a stacked =
reputation from your autopilot, LSATs, stake certificates, a HTLC-as-a-fide=
lity-bond, ... The space is quite wide there but I foresee those trust-mini=
mized, decentralized solutions being adopted by the LN ecosystem to patch t=
he risks when you enter in a channel/HTLC operation with an anonymous count=
erparty. <br><br></div><div>What other cool new tools could be considered t=
o 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 transaction relay/mempool acceptance policy =
might be beneficial to some class of already-deployed <br>Bitcoin applicati=
ons while being detrimental to newer ones. How do we preserve the current i=
nterests of 0-confs users while enabling upcoming interests of fancy L2s to=
 flourish is a good conversation to have. I think.<br><br>If there is ecosy=
stem agreement on switching to full-RBF, but 0.24 sounds too early, let&#39=
;s defer it to 0.25 or 0.26. I don&#39;t think Core has a consistent deprec=
ation 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.<br><br>Ch=
eers,<br>Antoine<br><br>[0] <a href=3D"https://lists.linuxfoundation.org/pi=
permail/lightning-dev/2021-May/003033.html" rel=3D"noreferrer" target=3D"_b=
lank">https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/00=
3033.html</a><br><br>[1] See scenario 3 : <a href=3D"https://lists.linuxfou=
ndation.org/pipermail/lightning-dev/2020-June/002758.html" rel=3D"noreferre=
r" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/lightning-=
dev/2020-June/002758.html</a><br><br>[2] <a href=3D"https://github.com/bitc=
oin/bitcoin/pull/10823#issuecomment-466485121" rel=3D"noreferrer" target=3D=
"_blank">https://github.com/bitcoin/bitcoin/pull/10823#issuecomment-4664851=
21</a><br><br></div>[3] And the LN ecosystem does have an interest to fix z=
ero-confs security, if &quot;turbo-channels&quot;-like become normalized fo=
r mobile nodes<br></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
 target=3D"_blank">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" rel=3D"noreferrer"=
 target=3D"_blank">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>
_______________________________________________<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>

--0000000000008da7f605c5fc3ce9--