Re: [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients
___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients
Good morning Richard,
> Thanks for sharing your thoughts ZmnSCPxj. I think I can summarize your
> concern as: A node without direct internet connectivity can not rely on an
> opportunistically incentivized local network peer for blockchain information
> because the off-grid node's direct LN peers could collude to not forward the
> payment.
Correct.
> > > 2) a light client can query an ISP connected full node on the same
> > > unmetered local WiFi network and exchange differences in block headers
> > > opportunistically or pay for large missing ranges of headers, filters or
> > > full blocks using a payment channel. Cost is reduced and privacy is
> > > enhanced for the light client by not using a centralized ISP. Bandwidth
> > > for running the full node can be amortized and subsidized by payments
> > > from light clients who they resell data to.
> >
> > A relatively pointless observation, but it seems to me that:
> >
> > * The light client is requesting for validation information, because...
> > * ...its direct peers might be defrauding it, leading to...
> > * ...the money it *thinks* it has in its channels being valueless.
> >
> > Thus, if the light client opportunistically pays for validation information
> > (whether full blocks, headers, or filters), the direct peers it has could
> > just as easily not forward any payments, thus preventing the light client
> > from paying for the validation information.
> >
> > Indeed, if the direct peer *is* defrauding the light client, the direct
> > peer has no real incentive to actually forward *any* payments --- to do so
> > would be to reduce the possible earnings it gets from defrauding the light
> > client.
> > ("Simulating" the payments so that the light client will not suspect
> > anything runs the risk that the light client will be able to forward all
> > its money out of the channel, and the cheating peer is still potentially
> > liable for any funds it originally had in the channel if it gets caught.)
>
> One question I had is: how can a malicious direct payment peer "simulate" a
> successful payment made by an off-grid victim peer to an information source?
> The censoring peer wouldn't be able to return the preimage for a payment they
> failed to forward. Also, since the information provider and off-grid node can
> presumably communicate via their local network connection, it would be
> obvious if all of the victims LN peers were failing to forward payments
> (whether maliciously or due to routing failures) to an information provider
> they could otherwise communicate with.
Perhaps "simulate" is not quite the correct term.
Basically, if the eclipsing peer(s) are reasonably sure they have eclipsed the
light client, then all funds in those channels are semantically theirs (they
"0wn" the eclipsed light client).
Then anything the light node offers from those channels (which it thinks are
its, but are now in reality owned by the eclipsing peer) has no value (the
eclipsing node already 0wns the light node and all its funds, what can the
light node offer to it?).
The eclipsing peer could still "simulate" what the light node expects of
reality by pretending that the light node actually still owns funds in the
channel (even though the eclipsing node has successfully stolen all those
funds), and forward as normal to get the payment preimage/scalar.
> > What would work would be to use a system similar to watchtowers, wherein
> > the validation-information-provider is prepaid and issues tokens that can
> > be redeemed later.
> > But this is not suitable for opportunistic on-same-WiFi where, say, a
> > laptop is running a validation-information-provider-for-payment program on
> > the same WiFi as a light-client mobile phone, if we consider that the
> > laptop and mobile may have never met before and may never meet again.
> > It would work if the laptop altruistically serves the blocks, but not if it
> > were for (on-Lightning) payment.
>
> There's another problem if we can't rely on a recurring relationship with an
> information provider besides not being able to prepay for validation
> information doesn't make sense. We don't want an information provider to
> collect payments for serving invalid information. Maybe for very small
> payments this isn't a problem, but ideally validity could be coded into the
> HTLC.
>
> For example, an alternative HTLC construct that only paid for valid 81 B
> headers that hash to 32 B values with a number of leading zeros committed to
> by the HTLC. It would make more economic sense for an internet gateway node
> to serve valid mined header to nodes on their local WiFi network than to
> create bogus ones with the same (high) amount of work.
If you are considering this for on-Lightning payments, do note that the
alternative HTLC construct has to be known by every forwarding node, including
the direct peer(s) of the light client, which are precisely the potential
attackers on
Re: [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients
Thanks for sharing your thoughts ZmnSCPxj. I think I can summarize your
concern as: A node without direct internet connectivity can not rely on an
opportunistically incentivized local network peer for blockchain
information because the off-grid node's direct LN peers could collude to
not forward the payment.
On Mon, May 11, 2020 at 7:44 AM ZmnSCPxj wrote:
> > 2) a light client can query an ISP connected full node on the same
> unmetered local WiFi network and exchange differences in block headers
> opportunistically or pay for large missing ranges of headers, filters or
> full blocks using a payment channel. Cost is reduced and privacy is
> enhanced for the light client by not using a centralized ISP. Bandwidth for
> running the full node can be amortized and subsidized by payments from
> light clients who they resell data to.
>
> A relatively pointless observation, but it seems to me that:
>
> * The light client is requesting for validation information, because...
> * ...its direct peers might be defrauding it, leading to...
> * ...the money it *thinks* it has in its channels being valueless.
>
> Thus, if the light client opportunistically pays for validation
> information (whether full blocks, headers, or filters), the direct peers it
> has could just as easily not forward any payments, thus preventing the
> light client from paying for the validation information.
>
> Indeed, if the direct peer *is* defrauding the light client, the direct
> peer has no real incentive to actually forward *any* payments --- to do so
> would be to reduce the possible earnings it gets from defrauding the light
> client.
> ("Simulating" the payments so that the light client will not suspect
> anything runs the risk that the light client will be able to forward all
> its money out of the channel, and the cheating peer is still potentially
> liable for any funds it originally had in the channel if it gets caught.)
>
One question I had is: how can a malicious direct payment peer "simulate" a
successful payment made by an off-grid victim peer to an information
source? The censoring peer wouldn't be able to return the preimage for a
payment they failed to forward. Also, since the information provider and
off-grid node can presumably communicate via their local network
connection, it would be obvious if all of the victims LN peers were failing
to forward payments (whether maliciously or due to routing failures) to an
information provider they could otherwise communicate with.
Any LN payments not monitored by a watchtower that are received by the
eclipsed off-grid victim node would be at risk in this attack scenario.
Likewise any layer 1 payments they received should be buried under
sufficient valid block headers before being relied on.
I don't see how a LN node one-step removed from a direct internet
connection is at more risk than an internet connected node eclipsed by
their ISP, for example. In both cases, failure to get timely blockchain
info should trigger warnings to stop accepting payments.
> What would work would be to use a system similar to watchtowers, wherein
> the validation-information-provider is prepaid and issues tokens that can
> be redeemed later.
> But this is not suitable for opportunistic on-same-WiFi where, say, a
> laptop is running a validation-information-provider-for-payment program on
> the same WiFi as a light-client mobile phone, if we consider that the
> laptop and mobile may have never met before and may never meet again.
> It would work if the laptop altruistically serves the blocks, but not if
> it were for (on-Lightning) payment.
>
There's another problem if we can't rely on a recurring relationship with
an information provider besides not being able to prepay for validation
information doesn't make sense. We don't want an information provider to
collect payments for serving invalid information. Maybe for very small
payments this isn't a problem, but ideally validity could be coded into the
HTLC.
For example, an alternative HTLC construct that only paid for valid 81 B
headers that hash to 32 B values with a number of leading zeros committed
to by the HTLC. It would make more economic sense for an internet gateway
node to serve valid mined header to nodes on their local WiFi network than
to create bogus ones with the same (high) amount of work.
> So it seems to me that this kind of service is best ridden on top of
> watchtower service providers.
>
Public watchtowers or some sort of HTTP proxy data cache similar to a
watchtower makes the most sense to me because they would be expected to be
economically motivated and LN payment aware. Full nodes could potentially
be incentivized to exchange new data with other nodes in a tit-for-tat way,
but I don't expect them to be incentivized by light clients using LN
micropayments in a server-client arrangement.
Network agents that monetize full node information services beyond channel
monitoring would be more than just a "Watchtower" for light
Re: [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients
Good morning Richard, and all,
> 2) a light client can query an ISP connected full node on the same unmetered
> local WiFi network and exchange differences in block headers
> opportunistically or pay for large missing ranges of headers, filters or full
> blocks using a payment channel. Cost is reduced and privacy is enhanced for
> the light client by not using a centralized ISP. Bandwidth for running the
> full node can be amortized and subsidized by payments from light clients who
> they resell data to.
A relatively pointless observation, but it seems to me that:
* The light client is requesting for validation information, because...
* ...its direct peers might be defrauding it, leading to...
* ...the money it *thinks* it has in its channels being valueless.
Thus, if the light client opportunistically pays for validation information
(whether full blocks, headers, or filters), the direct peers it has could just
as easily not forward any payments, thus preventing the light client from
paying for the validation information.
Indeed, if the direct peer *is* defrauding the light client, the direct peer
has no real incentive to actually forward *any* payments --- to do so would be
to reduce the possible earnings it gets from defrauding the light client.
("Simulating" the payments so that the light client will not suspect anything
runs the risk that the light client will be able to forward all its money out
of the channel, and the cheating peer is still potentially liable for any funds
it originally had in the channel if it gets caught.)
What would work would be to use a system similar to watchtowers, wherein the
validation-information-provider is prepaid and issues tokens that can be
redeemed later.
But this is not suitable for opportunistic on-same-WiFi where, say, a laptop is
running a validation-information-provider-for-payment program on the same WiFi
as a light-client mobile phone, if we consider that the laptop and mobile may
have never met before and may never meet again.
It would work if the laptop altruistically serves the blocks, but not if it
were for (on-Lightning) payment.
So it seems to me that this kind of service is best ridden on top of watchtower
service providers.
Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients
Hi Igor, Thanks for sharing about what it's technically possible to do for a full-node on phone, specially with regards to lower grade devices. I do see 2 limitations for sleeping nodes: - a lightning specific one, i.e you need to process block data real-time in case of incoming HTLC you need to claim on chain or a HTLC timeout. There is a bunch of timelocks implications in LN, with regards to CSV, CLTV_DELTA, incoming policy, outgoing policy, ... and you can't really afford to be late without loosing a payment. I don't see timelocks being increase, that would hinder liquidity. - a p2p bandwidth concern, even if this new class of nodes turn as public ones, they would still have a heavy sync period due to be fallen-behind during the day, so you would have huge bandwidth spikes every a timezone falls asleep and a risk of choking upload links of stable full-nodes. I think assume-utxo may be interesting in the future in case of long-fork detection, you may be able to download a utxo-set on the fly, and fall-back to a full-node. But that would be only an emergency measure, not a regular cost on the backbone network. Antoine Le jeu. 7 mai 2020 à 12:41, Igor Cota a écrit : > Hi Antoine et al, > > 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. >> > > >> So you may want to separate control/data plane, get filters from CDN and >> headers as check-and-control directly from the backbone network. "Hybrid" >> models should clearly be explored. > > > For some months now I've been exploring the feasibility of running full > nodes on everyday phones [1]. One of my first thoughts was how to avoid the > phones mooching off the network. Obviously due to battery, storage and > bandwidth constraints it is not reasonable to expect pocket full nodes to > serve blocks during day time. > > Huge exception to this is the time we are asleep and our phones are > connected to wifi and charging. IMO this is a huge untapped resource that > would allow mobile nodes to earn their keep. If we limit full node > operation to sleepy night time the only constraining resource is storage: > 512 gb of internal storage in phones is quite rare, probably about $100 for > an SD card with full archival node capacity but phones with memory card > slots rarer still - no one is going to bother. > > So depending on their storage capacity phone nodes could decide to store > and serve just a randomly selected range of blocks during their nighttime > operation. With trivial changes to P2P they could advertise the blocks they > are able to serve. > If there comes a time that normal full nodes feel DoS'ed they can > challenge such nodes to produce the blocks they advertise and ban them as > moochers if they fail to do so. Others may elect to be more charitable and > serve everyone. > > These types of nodes would truly be part-timing since they only carry a > subset of the blockchain and work while their operator is asleep. Probably > should be called part-time or Sleeper Nodes™. > > They could be user friendly as well, with Assume UTXO they could be > bootstrapped quickly and while they do the IBD in the background instead of > traditional pruning they can keep the randomly assigned bit of blockchain > to later serve the network. > > Save for the elderly, all the people I know could run such a node, and I > don't live in a first world country. > > There is also the feel-good kumbaya aspect of American phone nodes serving > the African continent while the Americans are asleep, Africans and > Europeans serving the Asians in kind. By plugging in our phones and going > to sleep we could blanket the whole world in (somewhat) full nodes! > > Cheers, > Igor > > [1] https://icota.github.io/ > > On Tue, 5 May 2020 at 12:18, 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 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
Re: [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients
Hi Antoine et al, 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. > > So you may want to separate control/data plane, get filters from CDN and > headers as check-and-control directly from the backbone network. "Hybrid" > models should clearly be explored. For some months now I've been exploring the feasibility of running full nodes on everyday phones [1]. One of my first thoughts was how to avoid the phones mooching off the network. Obviously due to battery, storage and bandwidth constraints it is not reasonable to expect pocket full nodes to serve blocks during day time. Huge exception to this is the time we are asleep and our phones are connected to wifi and charging. IMO this is a huge untapped resource that would allow mobile nodes to earn their keep. If we limit full node operation to sleepy night time the only constraining resource is storage: 512 gb of internal storage in phones is quite rare, probably about $100 for an SD card with full archival node capacity but phones with memory card slots rarer still - no one is going to bother. So depending on their storage capacity phone nodes could decide to store and serve just a randomly selected range of blocks during their nighttime operation. With trivial changes to P2P they could advertise the blocks they are able to serve. If there comes a time that normal full nodes feel DoS'ed they can challenge such nodes to produce the blocks they advertise and ban them as moochers if they fail to do so. Others may elect to be more charitable and serve everyone. These types of nodes would truly be part-timing since they only carry a subset of the blockchain and work while their operator is asleep. Probably should be called part-time or Sleeper Nodes™. They could be user friendly as well, with Assume UTXO they could be bootstrapped quickly and while they do the IBD in the background instead of traditional pruning they can keep the randomly assigned bit of blockchain to later serve the network. Save for the elderly, all the people I know could run such a node, and I don't live in a first world country. There is also the feel-good kumbaya aspect of American phone nodes serving the African continent while the Americans are asleep, Africans and Europeans serving the Asians in kind. By plugging in our phones and going to sleep we could blanket the whole world in (somewhat) full nodes! Cheers, Igor [1] https://icota.github.io/ On Tue, 5 May 2020 at 12:18, 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 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
Re: [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients
Thanks Antoine for starting this thread, I've also been curious about the current thinking on light clients and incentivized full node services after seeing the LSAT work. On Wed, May 6, 2020 at 11:40 AM Antoine Riard wrote: > > Yeah, I hadn't time to read the spec yet but that was clearly something > like LSATs I meaned speaking about monetary compensation to price > resources. I just hope it isn't too much tie to HTTP because you may want > to read/write over other communication channels like > tx-broadcast-over-radio to solve first-hop privacy. > I think we should consider alternative peer-to-peer communication channels both in the context of supporting light client users and encouraging full node diversity. Because block headers and block filters can be cached and forwarded we can use pure broadcast systems like geostationary satellites or radio systems with various trade-offs between range and bandwidth such as amateur radio, unlicensed UHF and community WiFi. Protocol features that support low-bandwidth broadcast and local peer-to-peer networks add resilience to the Bitcoin network because they can not be as easily sybilled, censored or surveilled en mass, as centralized ISPs can be. Bandwidth is the primary limitation of these alternative last-mile networks compared to nodes using wired internet connections. We would like all Bitcoin nodes to operate as equal peers (flat network), but the reality is that potential Bitcoin users do not have equal access to affordable bandwidth from centralized providers. A system that lets light clients access full nodes over local peer-to-peer networks could make self-custody more accessible to light-client users and more local full nodes incentivized to provide services over local peer-to-peer networks could help increase the geographic diversity of full nodes. For example, a light client could have inbound connections for block headers and filters from 1) other light client peers via bluetooth, 2) an ISP connected full node via a community WiFi network and 3) a blocksat connected full node via a UHF mesh network. These scenarios in more detail: 1) two nearby light clients can exchange cached block headers, block filters and full blocks over bluetooth or shared local WiFi - either tit for tat or altruistically. Full blocks can be used to spot check block filters and new block headers can help detect forks. There is no communication cost and when the local internet is censored or down can help (slowly) relay network state from any small set of operating links to the outside internet. 2) a light client can query an ISP connected full node on the same unmetered local WiFi network and exchange differences in block headers opportunistically or pay for large missing ranges of headers, filters or full blocks using a payment channel. Cost is reduced and privacy is enhanced for the light client by not using a centralized ISP. Bandwidth for running the full node can be amortized and subsidized by payments from light clients who they resell data to. 3) an off-grid validating full node can receive block information from the blocksat, but cross validate block headers from nearby full nodes connected to ISPs and light clients with cached information via low-bandwidth long-range UHF mesh radio. This full node has no fixed bandwidth costs and can also earn LN payments from light clients to help subsidize their initial hardware purchase. I also believe a light-client could confirm specific transactions by querying for Merkle proofs instead of full blocks when using a low-bandwidth long distance and/or multi-hop radio link without the same privacy linking concerns these queries would have if made using an internet address tied to their identity or more specific physical location. I wouldn't argue to add this to the core protocol, but like Watchtowers it's a service that can monetize and support the operation of a full node. -- Richard ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients
> As a result, the entire protocol could be served over something like HTTP, taking advantage of all the established CDNs and anycast serving infrastructure, Yes it's moving the issue of being a computation one to a distribution one. But still you need the bandwidth capacities. What I'm concerned is the trust model of relying on few-establish CDNs, you don't want to make it easy to have "headers-routing" hijack and therefore having massive channel closure or time-locks interference due to LN clients not seeing the last few block. So you may want to separate control/data plane, get filters from CDN and headers as check-and-control directly from the backbone network. "Hybrid" models should clearly be explored. Web-of-trust style of deployments should be also envisioned, you may get huge scaling improvement, assuming client may be peers between themselves and the ones belonging to the same social entity should be able to share the same chain view without too much risk. > Piggy backing off the above idea, if the data starts being widely served over HTTP, then LSATs[1][2] can be used to add a lightweight payment mechanism by inserting a new proxy server in front of the filter/header infrastructure. Yeah, I hadn't time to read the spec yet but that was clearly something like LSATs I meaned speaking about monetary compensation to price resources. I just hope it isn't too much tie to HTTP because you may want to read/write over other communication channels like tx-broadcast-over-radio to solve first-hop privacy. Le mar. 5 mai 2020 à 20:31, Olaoluwa Osuntokun a écrit : > Hi Antoine, > > > 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 > > One really dope thing about BIP 157+158, is that the protocol makes serving > light clients now _stateless_, since the full node doesn't need to perform > any unique work for a given client. As a result, the entire protocol could > be served over something like HTTP, taking advantage of all the established > CDNs and anycast serving infrastructure, which can reduce syncing time > (less latency to > fetch data) and also more widely distributed the load of light clients > using > the existing web infrastructure. Going further, with HTTP/2's server-push > capabilities, those serving this data can still push out notifications for > new headers, etc. > > > 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] > > Piggy backing off the above idea, if the data starts being widely served > over HTTP, then LSATs[1][2] can be used to add a lightweight payment > mechanism by inserting a new proxy server in front of the filter/header > infrastructure. The minted tokens themselves may allow a user to purchase > access to a single header/filter, a range of them in the past, or N headers > past the known chain tip, etc, etc. > > -- Laolu > > [1]: https://lsat.tech/ > [2]: https://lightning.engineering/posts/2020-03-30-lsat/ > > > On Tue, May 5, 2020 at 3:17 AM 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 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
Re: [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients
Hi Antoine, > 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 One really dope thing about BIP 157+158, is that the protocol makes serving light clients now _stateless_, since the full node doesn't need to perform any unique work for a given client. As a result, the entire protocol could be served over something like HTTP, taking advantage of all the established CDNs and anycast serving infrastructure, which can reduce syncing time (less latency to fetch data) and also more widely distributed the load of light clients using the existing web infrastructure. Going further, with HTTP/2's server-push capabilities, those serving this data can still push out notifications for new headers, etc. > 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] Piggy backing off the above idea, if the data starts being widely served over HTTP, then LSATs[1][2] can be used to add a lightweight payment mechanism by inserting a new proxy server in front of the filter/header infrastructure. The minted tokens themselves may allow a user to purchase access to a single header/filter, a range of them in the past, or N headers past the known chain tip, etc, etc. -- Laolu [1]: https://lsat.tech/ [2]: https://lightning.engineering/posts/2020-03-30-lsat/ On Tue, May 5, 2020 at 3:17 AM 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 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
Re: [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients
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 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
[Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients
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
