<div dir="ltr"><div>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.</div><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 6, 2020 at 11:40 AM Antoine Riard <<a href="mailto:antoine.riard@gmail.com" target="_blank">antoine.riard@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><br></div><div>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.<br></div></div></div></div></blockquote><div><br></div><div><div>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. </div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div> </div><div>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:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>  -- Richard</div></div></div></div>
</div>