path: root/81/3ad7b0d065db1266b9d6cb0d0a822110ec185f

Return-Path: <sergej@bitrefill.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 89FB0C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 14:12:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 657C36FAEA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 14:12:06 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 657C36FAEA
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=bitrefill.com header.i=@bitrefill.com
 header.a=rsa-sha256 header.s=b header.b=Wvx+BLb9
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level: 
X-Spam-Status: No, score=-2.089 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, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id kGnLbj7JL0tt
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 14:12:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org C46776FAE7
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com
 [IPv6:2a00:1450:4864:20::232])
 by smtp3.osuosl.org (Postfix) with ESMTPS id C46776FAE7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 14:12:02 +0000 (UTC)
Received: by mail-lj1-x232.google.com with SMTP id r22so26539781ljn.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 07:12:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitrefill.com; s=b;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=wTRFKGRIQJa3PLj/f2yq00dojOAJ4ghsOcC5NR72Eik=;
 b=Wvx+BLb9xyBczPPwbicE/QkFHBQZdE5asWVaL+HimqKCM2Gb8KiJHysi/6iJzJzrmj
 vWUVL9XRAZsmtfTfJ3k3snw5NXGvXpDsJxiDIIbgwIi5TlY1ZubUIXOx5Gv8V464509Z
 fcMytnDNHHZKeSgDHYf2Wpdrq+cc1C8TZvVMEtg5ADfbShAU4i2Tf1fLV7biZJihgCZx
 sc8/fChsR+zA+cI29c7K9vQjjRbWr/oXbvqxbFXgwhLIWNY7qqSMXv5DNWVHtZlZFfTX
 wvKV6nNmvd3TJQBrPGSoi6FlAOujSon7dl4P7p+Al1ZfQ/iHmGOigMG8tJ0030sLMiJi
 6bBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=wTRFKGRIQJa3PLj/f2yq00dojOAJ4ghsOcC5NR72Eik=;
 b=8QL1ssiTj0tSXoFwRiLx60inJMQgEAyKYiVEI8OAF0mIZNWdXM+PXYjwjxAD7U9/Pd
 l8ksLMr+80h82fuMIneZcUoIzJzGnYnTIz4Nv7tAfa0Q/u7VBxjH0fK43SVVgq0QqmXR
 ajJ3ylGGKjyEutiqLSibV2Crf/eWU+PlLXbUukyxpMPjK73i+WOeednVXEwVHBD4qxhZ
 jKdWhg5JJ7VCWbZsipcmWXkYRIEy+4fMRkQqtmjCHB5n0/EvU+WbCSldbXa5i1CdjqTD
 VBF9bmSEgDSRuKL/1wcQ72cE45p2Hx1NsXesgLGrXP1k1AzfuA6eosxAix4VQjicbQfS
 OtUA==
X-Gm-Message-State: ACrzQf2A8RmoaW2+S7SDmijMryRdykMewWgsxyOf0F4AzNMnUJ96nnfn
 EadT3//8NADpVLDMAbJHojqbfpj+hmHofdRmAsVHEc7sGNw=
X-Google-Smtp-Source: AMsMyM6NmucHjhKLTyfuXetrHPIKdOHi5XFBdLqeFJwTZRcIvY/GoGFChKjD3G5LEFw3S2hrum9VWYj8t064Jw0uIR4=
X-Received: by 2002:a2e:b8ca:0:b0:26f:c7a1:577a with SMTP id
 s10-20020a2eb8ca000000b0026fc7a1577amr5274794ljp.77.1666275120523; Thu, 20
 Oct 2022 07:12:00 -0700 (PDT)
MIME-Version: 1.0
References: <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
 <CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
 <CALZpt+ELLFMJstnTxUjKR6Q2OD-xuLTkt4q3BCHUHyz7NV123w@mail.gmail.com>
In-Reply-To: <CALZpt+ELLFMJstnTxUjKR6Q2OD-xuLTkt4q3BCHUHyz7NV123w@mail.gmail.com>
From: Sergej Kotliar <sergej@bitrefill.com>
Date: Thu, 20 Oct 2022 16:11:48 +0200
Message-ID: <CABZBVTBMoYJqBP8_4kOybdYoxYePfPJYSP=HO7NEjTfD-QeM7Q@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000a83e3f05eb77e8d4"
X-Mailman-Approved-At: Thu, 20 Oct 2022 14:15:19 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
	danger
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: Thu, 20 Oct 2022 14:12:06 -0000

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

On Thu, 20 Oct 2022 at 03:37, Antoine Riard <antoine.riard@gmail.com> wrote=
:

> Hi Sergej,
>
> Thanks for the insightful posting, especially highlighting the FX risk
> which was far from being evident on my side!
>
> I don't know in details the security architecture of Bitrefill zeroconf
> acceptance system, though from what I suppose there is at least a set of
> full-nodes well-connected across the p2p network, on top of which some
> mempools reconciliation is exercised
> and zeroconf candidate sanitize against. While I believe this is a
> far-more robust deployment against double-spend attempts, there is still
> the ability for a sophisticated attacker to "taint" miner mempools, and
> from then partition judiciously the transaction-relay network to game suc=
h
> distributed mempool monitoring system. There is also the possibility of a=
n
> attacker using some "divide-and-conquer" transaction broadcast algorithm =
to
> map Bitrefill monitoring point, though as far as I'm aware such algorithm
> has not been discussed. I agree with all of that, easier said than done.
>

There is a long list of countermeasures that can be built to reduce these
attacks, but to be frank we've only implemented a small subset of these and
not had any issues, so even a lower level of security is more than fine
today to have basically zero abuse. If issues arise we could implement more
of the countermeasures as appropriate to the abuse that has happened in the
wild.


> On the efficacy of RBF, I understand the current approach of assuming
> "manual" RBFing by power users ill UX thinking. I hope in the future to
> have automatic fee-bumping implemented by user wallets, where a fee-bumpi=
ng
> budget and a confirmation preference are pre-defined for all payments, an=
d
> the fee-bumping logic "simply" enforcing the user policy, ideally based o=
n
> historical mempool data. True fact: we don't have such logic in consumer
> wallets today.
>

In deed. And the vast majority of bitcoin users don't even have access to
any RBF functionality today, so we're not even seeing gradual development
of these things yet. I think this fact needs to be taken into account when
designing breaking changes to bitcoin policy. Had these things been in
place and widely used the conversation would have been much easier.

Fundamentally, my view is that all the UX problems related to RBF alone are
sufficient of an issue to hold off on rolling out these upgrades for the
foreseeable future and think of other ways of solving the pinning issue and
other issues w the current policy. Might be that it's just a fundamental
goal conflict that different people want different behavior but I remain
optimistic for creative solutions from both sides. UX issues are soft as
opposed to theoretical attack vectors which are hard and binary, we need
find a way to weigh "even though it doesn't happen it can theoretically be
hacked" against "many users find it confusing and stressful" which is not a
trivial assessment to do.

All that said, I learn to converge that as a community we would be better
> off to weigh deeper the risks/costs between 0confs applications and
> contracting protocols in light of full-rbf.
>

In deed. And as you wrote in a different message, I agree that it's
unfortunate that there isn't more interaction between the mailing list and
services and companies using this stuff day-to-day. Not that it's anyone's
fault in particular, let's try from all sides to find more ways to create
more interaction on these topics. I've pinged a few colleagues that work on
payments in the space and hope they will chime in more in this forum!

All the best,
Sergej


> Le mer. 19 oct. 2022 =C3=A0 10:33, Sergej Kotliar via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
>
>> Hi all,
>>
>> Chiming in on this thread as I feel like the real dangers of RBF as
>> default policy aren't sufficiently elaborated here. It's not only about =
the
>> zero-conf (I'll get to that) but there is an even bigger danger called t=
he
>> american call option, which risks endangering the entirety of BIP21 "Sca=
n
>> this QR code with your wallet to buy this product" model that I believe
>> we've all come to appreciate. Specifically, in a scenario with high
>> volatility and many transactions in the mempools (which is where RBF wou=
ld
>> come in handy), a user can make a low-fee transaction and then wait for
>> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD move=
s
>> up, user can cancel his transaction and make a new - cheaper one. The
>> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
>> (it's actually quite easily managed), it's FX risk as the merchant must
>> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
>> some transactions lose money to FX and others earn money - that evens ou=
t
>> in the end. But if there is an _easily accessible in the wallet_ feature=
 to
>> "cancel transaction" that means it will eventually get systematically
>> abused. A risk of X% loss on many payments that's easy to systematically
>> abuse is more scary than a rare risk of losing 100% of one occasional
>> payment. It's already possible to execute this form of abuse with opt-in
>> RBF, which may lead to us at some point refusing those payments (even wi=
th
>> confirmation) or cumbersome UX to work around it, such as crediting the
>> bitcoin to a custodial account.
>>
>> To compare zeroconf risk with FX risk: I think we've had one incident in
>> 8 years of operation where a user successfully fooled our server to acce=
pt
>> a payment that in the end didn't confirm. To successfully fool (non-RBF)
>> zeroconf one needs to have access to mining infrastructure and probabili=
ty
>> of success is the % of hash rate controlled. This is simply due to the f=
act
>> that the network currently won't propagage the replacement transaction t=
o
>> the miner, which is what's being discussed here. American call option ri=
sk
>> would however be available to 100% of all users, needs nothing beyond th=
e
>> wallet app, and has no cost to the user - only upside.
>>
>> Bitrefill currently processes 1500-2000 onchain payments every day. For
>> us, a world where bitcoin becomes de facto RBF by default, means that we
>> would likely turn off the BIP21 model for onchain payments, instruct
>> Bitcoin users to use Lightning or deposit onchain BTC to a custodial
>> account that we have.
>> This option is however not available for your typical
>> BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear
>> from other merchants or payment providers how they see this new behavior
>> and how they would counteract it.
>>
>> Currently Lightning is somewhere around 15% of our total bitcoin
>> payments. This is very much not nothing, and all of us here want Lightni=
ng
>> to grow, but I think it warrants a serious discussion on whether we want
>> Lightning adoption to go to 100% by means of disabling on-chain commerce=
.
>> For me personally it would be an easier discussion to have when Lightnin=
g
>> is at 80%+ of all bitcoin transactions. Currently far too many bitcoin
>> users simply don't have access to Lightning, and of those that do and ho=
ld
>> their own keys Muun is the biggest wallet per our data, not least due to
>> their ease-of-use which is under threat per the OP. It's hard to assess =
how
>> many users would switch to Lightning in such a scenario, the communicati=
on
>> around it would be hard. My intuition says that the majority of the curr=
ent
>> 85% of bitcoin users that pay onchain would just not use bitcoin anymore=
,
>> probably shift to an alt. The benefits of Lightning are many and obvious=
,
>> we don't need to limit onchain to make Lightning more appealing. As an
>> anecdote, we did experiment with defaulting to bech32 addresses some yea=
rs
>> back. The result was that simply users of the wallets that weren't able =
to
>> pay to bech32 didn't complete the purchase, no support ticket or anythin=
g,
>> just "it didn't work =F0=9F=A4=B7=E2=80=8D=E2=99=82=EF=B8=8F" and user m=
oved on. We rolled it back, and later
>> implemented a wallet selector to allow modern wallets to pay to bech32
>> while other wallets can pay to P2SH. This type of thing  is clunky, and
>> requires a certain level of scale to be able to do, we certainly wouldn'=
t
>> have had the manpower for that when we were starting out. This why I'm
>> cautious about introducing more such clunkiness vectors as they are
>> centralizing factors.
>>
>> I'm well aware of the reason for this policy being suggested and the
>> potential pinning attack vector for LN and other smart contracts, but I
>> think these two risks/costs need to be weighed against eachother first a=
nd
>> thoroughly discussed because the costs are non-trivial on both sides.
>>
>> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
>> After interacting with users during high-fee periods I've come to not
>> appreciate RBF as a solution to that issue. Most users (80% or so) simpl=
y
>> don't have access to that functionality, because their wallet doesn't
>> support it, or they use a custodial (exchange) wallet etc. Of those that
>> have the feature - only the power users understand how RBF works, and
>> explaining how to do RBF to a non-power-user is just too complex, for th=
e
>> same reason why it's complex for wallets to make sensible non-power-user=
 UI
>> around it. Current equilibrium is that mostly only power users have acce=
ss
>> to RBF and they know how to handle it, so things are somewhat working. B=
ut
>> rolling this out to the broad market is something else and would likely
>> cause more confusion.
>> CPFP is somewhat more viable but also not perfect as it would require
>> lots of edge case code to handle abuse vectors: What if users abuse a
>> generous CPFP policy to unstuck past transactions or consolidate large
>> wallets. Best is for CPFP to be done on the wallet side, not the merchan=
t
>> side, but there too are the same UX issues as with RBF.
>> In the end a risk-based approach to decide on which payments are
>> non-trivial to reverse is the easiest, taking account user experience an=
d
>> such. Remember that in the fiat world card payments have up to 5%
>> chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer th=
an
>> 1 in a million" accepted transactions successfully reversed. These days =
we
>> have very few support issues related to bitcoin payments. The few that d=
o
>> come in are due to accidental RBF users venting frustration about waitin=
g
>> for their tx to confirm.
>> "In theory, theory and practice are the same. In practice, they are not"
>>
>> All the best,
>> Sergej Kotliar
>> CEO Bitrefill.com
>>
>>
>> --
>>
>> Sergej Kotliar
>>
>> CEO
>>
>>
>> Twitter: @ziggamon <https://twitter.com/ziggamon>
>>
>>
>> www.bitrefill.com
>>
>> Twitter <https://www.twitter.com/bitrefill> | Blog
>> <https://www.bitrefill.com/blog/> | Angellist
>> <https://angel.co/bitrefill>
>>
>>
>> --
>>
>> Sergej Kotliar
>>
>> CEO
>>
>>
>> Twitter: @ziggamon <https://twitter.com/ziggamon>
>>
>>
>> www.bitrefill.com
>>
>> Twitter <https://www.twitter.com/bitrefill> | Blog
>> <https://www.bitrefill.com/blog/> | Angellist
>> <https://angel.co/bitrefill>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

--=20

Sergej Kotliar

CEO


Twitter: @ziggamon <https://twitter.com/ziggamon>


www.bitrefill.com

Twitter <https://www.twitter.com/bitrefill> | Blog
<https://www.bitrefill.com/blog/> | Angellist <https://angel.co/bitrefill>

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

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, 20 Oct 2022 at 03:37, Antoine=
 Riard &lt;<a href=3D"mailto:antoine.riard@gmail.com">antoine.riard@gmail.c=
om</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr">Hi Sergej,<br><br>Thanks for the insightful posting, esp=
ecially highlighting the FX risk which was far from being evident on my sid=
e!<br><br>I don&#39;t know in details the security architecture of Bitrefil=
l zeroconf acceptance system, though from what I suppose there is at least =
a set of full-nodes well-connected across the p2p network, on top of which =
some mempools reconciliation is exercised<br>and zeroconf candidate sanitiz=
e against. While I believe this is a far-more robust deployment against dou=
ble-spend attempts, there is still the ability for a sophisticated attacker=
 to &quot;taint&quot; miner mempools, and from then partition judiciously t=
he transaction-relay network to game such distributed mempool monitoring sy=
stem. There is also the possibility of an attacker using some &quot;divide-=
and-conquer&quot; transaction broadcast algorithm to map Bitrefill monitori=
ng point, though as far as I&#39;m aware such algorithm has not been discus=
sed. I agree with all of that, easier said than done.<br></div></blockquote=
><div><br></div><div>There is a long list of countermeasures that can be bu=
ilt to reduce these attacks, but to be frank we&#39;ve only implemented a s=
mall subset of these and not had any issues, so even a lower level of secur=
ity is more than fine today to have basically zero abuse. If issues arise w=
e could implement more of the countermeasures as appropriate to the abuse t=
hat has happened in the wild.</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr">On the efficacy of RBF, I under=
stand the current approach of assuming &quot;manual&quot; RBFing by power u=
sers ill UX thinking. I hope in the future to have automatic fee-bumping im=
plemented by user wallets, where a fee-bumping budget and a confirmation pr=
eference are pre-defined for all payments, and the fee-bumping logic &quot;=
simply&quot; enforcing the user policy, ideally based on historical mempool=
 data. True fact: we don&#39;t have such logic in consumer wallets today. <=
/div></blockquote><div><br></div><div>In deed. And the vast majority of bit=
coin users don&#39;t even have access to any RBF functionality today, so we=
&#39;re not even seeing gradual development of these things yet. I think th=
is fact needs to be taken into account when designing breaking changes to b=
itcoin policy. Had these things been in place and widely used the conversat=
ion would have been much easier.</div><div>=C2=A0</div><div>Fundamentally, =
my view is that all the UX problems related to RBF alone are sufficient of =
an issue to hold off on rolling out these upgrades for the foreseeable futu=
re and think of other ways of solving the pinning issue and other issues w =
the current policy. Might be that it&#39;s just a fundamental goal conflict=
 that different people want different behavior but I remain optimistic for =
creative solutions from both sides. UX issues are soft as opposed to theore=
tical attack vectors which are hard and binary, we need find=C2=A0a way to =
weigh &quot;even though it doesn&#39;t happen it can theoretically be hacke=
d&quot; against &quot;many users find it confusing and stressful&quot; whic=
h is not a trivial assessment to do.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">All that said, I learn to=
 converge that as a community we would be better off to weigh deeper the ri=
sks/costs between 0confs applications and contracting protocols in light of=
 full-rbf.<br></div></blockquote><div><br></div><div>In deed. And as you wr=
ote in a different message, I agree that it&#39;s unfortunate that there is=
n&#39;t more interaction between the mailing list and services and companie=
s using this stuff day-to-day. Not that it&#39;s anyone&#39;s fault in part=
icular, let&#39;s try from all sides to find more ways to create more inter=
action on these topics. I&#39;ve pinged a few colleagues that work on payme=
nts in the space and hope they will chime in more in this forum!</div><div>=
<br></div><div>All the best,</div><div>Sergej</div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer. 19 oct. 2022 =C3=A0=C2=A010:3=
3, Sergej Kotliar via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org=
</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">H=
i all,<div><br></div><div>Chiming in on this thread as I feel like the real=
 dangers of RBF as default policy aren&#39;t sufficiently elaborated here. =
It&#39;s not only about the zero-conf (I&#39;ll get to that) but there is a=
n even bigger danger called the american call option, which risks endangeri=
ng the entirety of BIP21 &quot;Scan this QR code with your wallet to buy th=
is product&quot; model that I believe we&#39;ve all come to appreciate. Spe=
cifically, in a scenario with high volatility and many transactions in the =
mempools (which is where RBF would come in handy), a user can make a low-fe=
e transaction and then wait for hours, days or even longer, and see whether=
 BTCUSD moves. If BTCUSD moves up, user can cancel his transaction and make=
 a new - cheaper one. The biggest risk in accepting bitcoin payments is in =
fact not zeroconf risk (it&#39;s actually quite easily managed), it&#39;s F=
X risk as the merchant must commit to a certain BTCUSD rate ahead of time f=
or a purchase. Over time some transactions lose money to FX and others earn=
 money - that evens out in the end. But if there is an _easily accessible i=
n the wallet_ feature to &quot;cancel transaction&quot; that means it will =
eventually get systematically abused. A risk of X% loss on many payments th=
at&#39;s easy to systematically abuse is more scary than a rare risk of los=
ing 100% of one occasional payment. It&#39;s already possible to execute th=
is form of abuse with opt-in RBF, which may lead to us at some point refusi=
ng those payments (even with confirmation) or cumbersome UX to work around =
it, such as crediting the bitcoin to a custodial account.</div><div><br></d=
iv><div>To compare zeroconf risk with FX risk: I think we&#39;ve had one in=
cident in 8 years of operation where a user successfully fooled our server =
to accept a payment that in the end didn&#39;t confirm. To successfully foo=
l (non-RBF) zeroconf one needs to have access to mining infrastructure and =
probability of success is the % of hash rate controlled. This is simply due=
 to the fact that the network currently won&#39;t propagage the replacement=
 transaction to the miner, which is what&#39;s being discussed here. Americ=
an call option risk would however be available to 100% of all users, needs =
nothing beyond the wallet app, and has no cost to the user - only upside.<b=
r></div><div><br></div><div>Bitrefill currently processes 1500-2000 onchain=
 payments every day. For us, a world where bitcoin becomes de facto RBF by =
default, means that we would likely turn off the BIP21 model for onchain pa=
yments, instruct Bitcoin users to use Lightning or deposit onchain BTC to a=
 custodial account that we have.=C2=A0<br></div><div>This option is however=
 not available for your typical BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode =
et al. Would be great to hear from other merchants or payment providers how=
 they see this new behavior and how they would counteract it.</div><div><br=
></div><div>Currently Lightning is somewhere around 15% of our total bitcoi=
n payments. This is very much not nothing, and all of us here want Lightnin=
g to grow, but I think it warrants a serious discussion on whether we want =
Lightning adoption to go to 100% by means of disabling on-chain commerce. F=
or me personally it would be an easier discussion to have when Lightning is=
 at 80%+ of all bitcoin transactions. Currently far too many bitcoin users =
simply don&#39;t have access to Lightning, and of those that do and hold th=
eir own keys Muun is the biggest wallet per our data, not least due to thei=
r ease-of-use which is under threat per the OP. It&#39;s hard to assess how=
 many users would switch to Lightning in such a scenario, the communication=
 around it would be hard. My intuition says that the majority of the curren=
t 85% of bitcoin users that pay onchain would just not use bitcoin anymore,=
 probably shift to an alt. The benefits of Lightning are many and obvious, =
we don&#39;t need to limit onchain to make Lightning more appealing. As an =
anecdote, we did experiment with defaulting to bech32 addresses some years =
back. The result was that simply users of the wallets that weren&#39;t able=
 to pay to bech32 didn&#39;t complete the purchase, no support ticket or an=
ything, just &quot;it didn&#39;t work =F0=9F=A4=B7=E2=80=8D=E2=99=82=EF=B8=
=8F&quot; and user moved on. We rolled it back, and later implemented a wal=
let selector to allow modern wallets to pay to bech32 while other wallets c=
an pay to P2SH. This type of thing=C2=A0 is clunky, and requires a certain =
level of scale to be able to do, we certainly wouldn&#39;t have had the man=
power for that when we were starting out. This why I&#39;m cautious about i=
ntroducing more such clunkiness vectors as they are centralizing factors.</=
div><div><br></div><div>I&#39;m well aware of the reason for this policy be=
ing suggested and the potential pinning attack vector for LN and other smar=
t contracts, but I think these two risks/costs need to be weighed against e=
achother first and thoroughly discussed because the costs are non-trivial o=
n both sides.<br clear=3D"all"><div><br></div><div>Sidenote: On the efficac=
y of RBF to &quot;unstuck&quot; stuck transactions</div><div>After interact=
ing with users during high-fee periods I&#39;ve come to not appreciate RBF =
as a solution to that issue. Most users (80% or so) simply don&#39;t have a=
ccess to that functionality, because their wallet doesn&#39;t support it, o=
r they use a custodial (exchange) wallet etc. Of those that have the featur=
e - only the power users understand how RBF works, and explaining how to do=
 RBF to a non-power-user is just too complex, for the same reason why it&#3=
9;s complex for wallets to make sensible non-power-user UI around it. Curre=
nt equilibrium is that mostly only power users have access to RBF and they =
know how to handle it, so things are somewhat working. But rolling this out=
 to the broad market is something else and would likely cause more confusio=
n.=C2=A0</div><div>CPFP is somewhat more viable but also not perfect as it =
would require lots of edge case code to handle abuse vectors: What if users=
 abuse a generous CPFP policy to unstuck past transactions or consolidate l=
arge wallets. Best is for CPFP to be done on the wallet side, not the merch=
ant side, but there too are the same UX issues as with RBF.=C2=A0</div><div=
>In the end a risk-based approach to decide on which payments are non-trivi=
al to reverse is the easiest, taking account user experience and such. Reme=
mber that in the fiat world card payments have up to 5% chargebacks, wherea=
s we in zero-conf bitcoin land we deal with &quot;fewer than 1 in a million=
&quot; accepted transactions successfully reversed. These days we have very=
 few support issues related to bitcoin payments. The few that do come in ar=
e due to accidental RBF users venting frustration about waiting for their t=
x to confirm.</div><div>&quot;In theory, theory and practice are the same. =
In practice, they are not&quot;</div><div><br></div><div>All the best,=C2=
=A0</div><div>Sergej Kotliar</div><div>CEO Bitrefill.com</div><div><br></di=
v><div><br></div>-- <br><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">=
<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div di=
r=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><p dir=3D"ltr"=
 style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D=
"font-size:9.5pt;font-family:Arial;color:rgb(0,0,0);background-color:transp=
arent;font-weight:700;font-style:normal;font-variant:normal;text-decoration=
:none;vertical-align:baseline;white-space:pre-wrap">Sergej Kotliar</span></=
p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt=
"><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(0,0,0);backgro=
und-color:transparent;font-weight:700;font-style:normal;font-variant:normal=
;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">CEO</sp=
an></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-botto=
m:0pt"><b style=3D"font-weight:normal"><br></b></p><p dir=3D"ltr" style=3D"=
line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size=
:11pt;font-family:Arial;color:rgb(102,102,102);background-color:transparent=
;font-weight:700;font-style:normal;font-variant:normal;text-decoration:none=
;vertical-align:baseline;white-space:pre-wrap"><span style=3D"border:medium=
 none;display:inline-block;overflow:hidden;width:220px;height:80px"><img sr=
c=3D"https://lh4.googleusercontent.com/wU5i7e8boCd7o3P52cUTKrqeTa7jV2dPEXlu=
ijGtPBy0f1F0R2_zIg_zOQ2kigkbVbSWqLlVdwuBYgo_txXMKkCWdMfBFRNhsDhFpNv1QrRZsD-=
gPxDui-4l0tZI1QcjtefCDkNG" style=3D"margin-left: 0px; margin-top: 0px;" wid=
th=3D"220" height=3D"80"></span></span></p><p dir=3D"ltr" style=3D"line-hei=
ght:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:9.5pt;f=
ont-family:Arial;color:rgb(102,102,102);background-color:transparent;font-w=
eight:400;font-style:normal;font-variant:normal;text-decoration:none;vertic=
al-align:baseline;white-space:pre-wrap">Twitter: @</span><a href=3D"https:/=
/twitter.com/ziggamon" style=3D"text-decoration:none" target=3D"_blank"><sp=
an style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);backgr=
ound-color:transparent;font-weight:400;font-style:normal;font-variant:norma=
l;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">z=
iggamon</span></a><span style=3D"font-size:9.5pt;font-family:Arial;color:rg=
b(102,102,102);background-color:transparent;font-weight:400;font-style:norm=
al;font-variant:normal;text-decoration:none;vertical-align:baseline;white-s=
pace:pre-wrap">=C2=A0</span></p><p dir=3D"ltr" style=3D"line-height:1.38;ma=
rgin-top:0pt;margin-bottom:0pt"><b style=3D"font-weight:normal"><br></b></p=
><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"=
><a href=3D"http://www.bitrefill.com/" style=3D"text-decoration:none" targe=
t=3D"_blank"><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102=
,102,102);background-color:transparent;font-weight:400;font-style:normal;fo=
nt-variant:normal;text-decoration:underline;vertical-align:baseline;white-s=
pace:pre-wrap">www.bitrefill.com</span></a></p><p dir=3D"ltr" style=3D"line=
-height:1.38;margin-top:0pt;margin-bottom:0pt"><a href=3D"https://www.twitt=
er.com/bitrefill" target=3D"_blank"><span style=3D"font-size:9.5pt;font-fam=
ily:Arial;color:rgb(102,102,102);background-color:transparent;vertical-alig=
n:baseline;white-space:pre-wrap">Twitter</span></a><span style=3D"font-size=
:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:transparen=
t;vertical-align:baseline;white-space:pre-wrap"> | </span><a href=3D"https:=
//www.bitrefill.com/blog/" target=3D"_blank"><span style=3D"font-size:9.5pt=
;font-family:Arial;color:rgb(102,102,102);background-color:transparent;vert=
ical-align:baseline;white-space:pre-wrap">Blog</span></a><span style=3D"fon=
t-size:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:tran=
sparent;vertical-align:baseline;white-space:pre-wrap"> | </span><a href=3D"=
https://angel.co/bitrefill" target=3D"_blank"><span style=3D"font-size:9.5p=
t;font-family:Arial;color:rgb(102,102,102);background-color:transparent;ver=
tical-align:baseline;white-space:pre-wrap">Angellist </span></a><br></p></d=
iv></div></div></div></div></div></div></div></div></div></div></div></div>
</div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"><div dir=3D"=
ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><d=
iv dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=
=3D"ltr"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bot=
tom:0pt"><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(0,0,0);=
background-color:transparent;font-weight:700;font-style:normal;font-variant=
:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">=
Sergej Kotliar</span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-to=
p:0pt;margin-bottom:0pt"><span style=3D"font-size:9.5pt;font-family:Arial;c=
olor:rgb(0,0,0);background-color:transparent;font-weight:700;font-style:nor=
mal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-=
space:pre-wrap">CEO</span></p><p dir=3D"ltr" style=3D"line-height:1.38;marg=
in-top:0pt;margin-bottom:0pt"><b style=3D"font-weight:normal"><br></b></p><=
p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><=
span style=3D"font-size:11pt;font-family:Arial;color:rgb(102,102,102);backg=
round-color:transparent;font-weight:700;font-style:normal;font-variant:norm=
al;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><span=
 style=3D"border:medium none;display:inline-block;overflow:hidden;width:220=
px;height:80px"><img src=3D"https://lh4.googleusercontent.com/wU5i7e8boCd7o=
3P52cUTKrqeTa7jV2dPEXluijGtPBy0f1F0R2_zIg_zOQ2kigkbVbSWqLlVdwuBYgo_txXMKkCW=
dMfBFRNhsDhFpNv1QrRZsD-gPxDui-4l0tZI1QcjtefCDkNG" style=3D"margin-left: 0px=
; margin-top: 0px;" width=3D"220" height=3D"80"></span></span></p><p dir=3D=
"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span sty=
le=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);background-c=
olor:transparent;font-weight:400;font-style:normal;font-variant:normal;text=
-decoration:none;vertical-align:baseline;white-space:pre-wrap">Twitter: @</=
span><a href=3D"https://twitter.com/ziggamon" style=3D"text-decoration:none=
" target=3D"_blank"><span style=3D"font-size:9.5pt;font-family:Arial;color:=
rgb(102,102,102);background-color:transparent;font-weight:400;font-style:no=
rmal;font-variant:normal;text-decoration:underline;vertical-align:baseline;=
white-space:pre-wrap">ziggamon</span></a><span style=3D"font-size:9.5pt;fon=
t-family:Arial;color:rgb(102,102,102);background-color:transparent;font-wei=
ght:400;font-style:normal;font-variant:normal;text-decoration:none;vertical=
-align:baseline;white-space:pre-wrap">=C2=A0</span></p><p dir=3D"ltr" style=
=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><b style=3D"font-wei=
ght:normal"><br></b></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top=
:0pt;margin-bottom:0pt"><a href=3D"http://www.bitrefill.com/" style=3D"text=
-decoration:none" target=3D"_blank"><span style=3D"font-size:9.5pt;font-fam=
ily:Arial;color:rgb(102,102,102);background-color:transparent;font-weight:4=
00;font-style:normal;font-variant:normal;text-decoration:underline;vertical=
-align:baseline;white-space:pre-wrap">www.bitrefill.com</span></a></p><p di=
r=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><a hr=
ef=3D"https://www.twitter.com/bitrefill" target=3D"_blank"><span style=3D"f=
ont-size:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:tr=
ansparent;vertical-align:baseline;white-space:pre-wrap">Twitter</span></a><=
span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);back=
ground-color:transparent;vertical-align:baseline;white-space:pre-wrap"> | <=
/span><a href=3D"https://www.bitrefill.com/blog/" target=3D"_blank"><span s=
tyle=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);background=
-color:transparent;vertical-align:baseline;white-space:pre-wrap">Blog</span=
></a><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102=
);background-color:transparent;vertical-align:baseline;white-space:pre-wrap=
"> | </span><a href=3D"https://angel.co/bitrefill" target=3D"_blank"><span =
style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);backgroun=
d-color:transparent;vertical-align:baseline;white-space:pre-wrap">Angellist=
 </span></a><br></p></div></div></div></div></div></div></div></div></div><=
/div></div></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><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"lt=
r"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div=
 dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><p dir=3D"ltr" style=3D"line=
-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:9.5=
pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-wei=
ght:700;font-style:normal;font-variant:normal;text-decoration:none;vertical=
-align:baseline;white-space:pre-wrap">Sergej Kotliar</span></p><p dir=3D"lt=
r" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=
=3D"font-size:9.5pt;font-family:Arial;color:rgb(0,0,0);background-color:tra=
nsparent;font-weight:700;font-style:normal;font-variant:normal;text-decorat=
ion:none;vertical-align:baseline;white-space:pre-wrap">CEO</span></p><p dir=
=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><b sty=
le=3D"font-weight:normal"><br></b></p><p dir=3D"ltr" style=3D"line-height:1=
.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-fa=
mily:Arial;color:rgb(102,102,102);background-color:transparent;font-weight:=
700;font-style:normal;font-variant:normal;text-decoration:none;vertical-ali=
gn:baseline;white-space:pre-wrap"><span style=3D"border:none;display:inline=
-block;overflow:hidden;width:220px;height:80px"><img src=3D"https://lh4.goo=
gleusercontent.com/wU5i7e8boCd7o3P52cUTKrqeTa7jV2dPEXluijGtPBy0f1F0R2_zIg_z=
OQ2kigkbVbSWqLlVdwuBYgo_txXMKkCWdMfBFRNhsDhFpNv1QrRZsD-gPxDui-4l0tZI1Qcjtef=
CDkNG" width=3D"220" height=3D"80" style=3D"margin-left: 0px; margin-top: 0=
px;"></span></span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:=
0pt;margin-bottom:0pt"><span style=3D"font-size:9.5pt;font-family:Arial;col=
or:rgb(102,102,102);background-color:transparent;font-weight:400;font-style=
:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;wh=
ite-space:pre-wrap">Twitter: @</span><a href=3D"https://twitter.com/ziggamo=
n" style=3D"text-decoration:none" target=3D"_blank"><span style=3D"font-siz=
e:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:transpare=
nt;font-weight:400;font-style:normal;font-variant:normal;text-decoration:un=
derline;vertical-align:baseline;white-space:pre-wrap">ziggamon</span></a><s=
pan style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);backg=
round-color:transparent;font-weight:400;font-style:normal;font-variant:norm=
al;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">=C2=
=A0</span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margi=
n-bottom:0pt"><b style=3D"font-weight:normal"><br></b></p><p dir=3D"ltr" st=
yle=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><a href=3D"http:/=
/www.bitrefill.com/" style=3D"text-decoration:none" target=3D"_blank"><span=
 style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);backgrou=
nd-color:transparent;font-weight:400;font-style:normal;font-variant:normal;=
text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">www=
.bitrefill.com</span></a></p><p dir=3D"ltr" style=3D"line-height:1.38;margi=
n-top:0pt;margin-bottom:0pt"><a href=3D"https://www.twitter.com/bitrefill" =
target=3D"_blank"><span style=3D"font-size:9.5pt;font-family:Arial;color:rg=
b(102,102,102);background-color:transparent;vertical-align:baseline;white-s=
pace:pre-wrap">Twitter</span></a><span style=3D"font-size:9.5pt;font-family=
:Arial;color:rgb(102,102,102);background-color:transparent;vertical-align:b=
aseline;white-space:pre-wrap"> | </span><a href=3D"https://www.bitrefill.co=
m/blog/" target=3D"_blank"><span style=3D"font-size:9.5pt;font-family:Arial=
;color:rgb(102,102,102);background-color:transparent;vertical-align:baselin=
e;white-space:pre-wrap">Blog</span></a><span style=3D"font-size:9.5pt;font-=
family:Arial;color:rgb(102,102,102);background-color:transparent;vertical-a=
lign:baseline;white-space:pre-wrap"> | </span><a href=3D"https://angel.co/b=
itrefill" target=3D"_blank"><span style=3D"font-size:9.5pt;font-family:Aria=
l;color:rgb(102,102,102);background-color:transparent;vertical-align:baseli=
ne;white-space:pre-wrap">Angellist </span></a><br></p></div></div></div></d=
iv></div></div></div></div></div></div></div></div>

--000000000000a83e3f05eb77e8d4--