On the scalability issues of onboarding millions of LN mobile clients

The ongoing advancement of BIP 157 implementation in Core presents an opportunity to reflect on the future of light client protocols. This knowledge can help make better-informed decisions about the kind of infrastructure needed to support mobile clients at a large scale. Trust-minimization of Bitcoin security model has always relied on running a full-node, but this paradigm may be shifting with the advent of LN. Fast, affordable, confidential, censorship-resistant payment services offered by LN may attract a lot of adoption without users running a full-node. Designing a mobile-first LN experience poses several challenges, particularly in terms of security and privacy. One bottleneck for LN is the number of full-nodes willing to dedicate resources to serve those clients. Assuming 10M light clients each consuming approximately 100MB/month for filters/headers, that means asking for 1PB/month of traffic to the backbone network. Even with cheaper and more efficient protocols like BIP 157, there may be a huge discrepancy between what is asked and what is offered. Unless the light client protocol is cheap enough to rely on the niceness of a subset of node operators offering free resources, it won't scale.Igor has been exploring the feasibility of running full nodes on everyday phones for some months now. One of his first thoughts was how to avoid the phones mooching off the network. However, he realized that the time we are asleep and our phones are connected to wifi and charging is a huge untapped resource that would allow mobile nodes to earn their keep. 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. 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. 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.Introducing monetary compensation in exchange for servicing filters may suit within the watchtower paradigm, where another entity is delegated some part of the protocol execution, alleviating client onliness requirement. However, it needs further analysis to avoid such "chain access" market turning into an oligopoly. In a discussion on the Lightning-dev mailing list, Antoine acknowledges Gleb's points about potential UTXO set size bottlenecks in the Lightning Network. He notes that even with just two channels, there could be around 20 million UTXOs, triple the current amount. Furthermore, the group discusses the potential for committing filters as part of headers to improve security, but acknowledges that an attacker could still delay or slow announcements. Additionally, they touch on the idea that the client-vs-peer distinction may not hold, as users may start as clients and then transition to relaying blocks, though this hybrid implementation is not ideal for mobile devices. Igor Cota of Codex Apertus Ltd adds his signature to the post.