User:Gmaxwell/Reverse header-fetching sync: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
No edit summary
m moved Reverse header-fetching sync to User:Gmaxwell/Reverse header-fetching sync: this is really just my notes, not something real
(No difference)

Revision as of 15:45, 6 February 2012

Ask peers for the identiy of their best block, get all distinct ones.

Exclude any that couldn't be valid based on what we can validate: Minimum difficulty, timestamp, syntax, subsidy. (An additional rule like diff must be >=x if the height is >=y can prevent spamming attacks here mostly safely)

Sort by {difficulty, height, num-peers-reporting, hash}, select the best.

Backwards fetch the headers from the fastest to respond out of the set of peers giving an identical best block. Abort if any header rules are violated. (timestamps/difficulty). Connect all the way back to the genesis. (if it stops, switch peers)

Check if peers are reporting new heads. For each distinct head, repeat the above, but stop where/if it merges into the previously fetched chain or when it couldn't beat the difficulty of the current longest chain.

Select the best chain based on headers. (normally there will only be one, save for a little bit of fraying at the very top)

For the best chain, fetch bodies and begin validating according to the full rules. If there is a violation blacklist the headers at/after the violation point, and switch to the longest remaining chain.

You now have the fully validated longest chain and can begin advertising yourself as a full node.

This could be augmented by also fetching bodies in reverse order in order to populate the wallet, then validating forward. If this is done the populating should only start a few (3-6) blocks deep from the top in order to avoid trouble making. This will improve user experience by getting transactions into the wallet faster.