Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id D1E3CC002D for ; Wed, 19 Oct 2022 16:04:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id ACFFA40C8E for ; Wed, 19 Oct 2022 16:04:48 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org ACFFA40C8E Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=bitrefill.com header.i=@bitrefill.com header.a=rsa-sha256 header.s=b header.b=WjnYnqHW 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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ieG8Kx-IGgb for ; Wed, 19 Oct 2022 16:04:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 3872840138 Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by smtp2.osuosl.org (Postfix) with ESMTPS id 3872840138 for ; Wed, 19 Oct 2022 16:04:46 +0000 (UTC) Received: by mail-lf1-x12d.google.com with SMTP id b1so28898141lfs.7 for ; Wed, 19 Oct 2022 09:04:46 -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=V50hQ69xBqvc7SEnS63TSrKhzuOvlFdHmdVEdIak9Zw=; b=WjnYnqHWuuwnGyKHe7TAaB4h+i9x/yJ8ertl8oARo5sERH486bRI7mLtsK/hRbdcdP Mo7c270ScBQbZH9CHufvMqI4BqxUi1c4IcIGUyK2yIdz3wWniMFW3W0xanZX8QfQeNBL SXsnVogIrfCMyDKS+Zigejxnvbm8maZAIL2YswkjzThHJ50HGbQ83uvMxf0OCfjXr8mn JVyn3Y4Lx7wEESk0zAb7qPGXdWx/GWfcIzOsmnHvxJAmHHQsWhmnPjU1+C1uzsZs9wBd wB8Ntd6Yk2rtiDtTAF9FLDOZbbxutjVOS5PWuy8088jp+yDJaxcZPwqy6FF6XkEZMkR3 fq+A== 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=V50hQ69xBqvc7SEnS63TSrKhzuOvlFdHmdVEdIak9Zw=; b=w79HwdbGFVW8ScG+E1RDpsqOBC2mIWGdLeoAKuQbnRHyoe7U8XdZ39PgOPkKLd8Osw F1kI17UQNh0wM9LHzbeEi56vlrKovpAofZR7QY4doozE0ysJEOJ5sUMcnuPubG7uZApq AMtn/I71qxlWDI335jN8eWloGJyZhDNmXkW6AcCQs6axoln4K3Cn/aZA0pQIa1nkz6MK oSCs1uxhWsBfTCYPQ7JGp6LstemVS6GteRN/qJWdkPZ8vmz7JGIZZJyNYuz5x5F9mnhV ThyL5pbLNHiS2/XJaF8qCU/FNYeL0dS5kHed/JASN7p7hEvE15Q33mIzdJ7LKtsQraob 3H8A== X-Gm-Message-State: ACrzQf1ayNDaT9G/6CV+AP2BHb96N9PG4iijNOfUBgl4Oi2ytyBCQ3Dz 8eKoPHtNy+XS8R6tBASTo4q4ZQuC8H3qHmDvdv4BAg== X-Google-Smtp-Source: AMsMyM56DT7GZcfdmamVkCQVYuxzZ5AgOKhktZRgu+Vs0wtFv8cZ/SWDONG7G/e8VaUuc/D4BKspmEf05rGNZdq4sfA= X-Received: by 2002:a05:6512:4019:b0:4a2:f25:4214 with SMTP id br25-20020a056512401900b004a20f254214mr3017863lfb.94.1666195482377; Wed, 19 Oct 2022 09:04:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sergej Kotliar Date: Wed, 19 Oct 2022 18:04:30 +0200 Message-ID: To: Jeremy Rubin Content-Type: multipart/alternative; boundary="000000000000da951705eb655d34" X-Mailman-Approved-At: Wed, 19 Oct 2022 16:05:13 +0000 Cc: Bitcoin Protocol Discussion 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 16:04:48 -0000 --000000000000da951705eb655d34 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's an interesting idea, presumably it would work w the new package relay. Scorched earth bidding war is definitely fine to deter this type of abuse. Need to consider it more thoroughly from all sides tho. CPFP on the server side generally has a couple of downsides: * Requires a hot wallet to receive bitcoin * an entity that is reliably known to do CPFP can be abused by people looking to consolidate utxos, which can be quite costly. Might be solvable with a set of conditionals, and bad UX for abusers is less of a concern :) Will follow up after more deliberation, thanks! On Wed, 19 Oct 2022 at 17:43, Jeremy Rubin wrote= : > 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 y= ou > 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 = 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 >> >> >> 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 >> > --=20 Sergej Kotliar CEO Twitter: @ziggamon www.bitrefill.com Twitter | Blog | Angellist --000000000000da951705eb655d34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's an interesting idea, presumably it would work w t= he new package relay.
Scorched earth bidding war is definitely fine to = deter this type of abuse.
Need to consider it more thoroughly fro= m all sides tho. CPFP on the server side generally has a couple of downside= s:
* Requires a hot wallet to receive bitcoin
* an enti= ty that is reliably known to do CPFP can be abused by people looking to con= solidate utxos, which can be quite costly. Might be solvable with a set of = conditionals, and bad UX for abusers is less of a concern :)

=
Will follow up after more deliberation,=C2=A0thanks!
<= br>

On Wed, 19 Oct 2022 at 17:43, Jeremy Rubin <jeremy.l.rubin@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
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 &= lt;bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi all,

Chiming in on this thr= ead as I feel like the real dangers of RBF as default policy aren't suf= ficiently elaborated 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 op= tion, 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 an= d 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 hours, days or e= ven longer, and see whether BTCUSD moves. If BTCUSD moves up, user can canc= el his transaction and make a new - cheaper one. The biggest risk in accept= ing 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 transactio= n" that means it will eventually get systematically abused. A risk of = X% loss on many payments that's easy to systematically abuse is more sc= ary than a rare risk of losing 100% of one occasional payment. It's alr= eady possible to execute this form of abuse with opt-in RBF, which may lead= to us at some point refusing those payments (even with confirmation) or cu= mbersome 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 succ= essfully fooled our server to accept a payment that in the end didn't c= onfirm. To successfully fool (non-RBF) zeroconf one needs to have access to= mining infrastructure and probability of success is the % of hash rate con= trolled. This is simply due to the fact that the network currently won'= t propagage the replacement transaction to the miner, which is what's b= eing discussed here. American call option risk would however be available t= o 100% of all users, needs nothing beyond the wallet app, and has no cost t= o the user - only upside.

Bitrefill currently = processes 1500-2000 onchain payments every day. For us, a world where bitco= in 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.=C2=A0
=
This option is however not available for your typical BTCPayServer/Coi= nGate/Bitpay/IBEX/OpenNode et al. Would be great to hear from other merchan= ts or payment providers how they see this new behavior and how they would c= ounteract it.

Currently Lightning is somewhere aro= und 15% of our total bitcoin payments. This is very much not nothing, and a= ll of us here want Lightning to grow, but I think it warrants a serious dis= cussion on whether we want Lightning adoption to go to 100% by means of dis= abling on-chain commerce. For me personally it would be an easier discussio= n 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 o= f those that do and hold 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 communication around it would be hard. My intuition says that= the majority of the current 85% of bitcoin users that pay onchain would ju= st not use bitcoin anymore, probably shift to an alt. The benefits of Light= ning are many and obvious, we don't need to limit onchain to make Light= ning more appealing. As an anecdote, we did experiment with defaulting to b= ech32 addresses some years back. The result was that simply users of the wa= llets that weren't able to pay to bech32 didn't complete the purcha= se, 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 moved on. We rolled it back, = and later implemented a wallet selector to allow modern wallets to pay to b= ech32 while other wallets can pay to P2SH. This type of thing=C2=A0 is clun= ky, and requires a certain level of scale to be able to do, we certainly wo= uldn't have had the manpower for that when we were starting out. This w= hy I'm cautious about introducing more such clunkiness vectors as they = are centralizing factors.

I'm well aware of th= e reason for this policy being suggested and the potential pinning attack v= ector for LN and other smart contracts, but I think these two risks/costs n= eed to be weighed against eachother first and thoroughly discussed because = the costs are non-trivial on both sides.

Sidenote: On the efficacy of RBF to "unstuck" stuck transactio= ns
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 walle= t 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 work= s, and explaining how to do RBF to a non-power-user is just too complex, fo= r the same reason why it's complex for wallets to make sensible non-pow= er-user UI around it. Current equilibrium is that mostly only power users h= ave access to RBF and they know how to handle it, so things are somewhat wo= rking. But rolling this out to the broad market is something else and would= likely cause more confusion.=C2=A0
CPFP is somewhat more viable = but also not perfect as it would require lots of edge case code to handle a= buse vectors: What if users abuse a generous CPFP policy to unstuck past tr= ansactions or 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 a= s with RBF.=C2=A0
In the end a risk-based approach to decide on w= hich payments are non-trivial to reverse is the easiest, taking account use= r experience and such. Remember that in the fiat world card payments have u= p to 5% chargebacks, whereas we in zero-conf bitcoin land we deal with &quo= t;fewer than 1 in a million" accepted transactions successfully revers= ed. These days we have very few support issues related to bitcoin payments.= The few that do come in are due to accidental RBF users venting frustratio= n about waiting for their tx to confirm.
"In theory, theory = and practice are the same. In practice, they are not"

All the best,=C2=A0
Sergej Kotliar
CEO Bitrefi= ll.com


--

Sergej Kotliar

CEO


Twitter: @ziggamon=C2=A0


w= ww.bitrefill.com

Twitter | Blog= | Angellist

<= /div>


--

= Sergej Kotliar

CEO


<= 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">

Twitter: @ziggamon=C2=A0


www.= bitrefill.com

Twitter | Blog |= Angellist

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


--

Sergej Kotliar

CEO


Twitter: @ziggamon=C2= =A0


www= .bitrefill.com

Twitter | Blog | Angellist

--000000000000da951705eb655d34--