This merge commit adds the following code from the
github.com/decred/dcrutil package into a new
github.com/decred/dcrd/dcrutil package:
* Address handling
* Amount type
* AppDataDir func
* bitflags functions
* Block wrapper type
* Hash160 func
* Tx wrapper type
* WIF type
as well as all tests for this code.
The old github.com/decred/dcrutil/hdkeychain package has also been
merged and moved to github.com/decred/dcrd/dcrutil/hdkeychain.
dcrd packages have been updated to use the new packages and the dep
files have been updated for this change.
This renames the chaincfg parameter for the vote choice which represents
an abstaining vote to be named IsAbstain instead of IsIgnore since that
more accurately describes its intent and behavior.
It also updates the RPC server choice result field for isignore to be
named isabstain to match and bumps the major version accordingly.
Finally, it renames other internal variables which make use of the
choice to include the word abstain as well for clarity and renames a
couple of other internal variables.
This adds a few more full block tests to more completely exercise the
new threshold state voting functionality.
The following is an overview of the additional tests:
- Cast a majority old version votes that have the same votebits set as
those defined in the new version votes in order to ensure the agenda
does not incorrectly succeed
- Create a voting period such that there is a majority vote, but quorum
is NOT reached and ensure the agenda does not incorrectly succeed
- Create a voting period such that quorum is reached, but there is NOT a
majority vote and ensure the agenda does not incorrectly succeed
This adds a series of full block tests which exercise the new voting
functionality exposed via PoS votebits and a threshold state machine.
As with other full block tests, these involve generating a completely
valid chain starting with genesis block and methodically reaching
various thresholds.
To achieve this, the tests creates two stake version 4 test dummy
deployments that are carried out at the same time to also ensure voting
on multiple agendas concurrently works as intended. The first agenda is
voted in via a majority yes vote while the second is rejected via a
majority no vote.
The following is an overview of the progression of the tests:
- Generate enough block to reach one block before the first stake
version interval using v3 blocks and v3 votes in order to trigger
stake version enforcement
- Generate enough blocks to reach one block before the next rule change
interval using v3 blocks and v3 votes
- Ensure that voting on the agendas does not start due to lack of
majority proof-of-work upgrade, lack of majority proof-of-stake
upgrade, and not being on a rule change interval
- Generate enough blocks to reach one block before the next stake
version interval using v3 blocks and v4 votes in order to achieve
stake version 4 enforcement
- Ensure that voting on the agendas does not start due to lack of
majority proof-of-work upgrade and not being on a rule change
interval
- Generate enough blocks to reach the next rule change interval while
still using a majority of v3 blocks and v4 votes, but set the last two
blocks to v4
- Ensure that voting on the agendas does not start due to lack of
majority proof-of-work upgrade and not being on a rule change
interval
- Generate enough blocks to achieve proof-of-work block version lockin
using v4 blocks and v4 votes
- Ensure that voting on the agendas does not start even though all
upgrade conditions have been met due to not having reached a rule
change interval
- Generate enough blocks to reach the next rule change interval using v4
blocks and v4 votes such that the majority votes vote yes to the first
agenda and no to the second agenda
- Ensure that the voting on agendas begins, but that the yes and no
votes do not count yet since the voting had not started yet until
this rule change interval was reached
- Generate enough blocks to reach the next rule change interval using v4
blocks and v4 votes such that the majority votes vote yes to the first
agenda and no to the second agenda
- Ensure the first agenda becomes locked in since it was voted in
with a majority yes and the second agenda fails since it was
rejected with a majority no
- Generate enough blocks to reach the next rule change interval using v4
blocks and v4 votes such that the majority votes vote the opposite way
they previously did (no to first agenda and yes to second agenda)
- Ensure the first agenda becomes active and the second agenda remains
failed since a rule change can't be undone once it has achieved
lockedin status or has failed
