<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="font-size: 13px;">Bitcoin development team,</div><div style="font-size: 13px;"><br></div><div style="font-size: 13px;">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. :)</div><div style="font-size: 13px;"><br></div><div style="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="font-size: 13px;"><br></div><div style="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… 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:</div><div style="font-size: 13px;"><br></div><div style="font-size: 13px;"><div style="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="font-size: 13px;"><br></div><div style="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="font-size: 13px;"><br></div><div style="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="font-size: 13px;"><br></div><div style="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="font-size: 13px;"><br></div><div style="font-size: 13px;">Ideas? Suggestions? Concerns? Prior it-ain’t-gonna-works?</div><div style="font-size: 13px;"><br></div><div style="font-size: 13px;">Thanks!</div><div style="font-size: 13px;"><br></div><div style="font-size: 13px;">RicMoo</div><div><br></div><div><br></div><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px;">.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º><br><br>Richard Moore ~ Founder<br>Genetic Mistakes Software inc.<br>phone: (778) 882-6125<br>email: <a href="mailto:ricmoo@geneticmistakes.com">ricmoo@geneticmistakes.com</a><br>www: <a href="http://GeneticMistakes.com/">http://GeneticMistakes.com</a></span>
</div>
<br></body></html>