path: root/36/88d4d079fea252790b9668091c5a788f80c1b7

Return-Path: <antoine.riard@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6F618C0859;
 Wed,  6 May 2020 08:27:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 647A688613;
 Wed,  6 May 2020 08:27:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id DoqrBbiyausg; Wed,  6 May 2020 08:27:57 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com
 [209.85.215.174])
 by hemlock.osuosl.org (Postfix) with ESMTPS id E62F688612;
 Wed,  6 May 2020 08:27:57 +0000 (UTC)
Received: by mail-pg1-f174.google.com with SMTP id r4so779670pgg.4;
 Wed, 06 May 2020 01:27:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=sAI7GtdNfcAQeNKm1p8qCzkM8RULeoMtEDGB4RPyc4o=;
 b=jEoUeASLlPop2VeyHxwnPbqCdSe1IK5zN5oI0cmrTIJZD+xG7Bl4rjQCC1pzeCebIb
 9ihoEJpeBAf4EFnZcj2DnRW7r5NANoLlzRQCxZgCP5A8z5WmNJLZgxF7ga/uMzD+NuqU
 mHSI4B1JNcLR9fX6+STMLKDHJa5HJ+0di40LXss0AvXNNf4zt41LvQjbolkgK0yPYri1
 uQwZ4QxiD7xgFP/DU2RQbv+478I1RhaM5TfJpG1d/k+wz8cXsZnWzdy2AL78ChdDSfeU
 4Bfdxgmen/VxQaxOs9WAACLVglrJ86raU4+K/xpzdflpmlV0bvmXsVDOBE+mjcj/g+7L
 R6gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=sAI7GtdNfcAQeNKm1p8qCzkM8RULeoMtEDGB4RPyc4o=;
 b=rrd5+JvoyQJBElIvMgjIUugMV6JuNNnnS7yXMyK4EkH0IkD7VvTKgL4dCyKv0W2CjQ
 ATZzHGQljtA/7jFcVleg52rM0lVW4q5QR5Ub/NIA7+qVKkogwCwnp1kb9UEx4vKNsW4O
 mRtFyZbo+79M8/vfXWa9RFd02YqBEI6dDDJvOe+jI+7PvLukdVbhy4uGnquyiomjRuO+
 bepBBZe5WMdz9vrNrj4ew7x1nGwRKLu+uw3ES1bZTVde/Se4IKAMhxUlADIwYZmmG112
 HZmNl/HVVXK9obdOTLgMhM6QrX62GzwtR7P3k5DCRGPHs3TsgEFyeq9rK9m2Cz5l9Xoq
 uNNA==
X-Gm-Message-State: AGi0PuZCwlGUtUUibI9kfT34+4lVMJoRKWXYhByJym2RntcFL4b1cW75
 h5K72nd2W5zZLyl6ywSfKLV2+Q4IA8VW664OZUk=
X-Google-Smtp-Source: APiQypL/6dAADm7c37qGJmzufXs/ddeXHP0mPMXb63LwaQ6ZqPPKAwSIz7eUfGfPeuQ0+YfXxbuQVNriZW+myuf0/f8=
X-Received: by 2002:a62:4e87:: with SMTP id c129mr6907311pfb.178.1588753677479; 
 Wed, 06 May 2020 01:27:57 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com>
 <CAGKT+VcZsMW_5jOqT2jxtbYTEPZU-NL8v3gZ8VJAP-bMe7iLSg@mail.gmail.com>
In-Reply-To: <CAGKT+VcZsMW_5jOqT2jxtbYTEPZU-NL8v3gZ8VJAP-bMe7iLSg@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 6 May 2020 04:27:45 -0400
Message-ID: <CALZpt+GnZa-LpNQHFLECAChStvfPb2MTc2oW0rHy275ciRvYuw@mail.gmail.com>
To: =?UTF-8?Q?Andr=C3=A9s_G=2E_Aragoneses?= <knocte@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000094f54105a4f68afb"
X-Mailman-Approved-At: Wed, 06 May 2020 13:25:00 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of
 onboarding millions of LN mobile clients
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: Wed, 06 May 2020 08:27:59 -0000

--00000000000094f54105a4f68afb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I didn't trust myself and verify. In fact the [3] is the real [2].

Le mar. 5 mai 2020 =C3=A0 06:28, Andr=C3=A9s G. Aragoneses <knocte@gmail.co=
m> a
=C3=A9crit :

> Hey Antoine, just a small note, [3] is missing in your footnotes, can you
> add it? Thanks
>
> On Tue, 5 May 2020 at 18:17, Antoine Riard <antoine.riard@gmail.com>
> wrote:
>
>> Hi,
>>
>> (cross-posting as it's really both layers concerned)
>>
>> Ongoing advancement of BIP 157 implementation in Core maybe the
>> opportunity to reflect on the future of light client protocols and use t=
his
>> knowledge to make better-informed decisions about what kind of
>> infrastructure is needed to support mobile clients at large scale.
>>
>> Trust-minimization of Bitcoin security model has always relied first and
>> above on running a full-node. This current paradigm may be shifted by LN
>> where fast, affordable, confidential, censorship-resistant payment servi=
ces
>> may attract a lot of adoption without users running a full-node. Assumin=
g a
>> user adoption path where a full-node is required to benefit for LN may
>> deprive a lot of users, especially those who are already denied a real
>> financial infrastructure access. It doesn't mean we shouldn't foster nod=
e
>> adoption when people are able to do so, and having a LN wallet maybe eve=
n a
>> first-step to it.
>>
>> Designing a mobile-first LN experience opens its own gap of challenges
>> especially in terms of security and privacy. The problem can be scoped a=
s
>> how to build a scalable, secure, private chain access backend for millio=
ns
>> of LN clients ?
>>
>> Light client protocols for LN exist (either BIP157 or Electrum are used)=
,
>> although their privacy and security guarantees with regards to
>> implementation on the client-side may still be an object of concern
>> (aggressive tx-rebroadcast, sybillable outbound peer selection, trusted =
fee
>> estimation). That said, one of the bottlenecks is likely the number of
>> full-nodes being willingly to dedicate resources to serve those clients.
>> It's not about _which_ protocol is deployed but more about _incentives_ =
for
>> node operators to dedicate long-term resources to client they have lower
>> reasons to care about otherwise.
>>
>> Even with cheaper, more efficient protocols like BIP 157, you may have a
>> huge discrepancy between what is asked and what is offered. Assuming 10M
>> light clients [0] each of them consuming ~100MB/month for filters/header=
s,
>> that means you're asking 1PB/month of traffic to the backbone network. I=
f
>> you assume 10K public nodes, like today, assuming _all_ of them opt-in t=
o
>> signal BIP 157, that's an increase of 100GB/month for each. Which is
>> consequent with regards to the estimated cost of 350GB/month for running=
 an
>> actual public node. Widening full-node adoption, specially in term of
>> geographic distribution means as much as we can to bound its operational
>> cost.
>>
>> Obviously,  deployment of more efficient tx-relay protocol like Erlay
>> will free up some resources but it maybe wiser to dedicate them to incre=
ase
>> health and security of the backbone network like deploying more outbound
>> connections.
>>
>> Unless your light client protocol is so ridiculous cheap to rely on
>> niceness of a subset of node operators offering free resources, it won't
>> scale. And it's likely you will always have a ratio disequilibrium betwe=
en
>> numbers of clients and numbers of full-node, even worst their growth rat=
e
>> won't be the same, first ones are so much easier to setup.
>>
>> It doesn't mean servicing filters for free won't work for now, numbers o=
f
>> BIP157 clients is still pretty low, but what is worrying is  wallet vend=
ors
>> building such chain access backend, hitting a bandwidth scalability wall
>> few years from now instead of pursuing better solutions. And if this
>> happen, maybe suddenly, isn't the quick fix going to be to rely on
>> centralized services, so much easier to deploy ?
>>
>> Of course, it may be brought that actually current full-node operators
>> don't get anything back from servicing blocks, transactions, addresses..=
.
>> It may be replied that you have an indirect incentive to participate in
>> network relay and therefore guarantee censorship-resistance, instead of
>> directly connecting to miners. You do have today ways to select your
>> resources exposure like pruning, block-only or being private but the wid=
er
>> point is the current (non?)-incentives model seems to work for the base
>> layer. For light clients data, are node operators going to be satisfied =
to
>> serve this new *class* of traffic en masse ?
>>
>> This doesn't mean you won't find BIP157 servers, ready to serve you with
>> unlimited credit, but it's more likely their intentions maybe not aligne=
d,
>> like spying on your transaction broadcast or block fetched. And you do w=
ant
>> peer diversity to avoid every BIP157 servers being on few ASNs for
>> fault-tolerance. Do people expect a scenario a la Cloudflare, where
>> everyone connections is to far or less the same set of entities ?
>>
>> Moreover, the LN security model diverges hugely from basic on-chain
>> transactions. Worst-case attack on-chain a malicious light client server
>> showing a longest, invalid, PoW-signed chain to double-spend the user. O=
n
>> LN, the *liveliness* requirement means the entity owning your view of th=
e
>> chain can lie to you on whether your channel has been spent by a revoked
>> commitment, the real tip of the blockchain or even dry-up block
>> announcement to trigger unexpected behavior in the client logic. A
>> malicious light client server may just drop any filters/utxos spends, wh=
at
>> your LN client should do in this case ? [1]
>>
>> Therefore, you may want to introduce monetary compensation in exchange o=
f
>> servicing filters. Light client not dedicating resources to maintain the
>> network but free-riding on it, you may use their micro-payment capabilit=
ies
>> to price chain access resources [3]. This proposition may suit within th=
e
>> watchtower paradigm, where another entity is delegated some part of
>> protocol execution, alleviating client onliness requirement. It needs
>> further analysis but how your funds may be compromised by a watchtower a=
re
>> likely to be the same scenario that how a chain validation provider can
>> compromise you. That said, how do you avoid such "chain access" market
>> turning as an oligopoly is an open question. You may "bind" them to
>> internet topology or ask for fidelity bonds and create some kind of
>> scarcity but still...
>>
>> Maybe I'm completely wrong, missing some numbers, and it's maybe fine to
>> just rely on few thousands of full-node operators being nice and servici=
ng
>> friendly millions of LN mobiles clients. But just in case it may be good=
 to
>> consider a reasonable alternative.
>>
>> Thanks Gleb for many points exposed here but all mistakes are my own.
>>
>> Cheers,
>>
>> Antoine
>>
>> [0] UTXO set size may be a bottleneck, but still if you have 2 channels
>> by clients that's 20M utxos, just roughly ~x3 than today.
>>
>> [1] And committing filters as part of headers may not solve everything a=
s
>> an attacker can just delay or slow announcements to you, so you still ne=
ed
>> network access to at least one honest node.
>>
>> [2]  It maybe argue that distinction client-vs-peer doesn't hold because
>> you may start as a client and start synchronizing the chain, relaying
>> blocks, etc. AFAIK, there is no such hybrid implementation and that's no=
t
>> what you want to run in a mobile.
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>

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

<div dir=3D"ltr">I didn&#39;t trust myself and verify. In fact the [3] is t=
he real [2].<br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">Le=C2=A0mar. 5 mai 2020 =C3=A0=C2=A006:28, Andr=C3=A9s G. A=
ragoneses &lt;<a href=3D"mailto:knocte@gmail.com">knocte@gmail.com</a>&gt; =
a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr">Hey Antoine, just a small note, [3] is missing in your=
 footnotes, can you add it? Thanks</div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Tue, 5 May 2020 at 18:17, Antoine Riar=
d &lt;<a href=3D"mailto:antoine.riard@gmail.com" target=3D"_blank">antoine.=
riard@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div dir=3D"ltr"><div>Hi,</div><div><br></div><div>(cross-po=
sting as it&#39;s really both layers concerned)<br></div><div><div><br>Ongo=
ing advancement of BIP 157 implementation in Core maybe the opportunity to =
reflect on the future of light client protocols and use this knowledge to m=
ake better-informed decisions about what kind of infrastructure is needed t=
o support mobile clients at large scale.<br><br></div><div>Trust-minimizati=
on of Bitcoin security model has always relied first and above on running a=
 full-node. This current paradigm may be shifted by LN where fast, affordab=
le, confidential, censorship-resistant payment services may attract a lot o=
f adoption without users running a full-node. Assuming a user adoption path=
 where a full-node is required to benefit for LN may deprive a lot of users=
, especially those who are already denied a real financial infrastructure a=
ccess. It doesn&#39;t mean we shouldn&#39;t foster node adoption when peopl=
e are able to do so, and having a LN wallet maybe even a first-step to it.<=
br><br></div><div>Designing a mobile-first LN experience opens its own gap =
of challenges especially in terms of security and privacy. The problem can =
be scoped as how to build a scalable, secure, private chain access backend =
for millions of LN clients ?<br><br></div><div>Light client protocols for L=
N exist (either BIP157 or Electrum are used), although their privacy and se=
curity guarantees with regards to implementation on the client-side may sti=
ll be an object of concern (aggressive tx-rebroadcast, sybillable outbound =
peer selection, trusted fee estimation). That said, one of the bottlenecks =
is likely the number of full-nodes being willingly to dedicate resources to=
 serve those clients. It&#39;s not about _which_ protocol is deployed but m=
ore about _incentives_ for node operators to dedicate long-term resources t=
o client they have lower reasons to care about otherwise.<br><br></div><div=
>Even with cheaper, more efficient protocols like BIP 157, you may have a h=
uge discrepancy between what is asked and what is offered. Assuming 10M lig=
ht clients [0] each of them consuming ~100MB/month for filters/headers, tha=
t means you&#39;re asking 1PB/month of traffic to the backbone network. If =
you assume 10K public nodes, like today, assuming _all_ of them opt-in to s=
ignal BIP 157, that&#39;s an increase of 100GB/month for each. Which is con=
sequent with regards to the estimated cost of 350GB/month for running an ac=
tual public node. Widening full-node adoption, specially in term of geograp=
hic distribution means as much as we can to bound its operational cost.<br>=
<br></div><div>Obviously,=C2=A0 deployment of more efficient tx-relay proto=
col like Erlay will free up some resources but it maybe wiser to dedicate t=
hem to increase health and security of the backbone network like deploying =
more outbound connections.<br><br></div><div>Unless your light client proto=
col is so ridiculous cheap to rely on niceness of a subset of node operator=
s offering free resources, it won&#39;t scale. And it&#39;s likely you will=
 always have a ratio disequilibrium between numbers of clients and numbers =
of full-node, even worst their growth rate won&#39;t be the same, first one=
s are so much easier to setup.<br><br></div><div>It doesn&#39;t mean servic=
ing filters for free won&#39;t work for now, numbers of BIP157 clients is s=
till pretty low, but what is worrying is=C2=A0 wallet vendors building such=
 chain access backend, hitting a bandwidth scalability wall few years from =
now instead of pursuing better solutions. And if this happen, maybe suddenl=
y, isn&#39;t the quick fix going to be to rely on centralized services, so =
much easier to deploy ?<br><br></div><div>Of course, it may be brought that=
 actually current full-node operators don&#39;t get anything back from serv=
icing blocks, transactions, addresses... It may be replied that you have an=
 indirect incentive to participate in network relay and therefore guarantee=
 censorship-resistance, instead of directly connecting to miners. You do ha=
ve today ways to select your resources exposure like pruning, block-only or=
 being private but the wider point is the current (non?)-incentives model s=
eems to work for the base layer. For light clients data, are node operators=
 going to be satisfied to serve this new *class* of traffic en masse ?<br><=
br>This doesn&#39;t mean you won&#39;t find BIP157 servers, ready to serve =
you with unlimited credit, but it&#39;s more likely their intentions maybe =
not aligned, like spying on your transaction broadcast or block fetched. An=
d you do want peer diversity to avoid every BIP157 servers being on few ASN=
s for fault-tolerance. Do people expect a scenario a la Cloudflare, where e=
veryone connections is to far or less the same set of entities ?<br><br>Mor=
eover, the LN security model diverges hugely from basic on-chain transactio=
ns. Worst-case attack on-chain a malicious light client server showing a lo=
ngest, invalid, PoW-signed chain to double-spend the user. On LN, the *live=
liness* requirement means the entity owning your view of the chain can lie =
to you on whether your channel has been spent by a revoked commitment, the =
real tip of the blockchain or even dry-up block announcement to trigger une=
xpected behavior in the client logic. A malicious light client server may j=
ust drop any filters/utxos spends, what your LN client should do in this ca=
se ? [1]<br><br>Therefore, you may want to introduce monetary compensation =
in exchange of servicing filters. Light client not dedicating resources to =
maintain the network but free-riding on it, you may use their micro-payment=
 capabilities to price chain access resources [3]. This proposition may sui=
t within the watchtower paradigm, where another entity is delegated some pa=
rt of protocol execution, alleviating client onliness requirement. It needs=
 further analysis but how your funds may be compromised by a watchtower are=
 likely to be the same scenario that how a chain validation provider can co=
mpromise you. That said, how do you avoid such &quot;chain access&quot; mar=
ket turning as an oligopoly is an open question. You may &quot;bind&quot; t=
hem to internet topology or ask for fidelity bonds and create some kind of =
scarcity but still...<br><br>Maybe I&#39;m completely wrong, missing some n=
umbers, and it&#39;s maybe fine to just rely on few thousands of full-node =
operators being nice and servicing friendly millions of LN mobiles clients.=
 But just in case it may be good to consider a reasonable alternative.<br><=
br>Thanks Gleb for many points exposed here but all mistakes are my own.<br=
><br></div><div>Cheers,<br><br></div><div>Antoine<br><br>[0] UTXO set size =
may be a bottleneck, but still if you have 2 channels by clients that&#39;s=
 20M utxos, just roughly ~x3 than today.<br><br>[1] And committing filters =
as part of headers may not solve everything as an attacker can just delay o=
r slow announcements to you, so you still need network access to at least o=
ne honest node.<br><br>[2]=C2=A0 It maybe argue that distinction client-vs-=
peer doesn&#39;t hold because you may start as a client and start synchroni=
zing the chain, relaying blocks, etc. AFAIK, there is no such hybrid implem=
entation and that&#39;s not what you want to run in a mobile.<br><br></div>=
</div></div>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href=3D"mailto:Lightning-dev@lists.linuxfoundation.org" target=3D"_blank=
">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev=
" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/ma=
ilman/listinfo/lightning-dev</a><br>
</blockquote></div>
</blockquote></div>

--00000000000094f54105a4f68afb--