___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
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
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
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
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
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
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
> 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
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
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
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
11 matches
Mail list logo
