From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0F785C002D for ; Thu, 20 Oct 2022 12:38:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id C2D0C41083 for ; Thu, 20 Oct 2022 12:38:11 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org C2D0C41083 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=bbWaxRcs 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 bUVRNzts5PQB for ; Thu, 20 Oct 2022 12:38:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org B27F8405E9 Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by smtp2.osuosl.org (Postfix) with ESMTPS id B27F8405E9 for ; Thu, 20 Oct 2022 12:38:07 +0000 (UTC) Received: by mail-lj1-x231.google.com with SMTP id by36so26159650ljb.4 for ; Thu, 20 Oct 2022 05:38:07 -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=UpROjDSq1yd+waahGJsAEEj4ldx6AZIUnmP1gnUb9w4=; b=bbWaxRcsn8n4c67ioHXEFVDO3InJwy+rk5NapxmHDGJdfavfz2GLo/NlHZ1MSs8FtD kOpzuz1jwhbo6xVYnWbVn5FRrFdJobAGaSQzuC8wfQdunyzAZ9D06L47PBtsbtmUXN90 mJZxCPAPjiyXAz+oChmAPWW4yE32EGeWHRxLpAjYVlX8X0tLYuEF6zEurpq5DoPCaUBo fQVCqlQwbyp8XYauvhOSj4avEWiPmLylMwF+lVjHMd+CLVN9gJ7rPcOCCoucmJumwSyy Ghq2G7uqPUPYCmPcrVB0B1sW+48alGbkCo3iB5QH35NNsD8KypYSG19edzIamTeLYATy ZsFw== 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=UpROjDSq1yd+waahGJsAEEj4ldx6AZIUnmP1gnUb9w4=; b=r6H992cyIVrAZMfclknlwrhTj9cnByKM9wVMrp38LoNfpFzC2Ag5L8nyi6sO9+CPj7 zsy4FJdH3EtZAr+lqZh7cye0GqrGF8OPg/ZuV2sfDK3lP98a+Odv2I5/mc6s8eSuRb+d MYkHasEAQEgsIR9OwgTasEGFibQZF3lm83yqXRSJB4pGPX4hsRNandojA8lJBhWltntk jWBTaXD1QQSX8c5ZYhsSKhKw1dDYGubAfXwB/u2hqJHp4LxGIffAvK9WJDnKAGk916P5 MLeAr01ld9Du2a4o7KPw267tI1nvaclz0dlcwEQ9RwctapS8AHusFVy8FsWa/64yCOMW yQPQ== X-Gm-Message-State: ACrzQf1LtV12k5cet+8jxdWy5lH+b3WtiCyW0gaoRuNkJ4EdcZrxt6Og fKAbb9IHHIowRsd/hzcwDAqtnEDPatG7wg9rIMUbuA== X-Google-Smtp-Source: AMsMyM4UoZceaYNabj4JjmCcTxeqGgf2h9RNN4sormKSDeFVqqA/0QIKTqFWmATGpshIOdigo1eGq+fk99zUCoyfdU4= X-Received: by 2002:a2e:8893:0:b0:26c:2f7f:c037 with SMTP id k19-20020a2e8893000000b0026c2f7fc037mr4915927lji.325.1666269484672; Thu, 20 Oct 2022 05:38:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sergej Kotliar Date: Thu, 20 Oct 2022 14:37:53 +0200 Message-ID: To: Anthony Towns Content-Type: multipart/alternative; boundary="000000000000bc07b705eb769897" X-Mailman-Approved-At: Thu, 20 Oct 2022 12:44:01 +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: Thu, 20 Oct 2022 12:38:12 -0000 --000000000000bc07b705eb769897 Content-Type: text/plain; charset="UTF-8" On Thu, 20 Oct 2022 at 09:22, Anthony Towns wrote: > On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev > wrote: > > The > > biggest risk in accepting bitcoin payments is in fact not zeroconf risk > > (it's actually quite easily managed), > > You mean "it's quite easily managed, provided the transaction doesn't > opt-in to rbf", right? At least, that's what I understood you saying last > time; ie that if the tx signals rbf, then you just don't do zeroconf no > matter what other trustworthy signals you might see: > > https://twitter.com/ziggamon/status/1435863691816275970 > > (rbf txs seem to have increased from 22% then to 29% now) > Yeah. Our share of RBF is a bit lower than that as many RBF transactions are something other than consumer purchases, and most consumer purchases can't do RBF > > 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, > > If someone's going to systematically exploit your store via this > mechanism, it seems like they'd just find a single wallet with a good > UX for opt-in RBF and lowballing fees, and go to town -- not something > where opt-in rbf vs fullrbf policies make any difference at all? > Sort of. But yes once this starts being abused systemically we will have to do something else w RBF payments, such as crediting the amount in BTC to a custodial account. But this option isn't available to your normal payment processor type business. Also worth keeping in mind that sometimes "opportunity makes the thief". Currently only power-user wallet have that feature and their market share is relatively small, mainly electrum stands out. But if this is available to all users everywhere then it will start being abused and we'll have to then direct all payments to custodial account, or some other convoluted solution. > It's not like existing wallets that don't let you set RBF will suddenly > get a good UX for replacing transactions just because they'd be relayed > if they did, is it? > > > To successfully fool (non-RBF) > > zeroconf one needs to have access to mining infrastructure and > probability > > of success is the % of hash rate controlled. > > I thought the "normal" avenue for fooling non-RBF zeroconf was to create > two conflicting txs in advance, one paying the merchant, one paying > yourself, connect to many peers, relay the one paying the merchant to > the merchant, and the other to everyone else. > > I'm just basing this off Peter Todd's stuff from years ago: > > > https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/ > > > https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py > > Yeah, I know the list still rehashes a single incident from 10 years ago to declare the entire practice as unsafe, and ignores real-world data that of the last million transactions we had zero cases of this successfully abusing us. > > Currently Lightning is somewhere around 15% of our total bitcoin > payments. > > So, based on last year's numbers, presumably that makes your bitcoin > payments break down as something like: > > 5% txs are on-chain and seem shady and are excluded from zeroconf > 15% txs are lightning > 20% txs are on-chain but signal rbf and are excluded from zeroconf > 60% txs are on-chain and seem fine for zeroconf > Numbers are right. Shady is too strong a word, it's mostly transactions with very low fee, or high purchase amount, or many dependent unconfirmed transactions, stuff like that. In some cases we do a human assessment of the support ticket and often just pass them through. > > 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. > > If the numbers above were accurate, this would just mean you'd go from 60% > zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain. > Point is that RBF transactions are unsafe even when waiting for a confirmation, which Peter Todd trivially proved in the reply next to this. The reliable solution is to reject all RBF payments and direct those users to custodial accounts. There are other variants to solve this with varying degree of convolutedness. RBF is a strictly worse UX as proven by anyone accepting bitcoin payments at scale. > > For me > > personally it would be an easier discussion to have when Lightning is at > > 80%+ of all bitcoin transactions. > > Can you extrapolate from the numbers you've seen to estimate when that > might be, given current trends? > Not sure, it might be exponential growth, and the next 60% of Lightning growth happen faster than the first 15%. Hard to tell. But we're likely talking years here.. > > > The benefits of Lightning are many and obvious, > > we don't need to limit onchain to make Lightning more appealing. > > To be fair, I think making lightning (and coinjoins) work better is > exactly what inspired this -- not as a "make on-chain worse so we look > better in comparison", but as a "making lightning work well is a bunch > of hard problems, here's the next thing we need in order to beat the > next problem". > In deed. The fact that the largest non-custodial Lightning wallet started this thread should be an indicator that despite these intentions the solution harms more than it fixes. Transactions being evicted from mempool is solved by requiring a minimum fee rate, which we do and now seems to have become a standard practice. Theoretically we can imagine them being evicted anyway but now we're several theoreticals deep again when discussing something that will cause massive problems right away. In emergency situations CPFP and similar can of course be done manually in special circumstances. Cheers Sergej On Thu, 20 Oct 2022 at 09:22, Anthony Towns wrote: > On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev > wrote: > > The > > biggest risk in accepting bitcoin payments is in fact not zeroconf risk > > (it's actually quite easily managed), > > You mean "it's quite easily managed, provided the transaction doesn't > opt-in to rbf", right? At least, that's what I understood you saying last > time; ie that if the tx signals rbf, then you just don't do zeroconf no > matter what other trustworthy signals you might see: > > https://twitter.com/ziggamon/status/1435863691816275970 > > (rbf txs seem to have increased from 22% then to 29% now) > > > 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, > > If someone's going to systematically exploit your store via this > mechanism, it seems like they'd just find a single wallet with a good > UX for opt-in RBF and lowballing fees, and go to town -- not something > where opt-in rbf vs fullrbf policies make any difference at all? > > It's not like existing wallets that don't let you set RBF will suddenly > get a good UX for replacing transactions just because they'd be relayed > if they did, is it? > > > To successfully fool (non-RBF) > > zeroconf one needs to have access to mining infrastructure and > probability > > of success is the % of hash rate controlled. > > I thought the "normal" avenue for fooling non-RBF zeroconf was to create > two conflicting txs in advance, one paying the merchant, one paying > yourself, connect to many peers, relay the one paying the merchant to > the merchant, and the other to everyone else. > > I'm just basing this off Peter Todd's stuff from years ago: > > > https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/ > > > https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py > > > Currently Lightning is somewhere around 15% of our total bitcoin > payments. > > So, based on last year's numbers, presumably that makes your bitcoin > payments break down as something like: > > 5% txs are on-chain and seem shady and are excluded from zeroconf > 15% txs are lightning > 20% txs are on-chain but signal rbf and are excluded from zeroconf > 60% txs are on-chain and seem fine for zeroconf > > > 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. > > If the numbers above were accurate, this would just mean you'd go from 60% > zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain. > > > For me > > personally it would be an easier discussion to have when Lightning is at > > 80%+ of all bitcoin transactions. > > Can you extrapolate from the numbers you've seen to estimate when that > might be, given current trends? Or perhaps when fine-for-zeroconf txs > drop to 20%, since opt-in-RBF txs and considered-unsafe txs would still > work the same in a fullrbf world. > > > The benefits of Lightning are many and obvious, > > we don't need to limit onchain to make Lightning more appealing. > > To be fair, I think making lightning (and coinjoins) work better is > exactly what inspired this -- not as a "make on-chain worse so we look > better in comparison", but as a "making lightning work well is a bunch > of hard problems, here's the next thing we need in order to beat the > next problem". > > > 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 > 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 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 merchant side, but > there > > too are the same UX issues as with RBF. > > I think if you're ruling out both merchants and users being able to add > fees to a tx to get it to confirm, then you're going to lose either way. > Txs will either expire because they've been stuck for more than a week, > and be vulnerable to replacement at that point anyway, or they'll be > dropped from mempools because they've filled up and they were the lowest > fee tx, and be vulnerable to replacement for that reason. In the expiry > case, the merchant can rebroadcast the original transaction to keep it > alive, perhaps with a good chance of beating an attacker to the punch, > but in the full mempool case, you could only do that if you were also > CPFPing it, which you already ruled out. > > Cheers, > aj > -- Sergej Kotliar CEO Twitter: @ziggamon www.bitrefill.com Twitter | Blog | Angellist --000000000000bc07b705eb769897 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj@erisian.com.au> w= rote:
On Wed, Oc= t 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev wrote:
&g= t; The
> biggest risk in accepting bitcoin payments is in fact not ze= roconf risk
> (it's actually quite easily managed),

You me= an "it's quite easily managed, provided the transaction doesn'= t
opt-in to rbf", right? At least, that's what I understood you= saying last
time; ie that if the tx signals rbf, then you just don'= t do zeroconf no
matter what other trustworthy signals you might see:
=C2=A0=C2=A0https://twitter.com/ziggamon= /status/1435863691816275970

(rbf txs seem to have increased from= 22% then to 29% now)

Yeah. Our = share of RBF is a bit lower than that as many RBF transactions are somethin= g other than consumer purchases, and most consumer purchases can't do R= BF
=C2=A0
> 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 o= thers earn money - that evens out
> in the end.

> But if th= ere 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 systematical= ly
> abuse is more scary than a rare risk of losing 100% of one occas= ional
> payment. It's already possible to execute this form of ab= use with opt-in
> RBF,

If someone's going to systematicall= y exploit your store via this
mechanism, it seems like they'd just f= ind a single wallet with a good
UX for opt-in RBF and lowballing fees, a= nd go to town -- not something
where opt-in rbf vs fullrbf policies make= any difference at all?

Sort of.= But yes once this starts being abused systemically we will have to do some= thing else w RBF payments, such as crediting the amount in BTC to a custodi= al account. But this option isn't available to your normal payment proc= essor type business.=C2=A0

Also worth keeping in m= ind that sometimes "opportunity makes the thief". Currently only = power-user wallet have that feature and their market share is relatively sm= all, mainly electrum stands out. But if this is available to all users ever= ywhere then it will start being abused and we'll have to then direct al= l payments to custodial account, or some other convoluted solution.
=C2=A0
It's not like existing wall= ets that don't let you set RBF will suddenly
get a good UX for repla= cing transactions just because they'd be relayed
if they did, is it?=

> To successfully fool (non-RBF)
> zeroconf one needs to h= ave access to mining infrastructure and probability
> of success is t= he % of hash rate controlled.

I thought the "normal" avenu= e for fooling non-RBF zeroconf was to create
two conflicting txs in adva= nce, one paying the merchant, one paying
yourself, connect to many peers= , relay the one paying the merchant to
the merchant, and the other to ev= eryone else.

I'm just basing this off Peter Todd's stuff fro= m years ago:

https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_to= dd_with_my_doublespendpy_tool_with/cytlhh0/

https://github.com/petertodd/replace-by-fee-= tools/blob/master/doublespend.py=C2=A0

<= /span>
Yeah, I know the list still rehashes a single incident from 10 y= ears ago to declare the entire practice as unsafe, and ignores real-world d= ata that of the last million transactions we had zero cases of this success= fully abusing us.
=C2=A0
> C= urrently Lightning is somewhere around 15% of our total bitcoin payments.
So, based on last year's numbers, presumably that makes your bitc= oin
payments break down as something like:

=C2=A0 =C2=A05% txs ar= e on-chain and seem shady and are excluded from zeroconf
=C2=A0 15% txs = are lightning
=C2=A0 20% txs are on-chain but signal rbf and are exclude= d from zeroconf
=C2=A0 60% txs are on-chain and seem fine for zeroconf

Numbers are right. Shady is too s= trong a word, it's mostly transactions with very low fee, or high purch= ase amount, or many dependent unconfirmed transactions, stuff like that. In= some cases we do a human assessment of the support ticket and often just p= ass them through.=C2=A0
=C2=A0
= > This is very much not nothing, and all of us here want Lightning to gr= ow,
> but I think it warrants a serious discussion on whether we want= Lightning
> adoption to go to 100% by means of disabling on-chain co= mmerce.

If the numbers above were accurate, this would just mean you= 'd go from 60%
zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn= 't be 0% on-chain.

Point is = that RBF transactions are unsafe even when waiting for a confirmation, whic= h Peter Todd trivially proved in the reply next to this. The reliable solut= ion is to reject all RBF payments and direct those users to custodial accou= nts. There are other variants to solve this with varying degree of convolut= edness. RBF is a strictly worse UX as proven by anyone accepting bitcoin pa= yments at scale.
=C2=A0
> Fo= r me
> personally it would be an easier discussion to have when Light= ning is at
> 80%+ of all bitcoin transactions.

Can you extrapo= late from the numbers you've seen to estimate when that
might be, gi= ven current trends?=C2=A0

Not su= re, it might be exponential growth, and the next 60% of Lightning growth ha= ppen faster than the first 15%. Hard to tell. But we're likely talking = years here..=C2=A0
=C2=A0

&= gt; The benefits of Lightning are many and obvious,
> we don't ne= ed to limit onchain to make Lightning more appealing.

To be fair, I = think making lightning (and coinjoins) work better is
exactly what inspi= red this -- not as a "make on-chain worse so we look
better in comp= arison", but as a "making lightning work well is a bunch
of ha= rd problems, here's the next thing we need in order to beat the
next= problem".

In deed. The fac= t that the largest non-custodial Lightning wallet started this thread shoul= d be an indicator that despite these intentions the solution harms more tha= n it fixes.
Tr= ansactions being evicted from mempool is solved by requiring a minimum fee = rate, which we do and now seems to have become a=C2=A0standard practice. Th= eoretically we can imagine them being evicted anyway but now we're seve= ral theoreticals deep again when discussing something that will cause massi= ve problems right away. In emergency situations CPFP and similar can of cou= rse be done manually in special=C2=A0circumstances.
=C2=A0
<= div>Cheers
Sergej


On Thu, 20 Oct 2022 at 09:22, Anthony Towns <aj@erisian.com.au> wrote:
On Wed, Oct 19, 2022 at 04:29:57PM +0200, = Sergej Kotliar via bitcoin-dev wrote:
> The
> biggest risk in accepting bitcoin payments is in fact not zeroconf ris= k
> (it's actually quite easily managed),

You mean "it's quite easily managed, provided the transaction does= n't
opt-in to rbf", right? At least, that's what I understood you sayi= ng last
time; ie that if the tx signals rbf, then you just don't do zeroconf no=
matter what other trustworthy signals you might see:

=C2=A0 https://twitter.com/ziggamon/status/14= 35863691816275970

(rbf txs seem to have increased from 22% then to 29% now)

> it's FX risk as the merchant must
> commit to a certain BTCUSD rate ahead of time for a purchase. Over tim= e
> 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 syste= matically
> abused. A risk of X% loss on many payments that's easy to systemat= ically
> abuse is more scary than a rare risk of losing 100% of one occasional<= br> > payment. It's already possible to execute this form of abuse with = opt-in
> RBF,

If someone's going to systematically exploit your store via this
mechanism, it seems like they'd just find a single wallet with a good UX for opt-in RBF and lowballing fees, and go to town -- not something
where opt-in rbf vs fullrbf policies make any difference at all?

It's not like existing wallets that don't let you set RBF will sudd= enly
get a good UX for replacing transactions just because they'd be relayed=
if they did, is it?

> To successfully fool (non-RBF)
> zeroconf one needs to have access to mining infrastructure and probabi= lity
> of success is the % of hash rate controlled.

I thought the "normal" avenue for fooling non-RBF zeroconf was to= create
two conflicting txs in advance, one paying the merchant, one paying
yourself, connect to many peers, relay the one paying the merchant to
the merchant, and the other to everyone else.

I'm just basing this off Peter Todd's stuff from years ago:

h= ttps://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespe= ndpy_tool_with/cytlhh0/

https://github.com/peter= todd/replace-by-fee-tools/blob/master/doublespend.py

> Currently Lightning is somewhere around 15% of our total bitcoin payme= nts.

So, based on last year's numbers, presumably that makes your bitcoin payments break down as something like:

=C2=A0 =C2=A05% txs are on-chain and seem shady and are excluded from zeroc= onf
=C2=A0 15% txs are lightning
=C2=A0 20% txs are on-chain but signal rbf and are excluded from zeroconf =C2=A0 60% txs are on-chain and seem fine for zeroconf

> This is very much not nothing, and all of us here want Lightning to gr= ow,
> but I think it warrants a serious discussion on whether we want Lightn= ing
> adoption to go to 100% by means of disabling on-chain commerce.

If the numbers above were accurate, this would just mean you'd go from = 60%
zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.=

> For me
> personally it would be an easier discussion to have when Lightning is = at
> 80%+ of all bitcoin transactions.

Can you extrapolate from the numbers you've seen to estimate when that<= br> might be, given current trends? Or perhaps when fine-for-zeroconf txs
drop to 20%, since opt-in-RBF txs and considered-unsafe txs would still
work the same in a fullrbf world.

> The benefits of Lightning are many and obvious,
> we don't need to limit onchain to make Lightning more appealing. <= br>
To be fair, I think making lightning (and coinjoins) work better is
exactly what inspired this -- not as a "make on-chain worse so we look=
better in comparison", but as a "making lightning work well is a = bunch
of hard problems, here's the next thing we need in order to beat the next problem".

> Sidenote: On the efficacy of RBF to "unstuck" stuck transact= ions
> 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) sim= ply
> don't have access to that functionality, because their wallet does= n't
> support it, or they use a custodial (exchange) wallet etc. Of those th= at
> have the feature - only the power users understand how RBF works, and<= br> > 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-powe= r-user UI
> around it. Current equilibrium is that mostly only power users have ac= cess
> 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 likel= y
> 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 gener= ous
> CPFP policy to unstuck 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 same UX issues as with RBF.

I think if you're ruling out both merchants and users being able to add=
fees to a tx to get it to confirm, then you're going to lose either way= .
Txs will either expire because they've been stuck for more than a week,=
and be vulnerable to replacement at that point anyway, or they'll be dropped from mempools because they've filled up and they were the lowes= t
fee tx, and be vulnerable to replacement for that reason. In the expiry
case, the merchant can rebroadcast the original transaction to keep it
alive, perhaps with a good chance of beating an attacker to the punch,
but in the full mempool case, you could only do that if you were also
CPFPing it, which you already ruled out.

Cheers,
aj


--

Sergej Kotliar

CEO


Twitter: @ziggamon=C2= =A0


www= .bitrefill.com

Twitter | Blog | Angellist

--000000000000bc07b705eb769897--