path: root/16/fa235826f274e61acd526f875ac555369f5166

Return-Path: <gsanders87@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6D741C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Oct 2022 14:01:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 4E3F442413
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Oct 2022 14:01:18 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4E3F442413
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=ivQsvev3
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.838
X-Spam-Level: 
X-Spam-Status: No, score=-1.838 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_ENVFROM_END_DIGIT=0.25, 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 smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id jn0cyJPy7ZTf
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Oct 2022 14:01:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org B522B42412
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
 [IPv6:2a00:1450:4864:20::531])
 by smtp4.osuosl.org (Postfix) with ESMTPS id B522B42412
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Oct 2022 14:01:15 +0000 (UTC)
Received: by mail-ed1-x531.google.com with SMTP id u21so6193431edi.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Oct 2022 07:01:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=QWY3mB149505HhxmZo0wHQzSiNnrUXABUYbHjAAKN74=;
 b=ivQsvev3407EQmepmDcmSeRapuYDLsvJcWbwuxfRxuEA3sZ2t+uf1M0ZiWLN2pPshQ
 pyUovp2I0HEFFgSwmK67JbpVogluwVjfsaI5/4qKTkoPHfh0V4Q7GuD8sAamtYP99Q9u
 9vbF+7ym3hC0CF/TZbGCJErX+XmhdZxGgXwDckGAavOvRwYDwG40ipzUCjlKYZzguwF3
 98n4WthglPr1qsW3GVA50wb3ovfb3+uGUm6CJUzWnOr4K+CNwcvjmmYWQLBunOLYQuto
 ZUFTFxhvFYB6GgfYlBzDS0l7BlgfZNaanXkcT9ToA+QtrTU73jFjtYZGIwZCgP3Tm51L
 woFA==
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=QWY3mB149505HhxmZo0wHQzSiNnrUXABUYbHjAAKN74=;
 b=piDFMlHZDVCRq6zgFNz23QZHRp9T4YooenKRhaJEbJYp2GjqQT3ka0DFYJG7Y3pIZR
 wWNw3faYaxmZ1nWlFVV8OWP1oz9YoTDPo+U69q2LOkHpU6IVaOnZuVHeaUmHEhSSfGdu
 Wo+4uwxGxZ1A3jne1q1W/gLpM9caT0uB3MXPIBpTK2YNn4U7XVSdalwg4H4Nn8fy3rE2
 oHwJHQ0LXoLKJsRTjUVQtJv/f/nuXh1pD0vJM/Lpwzn2wcNpTm28IJAFUeUN+HMxB+UN
 ahQINs21cn/EOxfjVTMQLtngl2BcvHMMiVuIPTUFYuIML/3aVUdyoctbP1dZrjuKmA6Y
 B7hQ==
X-Gm-Message-State: ACrzQf23o5iyQeg6U7vwZ1gde/mUxrzq78mZJJ3FOlLdukUberb3SQk6
 9W2Oqj+rC3GQ96IoUI/AOJU6PAwwLZvBsb2xecI=
X-Google-Smtp-Source: AMsMyM4ldL69fTmi5RyGZdcPXhPk74TaglEWyZOYqilQ7dE5Zvh/0R9GaDcXqfpHaKM0gAYJ/lYDy+EoOO8HnOGtG4M=
X-Received: by 2002:a17:907:2e19:b0:78e:11cc:3bc5 with SMTP id
 ig25-20020a1709072e1900b0078e11cc3bc5mr15702218ejc.543.1666360873420; Fri, 21
 Oct 2022 07:01:13 -0700 (PDT)
MIME-Version: 1.0
References: <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
 <CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
 <Y1D3OkdsCq2pLduG@erisian.com.au>
 <CABZBVTBupMcBbOUtLbMaEmAiWGsMwisNW+k+bTUJGsUad2=ZZg@mail.gmail.com>
 <Y1Gocf216O+yKqqS@erisian.com.au>
 <CAB3F3DtbxXiHW0GxtaVMMtAo5X7ZcsCPR7odVnwz50qw_3oCLg@mail.gmail.com>
 <CABZBVTBpZOdENv0tg0CZ4yV9J95ZGu0ME9f6gnQQ8WNyt2yePg@mail.gmail.com>
In-Reply-To: <CABZBVTBpZOdENv0tg0CZ4yV9J95ZGu0ME9f6gnQQ8WNyt2yePg@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Fri, 21 Oct 2022 10:01:01 -0400
Message-ID: <CAB3F3DutXajW4E0zZb82LdfRFBoKFd21Up2mxA-nYtCWooys-g@mail.gmail.com>
To: Sergej Kotliar <sergej@bitrefill.com>
Content-Type: multipart/alternative; boundary="000000000000ed8b0f05eb8bdfa3"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Anthony Towns <aj@erisian.com.au>
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: Fri, 21 Oct 2022 14:01:18 -0000

--000000000000ed8b0f05eb8bdfa3
Content-Type: text/plain; charset="UTF-8"

Full-rbf is an odd duck, because while it is not a consensus issue, it does
affect a large % of transactions made by wallets already, contrary to most
policy changes. We have a status quo that is understandable, but
unfortunately long-term incentive incompatible.

It's also a UX issue, not a safety issue for retail wallet users(except
Muun, who have given a clear timeline). Clearly considerations would be
very different otherwise, but retail wallets by and large do not consider
0-conf as a valid deposit, or at least put up some warning symbols to that
effect.

Can only speak for myself, but I am looking for a concrete timeframe from
0-conf stakeholders. I have no preference for any particular time frame, as
long as it can be agreed upon in the near-ish future. This keeps the
transition technically speaking very simple, and removes uncertainty from
decision making going forward.

To make a follow-on consensus analogy, I am in the BIP8
lock-on-timeout=true camp for full rbf. If metrics arise that shows we're
ready early, great. If not, I still want to avoid having this discussion
again in N+ years.

Cheers,
Greg

On Fri, Oct 21, 2022 at 8:02 AM Sergej Kotliar <sergej@bitrefill.com> wrote:

> On Thu, 20 Oct 2022 at 23:07, Greg Sanders <gsanders87@gmail.com> wrote:
>
>> A large number of coins/users sit on custodial rails and this would
>> essentially encumber protocol developers to those KYC/AML institutions. If
>> Binance decides to never support Lightning in favor of BNC-wrapped BTC,
>> should this be an issue at all for reasoning about a path forward?
>>
>
> This is a big question here, with the caveat that it's not just binance
> but in fact the majority of wallets and services that people use with
> bitcoin today.
> But the question remains as you phrased: At which point do we break
> backwards compatibility? Another analogy would be to have sunset the old
> P2PKH addresses during rollout of Segwit - it would certainly have led to
> Segwit getting rolled out faster. The rbf change actually breaks more
> things than that, takes more effort to address than just implementing a new
> address format. Previously in the Bitcoin Core process we've chosen to keep
> backwards compatibility and only roll out opt-in changes with broad
> consensus over them, with the default behavior being to not roll out
> changes that are controversial. At which point it's time to back away from
> that - I honestly don't know. There is probably such a point, and we should
> maybe have some kind of discussion around that topic on a higher level,
> just as you phrased it, and I'll paraphrase:
> If a majority of bitcoin wallets and services continue using legacy
> patterns and features, preventing progress, at which point do we want to
> break compatibility with them?
>
> Best,
> Sergej
>
>
> On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On Thu, Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev
>>> wrote:
>>> > > 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.
>>>
>>> So, what I'm hearing is:
>>>
>>>  * lightning works great, but is still pretty small
>>>  * zeroconf works great for txs that opt-out of RBF
>>>  * opt-in RBF is a pain for two reasons:
>>>     - people don't like that it's not treated as zeroconf
>>>     - the risk of fiat/BTC exchange rate changes between
>>>       now and when the tx actually confirms is worrying
>>>       even if it hasn't caused real problems yet
>>>
>>> (Please correct me if that's too far wrong)
>>>
>>> Maybe it would be productive to explore this opt-in RBF part a bit
>>> more? ie, see if "we" can come up with better answers to some question
>>> along the lines of:
>>>
>>>  "how can we make on-chain payments for goods priced in fiat work well
>>>   for payees that opt-in to RBF?"
>>>
>>> That seems like the sort of thing that's better solved by a collaboration
>>> between wallet devs and merchant devs (and protocol devs?), rather than
>>> just one or the other?
>>>
>>> Is that something that we could talk about here? Or maybe it's better
>>> done via an optech workgroup or something?
>>>
>>> If "we'll credit your account in BTC, then work out the USD coversion
>>> and deduct that for your purchase, then you can do whatever you like
>>> with any remaining BTC from your on-chain payment" is the idea, maybe we
>>> should just roll with that design, but make it more decentralised: have
>>> the initial payment setup a lightning channel between the customer and
>>> the merchant with the BTC (so it's not custodial), but do some magic to
>>> allow USD amounts to be transferred over it (Taro? something oracle based
>>> so that both parties are confident a fair exchange rate will be used?).
>>>
>>> Maybe that particular idea is naive, but having an actual problem to
>>> solve seems more constructive than just saying "we want rbf" "but we
>>> want zeroconf" all the time?
>>>
>>> (Ideally the lightning channels above would be dual funded so they could
>>> be used for routing more generally; but then dual funded channels are
>>> one of the things that get broken by lack of full rbf)
>>>
>>> > > 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.
>>>
>>> I mean, the avenue above isn't easy to exploit -- you have to identify
>>> the merchant's node so that they get the bad tx, and you have to connect
>>> to many peers so that your preferred tx propogates to miners first --
>>> and probably more importantly, it's relatively easy to detect -- if the
>>> merchant has a few passive nodes that the attacker doesn't know about
>>> it, and uses those to watch for attempted doublespends while it tries
>>> to ensure the real tx has propogated widely. So it doesn't surprise me
>>> at all that it's not often attempted, and even less often successful.
>>>
>>> > > > 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,
>>>
>>> Heh, fair enough.
>>>
>>> So the above suggests 25% of payments already get a sub-par experience,
>>> compared to what you'd like them to have (which sucks, but if you're
>>> trying to reinvent both money and payments, maybe isn't surprising). And
>>> going full rbf would bump that from 25% to 85%, which would be pretty
>>> terrible.
>>>
>>> > RBF is a strictly worse UX as proven by anyone
>>> > accepting bitcoin payments at scale.
>>>
>>> So let's make it better? Building bitcoin businesses on the lie that
>>> unconfirmed txs are safe and won't be replaced is going to bite us
>>> eventually; focussing on trying to push that back indefinitely is just
>>> going to make everyone less prepared when it eventually happens.
>>>
>>> > > > 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..
>>>
>>> Okay? Two years is very different from 50 years, and at the moment
>>> there's
>>> not really any data, so people are just going to go with their gut...
>>>
>>> If it were growing in line with lightning capacity in BTC, per
>>> bitcoinvisuals.com/ln-capacity; then 15% now would have grown from
>>> perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,
>>> getting from 15% to 80% would then be about 8 years.
>>>
>>> Presumably that's a laughably terrible model, of course. But if we had
>>> some actual numbers where we can watch the progress, it might be a lot
>>> easier to be patient about waiting for lightning adoption to hit 80%
>>> or whatever, and focus on productive things in the meantime?
>>>
>>> Cheers,
>>> aj
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>
> --
>
> 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>
>

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

<div dir=3D"ltr">Full-rbf is an odd duck, because while it is not a consens=
us issue, it does affect a large % of transactions made by wallets already,=
 contrary to most policy changes. We have a status quo that is understandab=
le, but unfortunately long-term incentive incompatible.=C2=A0<div><br></div=
><div>It&#39;s also a UX issue, not a safety issue for retail wallet users(=
except Muun, who have given a clear timeline). Clearly considerations would=
 be very different otherwise, but retail wallets by and large do not consid=
er 0-conf as a valid deposit,=C2=A0or at least put up some warning symbols =
to that effect.<br><div><br></div><div>Can only speak for myself, but I am =
looking for a concrete timeframe from 0-conf stakeholders. I have no prefer=
ence for any particular time frame, as long as it can be agreed upon in the=
 near-ish future. This keeps the transition technically speaking very simpl=
e, and removes uncertainty from decision making going forward.</div></div><=
div><br></div><div>To make a follow-on consensus analogy, I am in the BIP8 =
lock-on-timeout=3Dtrue camp for full rbf. If metrics arise=C2=A0that shows =
we&#39;re ready early, great. If not, I still want to avoid having this dis=
cussion again in N+ years.</div><div><br></div><div>Cheers,</div><div>Greg<=
/div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a=
ttr">On Fri, Oct 21, 2022 at 8:02 AM Sergej Kotliar &lt;<a href=3D"mailto:s=
ergej@bitrefill.com">sergej@bitrefill.com</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">=
On Thu, 20 Oct 2022 at 23:07, Greg Sanders &lt;<a href=3D"mailto:gsanders87=
@gmail.com" target=3D"_blank">gsanders87@gmail.com</a>&gt; wrote:<br></div>=
<div class=3D"gmail_quote"><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"><div>A large number of coins/users sit on custodial rail=
s and this would essentially encumber protocol developers to those KYC/AML =
institutions. If Binance decides to never support Lightning in favor of BNC=
-wrapped BTC, should this be an issue at all for reasoning about a path for=
ward?</div></div></blockquote><div><br></div><div>This is a big question he=
re, with the caveat that it&#39;s not just binance but in fact the majority=
 of wallets and services that people use with bitcoin today.</div><div>But =
the question remains as you phrased: At which point do we break backwards c=
ompatibility? Another analogy would be to have sunset the old P2PKH address=
es during rollout of Segwit - it would certainly have led to Segwit getting=
 rolled out faster. The rbf change actually breaks more things than that, t=
akes more effort to address than just implementing a new address format. Pr=
eviously in the Bitcoin Core process we&#39;ve chosen to keep backwards com=
patibility and only roll out opt-in changes with broad consensus over them,=
 with the default behavior being to not roll out changes that are controver=
sial. At which point it&#39;s time to back away from that - I honestly don&=
#39;t know. There is probably such a point, and we should maybe have some k=
ind of discussion around that topic on a higher level, just as you phrased =
it, and I&#39;ll paraphrase:=C2=A0</div><div>If a majority of bitcoin walle=
ts and services continue using legacy patterns and features, preventing pro=
gress, at which point do we want to break compatibility with them?</div><di=
v><br></div><div>Best,</div><div>Sergej</div><div><br></div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"gmail_quote=
"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Oct 20, 2022 at 3:59 PM Ant=
hony Towns via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu,=
 Oct 20, 2022 at 02:37:53PM +0200, Sergej Kotliar via bitcoin-dev wrote:<br=
>
&gt; &gt; If someone&#39;s going to systematically exploit your store via t=
his<br>
&gt; &gt; mechanism, it seems like they&#39;d just find a single wallet wit=
h a good<br>
&gt; &gt; UX for opt-in RBF and lowballing fees, and go to town -- not some=
thing<br>
&gt; &gt; where opt-in rbf vs fullrbf policies make any difference at all?<=
br>
&gt; Sort of. But yes once this starts being abused systemically we will ha=
ve to<br>
&gt; do something else w RBF payments, such as crediting the amount in BTC =
to a<br>
&gt; custodial account. But this option isn&#39;t available to your normal =
payment<br>
&gt; processor type business.<br>
<br>
So, what I&#39;m hearing is:<br>
<br>
=C2=A0* lightning works great, but is still pretty small<br>
=C2=A0* zeroconf works great for txs that opt-out of RBF<br>
=C2=A0* opt-in RBF is a pain for two reasons:<br>
=C2=A0 =C2=A0 - people don&#39;t like that it&#39;s not treated as zeroconf=
<br>
=C2=A0 =C2=A0 - the risk of fiat/BTC exchange rate changes between<br>
=C2=A0 =C2=A0 =C2=A0 now and when the tx actually confirms is worrying<br>
=C2=A0 =C2=A0 =C2=A0 even if it hasn&#39;t caused real problems yet<br>
<br>
(Please correct me if that&#39;s too far wrong)<br>
<br>
Maybe it would be productive to explore this opt-in RBF part a bit<br>
more? ie, see if &quot;we&quot; can come up with better answers to some que=
stion<br>
along the lines of:<br>
<br>
=C2=A0&quot;how can we make on-chain payments for goods priced in fiat work=
 well<br>
=C2=A0 for payees that opt-in to RBF?&quot;<br>
<br>
That seems like the sort of thing that&#39;s better solved by a collaborati=
on<br>
between wallet devs and merchant devs (and protocol devs?), rather than<br>
just one or the other?<br>
<br>
Is that something that we could talk about here? Or maybe it&#39;s better<b=
r>
done via an optech workgroup or something?<br>
<br>
If &quot;we&#39;ll credit your account in BTC, then work out the USD covers=
ion<br>
and deduct that for your purchase, then you can do whatever you like<br>
with any remaining BTC from your on-chain payment&quot; is the idea, maybe =
we<br>
should just roll with that design, but make it more decentralised: have<br>
the initial payment setup a lightning channel between the customer and<br>
the merchant with the BTC (so it&#39;s not custodial), but do some magic to=
<br>
allow USD amounts to be transferred over it (Taro? something oracle based<b=
r>
so that both parties are confident a fair exchange rate will be used?).<br>
<br>
Maybe that particular idea is naive, but having an actual problem to<br>
solve seems more constructive than just saying &quot;we want rbf&quot; &quo=
t;but we<br>
want zeroconf&quot; all the time?<br>
<br>
(Ideally the lightning channels above would be dual funded so they could<br=
>
be used for routing more generally; but then dual funded channels are<br>
one of the things that get broken by lack of full rbf)<br>
<br>
&gt; &gt; I thought the &quot;normal&quot; avenue for fooling non-RBF zeroc=
onf was to create<br>
&gt; &gt; two conflicting txs in advance, one paying the merchant, one payi=
ng<br>
&gt; &gt; yourself, connect to many peers, relay the one paying the merchan=
t to<br>
&gt; &gt; the merchant, and the other to everyone else.<br>
&gt; &gt; I&#39;m just basing this off Peter Todd&#39;s stuff from years ag=
o:<br>
&gt; &gt; <a href=3D"https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_=
todd_with_my_doublespendpy_tool_with/cytlhh0/" rel=3D"noreferrer" target=3D=
"_blank">https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my=
_doublespendpy_tool_with/cytlhh0/</a><br>
&gt; &gt; <a href=3D"https://github.com/petertodd/replace-by-fee-tools/blob=
/master/doublespend.py" rel=3D"noreferrer" target=3D"_blank">https://github=
.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py</a><br>
&gt; Yeah, I know the list still rehashes a single incident from 10 years a=
go to<br>
&gt; declare the entire practice as unsafe, and ignores real-world data tha=
t of<br>
&gt; the last million transactions we had zero cases of this successfully<b=
r>
&gt; abusing us.<br>
<br>
I mean, the avenue above isn&#39;t easy to exploit -- you have to identify<=
br>
the merchant&#39;s node so that they get the bad tx, and you have to connec=
t<br>
to many peers so that your preferred tx propogates to miners first --<br>
and probably more importantly, it&#39;s relatively easy to detect -- if the=
<br>
merchant has a few passive nodes that the attacker doesn&#39;t know about<b=
r>
it, and uses those to watch for attempted doublespends while it tries<br>
to ensure the real tx has propogated widely. So it doesn&#39;t surprise me<=
br>
at all that it&#39;s not often attempted, and even less often successful.<b=
r>
<br>
&gt; &gt; &gt; Currently Lightning is somewhere around 15% of our total bit=
coin<br>
&gt; &gt; &gt; payments.<br>
&gt; &gt; So, based on last year&#39;s numbers, presumably that makes your =
bitcoin<br>
&gt; &gt; payments break down as something like:<br>
&gt; &gt;=C2=A0 =C2=A0 5% txs are on-chain and seem shady and are excluded =
from zeroconf<br>
&gt; &gt;=C2=A0 =C2=A015% txs are lightning<br>
&gt; &gt;=C2=A0 =C2=A020% txs are on-chain but signal rbf and are excluded =
from zeroconf<br>
&gt; &gt;=C2=A0 =C2=A060% txs are on-chain and seem fine for zeroconf<br>
&gt; Numbers are right. Shady is too strong a word,<br>
<br>
Heh, fair enough.<br>
<br>
So the above suggests 25% of payments already get a sub-par experience,<br>
compared to what you&#39;d like them to have (which sucks, but if you&#39;r=
e<br>
trying to reinvent both money and payments, maybe isn&#39;t surprising). An=
d<br>
going full rbf would bump that from 25% to 85%, which would be pretty<br>
terrible.<br>
<br>
&gt; RBF is a strictly worse UX as proven by anyone<br>
&gt; accepting bitcoin payments at scale.<br>
<br>
So let&#39;s make it better? Building bitcoin businesses on the lie that<br=
>
unconfirmed txs are safe and won&#39;t be replaced is going to bite us<br>
eventually; focussing on trying to push that back indefinitely is just<br>
going to make everyone less prepared when it eventually happens.<br>
<br>
&gt; &gt; &gt; For me<br>
&gt; &gt; &gt; personally it would be an easier discussion to have when Lig=
htning is at<br>
&gt; &gt; &gt; 80%+ of all bitcoin transactions.<br>
&gt; &gt; Can you extrapolate from the numbers you&#39;ve seen to estimate =
when that<br>
&gt; &gt; might be, given current trends?<br>
&gt; Not sure, it might be exponential growth, and the next 60% of Lightnin=
g<br>
&gt; growth happen faster than the first 15%. Hard to tell. But we&#39;re l=
ikely<br>
&gt; talking years here..<br>
<br>
Okay? Two years is very different from 50 years, and at the moment there&#3=
9;s<br>
not really any data, so people are just going to go with their gut...<br>
<br>
If it were growing in line with lightning capacity in BTC, per<br>
<a href=3D"http://bitcoinvisuals.com/ln-capacity" rel=3D"noreferrer" target=
=3D"_blank">bitcoinvisuals.com/ln-capacity</a>; then 15% now would have gro=
wn from<br>
perhaps 4% in May 2021, so perhaps 8% per year. With linear growth,<br>
getting from 15% to 80% would then be about 8 years. <br>
<br>
Presumably that&#39;s a laughably terrible model, of course. But if we had<=
br>
some actual numbers where we can watch the progress, it might be a lot<br>
easier to be patient about waiting for lightning adoption to hit 80%<br>
or whatever, and focus on productive things in the meantime?<br>
<br>
Cheers,<br>
aj<br>
_______________________________________________<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"=
><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div d=
ir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"l=
tr"><div dir=3D"ltr"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0p=
t;margin-bottom:0pt"><span style=3D"font-size:9.5pt;font-family:Arial;color=
:rgb(0,0,0);background-color:transparent;font-weight:700;font-style:normal;=
font-variant:normal;text-decoration:none;vertical-align:baseline;white-spac=
e: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-fa=
mily:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:700;fo=
nt-style:normal;font-variant:normal;text-decoration:none;vertical-align:bas=
eline;white-space:pre-wrap">CEO</span></p><p dir=3D"ltr" style=3D"line-heig=
ht:1.38;margin-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-b=
ottom:0pt"><span style=3D"font-size:11pt;font-family:Arial;color:rgb(102,10=
2,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:none;display:inline-block;overflow:hidden;widt=
h:220px;height:80px"><img src=3D"https://lh4.googleusercontent.com/wU5i7e8b=
oCd7o3P52cUTKrqeTa7jV2dPEXluijGtPBy0f1F0R2_zIg_zOQ2kigkbVbSWqLlVdwuBYgo_txX=
MKkCWdMfBFRNhsDhFpNv1QrRZsD-gPxDui-4l0tZI1QcjtefCDkNG" width=3D"220" height=
=3D"80" style=3D"margin-left: 0px; margin-top: 0px;"></span></span></p><p d=
ir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><spa=
n style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);backgro=
und-color: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;c=
olor:rgb(102,102,102);background-color:transparent;font-weight:400;font-sty=
le:normal;font-variant:normal;text-decoration:underline;vertical-align:base=
line;white-space:pre-wrap">ziggamon</span></a><span style=3D"font-size:9.5p=
t;font-family:Arial;color:rgb(102,102,102);background-color:transparent;fon=
t-weight:400;font-style:normal;font-variant:normal;text-decoration:none;ver=
tical-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"fon=
t-weight:normal"><br></b></p><p dir=3D"ltr" style=3D"line-height:1.38;margi=
n-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;fon=
t-family:Arial;color:rgb(102,102,102);background-color:transparent;font-wei=
ght:400;font-style:normal;font-variant:normal;text-decoration:underline;ver=
tical-align:baseline;white-space: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.twitter.com/bitrefill" target=3D"_blank"><span style=
=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);background-col=
or:transparent;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)=
;background-color:transparent;vertical-align:baseline;white-space:pre-wrap"=
> | </span><a href=3D"https://www.bitrefill.com/blog/" target=3D"_blank"><s=
pan style=3D"font-size:9.5pt;font-family:Arial;color:rgb(102,102,102);backg=
round-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,10=
2,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);back=
ground-color:transparent;vertical-align:baseline;white-space:pre-wrap">Ange=
llist </span></a><br></p></div></div></div></div></div></div></div></div></=
div></div></div></div>
</blockquote></div>

--000000000000ed8b0f05eb8bdfa3--