This adds AFAutoRevocationsEnabled to blockchain.AgendaFlags, which may
be set to indicate that the automatic ticket revocations agenda should
be considered as active when checking a transaction so that any
additional checks which depend on the agenda being active are applied.
Additionally, this updates all references of blockchain.AgendaFlags to
set AFAutoRevocationsEnabled if the automatic ticket revocations agenda
is active.
This adds tests to ensure that ticket output amounts are calculated
correctly under a variety of conditions.
Additionally, it cleans up the code, naming, and documentation to be
more consistent with the consensus code that defines the rules that this
is following.
This removes the handling for a configurable maximum allowed transaction
version via the standardness policy since it is now enforced via
consensus rules instead.
The following is an overview of the changes:
- Remove the MaxTxVersion field from the Policy struct
- Remove the max tx version checking logic from checkTransactionStandard
- Remove the max tx version param from checkTransactionStandard
- Update the transaction standardness tests accordingly
- Update all callers accordingly
This adds enforcement of the newly introduced explicit version upgrade
requirements when considering candidate transactions for acceptance to
the mempool, relaying, and inclusion into block templates.
This is acceptable because the aforementioned areas only enforce policy.
Also of note is that the existing policy already rejected transactions
via the standardness policy that will now be rejected at a consensus
level.
It also adds tests to ensure the new enforcement works as intended.
This implements the agenda for voting on rejecting new script versions
until they have explicitly been enabled by a consensus rule change as
defined in DCP0008 along with consensus tests.
In particular, once the vote has passed and is active, script versions
greater than 0 will no longer be accepted.
Note that this does not implement block version bumps in the mining and
validation code that will ultimately be needed since another consensus
vote is expected to land before voting begins.
The following is an overview of the changes:
- Modify block validation to enforce the rejection of newer script
versions in accordance with the state of the vote
- Add tests to ensure proper behavior for new script versions as follows:
- Ensure stake transactions still require version 0 scripts regardless
of the state of the agenda
- Regular transactions with script versions newer than 0 are rejected
once the agenda is active
- Transaction outputs that have a non-zero output and script that
would make the output unspendable if it were version 0 are spendable
with a nil signature script both before the agenda is active and
remain spendable after it is active
This implements the agenda for voting on rejecting new transaction
versions until they have explicitly been enabled by a consensus rule
change as defined in DCP0008 along with consensus tests.
In particular, once the vote has passed and is active, transaction
versions greater than 3 will no longer be accepted.
This does not include the script version portion of the DCP as that will
be done in a future commit. This implies that it is important for both
this commit and the aforementioned future commit to be merged at the
same time.
Also note that this does not implement block version bumps in the mining
and validation code that will ultimately be needed since another
consensus vote is expected to land before voting begins.
The following is an overview of the changes:
- Introduce a convenience function for determining if the vote passed
and is now active
- Modify block validation to enforce the rejection of newer transaction
versions in accordance with the state of the vote
- Add tests for determining if the agenda is active for both mainnet and
testnet
- Add tests to ensure proper behavior for new transaction versions as follows:
- New regular and stake transaction versions are rejected once the
agenda is active
- Existing regular and stake outputs created with newer tx versions
are spendable before the agenda is active and remain spendable after
it is active
This consolidates the logic for constructing the agenda flags to use for
checking transactions into a separate method versus building them inline
in multiple different places.
This makes it easier to add new agendas in the future while keeping the
flags consistent.
This adds some additional text to the section regarding why running a
full node is desirable to specifically call out that it is also ideal
for providing the most reliable and accurate data about transactions.
As of go 1.16, "go build" and "go test" now exit with an error rather
than silently modifying go.mod or go.sum files. As a result, we don't
need to manually check for altered mod/sum files in the test script.
This modifies CreateTicketPurchase to accept a spendable output (instead
of a transaction) as well as munge functions similar to how
CreateSignedTx works and then introduces a new method named
CreateTicketPurchaseFromTx which keeps the existing signature and is
defined in terms of the aforementioned.
This allows the test code to more easily mutate the transactions as
desired prior to them being signed which provides greater flexibility.
This adds the three currently missing config values related to logging
to the "Debug" section of the sample config, and renames the section
to "Logging" instead.
The description of the debuglevel option is also modified to describe
it as configuring the log verbosity, since it is not only related to
enabling debug logs.
This adds the ability to snapshot the current spendable coinbase output
state of the generator with a name and restore it later. This will
allow more efficient tests to be created since they will be able to use
invalidation along with restoring the spendable outputs state to avoid
the need to go through the entire vote activation process multiple
times.
This adds a new definition for the upcoming agenda vote to reject new
transaction and script versions until they are explicitly enabled via a
consensus vote as defined by DCP0008. It does not include any code to
make decisions or bump the versions. It is only the definition.
This reworks the createrawssrtx handler to use the
CreateRevocationFromTicket function from the stake package rather than
creating the transaction directly.
It also adds additional error handling on the transaction input:
- The input must be a ticket submission output (output index 0)
- The input amount must equal the ticket submission amount
The logsize option enables configuration of the currently-hardcoded
value of 10MiB log files before they are rotated and compressed. The
default remains 10MiB.
This is a string option and requires using a suffix such as K, M, or
G to specify the units as kibibytes, mebibytes, or gibibytes.
This adds a FetchUtxoEntry method to the mining Config. This allows the
template generation logic to fetch unspent transaction outputs from the
point of view of the main chain tip. This has not been necessary in the
past since typically, the mining code uses FetchUtxoView to construct a
viewpoint for transactions that it includes in a block template.
However, with the automatic ticket revocations agenda, the template
generation code will need to create new revocation transactions, which
will require fetching utxos for the input tickets.
This adds a NextExpiringTickets field to the BestState type, which
represents the tickets that will expire in the next block. This allows
consumers, such as mining template generation, to determine the tickets
that are about to expire when validating or constructing a new block.
This will be used for the automatic ticket revocations agenda since one
of the new rules for that agenda is that blocks must contain revocations
for expired tickets in the block that they become expired.
This combines the checkAllowedVotes and checkAllowedRevocations
methods into a checkTicketRedeemers function. This reduces the number
of iterations through the stake transactions and subsequently reduces
the number of checks to determine the stake transaction type.
Further, additional validation rules for the votes and revocations in a
block will be added to this method for the upcoming automatic ticket
revocations agenda.
Attempting to publish a recently-mined transaction using the
sendrawtransaction JSON-RPC method will now use the same error code as
for duplicate transactions currently present in the mempool, rather
than a generic error for double spending or spending unknown inputs.
There is a very small chance that this check results in a false
positive and that a transaction rejected for other reasons is reported
as a duplicate when it had never been mined at all.
This allows returning the P2P address of the given harness node, which
is needed when trying to test third party services that connect via the
P2P network via rpctest (e.g. SPV wallets).
This adds an ExpiringNextBlock method on the Node type, which returns
the tickets that will expire in the next block. This allows consumers
to determine the tickets that are about to expire when validating or
constructing a new block.
This will be used for the automatic ticket revocations agenda since one
of the new rules for that agenda is that blocks must contain revocations
for expired tickets in the block that they become expired.
This changes the amount used for the large tspend in the rpc treasury
simnet test so that it is compatible to the new expenditure policy and
fails as expected.
This renames the existing maxTreasuryExpenditure function to
maxTreasuryExpenditureDCP0006 to identify it as the one implementing the
legacy policy.
A future commit will add a new policy and selection of the active one
will be based on the results of an on-chain voting.
This switches the current blockchain go.mod file to use a replace
directive for the chaincfg code, which is needed due to the new agenda
introduced in a previous commit.
