wrote: > Why do you want to optimise this? getheaders is used by SPV clients = not full nodes. SPV clients like bitcoinj can and do simply ship with = gist files in them, then getheaders from the last "checkpoint" (I wish = I hadn't reused terminology like that but this is what bitcoinj calls = them). >=20 > In practice when I look at performance issues with current SPV = clients, getheaders speed is not on my radar. .=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=_63C57CA8-3DBB-40F8-8AED-41399E2FEF46 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

I was considering names like getcheckpoints() = to use the terminology that already seemed to be in place, but they were = too long :)

I have been using getheaders() in my thick = client to quickly grab all the headers before downloading the full = blocks since I can grab more at a time. Even with getblocks(), there is = the case for a getgist() call. Right now you call getblocks(), = which can take some time to get the corresponding inv(), at which time = you can then start the call to getdata() as well as the next call to = getblocks().

With a gist, for example of segment_count 50, = you could call getgist(), then with the response, you could request 50 = getblocks() each with a block_locator of 1 hash from the gist (and = optimally the stop_hash of the next hash in the gist) to 50 different = peers, providing 25,000 (50 x 500) block hashes.

Currently:

>>> getblocks()
<<< = inv()
>>> getdata()
<<< block(), = block(), block(), =85 (x 500)

Saturates one peer, = while leaving the rest un-used. Step 1 and 2 can be repeated and = dispatched to different peers, but there is still the latency between = the two calls.

Gist:

>>> getgist()
<<< = inv()
>>> getblocks(), getblocks(), getblocks(), =85 (x = segment_count, 1 per peer)
<<< inv(), inv(), inv(), =85 = (x segment_count, 1 per peer)
>>> getdata(), getdata(), = getdata(), =85 (x segment_count, 1 per peer)
<<< = block(), block(), block(), =85 (x (500 * segment_count), ie. 500 in per = peer)

Each peer can be saturated.

I = will try to run some experiments this weekend to get numbers as to = whether there is actually any performance improvement using a gist, or = whether the getdata(), block() latency ends up dominating the time = anyways.

RicMoo

On Jun 4, = 2014, at 11:42 PM, Mike Hearn <mike@plan99.net> wrote:

Why do you want to optimise this? getheaders is used by SPV = clients not full nodes. SPV clients like bitcoinj can and do simply ship = with gist files in them, then getheaders from the last "checkpoint" = (I wish I hadn't reused terminology like that but this is what = bitcoinj calls them).

In practice when I look at performance issues with = current SPV clients, getheaders speed is not on my radar.

.=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<= br>www: http://GeneticMistakes.com=

= --Apple-Mail=_63C57CA8-3DBB-40F8-8AED-41399E2FEF46--