Releases: decred/dcrd
dcrd v1.7.4
davecgh
Dave Collins
This is a patch release of dcrd to support modifications to version 3 of the test network as well as provide some minor improvements related to mining.
Changelog
This patch release consists of 10 commits from 2 contributors which total to 17 files changed, 225 additional lines of code, and 57 deleted lines of code.
All commits since the last release may be viewed on GitHub here and here.
Protocol and network:
- blockchain: Enforce testnet difficulty throttling (decred/dcrd#2979)
- netsync: Improve sync height tracking (decred/dcrd#2985)
Mining:
- mining: Copy regular txns for alternate templates (decred/dcrd#2985)
- server: Send winning tickets when unsynced mining (decred/dcrd#2985)
RPC:
- rpcserver: Return template errors from getwork RPC (decred/dcrd#2985)
Developer-related package and module changes:
- blockchain: Consistency pass for next req dif calc (decred/dcrd#2979)
- main: Use backported blockchain updates (decred/dcrd#2984)
Testing and Quality Assurance:
- build: Update to latest actions and linter (decred/dcrd#2979)
- build: Use recommended golangci-lint installer (decred/dcrd#2984)
Misc:
- release: Bump for 1.7.4 (decred/dcrd#2986)
Code Contributors (alphabetical order):
- Dave Collins
- Jamie Holdstock
dcrd v1.7.2
davecgh
Dave Collins
This is a patch release of dcrd to resolve a rare and hard to hit case when optional indexing is enabled.
Changelog
This patch release consists of 4 commits from 2 contributors which total to 11 files changed, 158 additional lines of code, and 15 deleted lines of code.
All commits since the last release may be viewed on GitHub here and here.
Protocol and network:
- server: Fix syncNotified race (decred/dcrd#2931)
Developer-related package and module changes:
- indexers: fix subscribers race (decred/dcrd#2921)
- main: Use backported blockchain updates (decred/dcrd#2935)
Misc:
- release: Bump for 1.7.2 (decred/dcrd#2936)
Code Contributors (alphabetical order):
- Dave Collins
- Donald Adu-Poku
dcrd v1.7.1
davecgh
Dave Collins
This is a patch release of dcrd which includes the following changes:
- Resolve an issue related to RPC authentication of limited users
Changelog
This patch release consists of 2 commits from 2 contributors which total to 3 files changed, 170 additional lines of code, and 35 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
RPC:
- rpcserver: Fix websocket auth failure (decred/dcrd#2879)
Misc:
- release: Bump for 1.7.1 (decred/dcrd#2880)
Code Contributors (alphabetical order):
- Dave Collins
- 刘昆
dcrd v1.7.0
davecgh
Dave Collins
This is a new major release of dcrd. Some of the key highlights are:
- Four new consensus vote agendas which allow stakeholders to decide whether or not to activate support for the following:
- Reverting the Treasury maximum expenditure policy
- Enforcing explicit version upgrades
- Support for automatic ticket revocations for missed votes
- Changing the Proof-of-Work and Proof-of-Stake subsidy split from 60%/30% to 10%/80%
- Substantially reduced initial sync time
- Major performance enhancements to unspent transaction output handling
- Faster cryptographic signature validation
- Significant improvements to network synchronization
- Support for a configurable assumed valid block
- Block index memory usage reduction
- Asynchronous indexing
- Version 1 block filters removal
- Various updates to the RPC server:
- Additional per-connection read limits
- A more strict cross origin request policy
- A new alternative client authentication mechanism based on TLS certificates
- Availability of the scripting language version for transaction outputs
- Several other notable updates, additions, and removals related to the JSON-RPC API
- New developer modules:
- Age-Partitioned Bloom Filters
- Fixed-Precision Unsigned 256-bit Integers
- Standard Scripts
- Standard Addresses
- Infrastructure improvements
- Quality assurance changes
For those unfamiliar with the voting process in Decred, all code needed in order to support each of the aforementioned consensus changes is already included in this release, however it will remain dormant until the stakeholders vote to activate it.
For reference, the consensus change work for each of the four changes was originally proposed and approved for initial implementation via the following Politeia proposals:
- Decentralized Treasury Spending
- Explicit Version Upgrades Consensus Change
- Automatic Ticket Revocations Consensus Change
- Change PoW/PoS Subsidy Split From 60/30 to 10/80
The following Decred Change Proposals (DCPs) describe the proposed changes in detail and provide full technical specifications:
Upgrade Required
It is extremely important for everyone to upgrade their software to this latest release even if you don't intend to vote in favor of the agendas. This particularly applies to PoW miners as failure to upgrade will result in lost rewards after block height 635775. That is estimated to be around Feb 21st, 2022.
Downgrade Warning
The database format in v1.7.0 is not compatible with previous versions of the software. This only affects downgrades as users upgrading from previous versions will see a one time database migration.
Once this migration has been completed, it will no longer be possible to downgrade to a previous version of the software without having to delete the database and redownload the chain.
The database migration typically takes around 40-50 minutes on HDDs and 20-30 minutes on SSDs.
Notable Changes
Four New Consensus Change Votes
Four new consensus change votes are now available as of this release. After upgrading, stakeholders may set their preferences through their wallet.
Revert Treasury Maximum Expenditure Policy Vote
The first new vote available as of this release has the id reverttreasurypolicy.
The primary goal of this change is to revert the currently active maximum expenditure policy of the decentralized Treasury to the one specified in the original Politeia proposal.
See DCP0007 for the full technical specification.
Explicit Version Upgrades Vote
The second new vote available as of this release has the id explicitverupgrades.
The primary goals of this change are to:
- Provide an easy, reliable, and efficient method for software and hardware to determine exactly which rules should be applied to transaction and script versions
- Further embrace the increased security and other desirable properties that hard forks provide over soft forks
See the following for more details:
Automatic Ticket Revocations Vote
The third new vote available as of this release has the id autorevocations.
The primary goals of this change are to:
- Improve the Decred stakeholder user experience by removing the requirement for stakeholders to manually revoke missed and expired tickets
- Enable the recovery of funds for users who lost their redeem script for the legacy VSP system (before the release of vspd, which removed the need for the redeem script)
See the following for more details:
Change PoW/PoS Subsidy Split to 10/80 Vote
The fourth new vote available as of this release has the id changesubsidysplit.
The proposed modification to the subsidy split is intended to substantially diminish the ability to attack Decred's markets with mined coins and improve decentralization of the issuance process.
See the following for more details:
Substantially Reduced Initial Sync Time
The amount of time it takes to complete the initial chain synchronization process has been substantially reduced. With default settings, it is around 48% faster versus the previous release.
Unspent Transaction Output Overhaul
The way unspent transaction outputs (UTXOs) are handled has been significantly reworked to provide major performance enhancements to both steady-state operation as well as the initial chain sync process as follows:
- Each UTXO is now tracked independently on a per-output basis
- The UTXOs now reside in a dedicated database
- All UTXO reads and writes now make use of a cache
Unspent Transaction Output Cache
All reads and writes of unspent transaction outputs (utxos) now go through a cache that sits on top of the utxo set database which drastically reduces the amount of reading and writing to disk, especially during the initial sync process when a very large number of blocks are being processed in quick succession.
This utxo cache provides significant runtime performance benefits at the cost of some additional memory usage. The maximum size of the cache can be configured with the new --utxocachemaxsize command-line configuration option. The default value is 150 MiB, the minimum value is 25 MiB, and the maximum value is 32768 MiB (32 GiB).
Some key properties of the cache are as follows:
- For reads, the UTXO cache acts as a read-through cache
- All UTXO reads go through the cache
- Cache misses load the missing data from the disk and cache it for future lookups
- For writes, the UTXO cache acts as a write-back cache
- Writes to the cache are acknowledged by the cache immediately, but are only periodically flushed to disk
- Allows intermediate steps to effectively be skipped thereby avoiding the need to write millions of entries to disk
- On average, recent UTXOs are much more likely to be spent in upcoming blocks than older UTXOs, so only the oldest UTXOs are evicted as needed in order to maximize the hit ratio of the cache
- The cache is periodically flushed with conditional eviction:
- When the cache is NOT full, nothing is evicted, but the changes are still written to the disk set to allow for a quicker reconciliation in the case of an unclean shutdown
- When the cache is full, 15% of the oldest UTXOs are evicted
Faster Cryptographic Signature Validation
Some aspects of the underlying crypto code has been updated to further improve its execution speed and reduce the number of memory allocations resulting in about a 1% reduction to signature verification time.
The primary benefits are:
- Improved vote times since blocks and transactions propagate more quickly throughout the network
- Approximately a 2% reduction to the duration of the initial sync process
Significant Improvements to Network Synchronization
The method used to obtain blocks from other peers on the network is now guided entirely by block headers. This provides a wide variety of benefits, but the most notable ones for most users are:
- Faster initial synchronization
- Reduced bandwidth usage
- Enhanced protection against attempted DoS attacks
- Percentage-based progress reporting
- Improved steady state logging
Support for Configurable Assumed Valid Block
This release introduces a new model for deciding when several historical validation checks may be skipped for blocks that are an ancestor of a known good block.
Specifically, a new AssumeValid parameter is now used to specify the aforementioned known good block. The default value of the parameter is updated with each release to a recent block that is part of the main chain.
The default value of the parameter can be overridden with the --assumevalid command-line op...
dcrd v1.7.0-rc2
davecgh
Dave Collins
This is an updated release candidate of dcrd to introduce a minor quality of life change to help prevent WebSocket client disconnections in cases where there is extremely high contention and multi-continent communication.
Changelog
This updated release candidate consists of 1 commit from 1 contributor which total to 2 files changed, 14 additional lines of code, and 7 deleted lines of code.
All commits since the last release candidate may be viewed on GitHub here.
RPC:
- rpcserver: Update websocket ping timeout handling (decred/dcrd#2866)
Code Contributors (alphabetical order):
- Dave Collins
dcrd v1.7.0-rc1
davecgh
Dave Collins
This is a new major release of dcrd. Some of the key highlights are:
- Four new consensus vote agendas which allow stakeholders to decide whether or not to activate support for the following:
- Reverting the Treasury maximum expenditure policy
- Enforcing explicit version upgrades
- Support for automatic ticket revocations for missed votes
- Changing the Proof-of-Work and Proof-of-Stake subsidy split from 60%/30% to 10%/80%
- Substantially reduced initial sync time
- Major performance enhancements to unspent transaction output handling
- Faster cryptographic signature validation
- Significant improvements to network synchronization
- Support for a configurable assumed valid block
- Block index memory usage reduction
- Asynchronous indexing
- Version 1 block filters removal
- Various updates to the RPC server:
- Additional per-connection read limits
- A more strict cross origin request policy
- A new alternative client authentication mechanism based on TLS certificates
- Availability of the scripting language version for transaction outputs
- Several other notable updates, additions, and removals related to the JSON-RPC API
- New developer modules:
- Age-Partitioned Bloom Filters
- Fixed-Precision Unsigned 256-bit Integers
- Standard Scripts
- Standard Addresses
- Infrastructure improvements
- Quality assurance changes
For those unfamiliar with the voting process in Decred, all code needed in order to support each of the aforementioned consensus changes is already included in this release, however it will remain dormant until the stakeholders vote to activate it.
For reference, the consensus change work for each of the four changes was originally proposed and approved for initial implementation via the following Politeia proposals:
- Decentralized Treasury Spending
- Explicit Version Upgrades Consensus Change
- Automatic Ticket Revocations Consensus Change
- Change PoW/PoS Subsidy Split From 60/30 to 10/80
The following Decred Change Proposals (DCPs) describe the proposed changes in detail and provide full technical specifications:
It is important for everyone to upgrade their software to this latest release even if you don't intend to vote in favor of the agenda.
Downgrade Warning
The database format in v1.7.0 is not compatible with previous versions of the software. This only affects downgrades as users upgrading from previous versions will see a one time database migration.
Once this migration has been completed, it will no longer be possible to downgrade to a previous version of the software without having to delete the database and redownload the chain.
The database migration typically takes around 40-50 minutes on HDDs and 20-30 minutes on SSDs.
Notable Changes
Four New Consensus Change Votes
Four new consensus change votes are now available as of this release. After upgrading, stakeholders may set their preferences through their wallet.
Revert Treasury Maximum Expenditure Policy Vote
The first new vote available as of this release has the id reverttreasurypolicy.
The primary goal of this change is to revert the currently active maximum expenditure policy of the decentralized Treasury to the one specified in the original Politeia proposal.
See DCP0007 for the full technical specification.
Explicit Version Upgrades Vote
The second new vote available as of this release has the id explicitverupgrades.
The primary goals of this change are to:
- Provide an easy, reliable, and efficient method for software and hardware to determine exactly which rules should be applied to transaction and script versions
- Further embrace the increased security and other desirable properties that hard forks provide over soft forks
See the following for more details:
Automatic Ticket Revocations Vote
The third new vote available as of this release has the id autorevocations.
The primary goals of this change are to:
- Improve the Decred stakeholder user experience by removing the requirement for stakeholders to manually revoke missed and expired tickets
- Enable the recovery of funds for users who lost their redeem script for the legacy VSP system (before the release of vspd, which removed the need for the redeem script)
See the following for more details:
Change PoW/PoS Subsidy Split to 10/80 Vote
The fourth new vote available as of this release has the id changesubsidysplit.
The proposed modification to the subsidy split is intended to substantially diminish the ability to attack Decred's markets with mined coins and improve decentralization of the issuance process.
See the following for more details:
Substantially Reduced Initial Sync Time
The amount of time it takes to complete the initial chain synchronization process has been substantially reduced. With default settings, it is around 48% faster versus the previous release.
Unspent Transaction Output Overhaul
The way unspent transaction outputs (UTXOs) are handled has been significantly reworked to provide major performance enhancements to both steady-state operation as well as the initial chain sync process as follows:
- Each UTXO is now tracked independently on a per-output basis
- The UTXOs now reside in a dedicated database
- All UTXO reads and writes now make use of a cache
Unspent Transaction Output Cache
All reads and writes of unspent transaction outputs (utxos) now go through a cache that sits on top of the utxo set database which drastically reduces the amount of reading and writing to disk, especially during the initial sync process when a very large number of blocks are being processed in quick succession.
This utxo cache provides significant runtime performance benefits at the cost of some additional memory usage. The maximum size of the cache can be configured with the new --utxocachemaxsize command-line configuration option. The default value is 150 MiB, the minimum value is 25 MiB, and the maximum value is 32768 MiB (32 GiB).
Some key properties of the cache are as follows:
- For reads, the UTXO cache acts as a read-through cache
- All UTXO reads go through the cache
- Cache misses load the missing data from the disk and cache it for future lookups
- For writes, the UTXO cache acts as a write-back cache
- Writes to the cache are acknowledged by the cache immediately, but are only periodically flushed to disk
- Allows intermediate steps to effectively be skipped thereby avoiding the need to write millions of entries to disk
- On average, recent UTXOs are much more likely to be spent in upcoming blocks than older UTXOs, so only the oldest UTXOs are evicted as needed in order to maximize the hit ratio of the cache
- The cache is periodically flushed with conditional eviction:
- When the cache is NOT full, nothing is evicted, but the changes are still written to the disk set to allow for a quicker reconciliation in the case of an unclean shutdown
- When the cache is full, 15% of the oldest UTXOs are evicted
Faster Cryptographic Signature Validation
Some aspects of the underlying crypto code has been updated to further improve its execution speed and reduce the number of memory allocations resulting in about a 1% reduction to signature verification time.
The primary benefits are:
- Improved vote times since blocks and transactions propagate more quickly throughout the network
- Approximately a 2% reduction to the duration of the initial sync process
Significant Improvements to Network Synchronization
The method used to obtain blocks from other peers on the network is now guided entirely by block headers. This provides a wide variety of benefits, but the most notable ones for most users are:
- Faster initial synchronization
- Reduced bandwidth usage
- Enhanced protection against attempted DoS attacks
- Percentage-based progress reporting
- Improved steady state logging
Support for Configurable Assumed Valid Block
This release introduces a new model for deciding when several historical validation checks may be skipped for blocks that are an ancestor of a known good block.
Specifically, a new AssumeValid parameter is now used to specify the aforementioned known good block. The default value of the parameter is updated with each release to a recent block that is part of the main chain.
The default value of the parameter can be overridden with the --assumevalid command-line option by setting it as follows:
--assumevalid=0: Disable the feature resulting in no skipped validation checks--assumevalid=[blockhash]: SetAssumeValidto the specified block hash
S...
dcrd v1.6.2
davecgh
Dave Collins
This is a patch release of dcrd to introduce a quality of life change for lightweight clients, such as SPV wallets, by not sending them a certain class of announcements that only full nodes are equiped to handle.
Changelog
This patch release consists of 2 commits from 1 contributor which total to 3 files changed, 55 additional lines of code, and 31 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
Protocol and network:
- server: Only send fast block anns to full nodes (decred/dcrd#2609)
Misc:
- release: Bump for 1.6.2 (decred/dcrd#2629)
Code Contributors (alphabetical order):
- Dave Collins
dcrd v1.6.1
davecgh
Dave Collins
This is a patch release of dcrd which includes the following changes:
- Correct a hard to hit issue where connections might not be reestablished after a network outage under some rare circumstances
- Allow stakeholders to make use of the staking system to force proof-of-work miners to upgrade to the latest version so voting on the new consensus changes can commence
Changelog
This patch release consists of 3 commits from 1 contributor which total to 3 files changed, 30 additional lines of code, and 9 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
Protocol and network:
- server: Notify block mgr later and track ntfn (decred/dcrd#2588)
- server: Force PoW upgrade to v8 (decred/dcrd#2597)
Misc:
- release: Bump for 1.6.1 (decred/dcrd#2600)
Code Contributors (alphabetical order):
- Dave Collins
dcrd v1.6.0
davecgh
Dave Collins
This release of dcrd introduces a large number of updates. Some of the key highlights are:
- A new consensus vote agenda which allows the stakeholders to decide whether or not to activate support for a decentralized treasury
- Aggregate fee transaction selection in block templates (Child Pays For Parent)
- Improved peer discovery via HTTPS seeding with filtering capabilities
- Major performance enhancements for signature validation and other cryptographic operations
- Approximately 15% less overall resident memory usage
- Proactive signature cache eviction
- Improved support for single-party Schnorr signatures
- Ticket exhaustion prevention
- Various updates to the RPC server such as:
- A new method to retrieve the current treasury balance
- A new method to query treasury spend transaction vote details
- Infrastructure improvements
- Quality assurance changes
For those unfamiliar with the voting process in Decred, all code needed in order to support a decentralized treasury is already included in this release, however it will remain dormant until the stakeholders vote to activate it.
For reference, the decentralized treasury work was originally proposed and approved for initial implementation via the following Politeia proposal:
The following Decred Change Proposal (DCP) describes the proposed changes in detail and provides a full technical specification:
It is important for everyone to upgrade their software to this latest release even if you don't intend to vote in favor of the agenda.
Downgrade Warning
The database format in v1.6.0 is not compatible with previous versions of the software. This only affects downgrades as users upgrading from previous versions will see a one time database migration.
Once this migration has been completed, it will no longer be possible to downgrade to a previous version of the software without having to delete the database and redownload the chain.
The database migration typically takes about 5 to 10 minutes on HDDs and 2 to 4 minutes on SSDs.
Notable Changes
Decentralized Treasury Vote
A new vote with the id treasury is now available as of this release. After upgrading, stakeholders may set their preferences through their wallet or Voting Service Provider's (VSP) website.
The primary goal of this change is to fully decentralize treasury spending so that it is controlled by the stakeholders via ticket voting.
See the initial Politeia proposal for more details.
Aggregate Fee Block Template Transaction Selection (Child Pays For Parent)
The transactions that are selected for inclusion in block templates that Proof-of-Work miners solve now prioritize the overall fees of the entire
transaction ancestor graph.
This is beneficial for both miners and end users as it:
- Helps maximize miner profit by ensuring that unconfirmed transaction chains with higher aggregate fees are given priority over others with lower aggregate fees
- Provides a mechanism for users to increase the priority of an unconfirmed transaction by spending its outputs with another transaction that pays higher fees
This is commonly referred to as Child Pays For Parent (CPFP) as the spending ("child") transaction is able to increase the priority of the spent ("parent") transaction.
HTTPS Seeding
The initial bootstrap process that contacts seeders to discover other nodes to connect to now uses a REST-based API over HTTPS.
This change will be imperceptible for most users, with the exception that it accelerates the process of finding suitable candidate nodes that support desired services, particularly in the case of recently-introduced services that have not yet achieved widespread adoption on the network.
The following are some key benefits of HTTPS seeders over the previous DNS-based seeders:
- Support for non-standard ports
- Advertisement of supported service
- Better scalability both in terms of network load and new features
- Native support for TLS-secured communication channels
- Native support for proxies which allows the use of anonymous overlay networks such as Tor and I2P
- No need for a large DNSSEC dependency surface
- Uses better audited infrastructure
- More secure
- Increases flexibility
Signature Validation And Other Crypto Operation Optimizations
The underlying crypto code has been reworked to significantly improve its execution speed and reduce the number of memory allocations. While this has more benefits than enumerated here, probably the most important ones for most stakeholders are:
- Improved vote times since blocks and transactions propagate more quickly throughout the network
- The initial sync process is around 15% faster
Proactive Signature Cache Eviction
Signature cache entries that are nearly guaranteed to no longer be useful are now immediately and proactively evicted resulting in overall faster validation during steady state operation due to fewer cache misses.
The primary purpose of the cache is to avoid double checking signatures that are already known to be valid.
Orphan Transaction Relay Policy Refinement
Transactions that spend outputs which are not known to nodes relaying them, known as orphan transactions, now have the same size restrictions applied to them as standard non-orphan transactions.
This ensures that transactions chains are not artificially hindered from relaying regardless of the order they are received.
In order to keep memory usage of the now potentially larger orphan transactions under control, more intelligent orphan eviction has been implemented and the maximum number of allowed orphans before random eviction occurs has been lowered.
These changes, in conjunction with other related changes, mean that nodes are better about orphan transaction management and thus missing ancestors will typically either be broadcast or mined fairly quickly resulting in fewer overall orphans and smaller actual run-time orphan pools.
Ticket Exhaustion Prevention
Mining templates that would lead to the chain becoming unrecoverable due to inevitable ticket exhaustion will no longer be generated.
This is primarily aimed at the testing networks, but it could also theoretically affect the main network in some far future if the demand for tickets were to ever dry up for some unforeseen reason.
New Initial State Protocol Messages (getinitstate/initstate)
This release introduces a pair of peer-to-peer protocol messages named getinitstate and initstate which support querying one or more pieces of information that are useful to acquire when a node first connects in a consolidated fashion.
Some examples of the aforementioned information are the mining state as of the current tip block and, with the introduction of the decentralized treasury, any outstanding treasury spend transactions that are being voted on.
Mining State Protocol Messages Deprecated (getminings/minings)
Due to the addition of the previously-described initial state peer-to-peer protocol messages, the getminings and minings protocol messages are now deprecated. Use the new getinitstate and initstate messages with the headblocks and headblockvotes state types instead.
RPC Server Changes
The RPC server version as of this release is 6.2.0.
New Treasury Balance Query RPC (gettreasurybalance)
A new RPC named gettreasurybalance is now available to query the current balance of the decentralized treasury. Please note that this requires the decentralized treasury vote to pass and become active, so it will return an appropriate error indicating the decentralized treasury is inactive until that time.
See the gettreasurybalance JSON-RPC API Documentation for API details.
New Treasury Spend Vote Query RPC (gettreasuryspendvotes)
A new RPC named gettreasuryspendvotes is now available to query vote information about one or more treasury spend transactions. Please note that this requires the decentralized treasury vote to pass and become active to produce a meaningful result since treasury spend transactions are invalid until that time.
See the gettreasuryspendvotes JSON-RPC API Documentation for API details.
New Force Mining Template Regeneration RPC (regentemplate)
A new RPC named regentemplate is now available which can be used to force the current background block template to be regenerated.
See the regentemplate JSON-RPC API Documentation for API details.
New Unspent Transaction Output Set Query RPC (gettxoutsetinfo)
A new RPC named gettxoutsetinfo is now available which can be used to retrieve statistics about the current global set of unspent transaction outputs (UTXOs).
See the gettxoutsetinfo JSON-RPC API Documentation for API details.
Updates to Peer Information Query RPC (getpeerinfo)
The results of the getpeerinfo RPC are now sorted by the id field.
See the getpeerinfo JSON-RPC API Documentation for API details.
Enforced Results Limit on Transacti...
dcrd v1.6.0-rc5
davecgh
Dave Collins
This release of dcrd introduces a large number of updates. Some of the key highlights are:
- A new consensus vote agenda which allows the stakeholders to decide whether or not to activate support for a decentralized treasury
- Aggregate fee transaction selection in block templates (Child Pays For Parent)
- Improved peer discovery via HTTPS seeding with filtering capabilities
- Major performance enhancements for signature validation and other cryptographic operations
- Approximately 15% less overall resident memory usage
- Proactive signature cache eviction
- Improved support for single-party Schnorr signatures
- Ticket exhaustion prevention
- Various updates to the RPC server such as:
- A new method to retrieve the current treasury balance
- A new method to query treasury spend transaction vote details
- Infrastructure improvements
- Quality assurance changes
For those unfamiliar with the voting process in Decred, all code needed in order to support a decentralized treasury is already included in this release, however it will remain dormant until the stakeholders vote to activate it.
For reference, the decentralized treasury work was originally proposed and approved for initial implementation via the following Politeia proposal:
The following Decred Change Proposal (DCP) describes the proposed changes in detail and provides a full technical specification:
It is important for everyone to upgrade their software to this latest release even if you don't intend to vote in favor of the agenda.
Downgrade Warning
The database format in v1.6.0 is not compatible with previous versions of the software. This only affects downgrades as users upgrading from previous versions will see a one time database migration.
Once this migration has been completed, it will no longer be possible to downgrade to a previous version of the software without having to delete the database and redownload the chain.
The database migration typically takes about 5 to 10 minutes on HDDs and 2 to 4 minutes on SSDs.
Notable Changes
Decentralized Treasury Vote
A new vote with the id treasury is now available as of this release. After upgrading, stakeholders may set their preferences through their wallet or Voting Service Provider's (VSP) website.
The primary goal of this change is to fully decentralize treasury spending so that it is controlled by the stakeholders via ticket voting.
See the initial Politeia proposal for more details.
Aggregate Fee Block Template Transaction Selection (Child Pays For Parent)
The transactions that are selected for inclusion in block templates that Proof-of-Work miners solve now prioritize the overall fees of the entire
transaction ancestor graph.
This is beneficial for both miners and end users as it:
- Helps maximize miner profit by ensuring that unconfirmed transaction chains with higher aggregate fees are given priority over others with lower aggregate fees
- Provides a mechanism for users to increase the priority of an unconfirmed transaction by spending its outputs with another transaction that pays higher fees
This is commonly referred to as Child Pays For Parent (CPFP) as the spending ("child") transaction is able to increase the priority of the spent ("parent") transaction.
HTTPS Seeding
The initial bootstrap process that contacts seeders to discover other nodes to connect to now uses a REST-based API over HTTPS.
This change will be imperceptible for most users, with the exception that it accelerates the process of finding suitable candidate nodes that support desired services, particularly in the case of recently-introduced services that have not yet achieved widespread adoption on the network.
The following are some key benefits of HTTPS seeders over the previous DNS-based seeders:
- Support for non-standard ports
- Advertisement of supported service
- Better scalability both in terms of network load and new features
- Native support for TLS-secured communication channels
- Native support for proxies which allows the use of anonymous overlay networks such as Tor and I2P
- No need for a large DNSSEC dependency surface
- Uses better audited infrastructure
- More secure
- Increases flexibility
Signature Validation And Other Crypto Operation Optimizations
The underlying crypto code has been reworked to significantly improve its execution speed and reduce the number of memory allocations. While this has more benefits than enumerated here, probably the most important ones for most stakeholders are:
- Improved vote times since blocks and transactions propagate more quickly throughout the network
- The initial sync process is around 15% faster
Proactive Signature Cache Eviction
Signature cache entries that are nearly guaranteed to no longer be useful are now immediately and proactively evicted resulting in overall faster validation during steady state operation due to fewer cache misses.
The primary purpose of the cache is to avoid double checking signatures that are already known to be valid.
Orphan Transaction Relay Policy Refinement
Transactions that spend outputs which are not known to nodes relaying them, known as orphan transactions, now have the same size restrictions applied to them as standard non-orphan transactions.
This ensures that transactions chains are not artificially hindered from relaying regardless of the order they are received.
In order to keep memory usage of the now potentially larger orphan transactions under control, more intelligent orphan eviction has been implemented and the maximum number of allowed orphans before random eviction occurs has been lowered.
These changes, in conjunction with other related changes, mean that nodes are better about orphan transaction management and thus missing ancestors will typically either be broadcast or mined fairly quickly resulting in fewer overall orphans and smaller actual run-time orphan pools.
Ticket Exhaustion Prevention
Mining templates that would lead to the chain becoming unrecoverable due to inevitable ticket exhaustion will no longer be generated.
This is primarily aimed at the testing networks, but it could also theoretically affect the main network in some far future if the demand for tickets were to ever dry up for some unforeseen reason.
New Initial State Protocol Messages (getinitstate/initstate)
This release introduces a pair of peer-to-peer protocol messages named getinitstate and initstate which support querying one or more pieces of information that are useful to acquire when a node first connects in a consolidated fashion.
Some examples of the aforementioned information are the mining state as of the current tip block and, with the introduction of the decentralized treasury, any outstanding treasury spend transactions that are being voted on.
Mining State Protocol Messages Deprecated (getminings/minings)
Due to the addition of the previously-described initial state peer-to-peer protocol messages, the getminings and minings protocol messages are now deprecated. Use the new getinitstate and initstate messages with the headblocks and headblockvotes state types instead.
RPC Server Changes
The RPC server version as of this release is 6.2.0.
New Treasury Balance Query RPC (gettreasurybalance)
A new RPC named gettreasurybalance is now available to query the current balance of the decentralized treasury. Please note that this requires the decentralized treasury vote to pass and become active, so it will return an appropriate error indicating the decentralized treasury is inactive until that time.
See the gettreasurybalance JSON-RPC API Documentation for API details.
New Treasury Spend Vote Query RPC (gettreasuryspendvotes)
A new RPC named gettreasuryspendvotes is now available to query vote information about one or more treasury spend transactions. Please note that this requires the decentralized treasury vote to pass and become active to produce a meaningful result since treasury spend transactions are invalid until that time.
See the gettreasuryspendvotes JSON-RPC API Documentation for API details.
New Force Mining Template Regeneration RPC (regentemplate)
A new RPC named regentemplate is now available which can be used to force the current background block template to be regenerated.
See the regentemplate JSON-RPC API Documentation for API details.
New Unspent Transaction Output Set Query RPC (gettxoutsetinfo)
A new RPC named gettxoutsetinfo is now available which can be used to retrieve statistics about the current global set of unspent transaction outputs (UTXOs).
See the gettxoutsetinfo JSON-RPC API Documentation for API details.
Updates to Peer Information Query RPC (getpeerinfo)
The results of the getpeerinfo RPC are now sorted by the id field.
See the getpeerinfo JSON-RPC API Documentation for API details.