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
|
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 <mark@monetize.io>) id 1WsYeO-0003Wj-0u
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Jun 2014 14:28:16 +0000
Received: from mail-pd0-f174.google.com ([209.85.192.174])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WsYeL-0006AD-HA
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Jun 2014 14:28:15 +0000
Received: by mail-pd0-f174.google.com with SMTP id r10so1160901pdi.5
for <bitcoin-development@lists.sourceforge.net>;
Thu, 05 Jun 2014 07:28:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:organization:user-agent
:mime-version:to:subject:references:in-reply-to:content-type
:content-transfer-encoding;
bh=wm58bWIMQSMxI6POok+tSA31JB23qHRFHlZ5UQSAOi4=;
b=Pv0eSj9QR1RwtAPGxLRYjj+hEM2MyH19c4XKhvHFy1L6P87hWmDJvjt2NDEIQFIp4y
NvkBdP231R7f5IjIS1a4Camaj+AxI4gs95wUSin7oN9Q9wGYqlAG5fu4QRi+rco1rJPp
v8PQVxcb+93Wc+iWDOrYJ+dWgEG5YLpeaUVgU8S56Q9flfDSe6Hgy180S33mySgAXlDt
uaW9zU81755Oh1c5qSwr6TKt0Kg9XtFIu6mksTfAAoF392BLP17DLFFs0U9b8xbBXV8D
RV12uRlT4CMuQE9GAXSt2h09Q8XDK9wgOA4FzbFuYcQxkZWcpFRpRTw97kGjGweUeNbg
omUQ==
X-Gm-Message-State: ALoCoQn39SG68rNM8O0j/34ceDC23Oj1pJCsCUgXdadSNAywVuavQQdVON7EIQjMzZXRaUaVt0dB
X-Received: by 10.68.171.193 with SMTP id aw1mr76088096pbc.117.1401978487174;
Thu, 05 Jun 2014 07:28:07 -0700 (PDT)
Received: from [192.168.127.170] (50-0-36-179.dsl.dynamic.sonic.net.
[50.0.36.179]) by mx.google.com with ESMTPSA id
fv2sm23618097pbd.11.2014.06.05.07.28.04
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Thu, 05 Jun 2014 07:28:06 -0700 (PDT)
Message-ID: <53907E74.40401@monetize.io>
Date: Thu, 05 Jun 2014 07:28:04 -0700
From: Mark Friedenbach <mark@monetize.io>
Organization: Monetize.io Inc.
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: <34798C1C-FDA7-4A4C-B136-DBD4E59C254D@ricmoo.com>
In-Reply-To: <34798C1C-FDA7-4A4C-B136-DBD4E59C254D@ricmoo.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [209.85.192.174 listed in list.dnswl.org]
X-Headers-End: 1WsYeL-0006AD-HA
Subject: Re: [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: Thu, 05 Jun 2014 14:28:16 -0000
The correct approach here is header hash-tree commitments which enable
compact (logarithmic) SPV proofs that elide nearly all intervening
headers since the last checkpoint. You could then query the hash tree
for references to any of the headers you actually need.
See this message for details:
http://sourceforge.net/p/bitcoin/mailman/message/32111357/
On 06/04/2014 12:30 PM, Richard Moore wrote:
> Bitcoin development team,
>
> I recently started implementing my own Python full-node, and had an
> idea, so I’m 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’t 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… 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… 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’t-gonna-works?
>
> Thanks!
>
> RicMoo
>
>
> .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
>
> Richard Moore ~ Founder
> Genetic Mistakes Software inc.
> phone: (778) 882-6125
> email: ricmoo@geneticmistakes.com <mailto:ricmoo@geneticmistakes.com>
> www: http://GeneticMistakes.com <http://GeneticMistakes.com/>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
|
