path: root/3a/77a40fae31250fea2a01b444539ff6f27ab22c

Return-Path: <gsanders87@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 66964C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 21:07:23 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 390CF60D6F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 21:07:23 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 390CF60D6F
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=oeWgms1T
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 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] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id m1BkB7Rlp-M6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 21:07:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 2081C60D6A
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [IPv6:2a00:1450:4864:20::52d])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 2081C60D6A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 21:07:21 +0000 (UTC)
Received: by mail-ed1-x52d.google.com with SMTP id m15so1363996edb.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 20 Oct 2022 14:07:20 -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=rRfgx7UyXP3GcOTz926/NfHOh5ajs5UwWdSRH7psFmA=;
 b=oeWgms1TaAao6W2LtTnXdjdSM8V9iHGLGxB21G8P9wX21h6IZ0VwS1182UjLmUCOqK
 E9eRoJ/jx422TC+ekKFcP8ZXr7K0tlg57128khQ8M0hJYYecnI1lvYk3naTOz2o5mu2t
 IhqHfcsFGdEOzEyW8srcJEotDe6+a8U1Ku7MUNtgVEQm02QkRob9pb1zIkbvA7kVtDlb
 Blda2Pwoeioer1MhyX7QhmmJOo37u0lc7g/fLX/cLkEc0ApjD7953kFbKRqf/c7aHEKc
 uvaU3nGYVwXqMVeXk7/3vEDxBjA1IoSD8KNlA2fATI4S4qYeV7cRDgvD+tsLdcxSKltH
 bsRQ==
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=rRfgx7UyXP3GcOTz926/NfHOh5ajs5UwWdSRH7psFmA=;
 b=sskiIDo/F146gr9bnyzKp4kPnqsFrqp5KsxwH0BlUaNHnFwWYU8az/wJebqQYQYd3m
 iSGvNF07K7f9O76Zmz3CVv3U3BnZHQRNZyB0meiEdYequ6D0vCL33eiROWrKNkyRI2ih
 BeI+IVvb8ybj1fZnmkiimXLiewvDdHO0WPrlg81tkEGmJTHawsHHham+R1iG4jHYqtuv
 KrK5kF/KmJ7C/w2Nl61gCc38E4DrbqXwJAIOGqziRAzd2v0DdO9IWZFtKUAdl3knWinw
 3xb+utDOdTrcqC29Opfq6PoC+5Z/32VEUJBPLIke8DK2IJHYksYRGkbkVYSeM7lFYDfR
 HZWg==
X-Gm-Message-State: ACrzQf3FUgd8DxrPp7LLaU0mLLPrd51VOA0Fm6WOuSwad4olOICvYWW4
 qWrmn3kst8cS1XwZAH70Uo5Fx9LdoR5RiJ50QyU=
X-Google-Smtp-Source: AMsMyM52HDXkTzF4g1FZ3q2izt9a/7gp1nApm53Ib8IscQzm/eE0FJX3ZhYuF7D6gCGOt+AOTi2v/5gprAtZgOwzB/w=
X-Received: by 2002:a05:6402:370c:b0:453:9fab:1b53 with SMTP id
 ek12-20020a056402370c00b004539fab1b53mr14337885edb.28.1666300039063; Thu, 20
 Oct 2022 14:07:19 -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>
In-Reply-To: <Y1Gocf216O+yKqqS@erisian.com.au>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 20 Oct 2022 17:07:07 -0400
Message-ID: <CAB3F3DtbxXiHW0GxtaVMMtAo5X7ZcsCPR7odVnwz50qw_3oCLg@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000eaef2605eb7db5b0"
Cc: Sergej Kotliar <sergej@bitrefill.com>
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
	danger
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Oct 2022 21:07:23 -0000

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

> 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.

I'd caution against any metrics-based approach like this, unless it's
simply used for ballparking potential adoption curves to set a a timeframe
people can live with.

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?

Hoping to be wrong,
Greg



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
>

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

<div dir=3D"ltr">&gt; If it were growing in line with lightning capacity in=
 BTC, per<br><a href=3D"http://bitcoinvisuals.com/ln-capacity" rel=3D"noref=
errer" target=3D"_blank">bitcoinvisuals.com/ln-capacity</a>; then 15% now w=
ould have grown from<br>perhaps 4% in May 2021, so perhaps 8% per year. Wit=
h linear growth,<br>getting from 15% to 80% would then be about 8 years.<di=
v><br></div><div>I&#39;d caution against any metrics-based approach like th=
is, unless it&#39;s simply used for ballparking potential adoption curves t=
o set a a timeframe people=C2=A0can live with.</div><div><br></div><div>A l=
arge number of coins/users sit on custodial rails and this would essentiall=
y encumber protocol developers to those KYC/AML institutions. If Binance de=
cides to never support Lightning in favor of BNC-wrapped BTC, should this b=
e an issue at all for reasoning about a path forward? <br></div><div><br></=
div><div>Hoping to be wrong,</div><div>Greg</div><div><br></div><div><br></=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Thu, Oct 20, 2022 at 3:59 PM Anthony Towns via bitcoin-dev &lt;<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linux=
foundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-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>

--000000000000eaef2605eb7db5b0--