The method that calculates the next required difficulty currently logs
difficulty retargets which means it has side effects when it really
should free from them given its purpose.
This can be evidenced by the fact the logging is actually slightly
incorrect in a couple of ways due to those side effects. Namely, it can
potentially log when checking block templates when it shouldn't and it
is also currently logging when the headers are connected as opposed to
when the blocks themselves are actually connected which was the original
intention prior to the new headers-first logic.
Thus, this moves the debug logging for difficulty retargets from the
required difficulty calculation function to the block connection
function and also takes the opportunity to impose a new condition to
only log when the difficulty actually changes as opposed to the current
behavior of always logging on a retarget interval regardless.
This updates the blockchain checkpoints logic to use a single latest
checkpoint rather than multiple checkpoints. The intermediate
checkpoints are no longer necessary because headers first syncing was
introduced, which discovers the most recent checkpoint before block
syncing even starts.
This updates the Checkpoints param for mainnet and testnet to specify a
single latest checkpoint rather than multiple checkpoints. The
intermediate checkpoints are no longer necessary because headers first
syncing was introduced, which discovers the most recent checkpoint
before block syncing even starts.
This updates several of the tests in the script_test.go file to be more
consistent with the format used throughout the vast majority of the
other tests in the package.
The following is an overview of the changes:
- Use more compact format for the test definition tables
- Update the tests to make use of the short form script parsing logic
rather than manually defining byte slices
- Move the logic for testing various canonical integer and data pushes
into their respective test funcs
- Add names to the individual test conditions
- Update test failure output to be more consistent
This adds the ability for the short form script parsing to handle
different script versions and updates all of the tests to use the
version 0 function appropriately.
This updates the difficulty retarget logs to only be logged if the chain
believes it is current. These logs are otherwise very noisy when
syncing headers with the debug log level set.
This refactors finding the lowest index tip height out of CatchUp into
findLowestIndexTipHeight. The prevscripter snapshot now makes copies of
the pkScript to avoid holding on to references too long during the
catch up process.
This integrates the spend pruner's RemoveSpendConsumerDependency method
in the chaing query adapter to allow consumers access to the
functionality. The address index has been updated as such to remove its
spend journal dependencies when it processes block disconnections.
This updates the index subscriber catchup function to update
subscriptions directly with notification instead of going through the
Run lifecycle process which avoids a case of receiving out of sync
index notifications while catch up is in progress.
Multiple typos in error type tests and review issues have also been
fixed in this commit.
This removes last set of references to IndexManager and integrates the
IndexSubscriber into the chain. All indexes have now been updated to
subscribe to the index subscriber for updates.
This reworks the ExistsAddressIndex to implement the updated Indexer
interface for asynchoronous index updates. This index subscribes with
no prerequisites.
This updates the AddressIndex to implement the updated Indexer
interface for index updates. The index however subscribes with the
transaction index as a prerequisite.
This also adds the spend consumer for use by indexers that need to
lookup spend journal entries.
This reworks the TransactionIndex to implement the updated Indexer
interface for asynchoronous index updates. This index subscribes with
no prequisites.
This removes the IndexManager interface and reworks the ChainQueryer
and Indexer interfaces to facilitate index notification subscriptions
and asynchronous index notifications.
This adds the IndexSubscriber which allows subscribing for index
notifications as well as specifying an index notification dependency
or prerequisite for a subscriber.
This adds full test coverage for the calcTicketReturnAmounts function
to ensure that ticket return amounts are calculated correctly under a
variety of conditions.
This introduces automatic ticket revocations as defined in DCP0009,
including:
- Allowing tickets to be revoked by anyone instead of requiring a valid
signature from the voting address
- Requiring blocks to contain ticket revocation transactions for all
tickets that become missed or expired as of that block
An overview of the changes is as follows:
- blockchain/scriptval.go
- ValidateTransactionScripts, checkBlockScripts
- Skip script validation for version 2 revocations if the automatic
ticket revocations agenda is active
- blockchain/stake/staketx.go, blockchain/stake/staketx_test.go
- Introduce TxVersionAutoRevocations const for version 2 revocations
- CalculateRewards, CalculateRevocationRewards
- Add CalculateRevocationRewards to handle the required updates for
revocations while leaving CalculateRewards as-is for votes
- If the automatic ticket revocations agenda is active, and there is
a remainder after distributing the returns, then select a
uniformly pseudorandom output index to receive each remaining
atom
- Add additional tests to cover the new code paths
- CheckSSRtx
- Add checks to ensure that the input does not have a signature
script and does not have a fee if the automatic ticket revocations
agenda is active
- Add additional tests to cover the new code paths
- blockchain/validate.go, blockchain/validate_test.go
- checkTransactionContext
- Add rule that revocation transactions MUST be version 2 if the
automatic ticket revocations agenda is active.
- checkTicketRedeemers
- Add rule that if the automatic ticket revocations agenda is
active, then the block MUST contain revocation transactions for
all tickets that will become missed or expired as of that block
- Add rule that if the automatic ticket revocations agenda is
active, then revocations can spend tickets that will become missed
or expired as of that block (previously they could not be spent
until the block following the block where they became missed or
expired)
- Update to accept the referenced ticket hashes rather than the
overall block to simplify adding comprehensive unit tests for the
function
- calcTicketReturnAmounts
- Update to calculate the amounts for all outputs rather than a
single output
- For revocations, if the automatic ticket revocations agenda is active,
and there is a remainder after distributing the returns, then select a
uniformly pseudorandom output index to receive each remaining
atom
- checkTicketRedeemerCommitments
- Add rule that if the transaction is a version 2 revocation and the
automatic ticket revocation agenda is active, then the fee MUST be
zero
- Use the updated calcTicketReturnAmounts function so that returns
include the full amount, which allows for ensuring a truly zero
fee
- checkRevocationInputs
- Add rule that if the automatic ticket revocations agenda is
active, then revocations can spend tickets after ticket maturity
+ 1 blocks (in the block that they become missed or expired)
rather than after ticket maturity + 2 blocks (in the block AFTER
they become missed or expired)
- internal/mempool/mempool.go, internal/mempool/mempool_test.go
- Pass best block header to CheckTransactionInputs
- Pass isAutoRevocationsEnabled to ValidateTransactionScripts
- internal/mining/mining.go, internal/mining/mining_harness_test.go,
internal/mining/mining_test.go, internal/mining/mining_view_test.go
- Add a helper function, createRevocationFromTicket, to create a
revocation transaction from a ticket hash
- If the automatic ticket revocations agenda is active, then create
version 2 revocation transactions for all tickets that will become
missed or expired as of the block being created
- Create and insert these revocations into the priority queue AFTER
votes are done being added to ensure that revocations are added for
votes that fail validation checks or are otherwise not included into
the block
- Pass best block header to CheckTransactionInputs
- Pass isAutoRevocationsEnabled to ValidateTransactionScripts
- internal/rpcserver/interface.go, internal/rpcserver/rpcserver.go,
internal/rpcserver/rpcserverhandlers_test.go
- handleCreateRawSSRtx
- If the automatic ticket revocations agenda is active:
- Validate that the fee is zero
- Set the transaction version to 2
- Pass previous header bytes and isAutoRevocationsEnabled flag to
CreateRevocationFromTicket in order to create version 2 revocation
transactions properly with the updated rules
- Add additional tests to cover the new code paths
- server.go
- Pass previous block header to CheckTransactionInputs
- Pass isAutoRevocationsEnabled to ValidateTransactionScripts
This significantly reworks the docker support to provide build a
lightweight non-root distroless container image based on scratch. It
employs a multi-stage build that downloads and builds the latest source
code, compresses the resulting binaries, and then produces the final
image based on scratch that only includes the Decred-specific binaries.
It must be noted that there are some still remaining TODO items in the
documentation as well as the Dockerfile that will need to be handled by
a future commit, but the changes are being submitted now to allow
another contributor to finish up those aspects.
The following is an overview of the changes:
- Removes existing Dockerfile and Dockerfile.alpine
- Introduces a new Dockerfile under contrib/docker with the following
properties:
- Runs as a non-root user
- Uses a static UID:GID of 10000:10000
- Note that using UIDs/GIDs below 10000 for container users is a
security risk on several systems since a hypothetical attack which
allows escalation outside of the container might otherwise
coincide with an existing user's UID or existing group's GID which
has additional permissions
- The image is based on scratch image (aka completely empty) and only
includes the Decred-specific binaries which means there is no shell
or any other binaries available if an attacker were to somehow
manage to find a remote execution vulnerability exploit in a Decred
binary
- Introduces code to build an entrypoint for the image since it is based
on scratch and thus has no shell for that purpose
- Adds contrib/docker/README.md
- Updates README.md in the main directory to account for changes
- There is still outstanding work to be done here and thus has several
TODOs
- Updates contrib/README.md to call out the new addition
This renames the workSorterLess function to betterCandidate and reverses
the semantics accordingly.
It was originally named workSorterLess because it doubled as the less
function for a sorting implementation, but the sorting component was
removed in favor of just finding the best candidate. Also, the function
considers more than cumulative work for making the determination
(although cumulative work is the most important and primary criteria),
so it makes more sense to rename the function to more closely match its
intended purpose.
This modifies some recently-updated modules to use a valid gcs
prerelease version so they can be used in require statements in consumer
code that is also under development.
The updated direct dependencies are as follows:
- github.com/decred/dcrd/gcs/v3 v3.0.0-20210916172859-ca03de05ecd0
This modifies the recently-updated gcs module to use a valid prerelease
version of the blockchain/stake module so it can be used in require
statements in consumer code that is also under development.
The updated direct dependencies are as follows:
- github.com/decred/dcrd/blockchain/stake/v4 v4.0.0-20210906140327-598bf66f24a6
This modifies the recently-updated blockchain module to use a valid
prerelease version of the blockchain/stake and chaincfg modules so it
can be used in require statements in consumer code that is also under
development.
The updated direct dependencies are as follows:
- github.com/decred/dcrd/blockchain/stake/v4 v4.0.0-20210906140327-598bf66f24a6
- github.com/decred/dcrd/chaincfg/v3 v3.0.1-0.20210906134819-8c0e8616ebda
- This updates the spend pruner to use a single notification
channel to keep the order and processing of connectiong
and disconnections deterministic.
- The process lock is now held when spend journal entries
being removed by the pruner to ensure.
- The spend pruners lifecycle process uses an unbuffered
channel to recieve and process notifications. Notifications are
sent via goroutines to avoid blocking as a result.
- Comment related wrapping issues have been resolved.
This updates the dcrjson module dependencies, the copyright year in the
files modified since the previous release and serves as a base for
dcrjson/v4.0.0.
The updated direct dependencies in this commit are as follows:
- github.com/decred/dcrd/chaincfg/chainhash@v1.0.3
The full list of updated direct dependencies since the previous
dcrjson/v3.1.0 release are as follows:
- github.com/decred/dcrd/chaincfg/chainhash@v1.0.3
Finally, all modules in the repository are tidied to ensure they are
updated to use the latest versions hoisted forward as a result.
This updates the secp256k1 copyright year in the files modified since
the previous release and serves as a base for dcrec/secp256k1/v4.0.0.
There are no updated direct dependencies in this commit.
The following direct dependencies are no longer required as compared to
the previous dcrec/secp256k1/v3.0.0 release:
- github.com/decred/dcrd/chaincfg/chainhash
This updates the various README.md files, module hierarchy graphviz, and
module hierarchy diagram to reflect the new module version and the
removal of the chaincfg/chainhash dependency.
The current latest code for dcrjson already has breaking changes
compared to the last release and was unfortunately not preceded by
starting a new major version module per the standard process.
Fortunately, the two modules in this repo that use dcrjson, namely
rpcclient and rpc/json/rpctypes, use any of its types directly in their
public API nor have any replacements to the code that contains the
changes that require a new major version, so neither require a major
version bump as a result.
Therefore, this is able to mostly follow the process for introducing
major API breaks as follows:
- Bump the major version in the go.mod of the affected module if not
already done since the last release tag
- Add a replacement to the go.mod in the main module if not already done
since the last release tag
- Update all imports in the repo to use the new major version as
necessary
- Make necessary modifications to allow all other modules to use the new
version in the same commit
