path: root/b9/f047826e297fb2ceab51f724bc641b53fb83a5

Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CA15EC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 01:37:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 90EF74036F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 01:37:41 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 90EF74036F
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=dE/0P2hR
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level: 
X-Spam-Status: No, score=-2.088 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, T_KAM_HTML_FONT_INVALID=0.01]
 autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 22CGOtLAHLeQ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 01:37:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 8C6944013A
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com
 [IPv6:2607:f8b0:4864:20::d2d])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 8C6944013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 01:37:38 +0000 (UTC)
Received: by mail-io1-xd2d.google.com with SMTP id h203so16056024iof.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 19 Oct 2022 18:37:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=TjHTRwHPViAMaxZakhKpkU2hB4NZ1pSmDMwcSdhR4FM=;
 b=dE/0P2hRtZFEt54xHjTItOgVdqLE2GhLHesPGQH5+l35RkQ2s6htSxFI1YNhI7KiL1
 MSqMkdvrHBp3mZsa8T0glf0PyFOKz2phw7+CmyOh23YQdwwrm6RWHfTO10lBv2fCQpzZ
 W6U7QRJ8fzNI5RIyKrS9sVp8SmAmrzeO8QC+6UltuMwZDHmG2iAPQgEq4lsdnROzvawR
 ldp5cnCOrjBunp0vNH/tXrG5juJh9PVlNOBQl56nADxCVJ9P5JGWXsVXdjuPXvjN5Sr+
 AW051MAD06DORQSlFht9qcIJLFHmbxNla4dwEsEpOCuqtXpbUdoD5VCqjyDnIK0T+Yd/
 WTtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=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=TjHTRwHPViAMaxZakhKpkU2hB4NZ1pSmDMwcSdhR4FM=;
 b=SlN2PXRE/jX0VWAKSBiFgwbnzRBZ6YoS/Lz9EJ6Q0+gXGd4cJ3ZuRzDUOWVH6+/wX9
 04jTvhRqp+TDGaBCarV4c4fJ+g3GZbRp/Ugie43TOEWGkd2P2oZaJxtCwHWjqwHOGH8X
 tog5/DbOd4LbZ9iMKdiYmCidfTlRZLX7WA8KNY7N0ow7Jfaf/dWVv3jNg0GiPizDdUcc
 mS68K+xYPIKzc5lgWSzjiY36l/F0k7r+mwS0YYLMy9jyLEZYyhgVFa4pLHC+SPVKIygX
 7vT06qfNjraSuLFO9+RNf3BV70f8T8O7xNNC2GZolopvuy5w7eU5I3qn+SoQW3WxhDqd
 vOyA==
X-Gm-Message-State: ACrzQf0Ti+wtFz2IRCnzqjS/mSOLnC/lsat3ygihuBROQSoxvh4iApJr
 zsYdTzaiTdETCIGCFjUoEYBBu3w5z0/TZwEJNUIqt3pPMw8=
X-Google-Smtp-Source: AMsMyM7CuMfxvdUCnVNhWHwCOBDGpQ6vbb9g3ZqMO0RUua14p0Yb40Lo8YBZV2Zfv1cuaz2W+Oo0+WoKYemUn/kwCQQ=
X-Received: by 2002:a5d:8d81:0:b0:6bc:c1c7:de9c with SMTP id
 b1-20020a5d8d81000000b006bcc1c7de9cmr8109684ioj.211.1666229857270; Wed, 19
 Oct 2022 18:37:37 -0700 (PDT)
MIME-Version: 1.0
References: <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
 <CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
In-Reply-To: <CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 19 Oct 2022 21:37:25 -0400
Message-ID: <CALZpt+ELLFMJstnTxUjKR6Q2OD-xuLTkt4q3BCHUHyz7NV123w@mail.gmail.com>
To: Sergej Kotliar <sergej@bitrefill.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c1cf3205eb6d5e38"
X-Mailman-Approved-At: Thu, 20 Oct 2022 01:38:31 +0000
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 01:37:42 -0000

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

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 such
distributed mempool monitoring system. There is also the possibility of an
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.

(Which let me think that such distributed mempool monitoring system should
be provide some enhanced security even in a full-rbf world, that they would
require far more resources than the average node from the p2p network as a
whole might be a counter-argument for their social acceptance, however I'm
also thinking that a robust Lightning infrastructure of the future might
require multiple mempool/transaction-relay endpoints, at least to reduce
cross-layer mapping links, though conversation for another day...).

About the FX risk itself, this is far from being isolated from 0conf, as
Lightning payments themselves might still have a time lapse between the
issuance of invoices and the settlement of the HTLC at the payee endpoint.
In fact this volatility concern is endured by anyone using Bitcoin
regularly in interface with the fiats worlds, i.e everyone excepted the
long-term store of wealth crowd. From a merchant perspective, effectively,
the options to cover themselves against this risk are simple. One could
take positions directly in traditional financial derivatives, like doing
participants in international trades, though it would require an educated
manpower on the merchant side. Or leveraging some stablecoins derivatives
system, coming with its own technical complexity and social trust hazards.
Another direction would be to clearly define the responsibility between
merchants or users, on whom is the FX risk. If it's on users, they should
be the one RBFing/CPFPing to increase the merchant address output, beyond
the fact "dynamic pricing" would be a weird UX, it would require liveliness
from the wallets until block confirmation (introducing here many
requirements of a LN wallet). If it's on the merchants, they could be the
ones CPFPing thanks to package relay, though it would come again with some
engineering complexity and overhead blockspace cost (and the first version
of package relay likely won't enable CPFP batching for concerns of
potential bandwidth/CPU DoS).

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-bumping
budget and a confirmation preference are pre-defined for all payments, and
the fee-bumping logic "simply" enforcing the user policy, ideally based on
historical mempool data. True fact: we don't have such logic in consumer
wallets today. Or at least only rudimentary in the backend of LN
implementations, and only for time-sensitive on-chain claims for now (or at
least speaking for LDK). If we take the history of browsers as a
comparison, while we might be out of the Lynx-style phase of wallets, we
might still be more in the late Netscape kind of thing than something like
Chrome today. In other words, there are many directions for improvements
for users' wallets.

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.

Best,
Antoine

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 t=
he
> zero-conf (I'll get to that) but there is an even bigger danger called th=
e
> american call option, which risks endangering the entirety of BIP21 "Scan
> 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 woul=
d
> 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 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'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 out
> 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 wit=
h
> 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 accept =
a
> payment that in the end didn't confirm. To successfully fool (non-RBF)
> zeroconf one needs to have access to mining infrastructure and probabilit=
y
> of success is the % of hash rate controlled. This is simply due to the fa=
ct
> that the network currently won't propagage the replacement transaction to
> the miner, which is what's being discussed here. American call option ris=
k
> would however be available to 100% of all users, needs nothing beyond the
> 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 Lightning 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 Lightning 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 hold thei=
r
> 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 man=
y
> users would switch to Lightning in such a scenario, the communication
> around it would be hard. My intuition says that the majority of the curre=
nt
> 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 year=
s
> back. The result was that simply users of the wallets that weren't able t=
o
> pay to bech32 didn't complete the purchase, no support ticket or anything=
,
> just "it didn't work =F0=9F=A4=B7=E2=80=8D=E2=99=82=EF=B8=8F" and user mo=
ved 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 an=
d
> 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) simply
> 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 the
> 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 acces=
s
> to RBF and they know how to handle it, so things are somewhat working. Bu=
t
> 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 lot=
s
> of edge case code to handle abuse vectors: What if users abuse a generous
> CPFP policy to unstuck past transactions or consolidate large wallets. Be=
st
> is for CPFP to be done on the wallet side, not the merchant side, but the=
re
> 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 and
> 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 tha=
n
> 1 in a million" accepted transactions successfully reversed. These days w=
e
> have very few support issues related to bitcoin payments. The few that do
> come in are due to accidental RBF users venting frustration about waiting
> 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
>

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

<div dir=3D"ltr">Hi Sergej,<br><br>Thanks for the insightful posting, espec=
ially highlighting the FX risk which was far from being evident on my side!=
<br><br>I don&#39;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 so=
me mempools reconciliation is exercised<br>and zeroconf candidate sanitize =
against. While I believe this is a far-more robust deployment against doubl=
e-spend attempts, there is still the ability for a sophisticated attacker t=
o &quot;taint&quot; miner mempools, and from then partition judiciously the=
 transaction-relay network to game such distributed mempool monitoring syst=
em. There is also the possibility of an attacker using some &quot;divide-an=
d-conquer&quot; transaction broadcast algorithm to map Bitrefill monitoring=
 point, though as far as I&#39;m aware such algorithm has not been discusse=
d. I agree with all of that, easier said than done.<br><br>(Which let me th=
ink that such distributed mempool monitoring system should be provide some =
enhanced security even in a full-rbf world, that they would require far mor=
e resources than the average node from the p2p network as a whole might be =
a counter-argument for their social acceptance, however I&#39;m also thinki=
ng that a robust Lightning infrastructure of the future might require multi=
ple mempool/transaction-relay endpoints, at least to reduce=C2=A0 cross-lay=
er mapping links, though conversation for another day...).<br><br>About the=
 FX risk itself, this is far from being isolated from 0conf, as Lightning p=
ayments themselves might still have a time lapse between the issuance of in=
voices and the settlement of the HTLC at the payee endpoint. In fact this v=
olatility concern is endured by anyone using Bitcoin regularly in interface=
 with the fiats worlds, i.e everyone excepted the long-term store of wealth=
 crowd. From a merchant perspective, effectively, the options to cover them=
selves against this risk are simple. One could take positions directly in t=
raditional financial derivatives, like doing participants in international =
trades, though it would require an educated manpower on the merchant side. =
Or leveraging some stablecoins derivatives system, coming with its own tech=
nical complexity and social trust hazards. Another direction would be to cl=
early define the responsibility between merchants or users, on whom is the =
FX risk. If it&#39;s on users, they should be the one RBFing/CPFPing to inc=
rease the merchant address output, beyond the fact &quot;dynamic pricing&qu=
ot; would be a weird UX, it would require liveliness from the wallets until=
 block confirmation (introducing here many requirements of a LN wallet). If=
 it&#39;s on the merchants, they could be the ones CPFPing thanks to packag=
e relay, though it would come again with some engineering complexity and ov=
erhead blockspace cost (and the first version of package relay likely won&#=
39;t enable CPFP batching for concerns of potential bandwidth/CPU DoS).<br>=
<br>On the efficacy of RBF, I understand the current approach of assuming &=
quot;manual&quot; RBFing by power users ill UX thinking. I hope in the futu=
re to have automatic fee-bumping implemented by user wallets, where a fee-b=
umping budget and a confirmation preference are pre-defined for all payment=
s, 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. Or at least only rudimentary in the backe=
nd of LN implementations, and only for time-sensitive on-chain claims for n=
ow (or at least speaking for LDK). If we take the history of browsers as a =
comparison, while we might be out of the Lynx-style phase of wallets, we mi=
ght still be more in the late Netscape kind of thing than something like Ch=
rome today. In other words, there are many directions for improvements for =
users&#39; wallets.<br><br>All that said, I learn to converge that as a com=
munity we would be better off to weigh deeper the risks/costs between 0conf=
s applications and contracting protocols in light of full-rbf.<br><br>Best,=
<br>Antoine<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">Le=C2=A0mer. 19 oct. 2022 =C3=A0=C2=A010:33, Sergej Kotliar=
 via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g">bitcoin-dev@lists.linuxfoundation.org</a>&gt; a =C3=A9crit=C2=A0:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_quote"><div dir=3D"ltr">Hi all,<div><br></div><div>Chiming i=
n on this thread as I feel like the real dangers of RBF as default policy a=
ren&#39;t sufficiently elaborated here. It&#39;s not only about the zero-co=
nf (I&#39;ll get to that) but there is an even bigger danger called the ame=
rican call option, which risks endangering the entirety of BIP21 &quot;Scan=
 this QR code with your wallet to buy this product&quot; model that I belie=
ve we&#39;ve all come to appreciate. Specifically, 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-fee transaction and then wait for hou=
rs, 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 r=
isk in accepting bitcoin payments is in fact not zeroconf risk (it&#39;s ac=
tually quite easily managed), it&#39;s FX risk as the merchant must commit =
to a certain BTCUSD rate ahead of time for a purchase. Over time some trans=
actions lose money to FX and others earn money - that evens out in the end.=
 But if there is an _easily accessible in the wallet_ feature to &quot;canc=
el transaction&quot; that means it will eventually get systematically abuse=
d. A risk of X% loss on many payments that&#39;s easy to systematically abu=
se is more scary than a rare risk of losing 100% of one occasional payment.=
 It&#39;s already possible to execute this form of abuse with opt-in RBF, w=
hich may lead to us at some point refusing those payments (even with confir=
mation) or cumbersome UX to work around it, such as crediting the bitcoin t=
o a custodial account.</div><div><br></div><div>To compare zeroconf risk wi=
th FX risk: I think we&#39;ve had one incident in 8 years of operation wher=
e a user successfully fooled our server to accept a payment that in the end=
 didn&#39;t confirm. To successfully fool (non-RBF) zeroconf one needs to h=
ave access to mining infrastructure and probability of success is the % of =
hash rate controlled. This is simply due to the fact that the network curre=
ntly won&#39;t propagage the replacement transaction to the miner, which is=
 what&#39;s being discussed here. American call option risk would however b=
e available to 100% of all users, needs nothing beyond the wallet app, and =
has no cost to the user - only upside.<br></div><div><br></div><div>Bitrefi=
ll currently processes 1500-2000 onchain payments every day. For us, a worl=
d 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 u=
se 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 BTC=
PayServer/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 bitcoin payments. This is very much not n=
othing, and all of us here want Lightning 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 eas=
ier discussion to have when Lightning is at 80%+ of all bitcoin transaction=
s. Currently far too many bitcoin users simply don&#39;t have access to Lig=
htning, and of those that do and hold their own keys Muun is the biggest wa=
llet per our data, not least due to their ease-of-use which is under threat=
 per the OP. It&#39;s hard to assess how many users would switch to Lightni=
ng in such a scenario, the communication around it would be hard. My intuit=
ion says that the majority of the current 85% of bitcoin users that pay onc=
hain would just not use bitcoin anymore, probably shift to an alt. The bene=
fits 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 de=
faulting to bech32 addresses some years back. The result was that simply us=
ers of the wallets that weren&#39;t able to pay to bech32 didn&#39;t comple=
te the purchase, no support ticket or anything, just &quot;it didn&#39;t wo=
rk =F0=9F=A4=B7=E2=80=8D=E2=99=82=EF=B8=8F&quot; and user moved on. We roll=
ed 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=
=C2=A0 is clunky, and requires a certain level of scale to be able to do, w=
e certainly wouldn&#39;t have had the manpower for that when we were starti=
ng out. This why I&#39;m cautious about introducing more such clunkiness ve=
ctors as they are centralizing factors.</div><div><br></div><div>I&#39;m we=
ll aware of the reason for this policy being suggested and the potential pi=
nning attack vector for LN and other smart contracts, but I think these two=
 risks/costs need to be weighed against eachother first and thoroughly disc=
ussed because the costs are non-trivial on both sides.<br clear=3D"all"><di=
v><br></div><div>Sidenote: On the efficacy of RBF to &quot;unstuck&quot; st=
uck transactions</div><div>After interacting with users during high-fee per=
iods I&#39;ve come to not appreciate RBF as a solution to that issue. Most =
users (80% or so) simply don&#39;t have access to that functionality, becau=
se their wallet doesn&#39;t support it, or they use a custodial (exchange) =
wallet etc. Of those that have the feature - only the power users understan=
d how RBF works, and explaining how to do RBF to a non-power-user is just t=
oo complex, for the same reason why it&#39;s complex for wallets to make se=
nsible non-power-user UI around it. Current equilibrium is that mostly only=
 power users have access to RBF and they know how to handle it, so things a=
re somewhat working. But rolling this out to the broad market is something =
else and would likely cause more confusion.=C2=A0</div><div>CPFP is somewha=
t more viable but also not perfect as it would require lots of edge case co=
de to handle abuse vectors: What if users abuse a generous CPFP policy to u=
nstuck past transactions or consolidate large wallets. Best is for CPFP to =
be done on the wallet side, not the merchant side, but there too are the sa=
me UX issues as with RBF.=C2=A0</div><div>In the end a risk-based approach =
to decide on which payments are non-trivial to reverse is the easiest, taki=
ng account user experience and such. Remember that in the fiat world card p=
ayments have up to 5% chargebacks, whereas we in zero-conf bitcoin land we =
deal with &quot;fewer than 1 in a million&quot; accepted transactions succe=
ssfully reversed. These days we have very few support issues related to bit=
coin payments. The few that do come in are due to accidental RBF users vent=
ing frustration about waiting for their tx to confirm.</div><div>&quot;In t=
heory, theory and practice are the same. In practice, they are not&quot;</d=
iv><div><br></div><div>All the best,=C2=A0</div><div>Sergej Kotliar</div><d=
iv>CEO Bitrefill.com</div><div><br></div><div><br></div>-- <br><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"><div dir=3D"ltr"><p dir=3D"ltr" style=3D"line-height:1.38;margin-t=
op:0pt;margin-bottom:0pt"><span style=3D"font-size:9.5pt;font-family:Arial;=
color:rgb(0,0,0);background-color:transparent;font-weight:700;font-style:no=
rmal;font-variant:normal;text-decoration:none;vertical-align:baseline;white=
-space:pre-wrap">Sergej Kotliar</span></p><p dir=3D"ltr" style=3D"line-heig=
ht:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:9.5pt;fo=
nt-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:7=
00;font-style:normal;font-variant:normal;text-decoration:none;vertical-alig=
n: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 style=3D"font-weight:norm=
al"><br></b></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;mar=
gin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:rgb(1=
02,102,102);background-color:transparent;font-weight:700;font-style:normal;=
font-variant:normal;text-decoration:none;vertical-align:baseline;white-spac=
e:pre-wrap"><span style=3D"border:medium none;display:inline-block;overflow=
:hidden;width:220px;height:80px"><img src=3D"https://lh4.googleusercontent.=
com/wU5i7e8boCd7o3P52cUTKrqeTa7jV2dPEXluijGtPBy0f1F0R2_zIg_zOQ2kigkbVbSWqLl=
VdwuBYgo_txXMKkCWdMfBFRNhsDhFpNv1QrRZsD-gPxDui-4l0tZI1QcjtefCDkNG" style=3D=
"margin-left: 0px; margin-top: 0px;" width=3D"220" height=3D"80"></span></s=
pan></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bott=
om:0pt"><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,=
102);background-color:transparent;font-weight:400;font-style:normal;font-va=
riant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-w=
rap">Twitter: @</span><a href=3D"https://twitter.com/ziggamon" style=3D"tex=
t-decoration:none" target=3D"_blank"><span style=3D"font-size:9.5pt;font-fa=
mily:Arial;color:rgb(102,102,102);background-color:transparent;font-weight:=
400;font-style:normal;font-variant:normal;text-decoration:underline;vertica=
l-align:baseline;white-space:pre-wrap">ziggamon</span></a><span style=3D"fo=
nt-size:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:tra=
nsparent;font-weight:400;font-style:normal;font-variant:normal;text-decorat=
ion: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-weight:normal"><br></b></p><p dir=3D"ltr" style=3D"line-heigh=
t:1.38;margin-top:0pt;margin-bottom:0pt"><a href=3D"http://www.bitrefill.co=
m/" style=3D"text-decoration:none" target=3D"_blank"><span style=3D"font-si=
ze:9.5pt;font-family:Arial;color:rgb(102,102,102);background-color:transpar=
ent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:u=
nderline;vertical-align:baseline;white-space:pre-wrap">www.bitrefill.com</s=
pan></a></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-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:rgb(102,102,102);ba=
ckground-color:transparent;vertical-align:baseline;white-space:pre-wrap">Tw=
itter</span></a><span style=3D"font-size:9.5pt;font-family:Arial;color:rgb(=
102,102,102);background-color:transparent;vertical-align:baseline;white-spa=
ce: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;vertical-align:baseline;white-space:p=
re-wrap">Blog</span></a><span style=3D"font-size:9.5pt;font-family:Arial;co=
lor:rgb(102,102,102);background-color:transparent;vertical-align:baseline;w=
hite-space:pre-wrap"> | </span><a href=3D"https://angel.co/bitrefill" targe=
t=3D"_blank"><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">Angellist </span></a><br></p></div></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>

--000000000000c1cf3205eb6d5e38--