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
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1VekVt-0008It-Ai
for bitcoin-development@lists.sourceforge.net;
Fri, 08 Nov 2013 11:46:09 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.41 as permitted sender)
client-ip=209.85.219.41; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f41.google.com;
Received: from mail-oa0-f41.google.com ([209.85.219.41])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VekVr-0003sG-UN
for bitcoin-development@lists.sourceforge.net;
Fri, 08 Nov 2013 11:46:09 +0000
Received: by mail-oa0-f41.google.com with SMTP id g12so690188oah.14
for <bitcoin-development@lists.sourceforge.net>;
Fri, 08 Nov 2013 03:46:02 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.44.134 with SMTP id e6mr11272958obm.14.1383911162244;
Fri, 08 Nov 2013 03:46:02 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.156.42 with HTTP; Fri, 8 Nov 2013 03:46:02 -0800 (PST)
In-Reply-To: <527AD246.9050906@bluematt.me>
References: <5279D89D.5000609@bluematt.me>
<CAE-z3OXQiT-6OXddb9_jpY2Qqbfs+BKAVv3M-rQ4eedwBS2MAg@mail.gmail.com>
<527AD246.9050906@bluematt.me>
Date: Fri, 8 Nov 2013 12:46:02 +0100
X-Google-Sender-Auth: CJ2keeL1lz0jpv7nrq7d6dwFPhE
Message-ID: <CANEZrP2Jr-tOEXan_bq_g1Zi2mpyN96oD-aCh-m51HyAfN7pXw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: multipart/alternative; boundary=001a11c3235a39f55404eaa8ed32
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: doubleclick.net]
-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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1VekVr-0003sG-UN
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [ANN] High-speed Bitcoin Relay Network
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: Fri, 08 Nov 2013 11:46:09 -0000
--001a11c3235a39f55404eaa8ed32
Content-Type: text/plain; charset=UTF-8
I took a brief look at the code - it's looking very reasonable. You can
replace any construct like
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
which is quite verbose, just with
Uninterruptibles.sleepUninterruptably(1000, TimeUnit.MILLISECONDS); (and of
course static imports help too)
I think for this concept to take off, you'd need a website and to recruit
someone to help you market it. Pool operators won't reach out to you.
I still find it perhaps more elegant to just boost the connectivity of the
existing network with bitcoind changes, but this can help for now.
On Thu, Nov 7, 2013 at 12:35 AM, Matt Corallo <bitcoin-list@bluematt.me>wrote:
> No, the transactions relayed are piped through a bitcoind first (ie
> fully verified by a bitcoind). For blocks, for which the timing needs to
> be tighter, bitcoinj does SPV-validation. Though it is possible to
> create a block which passes SPV validation but causes a DoS score, doing
> so would cost a miner a full block's worth of profits, which they are
> fairly unlikely to do. In any case, if it every becomes a problem, its
> not hard to adapt addnode to allow higher DoS scores for individual nodes.
>
> Matt
>
> On 11/06/13 07:25, Tier Nolan wrote:
> >
> >
> >
> > On Wed, Nov 6, 2013 at 5:50 AM, Matt Corallo <bitcoin-list@bluematt.me
> > <mailto:bitcoin-list@bluematt.me>> wrote:
> >
> > Relay node details:
> > * The relay nodes do some data verification to prevent DoS, but in
> > order to keep relay fast, they do not fully verify the data they are
> > relaying, thus YOU SHOULD NEVER mine a block building on top of a
> > relayed block without fully checking it with your own bitcoin
> validator
> > (as you would any other block relayed from the P2P network).
> >
> >
> > Wouldn't this cause disconnects due to misbehavior?
> >
> > A standard node connecting to a relay node would receive
> > blocks/transactions that are not valid in some way and then disconnect.
> >
> > Have you looked though the official client to find what things are
> > considered signs that a peer is hostile? I assume things like double
> > spending checks count as misbehavior and can't be quickly checked by a
> > relay node.
> >
> > Maybe another bit could be assigned in the services field as "relay".
> > This means that the node doesn't do any checking.
> >
> > Connects to relay nodes could be command line/config file only. Peers
> > wouldn't connect to them.
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--001a11c3235a39f55404eaa8ed32
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I took a brief look at the code - it's looking very re=
asonable. You can replace any construct like<div><br></div><div>try {</div>=
<div>=C2=A0 Thread.sleep(1000);</div><div>} catch (InterruptedException e) =
{</div>
<div>=C2=A0 throw new RuntimeException(e);</div><div>}</div><div><br></div>=
<div>which is quite verbose, just with Uninterruptibles.sleepUninterruptabl=
y(1000, TimeUnit.MILLISECONDS); (and of course static imports help too)</di=
v>
<div><br></div><div>I think for this concept to take off, you'd need a =
website and to recruit someone to help you market it. Pool operators won=
9;t reach out to you.</div><div><br></div><div>I still find it perhaps more=
elegant to just boost the connectivity of the existing network with bitcoi=
nd changes, but this can help for now.</div>
<div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, Nov 7, 2013 at 12:35 AM, Matt Corallo <span dir=3D"ltr"><=
;<a href=3D"mailto:bitcoin-list@bluematt.me" target=3D"_blank">bitcoin-list=
@bluematt.me</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">No, the transactions relayed are piped throu=
gh a bitcoind first (ie<br>
fully verified by a bitcoind). For blocks, for which the timing needs to<br=
>
be tighter, bitcoinj does SPV-validation. Though it is possible to<br>
create a block which passes SPV validation but causes a DoS score, doing<br=
>
so would cost a miner a full block's worth of profits, which they are<b=
r>
fairly unlikely to do. In any case, if it every becomes a problem, its<br>
not hard to adapt addnode to allow higher DoS scores for individual nodes.<=
br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Matt<br>
</font></span><div class=3D"im HOEnZb"><br>
On 11/06/13 07:25, Tier Nolan wrote:<br>
><br>
><br>
><br>
> On Wed, Nov 6, 2013 at 5:50 AM, Matt Corallo <<a href=3D"mailto:bit=
coin-list@bluematt.me">bitcoin-list@bluematt.me</a><br>
</div><div class=3D"HOEnZb"><div class=3D"h5">> <mailto:<a href=3D"ma=
ilto:bitcoin-list@bluematt.me">bitcoin-list@bluematt.me</a>>> wrote:<=
br>
><br>
> =C2=A0 =C2=A0 Relay node details:<br>
> =C2=A0 =C2=A0 =C2=A0* The relay nodes do some data verification to pre=
vent DoS, but in<br>
> =C2=A0 =C2=A0 order to keep relay fast, they do not fully verify the d=
ata they are<br>
> =C2=A0 =C2=A0 relaying, thus YOU SHOULD NEVER mine a block building on=
top of a<br>
> =C2=A0 =C2=A0 relayed block without fully checking it with your own bi=
tcoin validator<br>
> =C2=A0 =C2=A0 (as you would any other block relayed from the P2P netwo=
rk).<br>
><br>
><br>
> Wouldn't this cause disconnects due to misbehavior?<br>
><br>
> A standard node connecting to a relay node would receive<br>
> blocks/transactions that are not valid in some way and then disconnect=
.<br>
><br>
> Have you looked though the official client to find what things are<br>
> considered signs that a peer is hostile? =C2=A0I assume things like do=
uble<br>
> spending checks count as misbehavior and can't be quickly checked =
by a<br>
> relay node.<br>
><br>
> Maybe another bit could be assigned in the services field as "rel=
ay".<br>
> This means that the node doesn't do any checking.<br>
><br>
> Connects to relay nodes could be command line/config file only. =C2=A0=
Peers<br>
> wouldn't connect to them.<br>
<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">-----------------------=
-------------------------------------------------------<br>
November Webinars for C, C++, Fortran Developers<br>
Accelerate application performance with scalable programming models. Explor=
e<br>
techniques for threading, error checking, porting, and tuning. Get the most=
<br>
from the latest Intel processors and coprocessors. See abstracts and regist=
er<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D60136231&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D60136231&iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@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>
</div></div></blockquote></div><br></div>
--001a11c3235a39f55404eaa8ed32--
|
