Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id EBBE5C002D for ; Wed, 19 Oct 2022 15:43:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id C72DE81368 for ; Wed, 19 Oct 2022 15:43:43 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C72DE81368 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=JYZkH1p8 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 smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj4uSO--oGUc for ; Wed, 19 Oct 2022 15:43:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E3B498134B Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by smtp1.osuosl.org (Postfix) with ESMTPS id E3B498134B for ; Wed, 19 Oct 2022 15:43:41 +0000 (UTC) Received: by mail-yb1-xb31.google.com with SMTP id y72so3404177yby.13 for ; Wed, 19 Oct 2022 08:43:41 -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=txm3n7P78BVEUf5kGFhIFtTBJey8rte75VLBC1TheIU=; b=JYZkH1p8xv/hiwgoyhtft5u2MJWHAG3n2E5IoYvS7lU2pb739RP8n0oRwka+GlJaWC 2LPHEzzyoDpkjKBsWhhe9L5hfKXwGka+MWoMXn2u7P4WEnfWM9lqzfO2XC3+KSu5I0NP jQbZLu1Xmwr3AL0AJEqE0019IkcVFLplzXfrdvl6E44H9Y1n1Nq0rPCmMP4ODPfUpOJ4 fMu8wElag/k984ckhPnd4qYZp6IFGPl27vcgXyUq2jbhASP8nbtUF59Req/FX4jNcSqG h/zKblu2WAR39EnPprLclaQ8oOHZiBTTvmkDQAIgqUnDSjhm0rIG2eGX1QYyo3RRGNiN 8gEw== 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=txm3n7P78BVEUf5kGFhIFtTBJey8rte75VLBC1TheIU=; b=1MYkPh+BNxsDJwOLdfSoccrrS5MvxDDLXC8T65R10IA7k/XQqqpTkEmUe/Ulx9hbPA dCHRzofdFqJupHaO6bO/6g1/rJCbdHgPEIIXIZXhtZz+uuEIVX9aAkS4kPlui9B7qrQl 52PQtQMVYgy6dlOASEWPsc32IDPgL36SnnqTOgU0uV5J17DA3q45clliP0y/swHRXtJE H6R6pts2eH5DnV27cuOxFSNh5rZR57XLquBdZDjrXcXlyl9KF/jdf6taj+UqD7QvSM8i xGmWmDEL6Rq75Uc4FlIvm9mMjkV3Y1eUxeCc1kNn1irSuS9a5DJL4CUzbzdMmNPbhO6A n68A== X-Gm-Message-State: ACrzQf16pa3U1TdsLXKJDzxfpEgWJUZw4ANKSuLK5VlMOEbcRJLuA6Hv ibVqlDrLQkMCrRyqWkMpAW3uLVd2Il9CNlbtEcs= X-Google-Smtp-Source: AMsMyM7J8ROMwKmaxihLbO0i/fKquDD4r2IZNhvGYGLok2DPJcl7nsfBKY6yaLXuClW6+9Qzf2aojL/xGEVP5tICO2Y= X-Received: by 2002:a25:c704:0:b0:6c1:9494:f584 with SMTP id w4-20020a25c704000000b006c19494f584mr7375788ybe.98.1666194220706; Wed, 19 Oct 2022 08:43:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Rubin Date: Wed, 19 Oct 2022 08:43:28 -0700 Message-ID: To: Sergej Kotliar , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000a6f05505eb651273" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2022 15:43:44 -0000 --000000000000a6f05505eb651273 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If they do this to you, and the delta is substantial, can't you sweep all such abusers with a cpfp transaction replacing their package and giving you the original txn? On Wed, Oct 19, 2022, 7:33 AM Sergej Kotliar via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > > > www.bitrefill.com > > Twitter | Blog > | Angellist > > > -- > > Sergej Kotliar > > CEO > > > Twitter: @ziggamon > > > www.bitrefill.com > > Twitter | Blog > | Angellist > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000a6f05505eb651273 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If they do this to you, and the delta is substantial, can= 't you sweep all such abusers with a cpfp transaction replacing their p= ackage and giving you the original txn?

On Wed, Oct 19, 2022, 7:33 AM Sergej= Kotliar via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi all,

Chiming in on this thread as I fe= el like the real dangers of RBF as default policy aren't sufficiently e= laborated here. It's not only about the zero-conf (I'll get to that= ) but there is an even bigger danger called the 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 tran= sactions in the mempools (which is where RBF would come in handy), a user c= an 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 tran= saction and make a new - cheaper one. The biggest risk in accepting bitcoin= payments is in fact not zeroconf risk (it's actually quite easily mana= ged), 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 _eas= ily accessible in the wallet_ feature to "cancel transaction" tha= t 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 possib= le to execute this form of abuse with opt-in RBF, which may lead to us at s= ome point refusing those payments (even with 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&#= 39;ve had one incident in 8 years of operation where a user successfully fo= oled 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 inf= rastructure and probability of success is the % of hash rate controlled. Th= is is simply due to the fact that the network currently won't propagage= the replacement transaction to the miner, which is what's being discus= sed here. American call option risk would however be available to 100% of a= ll users, needs nothing beyond the wallet app, and has no cost to the user = - only upside.

Bitrefill currently processes 1= 500-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 mode= l for onchain payments, instruct Bitcoin users to use Lightning or deposit = onchain BTC to a custodial account that we have.=C2=A0
This o= ption is however not available for your typical BTCPayServer/CoinGate/Bitpa= y/IBEX/OpenNode et al. Would be great to hear from other merchants or payme= nt providers how they see this new behavior and how they would counteract i= t.

Currently Lightning is somewhere around 15% of = our total bitcoin payments. This is very much not nothing, and all of us he= re 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-c= hain commerce. For me personally it would be an easier discussion to have w= hen Lightning is at 80%+ of all bitcoin transactions. Currently far too man= y bitcoin users simply don't have access to Lightning, and of those tha= t do and hold their own keys Muun is the biggest wallet per our data, not l= east due to their ease-of-use which is under threat per the OP. It's ha= rd to assess how many users would switch to Lightning in such a scenario, t= he communication around it would be hard. My intuition says that the majori= ty of the current 85% of bitcoin users that pay onchain would just not use = bitcoin anymore, probably shift to an alt. The benefits of Lightning are ma= ny and obvious, we don't need to limit onchain to make Lightning more a= ppealing. As an anecdote, we did experiment with defaulting to bech32 addre= sses 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 supp= ort ticket or anything, 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 im= plemented 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 requ= ires a certain level of scale to be able to do, we certainly wouldn't h= ave had the manpower for that when we were starting out. This why I'm c= autious about introducing more such clunkiness vectors as they are centrali= zing 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 we= ighed against eachother first and thoroughly discussed because the costs ar= e 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 d= on'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 expla= ining how to do RBF to a non-power-user is just too complex, for the same r= eason why it's complex for wallets to make sensible non-power-user UI a= round it. Current equilibrium is that mostly only power users have access t= o RBF and they know how to handle it, so things are somewhat working. But r= olling this out to the broad market is something else and would likely caus= e more confusion.=C2=A0
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 o= r consolidate large wallets. Best is for CPFP to be done on the wallet side= , not the merchant side, but there too are the same UX issues as with RBF.= =C2=A0
In the end a risk-based approach to decide on which paymen= ts are non-trivial to reverse is the easiest, taking account user experienc= e and such. Remember that in the fiat world card payments have up to 5% cha= rgebacks, whereas we in zero-conf bitcoin land we deal with "fewer tha= n 1 in a million" accepted transactions successfully reversed. These d= ays we have very few support issues related to bitcoin payments. The few th= at do come in are due to accidental RBF users venting frustration about wai= ting for their tx to confirm.
"In theory, theory and practic= e are the same. In practice, they are not"

Al= l the best,=C2=A0
Sergej Kotliar
CEO Bitrefill.com


--

Sergej Kotliar

CEO


Twitter: = @ziggamon= =C2=A0


www.bitrefill.com

| Blog | Angellist
=



--
<= div dir=3D"ltr">

Sergej Kotliar

CEO


Tw= itter: @ziggamon=C2=A0


www.bitrefill.com=

Twitter | Blog | Angellist <= /a>

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000a6f05505eb651273--