diff options
author | Antoine Riard <antoine.riard@gmail.com> | 2020-05-05 06:17:37 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2020-05-05 10:17:53 +0000 |
commit | 31528787fb0e69f1d1f8cb5f21e2e0c4086e7d32 (patch) | |
tree | 68fded914d82edf1251ab9b225957d6ee0c6e6f8 | |
parent | e4efebe1aa3f41fe83c27b7075cb333a149602c3 (diff) | |
download | pi-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/01432bf72653c8a4252e685d975a8a470dc995 | 300 |
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'= +;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= +'t mean we shouldn'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'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'= +;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 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't scale. And it'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't be the same, first ones are so much e= +asier to setup.<br><br></div><div>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=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'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'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't find BIP157 servers, ready to serve you with unlimi= +ted credit, but it'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 "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 st= +ill...<br><br>Maybe I'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'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'= +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's not what you want to run in a mobile.<br><br></div></div></div> + +--000000000000b8590105a4e3f559-- + |