multi: Enforce testnet difficulty throttling. #2978
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
davecgh
force-pushed
the
multi_enforce_testnet_diff_throttling
branch
3 times, most recently
from
c292121
to
3a06a22
Compare
alexlyp
approved these changes
Aug 2, 2022
chappjc
reviewed
Aug 2, 2022
|
|
||
| // block962928Hash is the hash of the checkpoint used to activate maximum | ||
| // difficulty semantics on the version 3 test network. | ||
| block962928Hash = mustParseHash("0000004fd1b267fd39111d456ff557137824538e6f6776168600e56002e23b93") |
davecgh
force-pushed
the
multi_enforce_testnet_diff_throttling
branch
6 times, most recently
from
0a52504
to
b8c99fc
Compare
chappjc
approved these changes
Aug 3, 2022
This makes the calcNextRequiredDifficulty method a little more consistent with the code in terms of the name of the parameter and using a shorter local convenience var to avoid overly long lines.
This modifies the template generation code in the case an alterative block building on the parent of the current tip is needed due to lack of votes to also copy the regular transactions from the current tip in addition to the stake transactions. This is useful because it helps make it the template creation logic more robust in the case of duplicate spends and also helps ensure all of the same transactions, such as split transactions make it into the new alternative block templates.
This modifies the RPC server getwork method to return an error in the case of a failed background template. Callers generally expect an error as opposed to long blocking behavior in the case there is a temporary reason block templates are unable to be generated. Also, correct the offsets in the comments regarding the serialized locations of the fields while here.
This modifies the behavior that notifies RPC clients about winning tickets when blocks are connected to send the notification even when the chain is not considered current in the case the --allowunsyncedmining CLI option is set.
This modifies the sync manager to update the sync height in the following additional cases to improve its accuracy: - When a block that is higher than the current known sync height is processed and connected to the main chain - When a header fails to connect during the initial header sync process
Currently, version 3 of the test network implements a minimum difficulty reduction rule that was inherited from btcsuite which intends to act as mechanism to deal with major difficulty spikes due to ASICs which are typically not running testnet and since it's not reasonable to require high-powered hardware to keep the test network running smoothly. Unfortunately, this existing rule is not a particularly good solution in general as it is not very deterministic and introduces additional complications around difficulty selection. It is an even worse solution in the the case of Decred due to its hybrid model. Rather than the aforementioned reactive approach, this introduces more deterministic proactive testnet rules in order limit the type of games that ASICs can play on testnet. In particular, two new rules are introduced that are only imposed started with block height 962928: - A maximum allowed difficulty is now imposed on testnet such that CPU mining will still be feasible without resorting to any type of reactive and more complicated difficulty dropping - Once the maximum allowed difficulty is reached on testnet, blocks must be at least 1 minute apart The combination of these rules will prevent the difficulty on testnet from ever rising to levels that are out of reach for CPUs to continue mining blocks and throttle production in the case of higher-powered hardware such as GPUs and ASICs. It should be noted that this solution is only suitable on a test network where no real monetary value is in play and thus the typical game theory mechanics do not apply. Finally, code to invalidate the existing extremely high work testnet chain which has stalled testnet after that point is added to allow the test network to be recovered without needing to fire up a bunch of ASICs.
This deprecates the ReduceMinDifficulty and MinDiffReductionTime parameters since they will no longer apply to testnet version 3 after activation of the maximum difficulty rules nor any future versions of testnet.
davecgh
force-pushed
the
multi_enforce_testnet_diff_throttling
branch
from
b8c99fc
to
46ab52d
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, version 3 of the test network implements a minimum difficulty reduction rule that was inherited from btcsuite which intends to act as mechanism to deal with major difficulty spikes due to ASICs which are typically not running testnet and since it's not reasonable to require high-powered hardware to keep the test network running smoothly.
Unfortunately, this existing rule is not a particularly good solution in general as it is not very deterministic and introduces additional complications around difficulty selection. It is an even worse solution in the the case of Decred due to its hybrid model.
Rather than the aforementioned reactive approach, this introduces more deterministic proactive testnet rules in order limit the type of games that ASICs can play on testnet.
In particular, two new rules are introduced that are only imposed starting with block height 962928:
The combination of these rules will prevent the difficulty on testnet from ever rising to levels that are out of reach for CPUs to continue mining blocks and throttle production in the case of higher-powered hardware such as GPUs and ASICs.
It should be noted that this solution is only suitable on a test network where no real monetary value is in play and thus the typical game theory mechanics do not apply.
Code to invalidate the existing extremely high work testnet chain which has stalled testnet after that point is added to allow the test network to be recovered without needing to fire up a bunch of ASICs.
Finally, this includes several other commits which improve the handling of mining and syncing when the new rules are enforced.