diff options
| author | Sergej Kotliar <sergej@bitrefill.com> | 2022-10-20 16:11:48 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-10-20 14:12:06 +0000 |
| commit | 3e629b04895b49b9f5046c5180f116d61ccc0326 (patch) | |
| tree | 593a839da012be40682c3181a885eccd9e3724b6 | |
| parent | 085900985be9931a9a5a0bd616ba2ef4fa6c7437 (diff) | |
| download | pi-bitcoindev-3e629b04895b49b9f5046c5180f116d61ccc0326.tar.gz pi-bitcoindev-3e629b04895b49b9f5046c5180f116d61ccc0326.zip | |
Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
| -rw-r--r-- | 81/3ad7b0d065db1266b9d6cb0d0a822110ec185f | 727 |
1 files changed, 727 insertions, 0 deletions
diff --git a/81/3ad7b0d065db1266b9d6cb0d0a822110ec185f b/81/3ad7b0d065db1266b9d6cb0d0a822110ec185f new file mode 100644 index 000000000..95ec5bc9d --- /dev/null +++ b/81/3ad7b0d065db1266b9d6cb0d0a822110ec185f @@ -0,0 +1,727 @@ +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 <<a href=3D"mailto:antoine.riard@gmail.com">antoine.riard@gmail.c= +om</a>> 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'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 "taint" 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 "divide-= +and-conquer" transaction broadcast algorithm to map Bitrefill monitori= +ng point, though as far as I'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'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 "manual" 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 "= +simply" enforcing the user policy, ideally based on historical mempool= + data. True fact: we don'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't even have access to any RBF functionality today, so we= +'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'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 "even though it doesn't happen it can theoretically be hacke= +d" against "many users find it confusing and stressful" 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's unfortunate that there is= +n't more interaction between the mailing list and services and companie= +s using this stuff day-to-day. Not that it's anyone's fault in part= +icular, let's try from all sides to find more ways to create more inter= +action on these topics. I'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 <<a href=3D"mailto:bitcoin-dev@lists.l= +inuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org= +</a>> 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't sufficiently elaborated here. = +It's not only about the zero-conf (I'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 "Scan this QR code with your wallet to buy th= +is product" model that I believe we'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's actually quite easily managed), it'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 "cancel transaction" that means it will = +eventually get systematically abused. A risk of X% loss on many payments th= +at's easy to systematically abuse is more scary than a rare risk of los= +ing 100% of one occasional payment. It'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'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'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't propagage the replacement= + transaction to the miner, which is what'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'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'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'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't able= + to pay to bech32 didn't complete the purchase, no support ticket or an= +ything, just "it didn't work =F0=9F=A4=B7=E2=80=8D=E2=99=82=EF=B8= +=8F" 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't have had the man= +power for that when we were starting out. This why I'm cautious about i= +ntroducing more such clunkiness vectors as they are centralizing factors.</= +div><div><br></div><div>I'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 "unstuck" stuck transactions</div><div>After interact= +ing 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 a= +ccess to that functionality, because their wallet doesn'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= +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 "fewer than 1 in a million= +" 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>"In theory, theory and practice are the same. = +In practice, they are not"</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-- + + |