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
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1WoLvf-0001gb-6h
for bitcoin-development@lists.sourceforge.net;
Sun, 25 May 2014 00:04:43 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.176 as permitted sender)
client-ip=209.85.216.176; envelope-from=etotheipi@gmail.com;
helo=mail-qc0-f176.google.com;
Received: from mail-qc0-f176.google.com ([209.85.216.176])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WoLvb-0000Z6-O7
for bitcoin-development@lists.sourceforge.net;
Sun, 25 May 2014 00:04:43 +0000
Received: by mail-qc0-f176.google.com with SMTP id r5so10426603qcx.35
for <bitcoin-development@lists.sourceforge.net>;
Sat, 24 May 2014 17:04:34 -0700 (PDT)
X-Received: by 10.224.60.137 with SMTP id p9mr19619025qah.92.1400976274146;
Sat, 24 May 2014 17:04:34 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPSA id h78sm4945572qgd.10.2014.05.24.17.04.33
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sat, 24 May 2014 17:04:33 -0700 (PDT)
Message-ID: <53813391.7040503@gmail.com>
Date: Sat, 24 May 2014 20:04:33 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CAOXABZohe93SSRm1FN5ai2H97eBJV2j+LAjA-39YAaNmX=ep0Q@mail.gmail.com> <CAAS2fgSJh83YEZjRfL81sKjC=nSKHtWT1qzS0evLJ9Gy6qdA1w@mail.gmail.com>
<CAOXABZoOnYSRf0Ktqxh8dx20Zi=E5gkp-8-C3-0ECudK=q05uA@mail.gmail.com>
In-Reply-To: <CAOXABZoOnYSRf0Ktqxh8dx20Zi=E5gkp-8-C3-0ECudK=q05uA@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative;
boundary="------------040001070404020208030105"
X-Spam-Score: 0.4 (/)
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
(etotheipi[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
1.0 FREEMAIL_REPLY From and body contain different freemails
X-Headers-End: 1WoLvb-0000Z6-O7
Subject: Re: [Bitcoin-development] Cut-through propagation of blocks
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: Sun, 25 May 2014 00:04:43 -0000
This is a multi-part message in MIME format.
--------------040001070404020208030105
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
On 05/24/2014 07:41 PM, Ashley Holman wrote:
> On Sun, May 25, 2014 at 8:29 AM, Bernd
> Jendrissek <bitcoin@bpj-code.co.za
> <mailto:bitcoin@bpj-code.co.za>> wrote:
>
> The difference is that with cut-through forwarding of blocks, a
> sufficiently motivated attacker (being willing to blow 25BTC's worth
> of electricity on the effort) can subjugate the entire Bitcoin network
> to its DoS attack, rather than having to connect to every node
> individually and then still have those individual nodes reject that
> invalid block without relaying any knowledge of its existence.
>
>
> That is true, but they could also apply the same hash power to mine
> valid blocks and would achieve the same outcome (their blocks would go
> to everyone), except they would get paid for it. I wonder if it
> should even be called DoS, due to the extreme and costly rate-limiting
> thats implied.
>
>
>
> An attack could also take the form of a block body that never arrives
> - a sort of teergrube attack, where the goal is to get the network
> mining empty block upon empty block on top of that valid-PoW header
> whose body never arrives. It doesn't have to be with an explicitly
> invalid block.
>
>
> Thank you for raising this, as I share this concern. There is another
> similar attack: if I send you a new block very slowly, I occupy all
> your upstream peer slots indefinitely until the block is complete,
> because there is no out-of-band messaging capability or ability to
> cancel a message.
>
> There is also sub-optimal logic in choosing to download a block only
> from the first person to offer it. It means you are fetching it from
> the lowest latency path, but what really matters is who can give it to
> you fastest. If there are multiple people who can send you a block at
> once, and you have some idea of your spare upstream bandwidth
> capacity, why not let two or more peers compete to send you the block
> fastest?
>
> So to implement this type of thing, the p2p protocol should allow for
> multiplexing of messages. Something like HTTP chunked encoding. It
> could be in the form of:
>
> <msgid><chunksize><rawbytes>, <msgid><chunksize><rawbytes>, etc etc
>
> You only send a chunk once you've got the whole chunk in your buffer,
> so it's not possible to get hung up on a single slow message. One
> block can overtake another along the same hop path if it is being
> streamed faster.
>
> On Sun, May 25, 2014 at 8:46 AM, Gregory Maxwell <gmaxwell@gmail.com
> <mailto:gmaxwell@gmail.com>> wrote:
>
> If you want to go full out crazy in optimizing in this space, there
> are fancier things that can be done to further reduce latency and
> increase efficiency:
> https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding ... but
> some of this stuff really should be done as a seperate protocol. There
> is no need to have Bitcoin transport all using a single protocol, and
> we can get better robustness and feature velocity if there are a
> couple protocols in use (you could just run a block-transport-protocol
> daemon that connects to your local node via the classic protocol).
>
>
> What about a separate project which is a mesh router specifically
> designed for low-latency transmission of blocks? It could support
> things like a more sophisticated/configurable routing table, and have
> some kind of discovery where it tries to optimise its topology. There
> could even be some way for nodes to prove their hash power, so pools
> can find each other and directly peer / prioritise sends.
>
I think the most important change is modifying the way Bitcoin Core
prioritizes blocks. Right now it uses the first full block verified.
Instead, it should consider the first valid header received as highest
priority, but only mine on it once it has done full verification of the
block. In other words, nodes will mine on whatever full/verified block
they have with the earliest header-received time. If another header
comes in and the tx list is received before the first tx list is done,
then the node will mine the second block *until* it receives and
verifies the first block, then it will switch to mining that first
block. Most of the time there's no race, it will simply mine the block
N-1 for an extra 1-3 seconds until it receives and verifies the full
block for the new header.
This at least solves part of the problem: nodes are still only mining
on full blocks, but priority is given to *headers* that come first which
is independent of block size. As long as a block isn't found within
the 1-3 seconds, then each miner will switch when they finish receiving
and verifying it. If miners are concerned about that 1-3 second gap,
they should perhaps focus on making sure the tx they are mining are
well-propagated already, so that most of the network has most of the
transactions already in their memory pool by the time their block is mined.
--------------040001070404020208030105
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 05/24/2014 07:41 PM, Ashley Holman wrote:<br>
<blockquote
cite="mid:CAOXABZoOnYSRf0Ktqxh8dx20Zi=E5gkp-8-C3-0ECudK=q05uA@mail.gmail.com"
type="cite">
<div dir="ltr">On Sun, May 25, 2014 at 8:29 AM, Bernd Jendrissek <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:bitcoin@bpj-code.co.za" target="_blank">bitcoin@bpj-code.co.za</a>></span> wrote:
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The
difference is that with cut-through forwarding of blocks, a<br>
sufficiently motivated attacker (being willing to blow 25BTC's
worth<br>
of electricity on the effort) can subjugate the entire Bitcoin
network<br>
to its DoS attack, rather than having to connect to every node<br>
individually and then still have those individual nodes reject
that<br>
invalid block without relaying any knowledge of its existence.<br>
</blockquote>
<div><br>
</div>
<div>That is true, but they could also apply the same hash power
to mine valid blocks and would achieve the same outcome (their
blocks would go to everyone), except they would get paid for
it. I wonder if it should even be called DoS, due to the
extreme and costly rate-limiting thats implied.</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">An
attack could also take the form of a block body that never
arrives<br>
- a sort of teergrube attack, where the goal is to get the
network<br>
mining empty block upon empty block on top of that valid-PoW
header<br>
whose body never arrives. It doesn't have to be with an
explicitly<br>
invalid block.<br>
</blockquote>
<div><br>
</div>
<div>Thank you for raising this, as I share this concern. There
is another similar attack: if I send you a new block very
slowly, I occupy all your upstream peer slots indefinitely
until the block is complete, because there is no out-of-band
messaging capability or ability to cancel a message.</div>
<div><br>
</div>
<div>There is also sub-optimal logic in choosing to download a
block only from the first person to offer it. It means you
are fetching it from the lowest latency path, but what really
matters is who can give it to you fastest. If there are
multiple people who can send you a block at once, and you have
some idea of your spare upstream bandwidth capacity, why not
let two or more peers compete to send you the block fastest?</div>
<div><br>
</div>
<div>So to implement this type of thing, the p2p protocol
should allow for multiplexing of messages. Something like
HTTP chunked encoding. It could be in the form of:</div>
<div><br>
</div>
<div><msgid><chunksize><rawbytes>,
<msgid><chunksize><rawbytes>, etc etc</div>
<div><br>
</div>
<div>You only send a chunk once you've got the whole chunk in
your buffer, so it's not possible to get hung up on a single
slow message. One block can overtake another along the same
hop path if it is being streamed faster.</div>
<div><br>
<div class="gmail_quote">On Sun, May 25, 2014 at 8:46 AM,
Gregory Maxwell <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:gmaxwell@gmail.com"
target="_blank">gmaxwell@gmail.com</a>></span> wrote:
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">If
you want to go full out crazy in optimizing in this space,
there<br>
are fancier things that can be done to further reduce
latency and<br>
increase efficiency:<br>
<a moz-do-not-send="true"
href="https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding"
target="_blank">https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding</a> ...
but<br>
some of this stuff really should be done as a seperate
protocol. There<br>
is no need to have Bitcoin transport all using a single
protocol, and<br>
we can get better robustness and feature velocity if there
are a<br>
couple protocols in use (you could just run a
block-transport-protocol<br>
daemon that connects to your local node via the classic
protocol).</blockquote>
</div>
</div>
<div><br>
</div>
<div>What about a separate project which is a mesh router
specifically designed for low-latency transmission of blocks?
It could support things like a more
sophisticated/configurable routing table, and have some kind
of discovery where it tries to optimise its topology. There
could even be some way for nodes to prove their hash power, so
pools can find each other and directly peer / prioritise
sends.</div>
</div>
<br>
</blockquote>
<br>
I think the most important change is modifying the way Bitcoin Core
prioritizes blocks. Right now it uses the first full block
verified. Instead, it should consider the first valid header
received as highest priority, but only mine on it once it has done
full verification of the block. In other words, nodes will mine on
whatever full/verified block they have with the earliest
header-received time. If another header comes in and the tx list is
received before the first tx list is done, then the node will mine
the second block *until* it receives and verifies the first block,
then it will switch to mining that first block. Most of the time
there's no race, it will simply mine the block N-1 for an extra 1-3
seconds until it receives and verifies the full block for the new
header.<br>
<br>
This at least solves part of the problem: nodes are still only
mining on full blocks, but priority is given to *headers* that come
first which is independent of block size. As long as a block isn't
found within the 1-3 seconds, then each miner will switch when they
finish receiving and verifying it. If miners are concerned about
that 1-3 second gap, they should perhaps focus on making sure the tx
they are mining are well-propagated already, so that most of the
network has most of the transactions already in their memory pool by
the time their block is mined.<br>
</body>
</html>
--------------040001070404020208030105--
|