summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAntoine Riard <antoine.riard@gmail.com>2020-05-05 06:17:37 -0400
committerbitcoindev <bitcoindev@gnusha.org>2020-05-05 10:17:53 +0000
commit31528787fb0e69f1d1f8cb5f21e2e0c4086e7d32 (patch)
tree68fded914d82edf1251ab9b225957d6ee0c6e6f8
parente4efebe1aa3f41fe83c27b7075cb333a149602c3 (diff)
downloadpi-bitcoindev-31528787fb0e69f1d1f8cb5f21e2e0c4086e7d32.tar.gz
pi-bitcoindev-31528787fb0e69f1d1f8cb5f21e2e0c4086e7d32.zip
[bitcoin-dev] On the scalability issues of onboarding millions of LN mobile clients
-rw-r--r--a3/01432bf72653c8a4252e685d975a8a470dc995300
1 files changed, 300 insertions, 0 deletions
diff --git a/a3/01432bf72653c8a4252e685d975a8a470dc995 b/a3/01432bf72653c8a4252e685d975a8a470dc995
new file mode 100644
index 000000000..c0091ed0b
--- /dev/null
+++ b/a3/01432bf72653c8a4252e685d975a8a470dc995
@@ -0,0 +1,300 @@
+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--
+