Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yx6mu-0004uX-2b for bitcoin-development@lists.sourceforge.net; Tue, 26 May 2015 04:48:24 +0000 X-ACL-Warn: Received: from mail-wi0-f176.google.com ([209.85.212.176]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yx6ms-0005SF-Lc for bitcoin-development@lists.sourceforge.net; Tue, 26 May 2015 04:48:24 +0000 Received: by wicmx19 with SMTP id mx19so63757418wic.0 for ; Mon, 25 May 2015 21:48:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pKh5+em5DXncrmO2aNS6I9e71DUXD/G3DVab0QspNh0=; b=UhcMvXrMnf+iBVjY5DzjB0J9Oeu0O3AnSdt8ZlHfUZJahPe5shya2kh/RwOdHW3GPt W5wLwQqJvfk4eLUJqvVns1Uk38ZdeV9zZcHeMWHdo3pijMuGW1GaJP4W3Q/S0iK6Gz8Z 6ddg/jNtEuQzNFcKnKbi87Wo0zqlKR7dKyuy3yIFqd7BhsDalju/JTUOo/QUqEAIRMj9 9sJygDexi6aMa7MnPWl4nioiaSm5IFp9KYrNYinqcVPB1x2E71gr2VTbxBgwpbp0hK4w QmH5GA9yKSrV+CyW0SV+SPIoGFRhNyrXRnALGJOp9ERF42HsBdJ9a5+nrHO0G/macu83 Pnhg== X-Gm-Message-State: ALoCoQm87h717B7rWjyoRRehO2ydfHxl7VdlvPVBPihmi/r9YGYd2vH//cK2Vt0h1aPah4k2/9xO MIME-Version: 1.0 X-Received: by 10.194.157.194 with SMTP id wo2mr45894399wjb.103.1432615696692; Mon, 25 May 2015 21:48:16 -0700 (PDT) Received: by 10.194.246.69 with HTTP; Mon, 25 May 2015 21:48:16 -0700 (PDT) Received: by 10.194.246.69 with HTTP; Mon, 25 May 2015 21:48:16 -0700 (PDT) In-Reply-To: <2916218.tfdjj1Sv9m@crushinator> References: <2916218.tfdjj1Sv9m@crushinator> Date: Mon, 25 May 2015 23:48:16 -0500 Message-ID: From: Jim Phillips To: Matt Whitlock Content-Type: multipart/alternative; boundary=089e013c673cb391ff0516f4d504 X-Spam-Score: 1.2 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message 0.2 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Yx6ms-0005SF-Lc Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Zero-Conf for Full Node Discovery X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 04:48:24 -0000 --089e013c673cb391ff0516f4d504 Content-Type: text/plain; charset=UTF-8 Do any wallets actually do this yet? On May 25, 2015 11:37 PM, "Matt Whitlock" wrote: > 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* > > > > > > > > *"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.* > --089e013c673cb391ff0516f4d504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Do any wallets actually do this yet?

On May 25, 2015 11:37 PM, "Matt Whitlock&qu= ot; <bip@mattwhitlock.name&= gt; wrote:
This is = very simple to do. Just ping the "all nodes" address (ff02::1) an= d 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 populate= d 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 ov= er
> WiFi to connect with a home server which in turn relays the transactio= ns
> they create out to the larger and faster relays on the Internet.
>
> In a situation where there are hundreds or thousands of small SPV devi= ces
> in a single home (if 21, Inc. is successful) monitoring the blockchain= ,
> this could result in lower traffic across the slow WAN connection.=C2= =A0 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 blockch= ain,
> but there's other reasons to host your own full node -- trust bein= g 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 o= f immortals."
> -- David Ogilvy*
>
>=C2=A0 *This message was created with 100% recycled electrons. Please t= hink twice
> before printing.*
--089e013c673cb391ff0516f4d504--