path: root/a3/01432bf72653c8a4252e685d975a8a470dc995

Return-Path: <antoine.riard@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1077BC0175;
 Tue,  5 May 2020 10:17:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id EB5EE877F4;
 Tue,  5 May 2020 10:17:52 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id cgG5D36spNk3; Tue,  5 May 2020 10:17:51 +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-pf1-f171.google.com (mail-pf1-f171.google.com
 [209.85.210.171])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 870A487D2F;
 Tue,  5 May 2020 10:17:51 +0000 (UTC)
Received: by mail-pf1-f171.google.com with SMTP id y25so676787pfn.5;
 Tue, 05 May 2020 03:17:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:from:date:message-id:subject:to;
 bh=YUJtxwj5XZm+8jU0hLHYd57pV/TRqybrVPGTvkHYcxo=;
 b=YjRQBiAOyEI6utKYILNgrliKB9MycEn3DuYEIGsDrlap+KOhhPx8VQ1OkC58j7+/iJ
 QwSVRwmSBFyDpFrGIIgfNsiCKuf4ND7qXN6b+YW21HAj7xeomHT45w0AW4f7DFV9Ujk8
 SpjA2ITLF9HKaHmu5BtZw62ODzLhEqSz3S6ZJoA/qTQo4vXYg/qjz2uLR3vNRMOhCM82
 McoIEWxws1Db7jPOS9qcPq/CQ3pcNg3hn+k6L2dmZCIM/zD4rwzB0iQwuo6GNhp+GfJe
 pPXqRXzsWbcJCX6uCJYE1XqAne/B6XRXhI9XakI1AkcuzJIqd5Z4d7E7OUMqlsUZmuD6
 VDFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=YUJtxwj5XZm+8jU0hLHYd57pV/TRqybrVPGTvkHYcxo=;
 b=TPmIezQc/FRzAqXBAUNi2w+thc8jgyH/fbDr4XxnVii+IzdnLxSyqOjBSH38nIb1NM
 EZkoLnREG3UezlIwdtci/wWxCMGA8g7LorSl3+imxhB1hGcYwFGPOf+IOA2Xiw3lwAHO
 YBjduq/+3F4gK1GUjwW8qGtzq7vOiNDQRTbfDDBv9TtsRbvKS129y7EHmr27k0BQcLl9
 h2rfK4vcEvEoH8cmFFOeHw36SJKuuCjE1jnS+2xCZQoXUj/hD4aQMfCiPDFLGKfa7Rca
 vyluyvZC3ZEIy8T5FMktukyLRUF5woS4TO920Y4PLGOMkSz8noS7az6PxV7mez4RVVhW
 RJEA==
X-Gm-Message-State: AGi0PuYCTP3/eRU/zav+6xXnJzcgCaMm9NFCXbpmHSNErZ01YXIkTDhS
 fRW2BjypQIjSMSgGgOO0g3SuJHYD6LcSQKlJ9FH03DqzXQQ=
X-Google-Smtp-Source: APiQypJmv1VMNQE8qH2sPq3RWg17eSwR1Q/niGNf9iY8MuV2CX4ZDzV08ZlPmsNGpL6eSWXsy4tFqldiG1WkYxgQJos=
X-Received: by 2002:a62:4e87:: with SMTP id c129mr2434830pfb.178.1588673870582; 
 Tue, 05 May 2020 03:17:50 -0700 (PDT)
MIME-Version: 1.0
From: Antoine Riard <antoine.riard@gmail.com>
Date: Tue, 5 May 2020 06:17:37 -0400
Message-ID: <CALZpt+GBPbf+Pgctm5NViNons50aQs1RPQkEo3FW5RM4fL9ztA@mail.gmail.com>
To: "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b8590105a4e3f559"
X-Mailman-Approved-At: Tue, 05 May 2020 12:38:58 +0000
Subject: [bitcoin-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: Tue, 05 May 2020 10:17:53 -0000

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

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.

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

<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 maybe the opportunity to reflect on the =
future of light client protocols and use this knowledge to make better-info=
rmed decisions about what kind of infrastructure is needed to support mobil=
e clients at large scale.<br><br></div><div>Trust-minimization of Bitcoin s=
ecurity model has always relied first and above on running a full-node. Thi=
s current paradigm may be shifted by LN where fast, affordable, confidentia=
l, censorship-resistant payment services may attract a lot of adoption with=
out users running a full-node. Assuming a user adoption path where a full-n=
ode is required to benefit for LN may deprive a lot of users, especially th=
ose who are already denied a real financial infrastructure access. It doesn=
&#39;t mean we shouldn&#39;t foster node adoption when people are able to d=
o so, and having a LN wallet maybe even a first-step to it.<br><br></div><d=
iv>Designing a mobile-first LN experience opens its own gap of challenges e=
specially in terms of security and privacy. The problem can be scoped as ho=
w to build a scalable, secure, private chain access backend for millions of=
 LN clients ?<br><br></div><div>Light client protocols for LN exist (either=
 BIP157 or Electrum are used), although their privacy and security guarante=
es 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 n=
umber of full-nodes being willingly to dedicate resources to serve those cl=
ients. It&#39;s not about _which_ protocol is deployed but more about _ince=
ntives_ for node operators to dedicate long-term resources to client they h=
ave lower reasons to care about otherwise.<br><br></div><div>Even with chea=
per, 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&#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 signal BIP 157, =
that&#39;s an increase of 100GB/month for each. Which is consequent with re=
gards to the estimated cost of 350GB/month for running an actual public nod=
e. Widening full-node adoption, specially in term of geographic distributio=
n means as much as we can to bound its operational cost.<br><br></div><div>=
Obviously,=C2=A0 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 c=
onnections.<br><br></div><div>Unless your light client protocol is so ridic=
ulous cheap to rely on niceness of a subset of node operators 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, e=
ven worst their growth rate won&#39;t be the same, first ones are so much e=
asier 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 wallet vendors building such chain access b=
ackend, hitting a bandwidth scalability wall few years from now instead of =
pursuing better solutions. And if this happen, maybe suddenly, isn&#39;t th=
e 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 curre=
nt full-node operators don&#39;t get anything back from servicing blocks, t=
ransactions, addresses... It may be replied that you have an indirect incen=
tive to participate in network relay and therefore guarantee censorship-res=
istance, instead of directly connecting to miners. You do have today ways t=
o select your resources exposure like pruning, block-only or being private =
but the wider point is the current (non?)-incentives model seems to work fo=
r the base layer. For light clients data, are node operators going to be sa=
tisfied 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 unlimi=
ted credit, but it&#39;s more likely their intentions maybe not aligned, li=
ke spying on your transaction broadcast or block fetched. And you do want p=
eer diversity to avoid every BIP157 servers being on few ASNs for fault-tol=
erance. Do people expect a scenario a la Cloudflare, where everyone connect=
ions is to far or less the same set of entities ?<br><br>Moreover, the LN s=
ecurity 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* require=
ment means the entity owning your view of the chain can lie to you on wheth=
er your channel has been spent by a revoked commitment, the real tip of the=
 blockchain or even dry-up block announcement to trigger unexpected behavio=
r in the client logic. A malicious light client server may just drop any fi=
lters/utxos spends, what your LN client should do in this case ? [1]<br><br=
>Therefore, you may want to introduce monetary compensation in exchange of =
servicing filters. Light client not dedicating resources to maintain the ne=
twork but free-riding on it, you may use their micro-payment capabilities t=
o price chain access resources [3]. This proposition may suit within the wa=
tchtower paradigm, where another entity is delegated some part of protocol =
execution, alleviating client onliness requirement. It needs further analys=
is but how your funds may be compromised by a watchtower are likely to be t=
he same scenario that how a chain validation provider can compromise you. T=
hat 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 and create some kind of scarcity but st=
ill...<br><br>Maybe I&#39;m completely 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 ca=
se 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 bottle=
neck, but still if you have 2 channels by clients that&#39;s 20M utxos, jus=
t roughly ~x3 than today.<br><br>[1] And committing filters as part of head=
ers may not solve everything as an attacker can just delay or slow announce=
ments to you, so you still need network 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 client and start synchronizing the chain,=
 relaying blocks, etc. AFAIK, there is no such hybrid implementation and th=
at&#39;s not what you want to run in a mobile.<br><br></div></div></div>

--000000000000b8590105a4e3f559--