User:Gmaxwell/Reverse header-fetching sync - Revision history

Gmaxwell: /* Protocol changes that would make this better */

2012-09-07T05:43:48Z

Protocol changes that would make this better

← Older revision		Revision as of 05:43, 7 September 2012
Line 26:		Line 26:
	==Protocol changes that would make this better==		==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:		* 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		** 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.		** 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)
	(~~Either would have some small~~ hardfork risk ~~but it could be made small except~~ 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.		<!-- 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.

Gmaxwell: /* Protocol changes that would make this better */

2012-09-07T05:41:49Z

Protocol changes that would make this better

← Older revision		Revision as of 05:41, 7 September 2012
Line 25:		Line 25:

	==Protocol changes that would make this better==		==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:		* 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		** 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.		** Increase the minimum acceptable difficulty to 10,000 or some other "we don't care if it were ever to fall that low" minimum.

Gmaxwell: /* Protocol changes that would make this better */

2012-09-07T05:41:30Z

Protocol changes that would make this better

← Older revision		Revision as of 05:41, 7 September 2012
Line 25:		Line 25:

	==Protocol changes that would make this better==		==Protocol changes that would make this better==
	* ~~Increase~~ the cost of adding more junk headers to fetch		* 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		** 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.		** Increase the minimum acceptable difficulty to 10,000 or some other "we don't care if it were ever to fall that low" minimum.

Gmaxwell: extra stuff

2012-09-07T05:40:32Z

extra stuff

← Older revision		Revision as of 05:40, 7 September 2012
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==
			* 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)

			<!-- 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.
			-->

Gmaxwell at 01:48, 14 May 2012

2012-05-14T01:48:42Z

← Older revision		Revision as of 01:48, 14 May 2012
Line 16:		Line 16:
	Select the best chain based on headers. (normally there will only be one, save for a little bit of fraying at the very top)		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		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		rules. If there is a violation blacklist the headers at/after the violation
	point, and switch to the longest remaining chain.		point, and switch to the longest remaining chain.

Gmaxwell: moved Reverse header-fetching sync to User:Gmaxwell/Reverse header-fetching sync: this is really just my notes, not something real

2012-02-06T15:45:19Z

moved Reverse header-fetching sync to User:Gmaxwell/Reverse header-fetching sync: this is really just my notes, not something real

← Older revision	Revision as of 15:45, 6 February 2012
(No difference)

Gmaxwell at 15:29, 6 February 2012

2012-02-06T15:29:29Z

← Older revision		Revision as of 15:29, 6 February 2012
Line 8:		Line 8:
	Sort by {difficulty, height, num-peers-reporting, hash}, select the best.		Sort by {difficulty, height, num-peers-reporting, hash}, select the best.

	Backwards fetch the headers from the fastest of the best ~~to respond~~. Abort if any header rules are violated.		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)
	(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		Check if peers are reporting new heads. For each distinct head, repeat the
Line 21:		Line 20:
	point, and switch to the longest remaining chain.		point, and switch to the longest remaining chain.

	You now have the fully validated longest 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.

Gmaxwell: wrote this up a while ago

2012-02-06T15:25:21Z

wrote this up a while ago

New page

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 of the best to respond. 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.