User:Gmaxwell/Reverse header-fetching sync

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 (load balanced across all peers!) 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.

Protocol changes that would make this better

• Headers are cheap to fetch and check but perhaps the attacker would create a really enormous amount of them we could increase the cost of adding more junk headers to fetch:
  • Fixing timewarp, or reducing the window for it with some more easily deployed timestamp rules
  • Increase the minimum acceptable difficulty to 10,000 or some other "we don't care if it were ever to fall that low" minimum.

(Either would have some small hardfork risk but it could be made small except in cases where bitcoin is already failing)