From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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: In-Reply-To: From: Antoine Riard Date: Wed, 6 May 2020 04:27:45 -0400 Message-ID: To: =?UTF-8?Q?Andr=C3=A9s_G=2E_Aragoneses?= Content-Type: multipart/alternative; boundary="00000000000094f54105a4f68afb" X-Mailman-Approved-At: Wed, 06 May 2020 13:25:00 +0000 Cc: Bitcoin Protocol Discussion , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > 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
I didn't trust myself and verify. In fact the [3] is t= he real [2].

Le=C2=A0mar. 5 mai 2020 =C3=A0=C2=A006:28, Andr=C3=A9s G. A= ragoneses <knocte@gmail.com> = a =C3=A9crit=C2=A0:
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 Riar= d <antoine.= riard@gmail.com> wrote:
Hi,

(cross-po= sting as it's really both layers concerned)

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.

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't mean we shouldn'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>
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 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'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.

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'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'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.
=
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.

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'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 one= s are so much easier to setup.

It doesn't mean servic= ing filters for free won'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'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 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>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. 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 ?

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]

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 "chain access" mar= ket turning as an oligopoly is an open question. You may "bind" t= hem to internet topology or ask for fidelity bonds and create some kind of = scarcity but still...

Maybe I'm completely wrong, missing some n= umbers, 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.
<= br>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 o= r slow announcements to you, so you still need network access to at least o= ne honest node.

[2]=C2=A0 It maybe argue that distinction client-vs-= peer doesn'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's not what you want to run in a mobile.

=
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/ma= ilman/listinfo/lightning-dev
--00000000000094f54105a4f68afb--