This modifies the NextBlock function to account for changes made to the
block height or previous block hash in munge functions and update the
commitments in all votes accordingly.
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 adds several new tests to the consensus tests based upon their
upstream equivalents as well as some Decred-specific cases and updates
the chaingen package accordingly.
The following is a summary of the new tests:
* Negative proof-of-work limit (bits header field)
* Spend from transaction that does not exist
* Max size block with canonical encoding which exceeds max size with
non-canonical encoding
* Too many signature operations with offending sigop before invalid data
push
* Max and too many signature operations via pay-to-script-hash redeem
scripts
* Invalid opcode in dead execution path
* Reorganization of txns with OP_RETURN outputs
* Spend of an OP_RETURN output
* Transaction with multiple OP_RETURN outputs
* Large max-sized block reorganization test (disabled by default since
it takes a long time and a lot of memory to run)
It also modifies a few tests to make them a little less reliant on the
specific parameters chosen such as replacing the number of votes with
the expected tickets per block divided by 2 instead of just subtracting
3 which assumes there are specifically 5 votes.
Finally, it adds some comments regarding some upstream tests that were
not included due to the specific conditions they test not applying to
Decred.
Upstream commit b86df0ba91.
The merge commit contains necessary Decred-specific alterations and also
removes the code that is related to generating and submitting a new
block.
While the block generation functionality is useful, the specific method
used in the upstream code will not work in Decred because of the
additional state needed for voting and the fact the difficulty
adjustment period is much more frequent which prevents just using the
pow limit.
Future commits can remedy this situation by making use of block
templates provided by the daemon and allowing the rpc test code to
modify the template accordingly.
The go compiler treats the math.MaxUint32 constant as an integer in the
error print which causes a compile error. This casts the constant to
avoid that thus allows the code to compile on 32-bit architectures.
The original test generation live ticket pool code was written quickly
and _extremely_ inefficiently since it was only intended for a
relatively small number of blocks. However, it has proven a useful tool
for much longer test chains even though it was incredibly slow to
generate them.
As a result, this significantly speeds up generation by replacing the
code related to generating the live ticket pool to a more complex
version that only handles the changes required by each block along with
handling reorgs caused by calling SetTip and using cached tx hashes
throughout.
Prior to this commit, the threshold state tests were taking over 10
minutes and they now take 8 seconds on a the same machine.
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
This introduces a new package named chaingen that is useful for
generating full-blown valid test chains. It is primarily a refactor of
the generator code that was previously in fullblocktests.
It also updates the fullblocktests package to make use of this new
chaingen package and removes the stakeversiontests package in favor of
performing all of the same tests inline making use of the new chaingen
package.
