📅 Original date posted:2020-05-07
📝 Original message:
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>
wrote:
>
> 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>;
Richard Myers [ARCHIVE] /
npub12j…hfxgj
2023-06-09 13:00:03
in reply to nevent1q…ehxp
Author Public Key
npub12jllrss5nmygfhg7j9ztk2te80t96kumx7cllfc29skut6phqh5qfhfxgjPublished at
2023-06-09 13:00:03Event JSON
{
"id": "6db6603c5efa71b0b653de0cb3c86140cb3e5a116690798935de593cb0345569",
"pubkey": "54bff1c2149ec884dd1e9144bb29793bd65d5b9b37b1ffa70a2c2dc5e83705e8",
"created_at": 1686315603,
"kind": 1,
"tags": [
[
"e",
"0df2add4dfaccf277be2eccc5a234af8a5a96a1dccfe3049efece9360df07a6f",
"",
"root"
],
[
"e",
"6653c21103d119e01e90234aa17c07f9b415300f7d0a20d105470fcbfd5e95ba",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "📅 Original date posted:2020-05-07\n📝 Original message:\nThanks Antoine for starting this thread, I've also been curious about the\ncurrent thinking on light clients and incentivized full node services after\nseeing the LSAT work.\n\nOn Wed, May 6, 2020 at 11:40 AM Antoine Riard \u003cantoine.riard at gmail.com\u003e\nwrote:\n\n\u003e\n\u003e Yeah, I hadn't time to read the spec yet but that was clearly something\n\u003e like LSATs I meaned speaking about monetary compensation to price\n\u003e resources. I just hope it isn't too much tie to HTTP because you may want\n\u003e to read/write over other communication channels like\n\u003e tx-broadcast-over-radio to solve first-hop privacy.\n\u003e\n\nI think we should consider alternative peer-to-peer communication channels\nboth in the context of supporting light client users and encouraging full\nnode diversity.\n\nBecause block headers and block filters can be cached and forwarded we can\nuse pure broadcast systems like geostationary satellites or radio systems\nwith various trade-offs between range and bandwidth such as amateur radio,\nunlicensed UHF and community WiFi. Protocol features that support\nlow-bandwidth broadcast and local peer-to-peer networks add resilience to\nthe Bitcoin network because they can not be as easily sybilled, censored or\nsurveilled en mass, as centralized ISPs can be.\n\nBandwidth is the primary limitation of these alternative last-mile networks\ncompared to nodes using wired internet connections. We would like all\nBitcoin nodes to operate as equal peers (flat network), but the reality is\nthat potential Bitcoin users do not have equal access to affordable\nbandwidth from centralized providers. A system that lets light clients\naccess full nodes over local peer-to-peer networks could make self-custody\nmore accessible to light-client users and more local full nodes\nincentivized to provide services over local peer-to-peer networks could\nhelp increase the geographic diversity of full nodes.\n\nFor example, a light client could have inbound connections for block\nheaders and filters from 1) other light client peers via bluetooth, 2) an\nISP connected full node via a community WiFi network and 3) a blocksat\nconnected full node via a UHF mesh network. These scenarios in more detail:\n\n1) two nearby light clients can exchange cached block headers, block\nfilters and full blocks over bluetooth or shared local WiFi - either tit\nfor tat or altruistically. Full blocks can be used to spot check block\nfilters and new block headers can help detect forks. There is no\ncommunication cost and when the local internet is censored or down can help\n(slowly) relay network state from any small set of operating links to the\noutside internet.\n\n2) a light client can query an ISP connected full node on the same\nunmetered local WiFi network and exchange differences in block headers\nopportunistically or pay for large missing ranges of headers, filters or\nfull blocks using a payment channel. Cost is reduced and privacy is\nenhanced for the light client by not using a centralized ISP. Bandwidth for\nrunning the full node can be amortized and subsidized by payments from\nlight clients who they resell data to.\n\n3) an off-grid validating full node can receive block information from the\nblocksat, but cross validate block headers from nearby full nodes connected\nto ISPs and light clients with cached information via low-bandwidth\nlong-range UHF mesh radio. This full node has no fixed bandwidth costs and\ncan also earn LN payments from light clients to help subsidize their\ninitial hardware purchase.\n\nI also believe a light-client could confirm specific transactions by\nquerying for Merkle proofs instead of full blocks when using a\nlow-bandwidth long distance and/or multi-hop radio link without the same\nprivacy linking concerns these queries would have if made using an internet\naddress tied to their identity or more specific physical location. I\nwouldn't argue to add this to the core protocol, but like Watchtowers it's\na service that can monetize and support the operation of a full node.\n\n -- Richard\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200507/f6246a76/attachment.html\u003e",
"sig": "1afd8d55a67deef654f2b8b7e5686953a201ade02f8b909bb4b3b04bf637764b171272ec457ff5b77cb96f53220d05aa3bd30981fdb64646ba3a132e063ef830"
}