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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <dscvlt@gmail.com>) id 1WoLZT-0003RK-3i
for bitcoin-development@lists.sourceforge.net;
Sat, 24 May 2014 23:41:47 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.42 as permitted sender)
client-ip=209.85.219.42; envelope-from=dscvlt@gmail.com;
helo=mail-oa0-f42.google.com;
Received: from mail-oa0-f42.google.com ([209.85.219.42])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WoLZR-0007pu-6B
for bitcoin-development@lists.sourceforge.net;
Sat, 24 May 2014 23:41:47 +0000
Received: by mail-oa0-f42.google.com with SMTP id j17so7127584oag.1
for <bitcoin-development@lists.sourceforge.net>;
Sat, 24 May 2014 16:41:39 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.153.33 with SMTP id vd1mr33540obb.86.1400974899398; Sat,
24 May 2014 16:41:39 -0700 (PDT)
Received: by 10.182.225.66 with HTTP; Sat, 24 May 2014 16:41:39 -0700 (PDT)
In-Reply-To: <CAAS2fgSJh83YEZjRfL81sKjC=nSKHtWT1qzS0evLJ9Gy6qdA1w@mail.gmail.com>
References: <CAOXABZohe93SSRm1FN5ai2H97eBJV2j+LAjA-39YAaNmX=ep0Q@mail.gmail.com>
<CAAS2fgSJh83YEZjRfL81sKjC=nSKHtWT1qzS0evLJ9Gy6qdA1w@mail.gmail.com>
Date: Sun, 25 May 2014 09:11:39 +0930
Message-ID: <CAOXABZoOnYSRf0Ktqxh8dx20Zi=E5gkp-8-C3-0ECudK=q05uA@mail.gmail.com>
From: Ashley Holman <dscvlt@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=089e013a237837ce8804fa2de3a0
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
(dscvlt[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: 1WoLZR-0007pu-6B
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
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: Sat, 24 May 2014 23:41:47 -0000
--089e013a237837ce8804fa2de3a0
Content-Type: text/plain; charset=UTF-8
On Sun, May 25, 2014 at 8:29 AM, Bernd Jendrissek <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>
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.
--089e013a237837ce8804fa2de3a0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sun, May 25, 2014 at 8:29 AM, Bernd Jendrissek=C2=A0<sp=
an dir=3D"ltr"><<a href=3D"mailto:bitcoin@bpj-code.co.za" target=3D"_bla=
nk">bitcoin@bpj-code.co.za</a>></span>=C2=A0wrote:<blockquote class=3D"g=
mail_quote" style=3D"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>sufficie=
ntly motivated attacker (being willing to blow 25BTC's worth<br>of elec=
tricity on the effort) can subjugate the entire Bitcoin network<br>to its D=
oS attack, rather than having to connect to every node<br>
individually and then still have those individual nodes reject that<br>inva=
lid 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 p=
ower to mine valid blocks and would achieve the same outcome (their blocks =
would go to everyone), except they would get paid for it. =C2=A0I wonder if=
it should even be called DoS, due to the extreme and costly rate-limiting =
thats implied.</div>
<div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,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>minin=
g empty block upon empty block on top of that valid-PoW header<br>whose bod=
y never arrives. It doesn't have to be with an explicitly<br>invalid bl=
ock.<br>
</blockquote><div><br></div><div>Thank you for raising this, as I share thi=
s concern. =C2=A0There 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. =C2=A0It means you are fet=
ching it from the lowest latency path, but what really matters is who can g=
ive it to you fastest. =C2=A0If there are multiple people who can send you =
a block at once, and you have some idea of your spare upstream bandwidth ca=
pacity, 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, =C2=A0the p2p proto=
col should allow for multiplexing of messages. =C2=A0Something like HTTP ch=
unked encoding. =C2=A0It could be in the form of:</div><div><br></div><div>=
<msgid><chunksize><rawbytes>, <msgid><chunksize&=
gt;<rawbytes>, =C2=A0etc etc</div>
<div><br></div><div>You only send a chunk once you've got the whole chu=
nk in your buffer, so it's not possible to get hung up on a single slow=
message. =C2=A0 One block can overtake another along the same hop path if =
it is being streamed faster.</div>
<div><br><div class=3D"gmail_quote">On Sun, May 25, 2014 at 8:46 AM, Gregor=
y Maxwell=C2=A0<span dir=3D"ltr"><<a href=3D"mailto:gmaxwell@gmail.com" =
target=3D"_blank">gmaxwell@gmail.com</a>></span>=C2=A0wrote:=C2=A0<block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth: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 e=
fficiency:<br><a href=3D"https://en.bitcoin.it/wiki/User:Gmaxwell/block_net=
work_coding" target=3D"_blank">https://en.bitcoin.it/wiki/User:Gmaxwell/blo=
ck_network_coding</a>=C2=A0=C2=A0... but<br>
some of this stuff really should be done as a seperate protocol. There<br>i=
s 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 pro=
tocols in use (you could just run a block-transport-protocol<br>
daemon that connects to your local node via the classic protocol).</blockqu=
ote></div></div><div><br></div><div>What about a separate project which is =
a mesh router specifically designed for low-latency transmission of blocks?=
=C2=A0It could support things like a more sophisticated/configurable routi=
ng table, and have some kind of discovery where it tries to optimise its to=
pology. =C2=A0There could even be some way for nodes to prove their hash po=
wer, so pools can find each other and directly peer / prioritise sends.</di=
v>
</div>
--089e013a237837ce8804fa2de3a0--
|
