User:Gmaxwell/Reverse header-fetching sync: Difference between revisions
No edit summary |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 23: | Line 23: | ||
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. | 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 (unacceptable hardfork), or reducing the window for it with some more easily deployed timestamp rules (softfork risk) | |||
** Increase the minimum acceptable difficulty to 10,000 or some other "we don't care if it were ever to fall that low" minimum. (hardfork risk only in cases where bitcoin is already failing) | |||
<!-- I keep liking this idea, but I can't actually see how to make it work. The attacker can still make you fetch all the attack headers first which is the only work you'd do on a truly shorter attack chain anyways. It at least could lead to faster true chain selection among multiple competing honest true chains. | |||
* Include a merged mined commitment to the sum difficulty in the block coinbase and enforce it as a block validity rule. Then on fetch fetch first the chain with the best claimed difficulty | |||
If the attacker claims true difficulty you select the true one first every time. If the attacker lies, you discover the lies only after reading the headers. | |||
Deploying the enforcement itself has soft-fork risk. | |||
--> | |||
Latest revision as of 05:43, 7 September 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 (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 (unacceptable hardfork), or reducing the window for it with some more easily deployed timestamp rules (softfork risk)
- Increase the minimum acceptable difficulty to 10,000 or some other "we don't care if it were ever to fall that low" minimum. (hardfork risk only in cases where bitcoin is already failing)