1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
|
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 <kgreenek@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CANe1mWwi+fxFU43_2mq-yd_qRsmCwMu_c5wWOpvFS4Un_FoT+Q@mail.gmail.com>
<2916218.tfdjj1Sv9m@crushinator>
From: Kevin Greene <kgreenek@gmail.com>
Date: Mon, 25 May 2015 21:46:22 -0700
Message-ID: <CAEY8wq40vyG8CFZ7U1Z3hhF_ziSqEQ3GDpXLwm1MAVtK03aT-A@mail.gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <bip@mattwhitlock.name>
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*
> > <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.*
>
>
> ------------------------------------------------------------------------------
> 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
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"color:#336666">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.</div><div =
class=3D"gmail_default" style=3D"color:#336666"><br></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Mon, May 25, 2015 at 9:37 PM, M=
att Whitlock <span dir=3D"ltr"><<a href=3D"mailto:bip@mattwhitlock.name"=
target=3D"_blank">bip@mattwhitlock.name</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">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.<br>
<span><br>
<br>
On Monday, 25 May 2015, at 11:06 pm, Jim Phillips wrote:<br>
> Is there any work being done on using some kind of zero-conf service<b=
r>
> discovery protocol so that lightweight clients can find a full node on=
the<br>
> same LAN to peer with rather than having to tie up WAN bandwidth?<br>
><br>
> I envision a future where lightweight devices within a home use SPV ov=
er<br>
> WiFi to connect with a home server which in turn relays the transactio=
ns<br>
> they create out to the larger and faster relays on the Internet.<br>
><br>
> In a situation where there are hundreds or thousands of small SPV devi=
ces<br>
> in a single home (if 21, Inc. is successful) monitoring the blockchain=
,<br>
> this could result in lower traffic across the slow WAN connection.=C2=
=A0 And<br>
> yes, I realize it could potentially take a LOT of these devices before=
the<br>
> total bandwidth is greater than downloading a full copy of the blockch=
ain,<br>
> but there's other reasons to host your own full node -- trust bein=
g one.<br>
><br>
> --<br>
</span>> *James G. Phillips IV*<br>
> <<a href=3D"https://plus.google.com/u/0/113107039501292625391/posts=
" target=3D"_blank">https://plus.google.com/u/0/113107039501292625391/posts=
</a>><br>
> <<a href=3D"http://www.linkedin.com/in/ergophobe" target=3D"_blank"=
>http://www.linkedin.com/in/ergophobe</a>><br>
><br>
> *"Don't bunt. Aim out of the ball park. Aim for the company o=
f immortals."<br>
> -- David Ogilvy*<br>
><br>
>=C2=A0 *This message was created with 100% recycled electrons. Please t=
hink twice<br>
> before printing.*<br>
<br>
---------------------------------------------------------------------------=
---<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div></div>
--089e013d1954181e9c0516f4d068--
|
