From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yx6lN-0004oq-UU for bitcoin-development@lists.sourceforge.net; Tue, 26 May 2015 04:46:49 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.180 as permitted sender) client-ip=209.85.212.180; envelope-from=kgreenek@gmail.com; helo=mail-wi0-f180.google.com; Received: from mail-wi0-f180.google.com ([209.85.212.180]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yx6lM-0006AT-NC for bitcoin-development@lists.sourceforge.net; Tue, 26 May 2015 04:46:49 +0000 Received: by wicmx19 with SMTP id mx19so53462440wic.0 for ; Mon, 25 May 2015 21:46:42 -0700 (PDT) X-Received: by 10.194.179.2 with SMTP id dc2mr46048186wjc.120.1432615602624; Mon, 25 May 2015 21:46:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.20.1 with HTTP; Mon, 25 May 2015 21:46:22 -0700 (PDT) In-Reply-To: <2916218.tfdjj1Sv9m@crushinator> References: <2916218.tfdjj1Sv9m@crushinator> From: Kevin Greene Date: Mon, 25 May 2015 21:46:22 -0700 Message-ID: To: Matt Whitlock Content-Type: multipart/alternative; boundary=089e013d1954181e9c0516f4d068 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (kgreenek[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Yx6lM-0006AT-NC 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:46:50 -0000 --089e013d1954181e9c0516f4d068 Content-Type: text/plain; charset=UTF-8 This is something you actually don't want. In order to make it as difficult as possible for an attacker to perform a sybil attack, you want to choose a set of peers that is as diverse, and unpredictable as possible. On Mon, May 25, 2015 at 9: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.* > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --089e013d1954181e9c0516f4d068 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This = is something you actually don't want. In order to make it as difficult = as possible for an attacker to perform a sybil attack, you want to choose a= set of peers that is as diverse, and unpredictable as possible.


On Mon, May 25, 2015 at 9:37 PM, M= att Whitlock <bip@mattwhitlock.name> wrote:
This is very simple to do. Just ping the "all no= des" address (ff02::1) and try connecting to TCP port 8333 of each nod= e 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 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.*

---------------------------------------------------------------------------= ---
One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--089e013d1954181e9c0516f4d068--