public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Antoine Riard <antoine.riard@gmail•com>
To: "Andrés G. Aragoneses" <knocte@gmail•com>
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
Date: Wed, 6 May 2020 04:27:45 -0400	[thread overview]
Message-ID: <CALZpt+GnZa-LpNQHFLECAChStvfPb2MTc2oW0rHy275ciRvYuw@mail.gmail.com> (raw)
In-Reply-To: <CAGKT+VcZsMW_5jOqT2jxtbYTEPZU-NL8v3gZ8VJAP-bMe7iLSg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 7867 bytes --]

I didn't trust myself and verify. In fact the [3] is the real [2].

Le mar. 5 mai 2020 à 06:28, Andrés G. Aragoneses <knocte@gmail•com> a
écrit :

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

[-- Attachment #2: Type: text/html, Size: 8552 bytes --]

  parent reply	other threads:[~2020-05-06  8:27 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-05 10:17 [bitcoin-dev] " Antoine Riard
2020-05-05 13:00 ` Luke Dashjr
2020-05-05 13:49   ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2020-05-05 17:09     ` John Newbery
2020-05-06  9:21       ` Antoine Riard
2020-05-05 15:16   ` [bitcoin-dev] " Lloyd Fournier
2020-05-12 21:05     ` Chris Belcher
2020-05-13 19:51       ` [bitcoin-dev] [Lightning-dev] " Antoine Riard
2020-05-14  4:02         ` ZmnSCPxj
     [not found]           ` <45FD4FF1-1E09-4748-8B05-478DEF6C1966@ed.ac.uk>
2020-05-14 15:25             ` Keagan McClelland
2020-05-17  9:11               ` Christopher Allen
2020-05-14 15:27             ` William Casarin
2020-05-17  3:37           ` Antoine Riard
2020-05-06  9:06   ` [bitcoin-dev] " Antoine Riard
2020-05-06 16:00     ` [bitcoin-dev] [Lightning-dev] " Keagan McClelland
2020-05-07  3:56       ` Antoine Riard
2020-05-07  4:07         ` Keagan McClelland
2020-05-08 19:51           ` Braydon Fuller
2020-05-08 20:01             ` Keagan McClelland
2020-05-08 20:22               ` Braydon Fuller
2020-05-08 21:29               ` Christopher Allen
2020-05-09  7:48                 ` Antoine Riard
2020-05-06  0:31 ` Olaoluwa Osuntokun
2020-05-06  9:40   ` Antoine Riard
     [not found]     ` <CACJVCgL4fAs7-F2O+T-gvTbpjsHhgBrU73FaC=EUHG5iTi2m2Q@mail.gmail.com>
2020-05-11  5:44       ` ZmnSCPxj
2020-05-12 10:09         ` Richard Myers
2020-05-12 15:48           ` ZmnSCPxj
2020-05-08 19:33   ` Braydon Fuller
     [not found] ` <CAGKT+VcZsMW_5jOqT2jxtbYTEPZU-NL8v3gZ8VJAP-bMe7iLSg@mail.gmail.com>
2020-05-06  8:27   ` Antoine Riard [this message]
2020-05-07 16:40 ` Igor Cota
2020-05-09  7:22   ` Antoine Riard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALZpt+GnZa-LpNQHFLECAChStvfPb2MTc2oW0rHy275ciRvYuw@mail.gmail.com \
    --to=antoine.riard@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=knocte@gmail$(echo .)com \
    --cc=lightning-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox