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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from
<SRS0=lbq4E4=HJ=godofgod.co.uk=matthewmitchell@eigbox.net>)
id 1TB9kW-00071a-9R for bitcoin-development@lists.sourceforge.net;
Mon, 10 Sep 2012 19:34:24 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of eigbox.net
designates 66.96.189.3 as permitted sender)
client-ip=66.96.189.3;
envelope-from=SRS0=lbq4E4=HJ=godofgod.co.uk=matthewmitchell@eigbox.net;
helo=bosmailout03.eigbox.net;
Received: from bosmailout03.eigbox.net ([66.96.189.3])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1TB9kV-0008PO-49 for bitcoin-development@lists.sourceforge.net;
Mon, 10 Sep 2012 19:34:24 +0000
Received: from bosmailscan02.eigbox.net ([10.20.15.2])
by bosmailout03.eigbox.net with esmtp (Exim) id 1TB9kP-00082Q-ID
for bitcoin-development@lists.sourceforge.net;
Mon, 10 Sep 2012 15:34:17 -0400
Received: from bosimpout01.eigbox.net ([10.20.55.1])
by bosmailscan02.eigbox.net with esmtp (Exim)
id 1TB9kO-0004Na-Ih; Mon, 10 Sep 2012 15:34:16 -0400
Received: from bosauthsmtp09.eigbox.net ([10.20.18.9])
by bosimpout01.eigbox.net with NO UCE
id xXaH1j0030BkY8i01XaHJp; Mon, 10 Sep 2012 15:34:17 -0400
X-Authority-Analysis: v=2.0 cv=aPZHX8Bm c=1 sm=1
a=EdgcOKDBJpMkesC5stW6Qg==:17 a=Goz4v7xpImgA:10 a=JhU9KSwl1l8A:10
a=RmqW3wxksLsA:10 a=eGitJVp2AAAA:8 a=-aUnnjAAwhoA:10 a=r7esRitPAAAA:8
a=mLYL7Y0PAAAA:8 a=uEaaO3vx7Ru_3I5q34oA:9 a=CjuIK1q_8ugA:10
a=29nVbMLIeY0A:10
a=tnEpsa5-Z5JzT0F1:21 a=PIdmGQ6WNGtAWcEa:21 a=VH2qAgixP-mNbH_KltEA:9
a=_W_S_7VecoQA:10 a=+tcVrJynzLVJ9yqDAOBWjQ==:117
X-EN-OrigOutIP: 10.20.18.9
X-EN-IMPSID: xXaH1j0030BkY8i01XaHJp
Received: from 5adb753d.bb.sky.com ([90.219.117.61] helo=[192.168.0.7])
by bosauthsmtp09.eigbox.net with esmtpsa (TLSv1:AES128-SHA:128)
(Exim) id 1TB9kO-0005yq-DF; Mon, 10 Sep 2012 15:34:16 -0400
From: Matthew Mitchell <matthewmitchell@godofgod.co.uk>
Content-Type: multipart/alternative;
boundary="Apple-Mail=_FB67F502-316A-4C55-BE79-EDFEDAD36E88"
Message-Id: <239CFE18-302F-47F1-8686-67297FDDFB3C@godofgod.co.uk>
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
Date: Mon, 10 Sep 2012 20:34:10 +0100
References: <BA7EEDEA-5A56-42F5-A43D-0D4C9CC99DBC@godofgod.co.uk>
<201209101859.05009.luke@dashjr.org>
To: Luke-Jr <luke@dashjr.org>, "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
In-Reply-To: <201209101859.05009.luke@dashjr.org>
X-Mailer: Apple Mail (2.1486)
X-EN-UserInfo: c68a83c59c94ef03b40bb4bc312c51e4:dffc0a9b4c8a0435ad832ff5852cab82
X-EN-AuthUser: godofgod@godofgod.co.uk
Sender: Matthew Mitchell <matthewmitchell@godofgod.co.uk>
X-EN-OrigIP: 90.219.117.61
X-EN-OrigHost: 5adb753d.bb.sky.com
X-Spam-Score: -0.9 (/)
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 SPF_PASS SPF: sender matches SPF record
-0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1TB9kV-0008PO-49
Subject: Re: [Bitcoin-development] Segmented Block Relaying BIP draft.
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: Mon, 10 Sep 2012 19:34:24 -0000
--Apple-Mail=_FB67F502-316A-4C55-BE79-EDFEDAD36E88
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Do you mean getdata? Here is the reason for the 6 new messages:
getseginv,seginv - These are for learning about what segments of a block =
a node has. Else you could remove these messages and simply have nodes =
advertise blocks via inventory messages. In this case nodes would have =
to wait until they had fully received a block before relaying anything. =
No longer is there a benefit with nodes being able to relay segments of =
blocks before they have received the entire block.
gettreelevel,treelevel - These are to received a level of the merle =
tree. Instead you might use get data but gettreelevel is more compact =
than get data and is clearly differentiates itself as part of the new =
protocol. Perhaps these messages could include the block headers =
alongside the hashes and you could request many at once like with the =
getheaders message? If you skip these messages, then you could verify =
the transactions at the end but there would be problems when peers give =
bad segments where data would need to be downloaded again.
getsegment,segment - These are clearly important to request and receive =
segments for the blocks. These allows for nodes to download arbitrary =
segments of blocks. The optimum number of segments could be calculated =
by node software using measurements of download speeds and latency =
times, the number of connections and how likely redundancy is to occur. =
If a node is up-to-date and likely has many of the transactions in =
blocks, it can start asking for the deepest merle level (tx hashes) and =
ask nodes for segments, avoiding transactions it already has.
I'll get around to doing measurements myself sometime to estimate the =
benefit of this proposal. It will certainly be beneficial when block =
sizes reach some size but not much is really known except what can be =
assumed/guessed.
I should also mention the bitcointalk topic here: =
https://bitcointalk.org/index.php?topic=3D103295.0
On 10 Sep 2012, at 19:59, "Luke-Jr" <luke@dashjr.org> wrote:
>=20
> Most of the problem with block propagation lies in implementation, not=20=
> protocol... Distributing missing transaction on an as-needed basis is =
a=20
> possible improvement at the protocol level, but there hasn't (AFAIK) =
been any=20
> research into whether the little benefit outweighs the cost yet. In =
any case,=20
> I don't see why 6 new messages are needed instead of simply adding a =
single=20
> new type to getinv?
--Apple-Mail=_FB67F502-316A-4C55-BE79-EDFEDAD36E88
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div>Do you mean getdata? Here is the reason for the 6 new =
messages:</div><div><br></div><div><span style=3D"font-family: =
sans-serif; font-size: 13px; line-height: 19.200000762939453px; =
background-color: rgb(255, 255, 255); ">getseginv,</span><span =
style=3D"font-family: sans-serif; font-size: 13px; line-height: =
19.200000762939453px; background-color: rgb(255, 255, 255); ">seginv - =
These are for learning about what segments of a block a node has. Else =
you could remove these messages and simply have nodes advertise blocks =
via inventory messages. In this case nodes would have to wait until they =
had fully received a block before relaying anything. No longer is there =
a benefit with nodes being able to </span><font =
face=3D"sans-serif"><span style=3D"font-size: 13px; line-height: =
19px;">relay segments of blocks before they have received the =
entire block.</span></font></div><div><font face=3D"sans-serif"><span =
style=3D"font-size: 13px; line-height: =
19px;"><br></span></font></div><div><span style=3D"font-family: =
sans-serif; font-size: 13px; line-height: 19.200000762939453px; =
background-color: rgb(255, 255, 255); ">gettreelevel,</span><span =
style=3D"background-color: rgb(255, 255, 255); "><font =
face=3D"sans-serif"><span style=3D"font-size: 13px; line-height: =
19.200000762939453px;">treelevel - These are to received a level of =
the </span><span style=3D"font-size: 13px; line-height: =
19px;">merle</span><span style=3D"font-size: 13px; line-height: =
19.200000762939453px;"> tree. Instead you might =
use </span><span style=3D"font-size: 13px; line-height: 19px;">get =
data</span><span style=3D"font-size: 13px; line-height: =
19.200000762939453px;"> but gettreelevel is more compact =
than </span><span style=3D"font-size: 13px; line-height: 19px;">get =
data and is clearly differentiates itself as part of the new protocol. =
Perhaps these messages could include the block headers alongside the =
hashes and you could request many at once like with the getheaders =
message? If you skip these messages, then you could verify the =
transactions at the end but there would be problems when peers give bad =
segments where data would need to be downloaded =
again.</span></font></span></div><div><span style=3D"background-color: =
rgb(255, 255, 255); "><font face=3D"sans-serif"><span style=3D"font-size: =
13px; line-height: 19px;"><br></span></font></span></div><div><span =
style=3D"font-family: sans-serif; font-size: 13px; line-height: =
19.200000762939453px; background-color: rgb(255, 255, 255); =
">getsegment,</span><span style=3D"background-color: rgb(255, 255, 255); =
"><font face=3D"sans-serif"><span style=3D"font-size: 13px; line-height: =
19.200000762939453px;">segment - These are clearly important to request =
and receive segments for the blocks. These </span><span =
style=3D"font-size: 13px; line-height: 19px;">allows for nodes =
to download arbitrary segments of blocks</span><span =
style=3D"font-size: 13px; line-height: 19.200000762939453px;">. The =
optimum number of segments could be calculated by node software =
using </span><span style=3D"font-size: 13px; line-height: =
19px;">measurements</span><span style=3D"font-size: 13px; line-height: =
19.200000762939453px;"> of download speeds and latency times, the =
number of connections and how likely redundancy is to occur. If a node =
is up-to-date and likely has many of the transactions in blocks, it can =
start asking for the deepest </span></font></span><font =
face=3D"sans-serif"><span style=3D"font-size: 13px; line-height: =
19px;">merle level (tx hashes) and ask nodes for segments, avoiding =
transactions it already has.</span></font></div><div><span =
style=3D"background-color: rgb(255, 255, 255); "><font =
face=3D"sans-serif"><span style=3D"font-size: 13px; line-height: =
19.200000762939453px;"><br></span></font></span></div><div><span =
style=3D"background-color: rgb(255, 255, 255); "><font =
face=3D"sans-serif"><span style=3D"font-size: 13px; line-height: =
19.200000762939453px;">I'll get around to doing </span><span =
style=3D"font-size: 13px; line-height: 19px;">measurements myself =
sometime to estimate the benefit of this proposal. It will certainly be =
beneficial when block sizes reach some size but not much is really known =
except what can be assumed/guessed.</span></font></span></div><div><span =
style=3D"background-color: rgb(255, 255, 255); "><font =
face=3D"sans-serif"><span style=3D"font-size: 13px; line-height: =
19px;"><br></span></font></span></div><div><span =
style=3D"background-color: rgb(255, 255, 255); "><font =
face=3D"sans-serif"><span style=3D"font-size: 13px; line-height: =
19px;">I should also mention the bitcointalk topic =
here: </span></font></span><a =
href=3D"https://bitcointalk.org/index.php?topic=3D103295.0">https://bitcoi=
ntalk.org/index.php?topic=3D103295.0</a></div><br><div><div>On 10 Sep =
2012, at 19:59, "Luke-Jr" <<a =
href=3D"mailto:luke@dashjr.org">luke@dashjr.org</a>> =
wrote:</div><blockquote type=3D"cite"><br>Most of the problem with block =
propagation lies in implementation, not <br>protocol... Distributing =
missing transaction on an as-needed basis is a <br>possible improvement =
at the protocol level, but there hasn't (AFAIK) been any <br>research =
into whether the little benefit outweighs the cost yet. In any case, =
<br>I don't see why 6 new messages are needed instead of simply adding a =
single <br>new type to getinv?<br></blockquote></div><br></body></html>=
--Apple-Mail=_FB67F502-316A-4C55-BE79-EDFEDAD36E88--
|
