[Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

Richard Myers rich at gotenna.com
Thu May 7 11:09:37 UTC 2020

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 <antoine.riard at gmail.com>

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200507/f6246a76/attachment.html>

More information about the Lightning-dev mailing list