A sum merkle tree could be built. The root node would be
Topic: Adding a step size field to getheaders (improved download speed) (Read 695 times)
I wonder if this scheme could be modified to perform the task.
A sum merkle tree could be built. The root node would be : and the root would be used to select which leaves.
A sum merkle tree could be built. The root node would be
I think there should be a way to download the chain in a more parallel way.
I suggest a tweak to the getheader rules to add a step field.
int: version
var_int: hash count
hash[]: the hashes
hash: hash-stop
int: step
The step would default to 1. If you set it to 20000 and give no known hashes, then you would get headers for 1, 20001, 40001, ...., 240001. This gives a "snapshot" of the chain from each peer. With 250k blocks, that's around 1kB per peer.
A new node could ask all peers for hashes of every 20000 blocks. If they all agree, then download a random 1000 from each of them until the full header chain is available. The full blocks can then be download from latest to earliest.
If there is disagreement, then the client would split peers into groups that agree. The client could ask for headers in steps of 1000 between a random hash and the one after it (and then in steps of 100 between 2 of those).
The node could then be asked for the 100 hashes. If it doesn't form a chain, then that node was lying and the IP can be blacklisted.
This would allow distinguishing of honest and dishonest nodes.
Blocks after the fork would need to be focused on.
Even with only 1 header from every 20k blocks, the total chain POW could be estimated and the client would focus on the one with most POW. Sending fake chains would be detected very quickly.
Step 20000: 13 headers (1kB)
Step 1000: 20 headers (1.6kB)
Step 50: 20 header (1.6kB)
Step 1: 50 headers (4kB)
So, for less than 10kB in received data, there is a good chance that the node will detect a dishonest chain.
I suggest a tweak to the getheader rules to add a step field.
int: version
var_int: hash count
hash[]: the hashes
hash: hash-stop
int: step
The step would default to 1. If you set it to 20000 and give no known hashes, then you would get headers for 1, 20001, 40001, ...., 240001. This gives a "snapshot" of the chain from each peer. With 250k blocks, that's around 1kB per peer.
A new node could ask all peers for hashes of every 20000 blocks. If they all agree, then download a random 1000 from each of them until the full header chain is available. The full blocks can then be download from latest to earliest.
If there is disagreement, then the client would split peers into groups that agree. The client could ask for headers in steps of 1000 between a random hash and the one after it (and then in steps of 100 between 2 of those).
The node could then be asked for the 100 hashes. If it doesn't form a chain, then that node was lying and the IP can be blacklisted.
This would allow distinguishing of honest and dishonest nodes.
Blocks after the fork would need to be focused on.
Even with only 1 header from every 20k blocks, the total chain POW could be estimated and the client would focus on the one with most POW. Sending fake chains would be detected very quickly.
Step 20000: 13 headers (1kB)
Step 1000: 20 headers (1.6kB)
Step 50: 20 header (1.6kB)
Step 1: 50 headers (4kB)
So, for less than 10kB in received data, there is a good chance that the node will detect a dishonest chain.
Jump to: