path: root/27/8acd05b01ef34c054abfdd2169f069925242da

Return-Path: <laolu32@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id C55CCC0859;
 Wed,  6 May 2020 00:31:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id ADD728698D;
 Wed,  6 May 2020 00:31:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id VAGcTFvBh8MI; Wed,  6 May 2020 00:31:45 +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-qt1-f173.google.com (mail-qt1-f173.google.com
 [209.85.160.173])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id F174C868D0;
 Wed,  6 May 2020 00:31:44 +0000 (UTC)
Received: by mail-qt1-f173.google.com with SMTP id b1so155867qtt.1;
 Tue, 05 May 2020 17:31:44 -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=oUkoZxkzEYZPrZITBxAtHFyjFUZp1+0+n82lh9RyfEQ=;
 b=OSCZoytvEv0zoe+d3DruiUpzZ9H8xkhz7Q3T9O6pwZ5kXLoQC/0+ZQb3xfgqqn7SuQ
 S35JTAm7QJPgUuMTxvdc0fDygR6wDJmxHzGnIul5ZgqBnPQ0NI0Vh6pZSh8z3SyPJwI2
 snmtCMQJk2Jvtx6uWajyFX/YmHy7xifcFezprnZqJHd8w59pd4MhIvh6jO6CL4Ba/2HW
 eoA2t5/FdiMnsP/LRwaiRe9ypzijXF0fUp8w/5Wokek+/K+TxPJRW7dh0V54RHQ1YADy
 OpfRHpjqofXArUUSd89iO4p2S/ZFX1BEJzZxi0JWIWlOPO2zHl25mA8J8GSZ7zEVuAv7
 s7GQ==
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=oUkoZxkzEYZPrZITBxAtHFyjFUZp1+0+n82lh9RyfEQ=;
 b=EX5oDGq1GSIJH61C6OMGULC8IYgFEftgg1o0KljktKlIHIaVX3d7WJBlq4ETMYVBDJ
 iQJZfxd067zMwuI3ojYY+8S9JyDluaqoMEYnmB3zvbVdfgGb1UDeOl0Agg8CFEZLIRVG
 DbVJM0wdzDicBXvXyo5zYQYtz41pCzG8+UX0OlC71MeLZkf7IhlP+TaURgwRkpmF9C89
 rljFwTZ1M8wd8Syo2T5kBizqbMnFqB8qLFHT6Jhp32egk8W9ecrGhZRSaoUVoiv+pbUx
 qUl3PyvkUCuXFQf/4BkiEsLvAo199eMnRw8s7N/F3XsAss6WSMF4xprTMcP+5rwdGeya
 S9jg==
X-Gm-Message-State: AGi0PuYpQVgSxYaXoon1Hdn++PBQWRP3g7IIMtAtPQrZ9sv06ITKrw8V
 CkLlO+lYfZ/ocAH9huIq+g6xOCIvjS0nrR2uwHo=
X-Google-Smtp-Source: APiQypLVFq98olnZCrLp37lAMHCfMc+zbpfWAHyyMG2OVVWv0Vn/TSpu8Rt32l4UId8MUkydI7TpWCZDOQIah0II1bI=
X-Received: by 2002:ac8:389d:: with SMTP id f29mr5674899qtc.187.1588725103745; 
 Tue, 05 May 2020 17:31:43 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com>
In-Reply-To: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Tue, 5 May 2020 17:31:32 -0700
Message-ID: <CAO3Pvs8rkouxQY912VW04pmn-hdAhMNL_6E_nXDmkeibBegwkA@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000745ded05a4efe364"
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 00:31:46 -0000

--000000000000745ded05a4efe364
Content-Type: text/plain; charset="UTF-8"

Hi Antoine,

> 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/headers,
> that means you'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
> 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

One really dope thing about BIP 157+158, is that the protocol makes serving
light clients now _stateless_, since the full node doesn't need to perform
any unique work for a given client. As a result, the entire protocol could
be served over something like HTTP, taking advantage of all the established
CDNs and anycast serving infrastructure, which can reduce syncing time
(less latency to
fetch data) and also more widely distributed the load of light clients using
the existing web infrastructure. Going further, with HTTP/2's server-push
capabilities, those serving this data can still push out notifications for
new headers, etc.

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

Piggy backing off the above idea, if the data starts being widely served
over HTTP, then LSATs[1][2] can be used to add a lightweight payment
mechanism by inserting a new proxy server in front of the filter/header
infrastructure. The minted tokens themselves may allow a user to purchase
access to a single header/filter, a range of them in the past, or N headers
past the known chain tip, etc, etc.

-- Laolu

[1]: https://lsat.tech/
[2]: https://lightning.engineering/posts/2020-03-30-lsat/


On Tue, May 5, 2020 at 3:17 AM 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 this
> 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 services
> may attract a lot of 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 access. It doesn't mean we shouldn't foster node
> adoption when people are able to do so, and having a LN wallet maybe even 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 as
> how to build a scalable, secure, private chain access backend for millions
> 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/headers,
> that means you'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
> 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 increase
> 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 between
> numbers of clients and numbers of full-node, even worst their growth rate
> 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 of
> BIP157 clients is still pretty low, but what is worrying is  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 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 wider
> 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 aligned,
> like spying on your transaction broadcast or block fetched. And you do want
> 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. On
> LN, the *liveliness* 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 unexpected behavior in the client logic. A
> malicious light client server may just drop any filters/utxos spends, what
> your LN client should do in this case ? [1]
>
> 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 suit within the
> 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 are
> 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 servicing
> 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 as
> an attacker can just delay or slow announcements to you, so you still need
> 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 not
> 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
>

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

<div dir=3D"ltr">Hi Antoine, <br><br>&gt; Even with cheaper, more efficient=
 protocols like BIP 157, you may have a<br>&gt; huge discrepancy between wh=
at is asked and what is offered. Assuming 10M<br>&gt; light clients [0] eac=
h of them consuming ~100MB/month for filters/headers,<br>&gt; that means yo=
u&#39;re asking 1PB/month of traffic to the backbone network. If<br>&gt; yo=
u assume 10K public nodes, like today, assuming _all_ of them opt-in to<br>=
&gt; signal BIP 157, that&#39;s an increase of 100GB/month for each. Which =
is<br>&gt; consequent with regards to the estimated cost of 350GB/month for=
 running<br>&gt; an actual public node<br><br>One really dope thing about B=
IP 157+158, is that the protocol makes serving<br>light clients now _statel=
ess_, since the full node doesn&#39;t need to perform<br>any unique work fo=
r a given client. As a result, the entire protocol could<br>be served over =
something like HTTP, taking advantage of all the established<br>CDNs and an=
ycast serving infrastructure, which can reduce syncing time (less latency t=
o<br>fetch data) and also more widely distributed the load of light clients=
 using<br>the existing web infrastructure. Going further, with HTTP/2&#39;s=
 server-push<br>capabilities, those serving this data can still push out no=
tifications for<br>new headers, etc.<br><br>&gt; Therefore, you may want to=
 introduce monetary compensation in exchange of<br>&gt; servicing filters. =
Light client not dedicating resources to maintain the<br>&gt; network but f=
ree-riding on it, you may use their micro-payment<br>&gt; capabilities to p=
rice chain access resources [3]<br><br>Piggy backing off the above idea, if=
 the data starts being widely served<br>over HTTP, then LSATs[1][2] can be =
used to add a lightweight payment<br>mechanism by inserting a new proxy ser=
ver in front of the filter/header<br>infrastructure. The minted tokens them=
selves may allow a user to purchase<br>access to a single header/filter, a =
range of them in the past, or N headers<br>past the known chain tip, etc, e=
tc.<br><br>-- Laolu<br><br>[1]: <a href=3D"https://lsat.tech/">https://lsat=
.tech/</a><br>[2]: <a href=3D"https://lightning.engineering/posts/2020-03-3=
0-lsat/">https://lightning.engineering/posts/2020-03-30-lsat/</a><br><br></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On=
 Tue, May 5, 2020 at 3:17 AM Antoine Riard &lt;<a href=3D"mailto:antoine.ri=
ard@gmail.com">antoine.riard@gmail.com</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi,</div><div><=
br></div><div>(cross-posting as it&#39;s really both layers concerned)<br><=
/div><div><div><br>Ongoing advancement of BIP 157 implementation in Core ma=
ybe the opportunity to reflect on the future of light client protocols and =
use this knowledge to make better-informed decisions about what kind of inf=
rastructure is needed to support mobile clients at large scale.<br><br></di=
v><div>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. Assumi=
ng 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 fin=
ancial infrastructure access. It doesn&#39;t mean we shouldn&#39;t foster n=
ode adoption when people are able to do so, and having a LN wallet maybe ev=
en a first-step to it.<br><br></div><div>Designing a mobile-first LN experi=
ence opens its own gap of challenges especially in terms of security and pr=
ivacy. The problem can be scoped as how to build a scalable, secure, privat=
e chain access backend for millions of LN clients ?<br><br></div><div>Light=
 client protocols for LN exist (either BIP157 or Electrum are used), althou=
gh their privacy and security guarantees with regards to implementation on =
the client-side may still be an object of concern (aggressive tx-rebroadcas=
t, sybillable outbound peer selection, trusted fee estimation). That said, =
one of the bottlenecks is likely the number of full-nodes being willingly t=
o dedicate resources to serve those clients. It&#39;s not about _which_ pro=
tocol is deployed but more about _incentives_ for node operators to dedicat=
e long-term resources to client they have lower reasons to care about other=
wise.<br><br></div><div>Even with cheaper, more efficient protocols like BI=
P 157, you may have a huge discrepancy between what is asked and what is of=
fered. Assuming 10M light clients [0] each of them consuming ~100MB/month f=
or filters/headers, that means you&#39;re asking 1PB/month of traffic to th=
e backbone network. If you assume 10K public nodes, like today, assuming _a=
ll_ of them opt-in to signal BIP 157, that&#39;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, speci=
ally in term of geographic distribution means as much as we can to bound it=
s operational cost.<br><br></div><div>Obviously,=C2=A0 deployment of more e=
fficient tx-relay protocol like Erlay will free up some resources but it ma=
ybe wiser to dedicate them to increase health and security of the backbone =
network like deploying more outbound connections.<br><br></div><div>Unless =
your light client protocol is so ridiculous cheap to rely on niceness of a =
subset of node operators offering free resources, it won&#39;t scale. And i=
t&#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 ones are so much easier to setup.<br><br></div><div>It =
doesn&#39;t mean servicing filters for free won&#39;t work for now, numbers=
 of BIP157 clients is still pretty low, but what is worrying is=C2=A0 walle=
t vendors building such chain access backend, hitting a bandwidth scalabili=
ty wall few years from now instead of pursuing better solutions. And if thi=
s happen, maybe suddenly, isn&#39;t the quick fix going to be to rely on ce=
ntralized 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 servicing blocks, transactions, addresses... It may be r=
eplied that you have an indirect incentive to participate in network relay =
and therefore guarantee censorship-resistance, instead of directly connecti=
ng to miners. You do have today ways to select your resources exposure like=
 pruning, block-only or being private but the wider point is the current (n=
on?)-incentives model seems to work for the base layer. For light clients d=
ata, 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 s=
ervers, ready to serve you with unlimited credit, but it&#39;s more likely =
their intentions maybe not aligned, like spying on your transaction broadca=
st or block fetched. And you do want peer diversity to avoid every BIP157 s=
ervers 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 o=
f entities ?<br><br>Moreover, the LN security model diverges hugely from ba=
sic on-chain transactions. Worst-case attack on-chain a malicious light cli=
ent server showing a longest, invalid, PoW-signed chain to double-spend the=
 user. On LN, the *liveliness* requirement means the entity owning your vie=
w of the chain can lie to you on whether your channel has been spent by a r=
evoked commitment, the real tip of the blockchain or even dry-up block anno=
uncement to trigger unexpected behavior in the client logic. A malicious li=
ght client server may just drop any filters/utxos spends, what your LN clie=
nt should do in this case ? [1]<br><br>Therefore, you may want to introduce=
 monetary compensation in exchange of servicing filters. Light client not d=
edicating resources to maintain the network but free-riding on it, you may =
use their micro-payment capabilities to price chain access resources [3]. T=
his proposition may suit within the watchtower paradigm, where another enti=
ty is delegated some part of protocol execution, alleviating client onlines=
s requirement. It needs further analysis but how your funds may be compromi=
sed by a watchtower are likely to be the same scenario that how a chain val=
idation provider can compromise you. That said, how do you avoid such &quot=
;chain access&quot; market turning as an oligopoly is an open question. You=
 may &quot;bind&quot; them to internet topology or ask for fidelity bonds a=
nd create some kind of scarcity but still...<br><br>Maybe I&#39;m completel=
y wrong, missing some numbers, 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 reaso=
nable 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 channel=
s 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 at=
tacker can just delay or slow announcements to you, so you still need netwo=
rk access to at least one 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 cli=
ent and start synchronizing the chain, relaying blocks, etc. AFAIK, there i=
s no such hybrid implementation 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>

--000000000000745ded05a4efe364--