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
|
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 <me@ricmoo.com>) id 1WsHFU-0001el-5r
for bitcoin-development@lists.sourceforge.net;
Wed, 04 Jun 2014 19:53:24 +0000
X-ACL-Warn:
Received: from mail-ig0-f177.google.com ([209.85.213.177])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WsHFS-0007zc-MJ
for bitcoin-development@lists.sourceforge.net;
Wed, 04 Jun 2014 19:53:24 +0000
Received: by mail-ig0-f177.google.com with SMTP id l13so1461227iga.16
for <bitcoin-development@lists.sourceforge.net>;
Wed, 04 Jun 2014 12:53:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:from:content-type:subject:message-id:date:to
:mime-version;
bh=yCiEO4jFQ7LmBdjfo3h3fKHv8Jdu5yECdmbp5lPEZ1g=;
b=NWtOwWXXg0KqzuZqCsAgIMOBsoMmQQzHLYWbDKCUrAIVHqzT2KbH2GCqk4MvEINFhB
q6lRPLpw8YMjLx3j6qFbaREt8Pbhd/2shs//q7he2Hb9LclE9SQja3qJtkUXbc6Hk0Pb
2Usy9kpxL5secTvdlUugb3BhPhKzmnrWYD5WoF3xVEr6pmodbumHOcuJTq/IAVduyy1J
PQRkEkPJvAmaht62+8z6eaQxqbkhmaCd5dD+fkMPz8kdif6Q6dxyB0czA/Whjk3yBI9p
0cnTo4QTAja2wEsRPf5WDdkq4+p4vRJEPvzR5xJUTYuhDWrlRPb4Boh5/aRJA4WQ7JPc
CHyA==
X-Gm-Message-State: ALoCoQn3fK+efb8bqUMO7mLHtw7qcd5bfpUiJrVB+jqXAfyMBg+ePgbICOL4oLzWSNT2I57AT6WH
X-Received: by 10.50.9.104 with SMTP id y8mr10409904iga.43.1401910212978;
Wed, 04 Jun 2014 12:30:12 -0700 (PDT)
Received: from [192.168.2.22] (bas5-toronto47-2925108301.dsl.bell.ca.
[174.89.156.77])
by mx.google.com with ESMTPSA id q5sm47164166igg.10.2014.06.04.12.30.12
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Wed, 04 Jun 2014 12:30:12 -0700 (PDT)
From: Richard Moore <me@ricmoo.com>
Content-Type: multipart/alternative;
boundary="Apple-Mail=_0604438E-29BB-487A-830E-47C672397825"
Message-Id: <34798C1C-FDA7-4A4C-B136-DBD4E59C254D@ricmoo.com>
Date: Wed, 4 Jun 2014 15:30:10 -0400
To: bitcoin-development@lists.sourceforge.net
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
X-Mailer: Apple Mail (2.1878.2)
X-Spam-Score: 0.9 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-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: 1WsHFS-0007zc-MJ
Subject: [Bitcoin-development] Future Feature Proposal - getgist
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: Wed, 04 Jun 2014 19:53:24 -0000
--Apple-Mail=_0604438E-29BB-487A-830E-47C672397825
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
Bitcoin development team,
I recently started implementing my own Python full-node, and had an =
idea, so I=92m prowling through BIP 001 for this proposal, which says to =
e-mail you kind folks to make sure the idea is original (enough) and =
that there aren=92t other existing means to accomplish what I was =
thinking. :)
The only way to grab all the headers seems to be to serially get one, =
then the next and so on, as you need the last hash of a headers() call =
to the next getheaders(). But we are on a peer-to-peer network, =
potentially able to getheaders() from many peers simultaneously, if we =
only knew the hash to look for.
What I was thinking is something to the effect of a getgist() command, =
fully backward compatible (any node not understanding it, can silently =
ignore it=85 Otherwise version or services could be used to announce the =
capability, but that seems like a little overkill). The inputs to =
getgist() would be similar to getheaders(); version, hash_count, =
block_locator_hash, stop_hash and an additional field, segment_count. =
The response would be a normal headers() message, except, not sequential =
block headers=85 Rather they would be spaced out, preferably =
2000-block-hash-aligned from the first block hash. So, for example, if =
you have a blockchain with 198,005 blocks, and you passed it the block =
locator of height 0 (the genesis block), and a segment_count of 25, you =
would expect (approximately, the actual algorithm needs to be figured =
out), the block hashes at the following 25 (segment_count) heights:
1, 8000, 16000, 24000, 32000, 40000, 48000, 56000, 64000, 72000, 80000, =
88000, 96000, 104000, 112000, 120000, 128000, 136000, 144000, 152000, =
160000, 168000, 176000, 184000, 192000
Which can now be spread across 25 different nodes, fetching the block =
headers (albeit, out of order, possibly increasing the complexity of the =
local block chain database) but vastly increasing the speed the whole =
blockchain can have all headers synced.
I still need to perform some tests to see what type of speed gains there =
are, but I would suspect it should be segment_count times faster.
Existing methods could be to use checkpoint-ish nodes or bootstrap data =
files, but these begin relying on semi-cetralizenesses.
Ideas? Suggestions? Concerns? Prior it-ain=92t-gonna-works?
Thanks!
RicMoo
.=B7=B4=AF`=B7.=B8=B8.=B7=B4=AF`=B7.=B8=B8.=B7=B4=AF`=B7.=B8=B8.=B7=B4=AF`=
=B7.=B8=B8.=B7=B4=AF`=B7.=B8><(((=BA>
Richard Moore ~ Founder
Genetic Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo@geneticmistakes.com
www: http://GeneticMistakes.com
--Apple-Mail=_0604438E-29BB-487A-830E-47C672397825
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div =
style=3D"font-size: 13px;">Bitcoin development team,</div><div =
style=3D"font-size: 13px;"><br></div><div style=3D"font-size: 13px;">I =
recently started implementing my own Python full-node, and had an idea, =
so I=92m prowling through BIP 001 for this proposal, which says to =
e-mail you kind folks to make sure the idea is original (enough) and =
that there aren=92t other existing means to accomplish what I was =
thinking. :)</div><div style=3D"font-size: 13px;"><br></div><div =
style=3D"font-size: 13px;">The only way to grab all the headers seems to =
be to serially get one, then the next and so on, as you need the last =
hash of a headers() call to the next getheaders(). But we are on a =
peer-to-peer network, potentially able to getheaders() from many peers =
simultaneously, if we only knew the hash to look for.</div><div =
style=3D"font-size: 13px;"><br></div><div style=3D"font-size: =
13px;">What I was thinking is something to the effect of a getgist() =
command, fully backward compatible (any node not understanding it, can =
silently ignore it=85 Otherwise version or services could be used to =
announce the capability, but that seems like a little overkill). The =
inputs to getgist() would be similar to getheaders(); version, =
hash_count, block_locator_hash, stop_hash and an additional field, =
segment_count. The response would be a normal headers() message, except, =
not sequential block headers=85 Rather they would be spaced out, =
preferably 2000-block-hash-aligned from the first block hash. So, for =
example, if you have a blockchain with 198,005 blocks, and you passed it =
the block locator of height 0 (the genesis block), and a segment_count =
of 25, you would expect (approximately, the actual algorithm needs to be =
figured out), the block hashes at the following 25 (segment_count) =
heights:</div><div style=3D"font-size: 13px;"><br></div><div =
style=3D"font-size: 13px;"><div style=3D"margin: 0px; font-size: 11px; =
font-family: Menlo;">1, 8000, 16000, 24000, 32000, 40000, 48000, 56000, =
64000, 72000, 80000, 88000, 96000, 104000, 112000, 120000, 128000, =
136000, 144000, 152000, 160000, 168000, 176000, 184000, =
192000</div></div><div style=3D"font-size: 13px;"><br></div><div =
style=3D"font-size: 13px;">Which can now be spread across 25 different =
nodes, fetching the block headers (albeit, out of order, possibly =
increasing the complexity of the local block chain database) but vastly =
increasing the speed the whole blockchain can have all headers =
synced.</div><div style=3D"font-size: 13px;"><br></div><div =
style=3D"font-size: 13px;">I still need to perform some tests to see =
what type of speed gains there are, but I would suspect it should be =
segment_count times faster.</div><div style=3D"font-size: =
13px;"><br></div><div style=3D"font-size: 13px;">Existing methods could =
be to use checkpoint-ish nodes or bootstrap data files, but these begin =
relying on semi-cetralizenesses.</div><div style=3D"font-size: =
13px;"><br></div><div style=3D"font-size: 13px;">Ideas? Suggestions? =
Concerns? Prior it-ain=92t-gonna-works?</div><div style=3D"font-size: =
13px;"><br></div><div style=3D"font-size: 13px;">Thanks!</div><div =
style=3D"font-size: 13px;"><br></div><div style=3D"font-size: =
13px;">RicMoo</div><div><br></div><div><br></div><div =
apple-content-edited=3D"true">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
border-spacing: =
0px;">.=B7=B4=AF`=B7.=B8=B8.=B7=B4=AF`=B7.=B8=B8.=B7=B4=AF`=B7.=B8=B8.=B7=B4=
=AF`=B7.=B8=B8.=B7=B4=AF`=B7.=B8><(((=BA><br><br>Richard Moore =
~ Founder<br>Genetic Mistakes Software inc.<br>phone: (778) =
882-6125<br>email: <a =
href=3D"mailto:ricmoo@geneticmistakes.com">ricmoo@geneticmistakes.com</a><=
br>www: <a =
href=3D"http://GeneticMistakes.com/">http://GeneticMistakes.com</a></span>=
</div>
<br></body></html>=
--Apple-Mail=_0604438E-29BB-487A-830E-47C672397825--
|
