Releases: decred/dcrd
dcrd v1.6.0-rc4
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-rc3
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.1.2.
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-rc2
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.1.2.
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 Transa...
dcrd v1.6.0-rc1.1
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.1.2.
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.5.2
dcrd v1.5.2
This is a patch release of dcrd to address a potential denial of service vector.
Changelog
This patch release consists of 5 commits from 2 contributors which total to 4 files changed, 114 additional lines of code, and 20 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
Protocol and network:
- blockmanager: handle notfound messages from peers (decred/dcrd#2344)
- blockmanager: limit the requested maps (decred/dcrd#2344)
- server: increase ban score for notfound messages (decred/dcrd#2344)
- server: return whether addBanScore disconnected the peer (decred/dcrd#2344)
Misc:
- release: Bump for 1.5.2(decred/dcrd#2345)
Code Contributors (alphabetical order):
- Dave Collins
- David Hill
dcrd v1.5.1
dcrd v1.5.1
This is a patch release of dcrd to address a minor memory leak with authenticated RPC websocket clients on intermittent connections. It also updates the dcrctl
utility to include the new auditreuse
dcrwallet command.
Changelog
This patch release consists of 4 commits from 3 contributors which total to 4 files changed, 27 additional lines of code, and 6 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
RPC:
- rpcwebsocket: Remove client from missed maps (decred/dcrd#2049)
- rpcwebsocket: Use nonblocking messages and ntfns (decred/dcrd#2050)
dcrctl utility changes:
- dcrctl: Update dcrwallet RPC types package (decred/dcrd#2051)
Misc:
- release: Bump for 1.5.1(decred/dcrd#2052)
Code Contributors (alphabetical order):
- Dave Collins
- Josh Rickmar
- Matheus Degiovani
dcrd v1.5.0
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 block header commitments
- More efficient block filters
- Significant improvements to the mining infrastructure including asynchronous work notifications
- Major performance enhancements for transaction script validation
- Automatic external IP address discovery
- Support for IPv6 over Tor
- Various updates to the RPC server such as:
- A new method to query information about the network
- A method to retrieve the new version 2 block filters
- More calls available to limited access users
- Infrastructure improvements
- Quality assurance changes
For those unfamiliar with the voting process in Decred, all code in order to support block header commitments is already included in this release, however its enforcement will remain dormant until the stakeholders vote to activate it.
For reference, block header commitments were 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.5.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.
Notable Changes
Block Header Commitments Vote
A new vote with the id headercommitments
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 increase the security and efficiency of lightweight clients, such as Decrediton in its lightweight mode and the dcrandroid/dcrios mobile wallets, as well as add infrastructure that paves the
way for several future scalability enhancements.
A high level overview aimed at a general audience including a cost benefit analysis can be found in the Politeia proposal.
In addition, a much more in-depth treatment can be found in the motivation section of DCP0005.
Version 2 Block Filters
The block filters used by lightweight clients, such as SPV (Simplified Payment Verification) wallets, have been updated to improve their efficiency, ergonomics, and include additional information such as the full ticket
commitment script. The new block filters are version 2. The older version 1 filters are now deprecated and scheduled to be removed in the next release, so consumers should update to the new filters as soon as possible.
An overview of block filters can be found in the block filters section of DCP0005.
Also, the specific contents and technical specification of the new version 2 block filters is available in the
version 2 block filters section of DCP0005.
Finally, there is a one time database update to build and store the new filters for all existing historical blocks which will likely take a while to complete (typically around 8 to 10 minutes on HDDs and 4 to 5 minutes on SSDs).
Mining Infrastructure Overhaul
The mining infrastructure for building block templates and delivering the work to miners has been significantly overhauled to improve several aspects as follows:
- Support asynchronous background template generation with intelligent vote propagation handling
- Improved handling of chain reorganizations necessary when the current tip is unable to obtain enough votes
- Current state synchronization
- Near elimination of stale templates when new blocks and votes are received
- Subscriptions for streaming template updates
The standard getwork RPC that PoW miners currently use to perform the mining process has been updated to make use of this new infrastructure, so existing PoW miners will seamlessly get the vast majority of benefits without requiring any updates.
However, in addition, a new notifywork RPC is now available that allows miners to register for work to be delivered
asynchronously as it becomes available via a WebSockets work notification. These notifications include the same information that getwork
provides along with an additional reason
parameter which allows the miners to make better decisions about when they should instruct workers to discard the current template immediately or should be allowed to finish their current round before being provided with the new template.
Miners are highly encouraged to update their software to make use of the new asynchronous notification infrastructure since it is more robust, efficient, and faster than polling getwork
to manually determine the aforementioned conditions.
The following is a non-exhaustive overview that highlights the major benefits of the changes for both cases:
- Requests for updated templates during the normal mining process in between tip changes will now be nearly instant instead of potentially taking several seconds to build the new template on the spot
- When the chain tip changes, requesting a template will now attempt to wait until either all votes have been received or a timeout occurs prior to handing out a template which is beneficial for PoW miners, PoS miners, and the network as a whole
- PoW miners are much less likely to end up with template with less than the max number of votes which means they are less likely to receive a reduced subsidy
- PoW miners will be much less likely to receive stale templates during chain tip changes due to vote propagation
- PoS voters whose votes end up arriving to the miner slightly slower than the minimum number required are much less likely to have their votes excluded despite having voted simply due to propagation delay
PoW miners who choose to update their software, pool or otherwise, to make use of the asynchronous work notifications will receive additional benefits such as:
- Ability to start mining a new block sooner due to receiving updated work as soon as it becomes available
- Immediate notification with new work that includes any votes that arrive late
- Periodic notifications with new work that include new transactions only when there have actually been new transaction
- Simplified interface code due to removal of the need for polling and manually checking the work bytes for special cases such as the number of votes
NOTE: Miners that are not rolling the timestamp field as they mine should ensure their software is upgraded to roll the timestamp to the latest timestamp each time they hand work out to a miner. This helps ensure the block timestamps are as accurate as possible.
Transaction Script Validation Optimizations
Transaction script validation has been almost completely rewritten to significantly improve its speed and reduce the number of memory allocations. While this has many more benefits than enumerated here, probably the most
important ones for most stakeholders are:
- Votes can be cast more quickly which helps reduce the number of missed votes
- Blocks are able to propagate more quickly throughout the network, which in turn further improves votes times
- The initial sync process is around 20-25% faster
Automatic External IP Address Discovery
In order for nodes to fully participate in the peer-to-peer network, they must be publicly accessible and made discoverable by advertising their external IP address. This is typically made slightly more complicated since most users run their nodes on networks behind Network Address Translation (NAT).
Previously, in addition to configuring the network firewall and/or router to allow inbound connections to port 9108 and forwarding the port to the internal IP address running dcrd, it was also required to manually set the public external IP address via the --externalip
CLI option.
This release will now make use of other nodes on the network in a decentralized fashion to automatically discover the external IP address, so it is no longer necessary to manually set CLI option for the vast majority of users.
Tor IPv6 Support
It is now possible to resolve and connect to IPv6 peers over Tor in addition to the existing IPv4 support.
RPC Server Changes
New Version 2 Block Filter Query RPC (getcfilterv2
)
A new RPC named getcfilterv2
is now available which can be used to retrieve the version 2 block filter
for a given block along with its associated inclusion proof. See the [getcfilterv2 JSON-RPC API Documentation](https://github.com/decred/dcrd/blob/master/docs/json...
dcrd v1.5.0-rc2
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 block header commitments
- More efficient block filters
- Significant improvements to the mining infrastructure including asynchronous work notifications
- Major performance enhancements for transaction script validation
- Automatic external IP address discovery
- Support for IPv6 over Tor
- Various updates to the RPC server such as:
- A new method to query information about the network
- A method to retrieve the new version 2 block filters
- More calls available to limited access users
- Infrastructure improvements
- Quality assurance changes
For those unfamiliar with the voting process in Decred, all code in order to support block header commitments is already included in this release, however its enforcement will remain dormant until the stakeholders vote to activate it.
For reference, block header commitments were 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.5.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.
Notable Changes
Block Header Commitments Vote
A new vote with the id headercommitments
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 increase the security and efficiency of lightweight clients, such as Decrediton in its lightweight mode and the dcrandroid/dcrios mobile wallets, as well as add infrastructure that paves the
way for several future scalability enhancements.
A high level overview aimed at a general audience including a cost benefit analysis can be found in the Politeia proposal.
In addition, a much more in-depth treatment can be found in the motivation section of DCP0005.
Version 2 Block Filters
The block filters used by lightweight clients, such as SPV (Simplified Payment Verification) wallets, have been updated to improve their efficiency, ergonomics, and include additional information such as the full ticket
commitment script. The new block filters are version 2. The older version 1 filters are now deprecated and scheduled to be removed in the next release, so consumers should update to the new filters as soon as possible.
An overview of block filters can be found in the block filters section of DCP0005.
Also, the specific contents and technical specification of the new version 2 block filters is available in the
version 2 block filters section of DCP0005.
Finally, there is a one time database update to build and store the new filters for all existing historical blocks which will likely take a while to complete (typically around 8 to 10 minutes on HDDs and 4 to 5 minutes on SSDs).
Mining Infrastructure Overhaul
The mining infrastructure for building block templates and delivering the work to miners has been significantly overhauled to improve several aspects as follows:
- Support asynchronous background template generation with intelligent vote propagation handling
- Improved handling of chain reorganizations necessary when the current tip is unable to obtain enough votes
- Current state synchronization
- Near elimination of stale templates when new blocks and votes are received
- Subscriptions for streaming template updates
The standard getwork RPC that PoW miners currently use to perform the mining process has been updated to make use of this new infrastructure, so existing PoW miners will seamlessly get the vast majority of benefits without requiring any updates.
However, in addition, a new notifywork RPC is now available that allows miners to register for work to be delivered
asynchronously as it becomes available via a WebSockets work notification. These notifications include the same information that getwork
provides along with an additional reason
parameter which allows the miners to make better decisions about when they should instruct workers to discard the current template immediately or should be allowed to finish their current round before being provided with the new template.
Miners are highly encouraged to update their software to make use of the new asynchronous notification infrastructure since it is more robust, efficient, and faster than polling getwork
to manually determine the aforementioned conditions.
The following is a non-exhaustive overview that highlights the major benefits of the changes for both cases:
- Requests for updated templates during the normal mining process in between tip changes will now be nearly instant instead of potentially taking several seconds to build the new template on the spot
- When the chain tip changes, requesting a template will now attempt to wait until either all votes have been received or a timeout occurs prior to handing out a template which is beneficial for PoW miners, PoS miners, and the network as a whole
- PoW miners are much less likely to end up with template with less than the max number of votes which means they are less likely to receive a reduced subsidy
- PoW miners will be much less likely to receive stale templates during chain tip changes due to vote propagation
- PoS voters whose votes end up arriving to the miner slightly slower than the minimum number required are much less likely to have their votes excluded despite having voted simply due to propagation delay
PoW miners who choose to update their software, pool or otherwise, to make use of the asynchronous work notifications will receive additional benefits such as:
- Ability to start mining a new block sooner due to receiving updated work as soon as it becomes available
- Immediate notification with new work that includes any votes that arrive late
- Periodic notifications with new work that include new transactions only when there have actually been new transaction
- Simplified interface code due to removal of the need for polling and manually checking the work bytes for special cases such as the number of votes
NOTE: Miners that are not rolling the timestamp field as they mine should ensure their software is upgraded to roll the timestamp to the latest timestamp each time they hand work out to a miner. This helps ensure the block timestamps are as accurate as possible.
Transaction Script Validation Optimizations
Transaction script validation has been almost completely rewritten to significantly improve its speed and reduce the number of memory allocations. While this has many more benefits than enumerated here, probably the most
important ones for most stakeholders are:
- Votes can be cast more quickly which helps reduce the number of missed votes
- Blocks are able to propagate more quickly throughout the network, which in turn further improves votes times
- The initial sync process is around 20-25% faster
Automatic External IP Address Discovery
In order for nodes to fully participate in the peer-to-peer network, they must be publicly accessible and made discoverable by advertising their external IP address. This is typically made slightly more complicated since most users run their nodes on networks behind Network Address Translation (NAT).
Previously, in addition to configuring the network firewall and/or router to allow inbound connections to port 9108 and forwarding the port to the internal IP address running dcrd, it was also required to manually set the public external IP address via the --externalip
CLI option.
This release will now make use of other nodes on the network in a decentralized fashion to automatically discover the external IP address, so it is no longer necessary to manually set CLI option for the vast majority of users.
Tor IPv6 Support
It is now possible to resolve and connect to IPv6 peers over Tor in addition to the existing IPv4 support.
RPC Server Changes
New Version 2 Block Filter Query RPC (getcfilterv2
)
A new RPC named getcfilterv2
is now available which can be used to retrieve the version 2 block filter
for a given block along with its associated inclusion proof. See the [getcfilterv2 JSON-RPC API Documentation](https://github.com/decred/dcrd/blob/master/docs/json...
dcrd v1.5.0-rc1
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 block header commitments
- More efficient block filters
- Significant improvements to the mining infrastructure including asynchronous work notifications
- Major performance enhancements for transaction script validation
- Automatic external IP address discovery
- Support for IPv6 over Tor
- Various updates to the RPC server such as:
- A new method to query information about the network
- A method to retrieve the new version 2 block filters
- More calls available to limited access users
- Infrastructure improvements
- Quality assurance changes
For those unfamiliar with the voting process in Decred, all code in order to support block header commitments is already included in this release, however its enforcement will remain dormant until the stakeholders vote to activate it.
For reference, block header commitments were 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.5.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.
Notable Changes
Block Header Commitments Vote
A new vote with the id headercommitments
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 increase the security and efficiency of lightweight clients, such as Decrediton in its lightweight mode and the dcrandroid/dcrios mobile wallets, as well as add infrastructure that paves the
way for several future scalability enhancements.
A high level overview aimed at a general audience including a cost benefit analysis can be found in the Politeia proposal.
In addition, a much more in-depth treatment can be found in the motivation section of DCP0005.
Version 2 Block Filters
The block filters used by lightweight clients, such as SPV (Simplified Payment Verification) wallets, have been updated to improve their efficiency, ergonomics, and include additional information such as the full ticket
commitment script. The new block filters are version 2. The older version 1 filters are now deprecated and scheduled to be removed in the next release, so consumers should update to the new filters as soon as possible.
An overview of block filters can be found in the block filters section of DCP0005.
Also, the specific contents and technical specification of the new version 2 block filters is available in the
version 2 block filters section of DCP0005.
Finally, there is a one time database update to build and store the new filters for all existing historical blocks which will likely take a while to complete (typically around 8 to 10 minutes on HDDs and 4 to 5 minutes on SSDs).
Mining Infrastructure Overhaul
The mining infrastructure for building block templates and delivering the work to miners has been significantly overhauled to improve several aspects as follows:
- Support asynchronous background template generation with intelligent vote propagation handling
- Improved handling of chain reorganizations necessary when the current tip is unable to obtain enough votes
- Current state synchronization
- Near elimination of stale templates when new blocks and votes are received
- Subscriptions for streaming template updates
The standard getwork RPC that PoW miners currently use to perform the mining process has been updated to make use of this new infrastructure, so existing PoW miners will seamlessly get the vast majority of benefits without requiring any updates.
However, in addition, a new notifywork RPC is now available that allows miners to register for work to be delivered
asynchronously as it becomes available via a WebSockets work notification. These notifications include the same information that getwork
provides along with an additional reason
parameter which allows the miners to make better decisions about when they should instruct workers to discard the current template immediately or should be allowed to finish their current round before being provided with the new template.
Miners are highly encouraged to update their software to make use of the new asynchronous notification infrastructure since it is more robust, efficient, and faster than polling getwork
to manually determine the aforementioned conditions.
The following is a non-exhaustive overview that highlights the major benefits of the changes for both cases:
- Requests for updated templates during the normal mining process in between tip changes will now be nearly instant instead of potentially taking several seconds to build the new template on the spot
- When the chain tip changes, requesting a template will now attempt to wait until either all votes have been received or a timeout occurs prior to handing out a template which is beneficial for PoW miners, PoS miners, and the network as a whole
- PoW miners are much less likely to end up with template with less than the max number of votes which means they are less likely to receive a reduced subsidy
- PoW miners will be much less likely to receive stale templates during chain tip changes due to vote propagation
- PoS voters whose votes end up arriving to the miner slightly slower than the minimum number required are much less likely to have their votes excluded despite having voted simply due to propagation delay
PoW miners who choose to update their software, pool or otherwise, to make use of the asynchronous work notifications will receive additional benefits such as:
- Ability to start mining a new block sooner due to receiving updated work as soon as it becomes available
- Immediate notification with new work that includes any votes that arrive late
- Periodic notifications with new work that include new transactions only when there have actually been new transaction
- Simplified interface code due to removal of the need for polling and manually checking the work bytes for special cases such as the number of votes
NOTE: Miners that are not rolling the timestamp field as they mine should ensure their software is upgraded to roll the timestamp to the latest timestamp each time they hand work out to a miner. This helps ensure the block timestamps are as accurate as possible.
Transaction Script Validation Optimizations
Transaction script validation has been almost completely rewritten to significantly improve its speed and reduce the number of memory allocations. While this has many more benefits than enumerated here, probably the most
important ones for most stakeholders are:
- Votes can be cast more quickly which helps reduce the number of missed votes
- Blocks are able to propagate more quickly throughout the network, which in turn further improves votes times
- The initial sync process is around 20-25% faster
Automatic External IP Address Discovery
In order for nodes to fully participate in the peer-to-peer network, they must be publicly accessible and made discoverable by advertising their external IP address. This is typically made slightly more complicated since most users run their nodes on networks behind Network Address Translation (NAT).
Previously, in addition to configuring the network firewall and/or router to allow inbound connections to port 9108 and forwarding the port to the internal IP address running dcrd, it was also required to manually set the public external IP address via the --externalip
CLI option.
This release will now make use of other nodes on the network in a decentralized fashion to automatically discover the external IP address, so it is no longer necessary to manually set CLI option for the vast majority of users.
Tor IPv6 Support
It is now possible to resolve and connect to IPv6 peers over Tor in addition to the existing IPv4 support.
RPC Server Changes
New Version 2 Block Filter Query RPC (getcfilterv2
)
A new RPC named getcfilterv2
is now available which can be used to retrieve the version 2 block filter
for a given block along with its associated inclusion proof. See the [getcfilterv2 JSON-RPC API Documentation](https://github.com/decred/dcrd/blob/master/docs/json...
dcrd 1.4.0
This release of dcrd introduces a new consensus vote agenda which allows the
stakeholders to decide whether or not to activate changes needed to modify the
sequence lock handling which is required for providing full support for the
Lightning Network. For those unfamiliar with the voting process in Decred, this
means that all code in order to make the necessary changes is already included
in this release, however its enforcement will remain dormant until the
stakeholders vote to activate it.
It also contains smart fee estimation, performance enhancements for block relay
and processing, a major internal restructuring of how unspent transaction
outputs are handled, support for whitelisting inbound peers to ensure service
for your own SPV (Simplified Payment Verification) wallets, various updates to
the RPC server such as a new method to query the state of the chain and more
easily supporting external RPC connections over TLS, infrastructure
improvements, and other quality assurance changes.
The following Decred Change Proposals (DCP) describes the proposed changes in detail:
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.4.0 is not compatible with previous versions of the
software. This only affects downgrades as users upgrading from previous
versions will see a lengthy 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.
Notable Changes
Fix Lightning Network Sequence Locks Vote
In order to fully support the Lightning Network, the current sequence lock
consensus rules need to be modified. A new vote with the id fixlnseqlocks
is
now available as of this release. After upgrading, stakeholders may set their
preferences through their wallet or Voting Service Provider's (VSP) website.
Smart Fee Estimation (estimatesmartfee
)
A new RPC named estimatesmartfee
is now available which returns a suitable
fee rate for transactions to use in order to have a high probability of them
being mined within a specified number of confirmations. The estimation is based
on actual network usage and thus varies according to supply and demand.
This is important in the context of the Lightning Network (LN) and, more
generally, it provides services and users with a mechanism to choose how to
handle network congestion. For example, payments that are high priority might
be willing to pay a higher fee to help ensure the transaction is mined more
quickly, while lower priority payments might be willing to wait longer in
exchange for paying a lower fee. This estimation capability provides a way to
obtain a fee that will achieve the desired result with a high probability.
Support for Whitelisting Inbound Peers
When peers are whitelisted via the --whitelist
option, they will now be
allowed to connect even when they would otherwise exceed the maximum number of
peers. This is highly useful in cases where users have configured their wallet
to use SPV mode and only connect to dcrd instances that they control for
increased privacy and guaranteed service.
Several Speed Optimizations
Similar to previous releases, this release also contains several enhancements to
improve speed for the initial sync process, validation, and network operations.
In order to achieve these speedups, there is a lengthy one time database
migration, as previously mentioned, that typically takes anywhere from 30
minutes to an hour to complete depending on hardware.
Faster Tip Block Relay
Blocks that extend the current best chain are now relayed to the network
immediately after they pass the initial sanity and contextual checks, most
notably valid proof of work. This allows blocks to propagate more quickly
throughout the network, which in turn improves vote times.
UTXO Set Restructuring
The way the unspent transaction outputs are handled internally has been
overhauled to significantly decrease the time it takes to validate blocks and
transactions. While this has many benefits, probably the most important one
for most stakeholders is that votes can be cast more quickly which helps reduce
the number of missed votes.
RPC Server Changes
New Chain State Query RPC (getblockchaininfo
)
A new RPC named getblockchaininfo
is now available which can be used to query
the state of the chain including details such as its overall verification
progress during initial sync, the maximum supported block size, and that status
of consensus changes (deployments) which require stakeholder votes. See the
JSON-RPC API Documentation
for API details.
Removal of Vote Creation RPC (createrawssgen
)
The deprecated createrawssgen
, which was previously used to allow creating a
vote via RPC is no longer available. Votes are time sensitive and thus it does
not make sense to create them offline.
Updates to Block and Transaction RPCs
The getblock
, getblockheader
, getrawtransaction
, and
searchrawtransactions
RPCs now contain additional information such as the
extradata
field in the header, the expiry
field in transactions, and the
blockheight
and blockindex
of the block that contains a transaction if it
has been mined. See the JSON-RPC API Documentation
for API details.
Built-in Support for Enabling External TLS RPC Connections
A new command line parameter (--altdnsnames
) and environment variable
(DCRD_ALT_DNSNAMES
) can now be used before the first launch of drcd to specify
additional external IP addresses and DNS names to add during the certificate
creation that are permitted to connect to the RPC server via TLS. Previously,
a separate tool was required to accomplish this configuration.
Changelog
All commits since the last release may be viewed on GitHub here.
Protocol and network:
- chaincfg: Add checkpoints for 1.4.0 release (decred/dcrd#1547)
- chaincfg: Introduce agenda for fixlnseqlocks vote (decred/dcrd#1578)
- multi: Enable vote for DCP0004 (decred/dcrd#1579)
- peer: Add support for specifying ua comments (decred/dcrd#1413)
- blockmanager: Fast relay checked tip blocks (decred/dcrd#1443)
- multi: Latest consensus active from simnet genesis (decred/dcrd#1482)
- server: Always allow whitelisted inbound peers (decred/dcrd#1516)
Transaction relay (memory pool):
- blockmanager: handle txs in invalid blocks (decred/dcrd#1430)
- mempool: Remove potential negative locktime check (decred/dcrd#1455)
- mempool: Stake-related readability improvements (decred/dcrd#1456)
RPC:
- multi: Include additional fields on RPC tx results (decred/dcrd#1441)
- rpcserver: Allow scripthash addrs in createrawsstx (decred/dcrd#1444)
- rpcserver: Remove createrawssgen RPC (decred/dcrd#1448)
- rpcclient: support getchaintips RPC (decred/dcrd#1469)
- multi: Add getblockchaininfo rpc (decred/dcrd#1479)
- rpcserver: Adds ability to allow alternative dns names for TLS (decred/dcrd#1476)
- multi: Cleanup recent alt DNS names additions (decred/dcrd#1493)
- multi: Cleanup getblock and getblockheader RPCs (decred/dcrd#1497)
- multi: Return total chain work in RPC results (decred/dcrd#1498)
- rpcserver: Improve GenerateNBlocks error message (decred/dcrd#1507)
- rpcserver: Fix verify progress calculation (decred/dcrd#1508)
- rpcserver: Fix sendrawtransaction error code (decred/dcrd#1512)
- blockchain: Notify stake states after connected block (decred/dcrd#1515)
- rpcserver: bump version to 5.0. (decred/dcrd#1531)
- rpcclient: support getblockchaininfo RPC (decred/dcrd#1539)
- rpcserver: update block template reconstruction (decred/dcrd#1567)
dcrd command-line flags and configuration:
- config: add --maxsameip to limit # of conns to same IP (decred/dcrd#1517)
Documentation:
- docs: Update docs for versioned modules (decred/dcrd#1391)
- docs: Update for fees package (decred/dcrd#1540)
- docs: Revamp main README.md and update docs (decred/dcrd#1447)
- docs: Use relative versions in contrib checklist ([#1451](htt...