Releases: decred/dcrd
dcrd v1.8.1
davecgh
Dave Collins
This is a patch release of dcrd that includes some updates to the RPC server and JSON-RPC API in light of the changes made by DCP0011 as follows:
- The
getblockandgetblockheaderRPCs now have an additionalpowhashfield for the new Proof-of-Work hash - The
getnetworkhashpsRPC now treats -1 for the blocks parameter as the default number of blocks versus the previous behavior that is no longer applicable to the new difficulty adjustment algorithm
The RPC server version as of this release is 8.1.0.
Changelog
This patch release consists of 5 commits from 2 contributors which total to 7 files changed, 47 additional lines of code, and 29 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
RPC:
- rpc: Add PoWHash to getblock/getblockheader (verbose) results (decred/dcrd#3192)
- rpcserver: Modify getnetworkhashps -1 blocks logic (decred/dcrd#3193)
Developer-related package and module changes:
- jsonrpc/types: Add powhash to verbose block output (decred/dcrd#3192)
- main: Use backported rpc types updates (decred/dcrd#3192)
Misc:
- release: Bump for 1.8.1 (decred/dcrd#3194)
Code Contributors (alphabetical order):
- Dave Collins
- Jonathan Chappelow
dcrd v1.8.0
davecgh
Dave Collins
This is a new major release of dcrd. Some of the key highlights are:
- Two new consensus vote agendas which allow stakeholders to decide whether or
not to activate support for the following:- Changing the Proof-of-Work hashing algorithm to BLAKE3 and the difficulty algorithm to ASERT
- Changing the Proof-of-Work and Proof-of-Stake subsidy split from 10%/80% to 1%/89%
- Separation of block hash from Proof-of-Work hash
- BLAKE3 CPU mining support
- Initial sync time reduced by about 20%
- Runtime memory management optimizations
- Faster cryptographic signature validation
- Low fee transaction rejection
- Unspent transaction output set size reduction
- No more checkpoints
- Improved network protocol message responsiveness
- Header proof commitment hash storage
- Address index removal
- Several CLI options deprecated
- Various updates to the RPC server:
- Total coin supply output correction
- More stable global communication over WebSockets
- Winning ticket notifications when unsynced mining on test networks
- Several other notable updates, additions, and removals related to the JSON-RPC API
- Infrastructure improvements
- Miscellaneous network and protocol optimizations
- 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 was originally proposed and approved for initial implementation via the following Politeia proposal:
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 agenda. This particularly applies to PoW miners as failure to upgrade will result in lost rewards after block height 777240. That is estimated to be around June 29th, 2023.
Downgrade Warning
The database format in v1.8.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 4-6 minutes on HDDs and 2-3 minutes on SSDs.
Notable Changes
Two New Consensus Change Votes
Two new consensus change votes are now available as of this release. After upgrading, stakeholders may set their preferences through their wallet.
Change PoW to BLAKE3 and ASERT
The first new vote available as of this release has the id blake3pow.
The primary goals of this change are to:
- Increase decentralization of proof of work mining by obsoleting the current specialized hardware (ASICs) that is only realistically available to the existing highly centralized mining monopoly
- Improve the proof of work mining difficulty adjustment algorithm responsiveness
- Provide more equal profitability to steady state PoW miners versus hit and run miners
See the following for more details:
Change PoW/PoS Subsidy Split to 1/89 Vote
The second new vote available as of this release has the id changesubsidysplitr2.
The proposed modification to the subsidy split in tandem with the change to the PoW hashing function is intended to break up the mining cartel and further improve decentralization of the issuance process.
See the following for more details:
Separation of Block Hash from Proof-of-Work Hash
A new Proof-of-Work (PoW) hash that is distinct from the existing block hash is now used for all consensus rules related to PoW verification.
Block hashes have historically served multiple roles which include those related to proof of work (PoW). As of this release, the roles related to PoW are now solely the domain of the new PoW hash.
Some key points related to this change are:
- The new PoW hash will be exactly the same as the existing block hash for all blocks prior to the activation of the stakeholder vote to change the PoW hashing algorithm
- The block hash continues to use the existing hashing algorithm
- The block hash will no longer have the typical pattern of leading zeros upon activation of the PoW hashing algorithm
- The PoW hash will have the typical pattern of leading zeros both before and after the activation of the new PoW hashing algorithm
BLAKE3 CPU Mining Support
The internal CPU miner has been significantly optimized to provide much higher hash rates, especially when using multiple cores, and now automatically mines using the BLAKE3 algorithm when the blake3pow agenda is active.
Initial Sync Time Reduced by About 20%
The amount of time it takes to complete the initial chain synchronization process with default settings has been reduced by about 20% versus the previous release.
Runtime Memory Management Optimizations
The way memory is managed has been optimized to provide performance enhancements to both steady-state operation as well as the initial chain sync process.
The primary benefits are:
- Lower maximum memory usage during transient periods of high demand
- Approximately a 10% reduction to the duration of the initial sync process
- Significantly reduced overall total memory allocations (~42%)
- Less overall CPU usage for the same amount of work
Faster Cryptographic Signature Validation
Similar to the previous release, this release further improves some aspects of the underlying crypto code to increase its execution speed and reduce the number of memory allocations. The overall result is a 52% reduction in allocations and about a 1% reduction to the verification time for a single signature.
The primary benefits are:
- Improved vote times since blocks and transactions propagate more quickly throughout the network
- Approximately a 4% reduction to the duration of the initial sync process
Low Fee Transaction Rejection
The default transaction acceptance and relay policy is no longer based on priority and instead now immediately rejects all transactions that do not pay the minimum required fee.
This provides a better user experience for transactions that do not pay enough fees.
For some insight into the motivation for this change, prior to the introduction of support for child pays for parent (CPFP), it was possible for transactions to essentially become stuck forever if they didn't pay a high enough fee for miners to include them in a block.
In order to prevent this, a policy was introduced that allowed relaying transactions that do not pay enough fees based on a priority calculated from the fee as well as the age of coins being spent. The result is that the priority slowly increased over time as the coins aged to ensure such transactions would eventually be relayed and mined. In order to prevent abuse the behavior could otherwise allow, the policy also included additional rate-limiting of these types of transactions.
While the policy served its purpose, it had some downsides such as:
- A confusing user experience where transactions that do not pay enough fees and also are not old enough to meet the dynamically changing priority requirements are rejected due to having insufficient priority instead of not paying enough fees as the user might expect
- The priority requirements dynamically change over time which leads to non-deterministic behavior and thus ultimately results in what appear to be intermittent/transient failures to users
The policy is no longer necessary or desirable given such transactions can now use CPFP to increase the overall fee of the entire transaction chain thereby ensuring they are mined.
Unspent Transaction Output Set Size Reduction
The set of all unspent transaction outputs (UTXO set) no longer contains unspendable treasurybase outputs.
A treasurybase output is a special output that increases the balance of the decentralized treasury account which requires stakeholder approval to spend funds. As a result, they do not operate like normal transaction outputs and therefore are never directly spendable.
Removing these unspendable outputs from the UTXO set reduces its overall size.
No More Checkpoints
This release introduces a new model for deciding when to reject old forks to make use of the hard-coded assumed valid block that is updated with each release to a recent block thereby removing the final remaining usage of checkpoints.
Consequently, the --nocheckpoints command-line option and separate findcheckpoints utility have been removed.
Improved Network Protocol Message Responsiveness (getheaders/getcfilterv2)
All protocol message requests for headers (getheaders) and version 2 compact filters (getcfilterv2) will now receive empty responses when there is not any available data or the peer is o...
dcrd v1.7.7
davecgh
Dave Collins
This is a patch release of dcrd that includes the following changes:
- Use the latest network protocol version
- Reduce bandwidth usage in certain scenarios by avoiding requests for inventory that is already known
- Mitigate excessive CPU usage in some rare scenarios specific to the test network
- Improve best address candidate selection efficiency
Changelog
This patch release consists of 19 commits from 3 contributors which total to 92 files changed, 1357 additional lines of code, and 1191 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
Protocol and network:
- peer: Use latest pver by default (decred/dcrd#3083)
- peer: Correct known inventory check (decred/dcrd#3083)
Documentation:
- peer: Go 1.19 doc comment formatting (decred/dcrd#3083)
- addrmgr: Go 1.19 doc comment formatting (decred/dcrd#3084)
- multi: Go 1.19 doc comment formatting (decred/dcrd#3087)
- docs: Update README.md to required Go 1.19/1.20 (decred/dcrd#3087)
Developer-related package and module changes:
- peer: Support module graph prune and lazy load (decred/dcrd#3083)
- main: Use backported peer updates (decred/dcrd#3083)
- addmrgr: Use TempDir to create temp test dirs (decred/dcrd#3084)
- addrmgr: Support module graph prune and lazy load (decred/dcrd#3084)
- addrmgr: Break after selecting random address (decred/dcrd#3084)
- addrmgr: Set min value and optimize address chance (decred/dcrd#3084)
- main: Use backported addrmgr updates (decred/dcrd#3084)
- main: Update to use latest sys module (decred/dcrd#3087)
Testing and Quality Assurance:
- build: Enable run_tests.sh to work with go.work (decred/dcrd#3087)
- build: Update to latest action versions (decred/dcrd#3087)
- build: Update golangci-lint to v1.51.1 (decred/dcrd#3087)
- build: Test against Go 1.20 (decred/dcrd#3087)
Misc:
- release: Bump for 1.7.7 (decred/dcrd#3085)
Code Contributors (alphabetical order):
- Dave Collins
- Eng Zer Jun
- Jonathan Chappelow
dcrd v1.7.5
davecgh
Dave Collins
This is a patch release of dcrd that updates the utxo cache to improve its robustness, optimize it, and correct some hard to hit corner cases that involve a mix of manual block invalidation, conditional flushing, and successive unclean shutdowns.
Changelog
This patch release consists of 19 commits from 1 contributor which total to 13 files changed, 1118 additional lines of code, and 484 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
Developer-related package and module changes:
- blockchain: Misc consistency cleanup pass (decred/dcrd#3006)
- blockchain: Pre-allocate in-flight utxoview tx map (decred/dcrd#3006)
- blockchain: Remove unused utxo cache add entry err (decred/dcrd#3006)
- blockchain: Fix rare unclean utxo cache recovery (decred/dcrd#3006)
- blockchain: Don't fetch trsy{base,spend} inputs (decred/dcrd#3006)
- blockchain: Don't add treasurybase utxos (decred/dcrd#3006)
- blockchain: Separate utxo cache vs view state (decred/dcrd#3006)
- blockchain: Improve utxo cache spend robustness (decred/dcrd#3006)
- blockchain: Split regular/stake view tx connect (decred/dcrd#3006)
- blockchain: Bypass utxo cache for zero conf spends (decred/dcrd#3006)
- main: Use backported blockchain updates (decred/dcrd#3007)
Testing and Quality Assurance:
- blockchain: Address some linter complaints (decred/dcrd#3005)
- blockchain: Allow tests to override cache flushing (decred/dcrd#3006)
- blockchain: Improve utxo cache initialize tests (decred/dcrd#3006)
- blockchain: Consolidate utxo cache test entries (decred/dcrd#3006)
- blockchain: Rework utxo cache spend entry tests (decred/dcrd#3006)
- blockchain: Rework utxo cache commit tests (decred/dcrd#3006)
- blockchain: Rework utxo cache add entry tests (decred/dcrd#3006)
Misc:
- release: Bump for 1.7.5 (decred/dcrd#3008)
Code Contributors (alphabetical order):
- Dave Collins
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...