This udpates the blockchain module to use the lastest module major
versions.
While here, it also corrects a few typos and updates some test function
names to more accurately reflect their purpose.
The updated direct dependencies are as follows:
- github.com/decred/dcrd/blockchain/stake/v2@v2.0.1
- github.com/decred/dcrd/chaincfg/v2@v2.2.0
- github.com/decred/dcrd/database/v2@v2.0.0
- github.com/decred/dcrd/dcrutil/v2@v2.0.0
- github.com/decred/dcrd/txscript/v2@v2.0.0
This modifies the various code which deals with choosing which set of
consensus rules to use based upon the result of consensus votes to
remove the hard coded network checks. Not only does it simplify the
existing code, but it makes it less error prone and cumbersome to
introduce new consensus votes in the future.
In order to accomplish this, introduce a new map to associate each
vote/agenda ID to the version that defines it within a given set of
chain parameters and populate the map when creating the chain instance.
Then, when the version is needed to make a decision regarding which
consensus rules are active, query the version from the map by ID. A
missing entry means there is no voting agenda for the given network
(such as will be the case on simnet), and therefore the new rules will
always be in effect for that network.
An important point is that it is theoretically possible that the same ID
could be used in multiple consensus votes since they are only
technically unique per deployment version, although in practice reusing
IDs would be confusing. Given the former, and since duplicate IDs would
break this logic otherwise, the chain instance will now return an error
if a duplicate ID is detected.
This implements the agenda for voting on the sequence lock fixes as
defined in DCP0004 along with consensus tests and mempool acceptance
tests to ensure its correctness.
It also modifies the mempool to conditionally treat all transactions
with enabled sequence locks as non standard until the vote passes at
which point the will become standard with the modified semantics
enforced.
The following is an overview of the changes:
- Generate new version blocks and reject old version blocks after a
super majority has been reached
- New block version on mainnet is version 6
- New block version on testnet is version 7
- Introduce a convenience function for determining if the vote passed
and is now active
- Enforce modified sequence lock semantics in accordance with the state
of the vote
- Modify the more strict standardness checks (acceptance to the mempool
and relay) to enforce DCP0004 in accordance with the state of the vote
- Make all transactions with enabled sequence locks non standard until
the agenda vote passes
- Add tests to ensure acceptance and relay behave according to the
aforementioned description
- Add tests for determining if the agenda is active for both mainnet and
testnet
- Add tests to ensure the corrected sequence locks are handled properly
depending on the result of the vote
This renames the unexported and exported versions
of ThresholdState to NextThresholdState as well as
related test helpers.
NextThresholdState better describes the function
because the threshold state being returned is for the
block after the provided block hash.
This modifies simnet to include the latest consensus changes that have
been successfully voted into mainnet to date starting from its genesis
block. This means it is no longer necessary to vote those changes in to
simnet first before making use of them.
The changes entail removing the deployment entries for those votes,
updating the mining templates to start from version 5, which matches the
current mainnet version, and modifying the various sections in
blockchain which make decisions accordingly.
The chaincfg and blockchain modules are affected, but since their
version has already been bumped since their last release tags, they are
not bumped again.
This resurrects the regression test network that was removed before
initial launch although it really should not have been. The simulation
test network and the regression test network do not serve the same
purpose. Specifically, the regression test network is intended for unit
tests, RPC server tests, and consensus tests. On the other hand, the
simulation test network is intended for private use within a group of
individuals doing simulation testing and full integration tests between
different applications such as wallets, voting service providers, mining
pools, block explorers, and other services that build on Decred.
Keeping the concerns separate will allow the simulation test network to
be modified in ways such as activating consensus changes that have been
successfully voted into mainnet without also needing to vote them in on
the simulation test network while still preserving the ability for the
unit tests to properly test the voting semantics and handling to help
prevent regressions.
In addition to resurrecting the regression test network, this also fully
fleshes out new values for the various addresses prefixes (Rk, Rs, Re,
etc), HD key prefixes (rprv, rpub), and treasury multisig details.
As a part of resurrecting the network, a new CLI flag `--regnet` is
added to allow the RPC test harness connect to a running instance, the
areas of the code which involve votes have been modified to allow the
votes to apply to the new network, and tests have been added to the
relevant modules.
This bumps the affected module versions as follows:
- github.com/decred/dcrd/wire@v1.2.0
- github.com/decred/dcrd/chaincfg@v1.2.0
- github.com/decred/dcrd/dcrutil@v1.2.0
- github.com/decred/dcrd/hdkeychain@v1.1.1
The blockchain module is also affected, but since its version has
already been bumped since the last release tag, it is not bumped again.
Finally, this does not include switching unit tests or the RPC test
harness over the new network since that will be done in a separate
commit.
This modifies the code in blockchain to make less assumptions about the
availability of the block data by checking the status flags to determine
whether or not it is available.
While currently there aren't actually ever any nodes in the block index
that don't have the full block data available, that will not always be
true in the future.
This adds a new testnet3 network with new genesis block, block one
ledger, treasury address, and network magic.
All consensus rules that were voted in by testnet2 are automatically
active on the new testnet3 without having to vote them in again.
Consequently, there are no consensus vote agendas defined for it.
This refactors and simplifies the code in blockchain to use the new more
efficient chain views.
An overview of the logic changes are as follows:
- Remove inMainChain from block nodes since that can now be efficiently
determined by using the chain view
- Track the best chain via a chain view instead of a single block node
- Use the tip of the best chain view everywhere bestNode was used
- Update chain view tip instead of updating best node
- Remove height map and associated lock in favor of chain view
- Use chain view NodeByHeight everywhere height map was used
- Change reorg logic to use more efficient chain view fork finding logic
- Change block locator code over to use more efficient chain view logic
- Remove now unused block-index-based block locator code
- Move BlockLocator definition to chain.go
- Move BlockLocatorFromHash and LatestBlockLocator to chain.go
- Update both to use more efficient chain view logic
- Rework several functions to use chain view for main chain detection
- fetchMainChainBlockByNode
- BlockByHeight
- MainChainHasBlock
- findPreviousCheckpoint
- IsCheckpointCandidate
This reworks the block index code such that it loads all of the headers
in the main chain at startup and constructs the full block index
accordingly.
Since the full index from the current best tip all the way back to the
genesis block is now guaranteed to be in memory, this also removes all
code related to dynamically loading the nodes and updates some of the
logic to take advantage of the fact traversing the block index can no
longer potentially fail. There are also many more optimizations and
simplifications that can be made in the future as a result of this.
Due to removing all of the extra overhead of tracking the dynamic state,
and ensuring the block node structs are aligned to eliminate extra
padding, the end result of a fully populated block index now takes quite
a bit less memory than the previous dynamically loaded version.
It also speeds up the initial startup process by roughly 2x since it is
faster to bulk load the nodes in order as opposed to dynamically loading
only the nodes near the tip in backwards order.
For example, here is some startup timing information before and after
this commit on a node that contains roughly 238,000 blocks:
7200 RPM HDD:
-------------
Startup time before this commit: ~7.71s
Startup time after this commit: ~3.47s
SSD:
----
Startup time before this commit: ~6.34s
Startup time after this commit: ~3.51s
Some additional benefits are:
- Since every block node is in memory, the code which reconstructs
headers from block nodes means that all headers can always be served
from memory which will be important since the network will be moving
to header-based semantics
- Several of the error paths can be removed since they are no longer
necessary
- It is no longer expensive to calculate CSV sequence locks or median
times of blocks way in the past
- It is much less expensive to calculate the initial states for the
various intervals such as the stake and voter version
- It will be possible to create much more efficient iteration and
simplified views of the overall index
An overview of the logic changes are as follows:
- Move AncestorNode from blockIndex to blockNode and greatly simplify
since it no longer has to deal with the possibility of dynamically
loading nodes and related failures
- Replace nodeAtHeightFromTopNode from BlockChain with RelativeAncestor
on blockNode and define it in terms of AncestorNode
- Move CalcPastMedianTime from blockIndex to blockNode and remove no
longer necessary test for nil
- Remove findNode and replace all of its uses with direct queries of the
block index
- Remove blockExists and replace all of its uses with direct queries of
the block index
- Remove all functions and fields related to dynamically loading nodes
- children and parentHash fields from blockNode
- depNodes from blockIndex
- loadBlockNode from blockIndex
- PrevNodeFromBlock from blockIndex
- {p,P}revNodeFromNode from blockIndex
- RemoveNode
- Replace all instances of iterating backwards through nodes to directly
access the parent now that nodes don't potentially need to be
dynamically loaded
- Introduce a lookupNode function on blockIndex which allows the
initialization code to locklessly query the index
- No longer take the chain lock when only access to the block index,
which has its own lock, is needed
- Removed the error paths from several functions that can no longer fail
- getReorganizeNodes
- findPrevTestNetDifficulty
- sumPurchasedTickets
- findStakeVersionPriorNode
- Removed all error paths related to node iteration that can no longer
fail
- Modify FetchUtxoView to return an empty view for the genesis block
This refactors the block index logic into a separate struct and
introduces an individual lock for it so it can be queried independent of
the chain lock.
It also modifies the `newBlockNode` function to accept nil for the
ticket spend information parameter and updates all of the test code that
doesn't require it to use nil.
This implements the agenda for voting on the LN features as defined in
DCP0002 and DCP0003 along with consensus tests to ensure its correctness.
The following is an overview of the changes:
- Generate new version blocks and reject old version blocks after a
super majority has been reached
- New block version on mainnet is version 5
- New block version on testnet is version 6
- Introduce a convenience function for determining if the vote passed
and is now active
- Introduce a new function for getting the consensus script verification
flags and setting the appropriate flags to enforce the new consensus
semantics in accordance with the state of the vote
- Enforce transaction finality checks based on the past median time in
accordance with the state of the vote
- Enforce relative time locks via sequence numbers in accordance with
the state of the vote
- Modify the more strict standardness checks (acceptance to the mempool
and relay) to enforce DCP0002 in accordance with the state of the vote
- It should be noted that the flag for DCP0003 is always set for
the more strict standardness checks because it is a soft fork while
the DCP0002 enforcement must depend on the result of the vote
because it is a hard fork
- Add tests for determining consensus script verification flags for both
mainnet and testnet
- Add tests for determining if the agenda is active for both mainnet and
testnet
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.
Modify threshold state to use the stake version that will be used in the
next block. That removes a full interval before voting can start and it
makes all voting intervals consistent.
Fixes#595
Requires #596
Propagate version and bits on the getstakeversions call. Now we can
interrogate all raw vote version/bits data in addition to cooked values.
Diff is mostly mechanical exporting the Version:Bits tuple.
With this change we can keep the version and the bits in blockNode.
This is used to fix an oversight where we weren't strictly enforcing
the vote version. This also adds tests that validate quorum-1, quorum,
75%-1 and 75% rules during tallying.
Also adjust getvoteinfo totals to only return the specified vote version
totals.
This implements a new voting agenda for the testnet and simnet networks
for increasing the maximum block size from 1MiB to 1.25MB.
The following is an overview of the changes:
- Bump the maximum protocol block size limit to 1.25MB
- Bump the protocol version to 4
- Add wire tests for v3 protocol sizes and update tests for latest
- Update all wire values that are defined in terms of the max block size
to respect the protocol version
- Update the MaxSigOpsPerBlock constant to maintain existing value
regardless of the raised max protocol block size
- Decouple the maximum tx size from the block size by creating a chain
parameter for it with the current sizes so it is not a part of the
hard fork vote
- Add definition for new version 4 stake vote along with agenda to vote
on block size to the testnet and simnet networks
- Convert the MaximumBlockSize chain parameter to a slice in order to
hold the different possible sizes
- Adds a new function that returns the maximum block size based upon the
result of the vote
- Change the existing context-free block size check to enforce the max
protocol size and introduce a context-specific check which enforces a
restricted size based upon the network consensus parameters and the
result of the vote
- Set the max allowed size in generated block templates based upon the
network params and result of the vote
- Generate version 4 blocks and reject version 3 blocks after a super
majority has been reached
Port BIP0009 over from btcd. The following is an overview of the
changes:
- Add new configuration options to the chaincfg package which allows the
rule deployments to be defined per chain
- Implement code to calculate the threshold state as required by voting
- Use threshold state caches that are stored to the database in order
to accelerate startup time
- Remove caches that are invalid due to definition changes in the
params including additions, deletions, and changes to existing
entries
- Verify that PoW and PoS majorities have been reached.
- Add tests for new error type
- Add tests for threshold state
- Deployments are per stake version.
- Add human readable vote/choice infrastructure.
- Add RPC command to interrogate vote status (getvoteinfo).
