Published on: 2020-05-17T09:11:33+00:00
The email conversation revolves around improving the user experience of connecting a mobile Lightning Network client to a home full node. Currently, a solution called QuickConnect exists, but it still needs further development. Contributions to requirements and proposals for the next version are welcome.The discussion explores the potential of Lightning Network replacing centralized custodial services, which would allow for scalability while maintaining noncustodiality. Evaluating economic weight in Lightning is challenging due to different chain views. The implementation of backup servers that are publicly-facing is suggested, but ensuring uniform distribution is difficult in a free market. An alternative solution proposed is to have everyone run a privately-owned server, similar to having a Lightning node at home with a full node accessed via a remote control mobile device.The conversation also highlights the importance of combining UX, user education, and fallback security mechanisms to avoid economy hijack. The economic weight of nodes is discussed in evaluating miner consensus-hijack success. The hope is that Lightning will replace centralized custodial services, but there are concerns about compromising Bitcoin's security model. It is emphasized that a supermajority of the economy should be verifying transactions using their own full nodes to prevent potential attacks and splits in the system.Another topic of discussion is the challenges faced by off-grid nodes relying on local network peers for blockchain information. Possible solutions include using prepaid tokens issued by validation-information-providers or utilizing watchtower service providers. Privacy concerns when public-service nodes serve generic headers to light clients are also addressed, with a suggestion to use Tor for accessing public-service nodes and decorrelating payments for services.In addition, proposals are made for defining different sets of wallet functionality to inform the future of core wallet functionality. A collaboration is suggested to work on this, starting with a transparent shim between bitcoin-core and remote RPC. The idea of running full nodes on mobile phones as part-time or Sleeper Nodes is also proposed.The challenges in designing a scalable, secure, and private chain access backend for Lightning Network clients are discussed. Compensating node operators for servicing filters may be necessary, but avoiding market concentration is a concern.Finally, the need for an interface between a peer and owner interface is expressed, with suggestions for a cryptographic capability mechanism that allows remote wallets to request specific node functions and additional authorization for rarer services. Blockchain Commons expresses interest in hosting a collaboration to define different sets of wallet functionality for future core wallet improvements.In an email conversation, Keagan McClelland and others discussed the limitations of the RPC interface in Bitcoin Core and the need for a peer service model between "full public" and "owner only" interfaces. The RPC interface exposes unnecessary functionality and introduces risks. Keagan suggests that light clients should explicitly choose their full node tethers to limit peer services to authenticated peers. However, there are concerns about consensus capture by economically weighty institutions.Antoine Riard discusses the potential scalability issues of BIP 157 and highlights the positive aspect of BIP 157+158's protocol, which would make serving light clients stateless. This allows for the servability of the entire protocol over HTTP, taking advantage of established CDNs and anycast serving infrastructure. Compact block filters can be useful due to their statelessness, as they eliminate the inefficiencies of Bloom filters for blocks.Igor Cota suggests exploring the feasibility of running full nodes on everyday phones as an alternative to relying on a few thousand full-node operators servicing Lightning Network mobile clients. He proposes part-time or Sleeper Nodes™ that work while their operator is asleep, allowing mobile nodes to earn their keep. Antoine Riard discusses the ongoing advancement of BIP 157 implementation in Core and the future of light client protocols. He suggests introducing monetary compensation for servicing filters to incentivize full node operators.The discussion also revolves around externalizing the costs of security from light clients onto full nodes. It is suggested that having light clients choose their full node tethers explicitly could be a solution, but there are concerns about consensus capture by economically weighty institutions. Luke Dashjr opposes improving the "full node-less" experience, stating that it compromises Bitcoin's security assumption. All efforts to improve the "full node-less" experience should be actively avoided.The scalability of light client protocols for Lightning Network is discussed, along with the need for a scalable, secure, private chain access backend for millions of LN clients. The current trust-minimization paradigm may be shifted by LN, but efforts to improve the "full node-less" experience should be avoided. Monetary compensation can be introduced in exchange for servicing filters, and LSATs can be used to add a lightweight payment mechanism.The implementation of BIP 157 protocol in Core is also discussed. Arguments against light clients are restated, but the choice is whether to offer a better or worse light client technology. The benefits of BIP 157 over existing technologies are summarized, including uniqueness for a block and being less prone to DoS attacks.
Updated on: 2023-08-02T02:11:33.606489+00:00