📅 Original date posted:2015-05-26
📝 Original message:This is very simple to do. Just ping the "all nodes" address (ff02::1) and try connecting to TCP port 8333 of each node that responds. Shouldn't take but more than a few milliseconds on any but the most densely populated LANs.
On Monday, 25 May 2015, at 11:06 pm, Jim Phillips wrote:
> Is there any work being done on using some kind of zero-conf service
> discovery protocol so that lightweight clients can find a full node on the
> same LAN to peer with rather than having to tie up WAN bandwidth?
>
> I envision a future where lightweight devices within a home use SPV over
> WiFi to connect with a home server which in turn relays the transactions
> they create out to the larger and faster relays on the Internet.
>
> In a situation where there are hundreds or thousands of small SPV devices
> in a single home (if 21, Inc. is successful) monitoring the blockchain,
> this could result in lower traffic across the slow WAN connection. And
> yes, I realize it could potentially take a LOT of these devices before the
> total bandwidth is greater than downloading a full copy of the blockchain,
> but there's other reasons to host your own full node -- trust being one.
>
> --
> *James G. Phillips IV*
> <https://plus.google.com/u/0/113107039501292625391/posts>;
> <http://www.linkedin.com/in/ergophobe>;
>
> *"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
> -- David Ogilvy*
>
> *This message was created with 100% recycled electrons. Please think twice
> before printing.*
Matt Whitlock [ARCHIVE] /
npub17q…upwet
2023-06-07 15:35:34
in reply to nevent1q…yt9n
Author Public Key
npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwetPublished at
2023-06-07 15:35:34Event JSON
{
"id": "e45ed600603bd8a843ef1150eaf1831b0cb6e5ce99db40db3334316325322213",
"pubkey": "f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91",
"created_at": 1686152134,
"kind": 1,
"tags": [
[
"e",
"2754f6df425d0f26fe27c6426d73b5ed47aee2228af52009176ded69f7bbcf5e",
"",
"root"
],
[
"e",
"48a0ea4e954750bbabce2bf4acfac04461252508f046e71e7d9c3f19e74fa6ca",
"",
"reply"
],
[
"p",
"8b64be8dfcb19730f674fdb0169f772317a629f8dd3b8d925d342a0273bbb37b"
]
],
"content": "📅 Original date posted:2015-05-26\n📝 Original message:This is very simple to do. Just ping the \"all nodes\" address (ff02::1) and try connecting to TCP port 8333 of each node that responds. Shouldn't take but more than a few milliseconds on any but the most densely populated LANs.\n\n\nOn Monday, 25 May 2015, at 11:06 pm, Jim Phillips wrote:\n\u003e Is there any work being done on using some kind of zero-conf service\n\u003e discovery protocol so that lightweight clients can find a full node on the\n\u003e same LAN to peer with rather than having to tie up WAN bandwidth?\n\u003e \n\u003e I envision a future where lightweight devices within a home use SPV over\n\u003e WiFi to connect with a home server which in turn relays the transactions\n\u003e they create out to the larger and faster relays on the Internet.\n\u003e \n\u003e In a situation where there are hundreds or thousands of small SPV devices\n\u003e in a single home (if 21, Inc. is successful) monitoring the blockchain,\n\u003e this could result in lower traffic across the slow WAN connection. And\n\u003e yes, I realize it could potentially take a LOT of these devices before the\n\u003e total bandwidth is greater than downloading a full copy of the blockchain,\n\u003e but there's other reasons to host your own full node -- trust being one.\n\u003e \n\u003e --\n\u003e *James G. Phillips IV*\n\u003e \u003chttps://plus.google.com/u/0/113107039501292625391/posts\u003e\n\u003e \u003chttp://www.linkedin.com/in/ergophobe\u003e\n\u003e \n\u003e *\"Don't bunt. Aim out of the ball park. Aim for the company of immortals.\"\n\u003e -- David Ogilvy*\n\u003e \n\u003e *This message was created with 100% recycled electrons. Please think twice\n\u003e before printing.*",
"sig": "8211b661fa828d50ade27e5df5b21369adca914abc2f54ebd866680a3d06f9a64f3cf008bca517f4f05f4a49b824307ff30d926c2bbc171a687017962746616b"
}