Bot releases are hidden (Show)
This is a patch release of dcrd which includes the following key changes:
getmixmessage
that can be used to query decentralized StakeShuffle mixing messagesThis patch release consists of 19 commits from 3 contributors which total to 18 files changed, 388 additional lines of code, and 187 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
Published by davecgh 5 months ago
This is a new major release of dcrd. Some of the key highlights are:
Although upgrading to this latest release is not absolutely required for continued operation of the core network, it is required for anyone who wishes to continue participating in StakeShuffle mixing.
The StakeShuffle mixing process is now fully decentralized via the peer-to-peer network as of this release. All core software has been upgraded to make use of the new decentralized coordination facilities.
This release introduces several new peer-to-peer protocol messages to provide the decentralized coordination. The following is a brief summary of the new messages:
Message | Overall Purpose |
---|---|
mixpairreq |
Request to participate in a mix with relevant data and proofs. |
mixkeyxchg |
Publishes public keys and commitments for blame assignment. |
mixcphrtxt |
Enables quantum resistant (PQ) blinded key exchange. |
mixslotres |
Establishes slot reservations used in the blinding process. |
mixfactpoly |
Encodes solution to the factored slot reservation polynomial. |
mixdcnet |
Untraceable multi-party broadcast (dining cryptographers). |
mixconfirm |
Provides partial signatures to create the mix transaction. |
mixsecrets |
Reveals secrets of an unsuccessful mix for blame assignment. |
This release now supports concurrent data requests (getdata
) which allows for higher network throughput, particularly when the communications channel is experiencing high latency.
A couple of notable benefits are:
Lightweight clients may now request version 2 compact filters in batches as opposed to one at a time. This has the effect of drastically reducing the initial sync time for lightweight clients such as Simplified Payment Verification (SPV) wallets.
This release introduces a new pair of peer-to-peer protocol messages named getcfsv2
and cfiltersv2
which provide the aforementioned capability.
Peers will now continue to query unreachable seeders in the background with an increasing backoff timeout when they have not already discovered a sufficient number of peers on the network to achieve the target connectivity.
This primarily improves the experience for peers joining the network for the first time and those that have not been online for a long time since they do not have a known list of good peers to use.
reject
)The previously deprecated reject
peer-to-peer protocol message is no longer available.
Consequently, the minimum required network protocol version to participate on the network is now version 9.
Note that all nodes on older protocol versions are already not able to participate in the network due to consensus changes that have passed.
Recall from previous release notes that this message is being removed because it is a holdover from the original codebase where it was required, but it really is not a useful message and has several downsides:
The RPC server version as of this release is 8.2.0.
The RPC server now checks for updates to the TLS certificate key pair (rpc.cert
and rpc.key
by default) on new connections and dynamically reloads them if needed. Similarly, the authorized client certificates (clients.pem
by default) when running with the client certificate authorization type mode (--authtype=clientcert
).
Some key highlights of this change:
getblock
and getblockheader
)The verbose results of the getblock
and getblockheader
RPCs now include a powhash
field in the JSON object that contains the Proof-of-Work hash for the block. The new field will be exactly the same as the hash
(block hash) field for all blocks prior to the activation of the stakeholder vote to change the PoW hashing algorithm (DCP0011).
See the following for API details:
sendrawmixmessage
)A new RPC named sendrawmixmessage
is now available. This RPC can be used to manually submit all mixing messages to the mixpool and broadcast them to the network.
See the following for API details:
notifymixmessages
)WebSocket notifications for mixing messages accepted to the mixpool are now available.
Use notifymixmessages
to request mixmessage
notifications and stopnotifymixmessages
to stop receiving notifications.
See the following for API details:
This release consists of 168 commits from 11 contributors which total to 265 files changed, 18292 additional lines of code, and 2978 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
Published by davecgh about 1 year ago
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:
getblock
and getblockheader
RPCs now have an additional powhash
field for the new Proof-of-Work hashgetnetworkhashps
RPC 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 ajustement algorithmThe RPC server version as of this release is 8.1.0.
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.
Published by davecgh over 1 year ago
This is a new major release of dcrd. Some of the key highlights are:
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:
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.
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.
Two new consensus change votes are now available as of this release. After upgrading, stakeholders may set their preferences through their wallet.
The first new vote available as of this release has the id blake3pow
.
The primary goals of this change are to:
See the following for more details:
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:
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 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.
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.
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:
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:
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:
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.
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.
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.
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 otherwise unwilling to serve the data for a variety of reasons.
For example, a peer might be unwilling to serve data because they are still performing the initial sync or temporarily no longer consider themselves synced with the network due to recently coming back online after being unable to communicate with the network for a long time.
This change helps improve network robustness by preventing peers from appearing unresponsive or stalled in such cases.
The individual commitment hashes covered by the commitment root field of the header of each block are now stored in the database for fast access. This provides better scaling for generating and serving inclusion proofs as more commitments are added to the header proof in future upgrades.
--addrindex
, --dropaddrindex
)The previously deprecated optional address index that could be enabled via --addrindex
and removed via --dropaddrindex
is no longer available. All of the information previously provided from the address index, and much more, is available via dcrdata.
The following CLI options no longer have any effect and are now deprecated:
--norelaypriority
--limitfreerelay
--blockminsize
--blockprioritysize
They will be removed in a future release.
The RPC server version as of this release is 8.0.0.
getcoinsupply
)The total coin supply reported by getcoinsupply
will now correctly include the coins generated as a part of the block reward for the decentralized treasury as intended.
As a result, the amount reported will now be higher than it was previously. It is important to note that this issue was only an RPC display issue and did not affect consensus in any way.
WebSocket connections now have longer timeouts and remain connected through transient network timeouts. This significantly improves the stability of high-latency connections such as those communicating across multiple continents.
winningtickets
)Clients that subscribe to receive winningtickets
notifications via WebSockets with notifywinningtickets
will now also receive the notifications on test networks prior to being fully synced when the --allowunsyncedmining
CLI option is provided.
See the following for API details:
getrawmempool
)Due to the removal of the policy related to low fee transaction priority, the startingpriority
and currentpriority
fields of the results of the verbose output of the getrawmempool
RPC are now deprecated. They will always be set to 0 and are scheduled to be removed in a future version.
See the getrawmempool JSON-RPC API Documentation for API details.
searchrawtransactions
)The deprecated searchrawtransactions
RPC, which could previously be used to obtain all transactions that either credit or debit a given address via RPC is no longer available.
Callers that wish to access details related to addresses are encouraged to use dcrdata instead.
getinfo
)The addrindex
field of the getinfo
RPC is no longer available.
See the getinfo JSON-RPC API Documentation for API details.
Now that missed and expired tickets are automatically revoked by the consensus rules, all RPCs related to querying and requesting notifications for missed and expired tickets are no longer available.
In particular, the following deprecated RPCs are no longer available:
missedtickets
rebroadcastmissed
existsmissedtickets
existsexpiredtickets
notifyspentandmissedtickets
getwork
)The getwork
RPC will now return an error message immediately if block template generation is temporarily unable to generate a template indicating the reason. Previously, the RPC would block until a new template was eventually generated which could potentially be an exceedingly long time.
Additionally, cancelling a getwork
invocation before the work has been fully generated will now cancel the underlying request which allows the RPC server to immediately service other queued work requests.
See the getwork JSON-RPC API Documentation for API details.
This release consists of 439 commits from 18 contributors which total to 408 files changed, 25840 additional lines of code, and 22871 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
Published by davecgh over 1 year ago
This is a patch release of dcrd that includes the following changes:
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.
Published by davecgh about 2 years ago
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.
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.
Published by davecgh about 2 years ago
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.
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.
Published by davecgh over 2 years ago
This is a patch release of dcrd to resolve a rare and hard to hit case when optional indexing is enabled.
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.
Published by davecgh over 2 years ago
This is a patch release of dcrd which includes the following changes:
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.
Published by davecgh over 2 years ago
This is a new major release of dcrd. Some of the key highlights are:
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:
The following Decred Change Proposals (DCPs) describe the proposed changes in detail and provide full technical specifications:
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.
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.
Four new consensus change votes are now available as of this release. After upgrading, stakeholders may set their preferences through their wallet.
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.
The second new vote available as of this release has the id explicitverupgrades
.
The primary goals of this change are to:
See the following for more details:
The third new vote available as of this release has the id autorevocations
.
The primary goals of this change are to:
See the following for more details:
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:
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.
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:
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:
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:
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:
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]
: Set AssumeValid
to the specified block hashSpecifying a block hash closer to the current best chain tip allows for faster syncing. This is useful since the validation requirements increase the longer a particular release build is out as the default known good block becomes deeper in the chain.
The block index that keeps track of block status and connectivity now occupies around 30MiB less memory and scales better as more blocks are added to the chain.
The various optional indexes are now created asynchronously versus when blocks are processed as was previously the case.
This permits blocks to be validated more quickly when the indexes are enabled since the validation no longer needs to wait for the indexing operations to complete.
In order to help keep consistent behavior for RPC clients, RPCs that involve interacting with the indexes will not return results until the associated indexing operation completes when the indexing tip is close to the current best chain tip.
One side effect of this change that RPC clients should be aware of is that it is now possible to receive sync timeout errors on RPCs that involve interacting with the indexes if the associated indexing tip gets so far behind it would end up delaying results for too long. In practice, errors of this type are rare and should only ever be observed during the initial sync process before the associated indexes are current. However, callers should be aware of the possibility and handle the error accordingly.
The following RPCs are affected:
existsaddress
existsaddresses
getrawtransaction
searchrawtransactions
The previously deprecated version 1 block filters are no longer available on the peer-to-peer network. Use version 2 block filters with their associated block header commitment and inclusion proof instead.
The RPC server version as of this release is 7.0.0.
The RPC server now imposes the following additional per-connection read limits to help further harden it against potential abuse in non-standard configurations on poorly-configured networks:
In practice, these changes will not have any noticeable effect for the vast majority of nodes since the RPC server is not publicly accessible by default and also requires authentication.
Nevertheless, it can still be useful for scenarios such as authenticated fuzz testing and improperly-configured networks that have disabled all other security measures.
The CORS policy for WebSocket clients is now more strict and rejects requests from other domains.
In practice, CORS requests will be rejected before ever reaching that point due to the use of a self-signed TLS certificate and the requirement for
authentication to issue any commands. However, additional protection mechanisms make it that much more difficult to attack by providing defense in depth.
A new alternative method for TLS clients to authenticate to the RPC server by presenting a client certificate in the TLS handshake is now available.
Under this authentication method, the certificate authority for a client certificate must be added to the RPC server as a trusted root in order for it to trust the client. Once activated, clients will no longer be required to provide HTTP Basic authentication nor use the authenticate
RPC in the case of WebSocket clients.
Note that while TLS client authentication has the potential to ultimately allow more fine grained access controls on a per-client basis, it currently only supports clients with full administrative priveleges. In other words, it is not currently compatible with the --rpclimituser
and --rpclimitpass
mechanism, so users depending on the limited user settings should avoid the new authentication method for now.
The new authentication type can be activated with the --authtype=clientcert
configuration option.
By default, the trusted roots are loaded from the clients.pem
file in dcrd's application data directory, however, that location can be modified via the --clientcafile
option if desired.
gettxout
)The gettxout
RPC has the following modifications:
tree
parameter is now required in order to explicitly identify the exact transaction output being requestedversion
field is no longer available in the primary JSON object of the resultsscriptPubKey
JSON object in the results now includes a new version
field that identifies the scripting language versionSee the gettxout JSON-RPC API Documentation for API details.
notifystakedifficulty
and stakedifficulty
)The deprecated notifystakedifficulty
and stakedifficulty
WebSocket-only RPCs are no longer available. This notification is unnecessary since the difficulty change interval is well defined. Callers may obtain the difficulty via getstakedifficulty
at the appropriate difficulty change intervals instead.
See the getstakedifficulty JSON-RPC API Documentation for API details.
getcfilter
and getcfilterheader
)The deprecated getcfilter
and getcfilterheader
RPCs, which were previously used to obtain version 1 block filters via RPC are no longer available. Use getcfilterv2
instead.
See the getcfilterv2 JSON-RPC API Documentation for API details.
getblock
and getblockheader
)The verbose results of the getblock
and getblockheader
RPCs now include a mediantime
field that specifies the median block time associated with the block.
See the following for API details:
getrawtransaction
, decoderawtransaction
, searchrawtransactions
, and getblock
)The verbose results of the getrawtransaction
, decoderawtransaction
, searchrawtransactions
, and getblock
RPCs now include a version
field in the child scriptPubKey
JSON object that identifies the scripting language version.
See the following for API details:
getrawmempool
)The transaction type parameter of the getrawmempool
RPC now accepts tadd
to only include treasury add transactions in the results.
See the getrawmempool JSON-RPC API Documentation for API details.
invalidateblock
and reconsiderblock
)A new pair of RPCs named invalidateblock
and reconsiderblock
are now available. These RPCs can be used to manually invalidate a block as if it had violated consensus rules and reconsider a block for validation and best chain selection by removing any invalid status from it and its ancestors, respectively.
This capability is provided for development, testing, and debugging. It can be particularly useful when developing services that build on top of Decred to more easily ensure edge conditions associated with invalid blocks and chain reorganization are being handled properly.
These RPCs do not apply to regular users and can safely be ignored outside of development.
See the following for API details:
reject
)The reject
peer-to-peer protocol message is now deprecated and is scheduled to be removed in a future release.
This message is a holdover from the original codebase where it was required, but it really is not a useful message and has several downsides:
--nodnsseed
)The --nodnsseed
command-line configuration option is now deprecated and will be removed in a future release. Use --noseeders
instead.
DNS seeding has not been used since the previous release.
A new github.com/decred/dcrd/container/apbf
module is now available that provides Age-Partitioned Bloom Filters (APBFs).
An APBF is a probabilistic lookup device that can quickly determine if it contains an element. It permits tracking large amounts of data while using very little memory at the cost of a controlled rate of false positives. Unlike classic Bloom filters, it is able to handle an unbounded amount of data by aging and discarding old items.
For a concrete example of actual savings achieved in Decred by making use of an APBF, the memory to track addresses known by 125 peers was reduced from ~200 MiB to ~5 MiB.
See the apbf module documentation for full details on usage, accuracy under workloads, expected memory usage, and performance benchmarks.
A new github.com/decred/dcrd/math/uint256
module is now available that provides highly optimized allocation free fixed precision unsigned 256-bit integer arithmetic.
The package has a strong focus on performance and correctness and features arithmetic, boolean comparison, bitwise logic, bitwise shifts, conversion to/from relevant types, and full formatting support - all served with an ergonomic API, full test coverage, and benchmarks.
Every operation is faster than the standard library big.Int
equivalent and the primary math operations provide reductions of over 90% in the calculation time. Most other operations are also significantly faster.
See the uint256 module documentation for full details on usage, including a categorized summary, and performance benchmarks.
A new github.com/decred/dcrd/txscript/v4/stdscript
package is now available that provides facilities for identifying and extracting data from transaction scripts that are considered standard by the default policy of most nodes.
The package is part of the github.com/decred/dcrd/txscript/v4
module.
See the stdscript package documentation for full details on usage and a list of the recognized standard scripts.
A new github.com/decred/dcrd/txscript/v4/stdaddr
package is now available that provides facilities for working with human-readable Decred payment addresses.
The package is part of the github.com/decred/dcrd/txscript/v4
module.
See the stdaddr package documentation for full details on usage and a list of the supported addresses.
This release consists of 877 commits from 16 contributors which total to 492 files changed, 77937 additional lines of code, and 30961 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
Published by davecgh almost 3 years ago
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.
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.
Published by davecgh almost 3 years ago
This is a new major release of dcrd. Some of the key highlights are:
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:
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.
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.
Four new consensus change votes are now available as of this release. After upgrading, stakeholders may set their preferences through their wallet.
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.
The second new vote available as of this release has the id explicitverupgrades
.
The primary goals of this change are to:
See the following for more details:
The third new vote available as of this release has the id autorevocations
.
The primary goals of this change are to:
See the following for more details:
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:
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.
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:
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:
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:
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:
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]
: Set AssumeValid
to the specified block hashSpecifying a block hash closer to the current best chain tip allows for faster syncing. This is useful since the validation requirements increase the longer a particular release build is out as the default known good block becomes deeper in the chain.
The block index that keeps track of block status and connectivity now occupies around 30MiB less memory and scales better as more blocks are added to the chain.
The various optional indexes are now created asynchronously versus when blocks are processed as was previously the case.
This permits blocks to be validated more quickly when the indexes are enabled since the validation no longer needs to wait for the indexing operations to complete.
In order to help keep consistent behavior for RPC clients, RPCs that involve interacting with the indexes will not return results until the associated indexing operation completes when the indexing tip is close to the current best chain tip.
One side effect of this change that RPC clients should be aware of is that it is now possible to receive sync timeout errors on RPCs that involve interacting with the indexes if the associated indexing tip gets so far behind it would end up delaying results for too long. In practice, errors of this type are rare and should only ever be observed during the initial sync process before the associated indexes are current. However, callers should be aware of the possibility and handle the error accordingly.
The following RPCs are affected:
existsaddress
existsaddresses
getrawtransaction
searchrawtransactions
The previously deprecated version 1 block filters are no longer available on the peer-to-peer network. Use version 2 block filters with their associated block header commitment and inclusion proof instead.
The RPC server version as of this release is 7.0.0.
The RPC server now imposes the following additional per-connection read limits to help further harden it against potential abuse in non-standard configurations on poorly-configured networks:
In practice, these changes will not have any noticeable effect for the vast majority of nodes since the RPC server is not publicly accessible by default and also requires authentication.
Nevertheless, it can still be useful for scenarios such as authenticated fuzz testing and improperly-configured networks that have disabled all other security measures.
The CORS policy for WebSocket clients is now more strict and rejects requests from other domains.
In practice, CORS requests will be rejected before ever reaching that point due to the use of a self-signed TLS certificate and the requirement for
authentication to issue any commands. However, additional protection mechanisms make it that much more difficult to attack by providing defense in depth.
A new alternative method for TLS clients to authenticate to the RPC server by presenting a client certificate in the TLS handshake is now available.
Under this authentication method, the certificate authority for a client certificate must be added to the RPC server as a trusted root in order for it to trust the client. Once activated, clients will no longer be required to provide HTTP Basic authentication nor use the authenticate
RPC in the case of WebSocket clients.
Note that while TLS client authentication has the potential to ultimately allow more fine grained access controls on a per-client basis, it currently only supports clients with full administrative priveleges. In other words, it is not currently compatible with the --rpclimituser
and --rpclimitpass
mechanism, so users depending on the limited user settings should avoid the new authentication method for now.
The new authentication type can be activated with the --authtype=clientcert
configuration option.
By default, the trusted roots are loaded from the clients.pem
file in dcrd's application data directory, however, that location can be modified via the --clientcafile
option if desired.
gettxout
)The gettxout
RPC has the following modifications:
tree
parameter is now required in order to explicitly identify the exact transaction output being requestedversion
field is no longer available in the primary JSON object of the resultsscriptPubKey
JSON object in the results now includes a new version
field that identifies the scripting language versionSee the gettxout JSON-RPC API Documentation for API details.
notifystakedifficulty
and stakedifficulty
)The deprecated notifystakedifficulty
and stakedifficulty
WebSocket-only RPCs are no longer available. This notification is unnecessary since the difficulty change interval is well defined. Callers may obtain the difficulty via getstakedifficulty
at the appropriate difficulty change intervals instead.
See the getstakedifficulty JSON-RPC API Documentation for API details.
getcfilter
and getcfilterheader
)The deprecated getcfilter
and getcfilterheader
RPCs, which were previously used to obtain version 1 block filters via RPC are no longer available. Use getcfilterv2
instead.
See the getcfilterv2 JSON-RPC API Documentation for API details.
getblock
and getblockheader
)The verbose results of the getblock
and getblockheader
RPCs now include a mediantime
field that specifies the median block time associated with the block.
See the following for API details:
getrawtransaction
, decoderawtransaction
, searchrawtransactions
, and getblock
)The verbose results of the getrawtransaction
, decoderawtransaction
, searchrawtransactions
, and getblock
RPCs now include a version
field in the child scriptPubKey
JSON object that identifies the scripting language version.
See the following for API details:
getrawmempool
)The transaction type parameter of the getrawmempool
RPC now accepts tadd
to only include treasury add transactions in the results.
See the getrawmempool JSON-RPC API Documentation for API details.
invalidateblock
and reconsiderblock
)A new pair of RPCs named invalidateblock
and reconsiderblock
are now available. These RPCs can be used to manually invalidate a block as if it had violated consensus rules and reconsider a block for validation and best chain selection by removing any invalid status from it and its ancestors, respectively.
This capability is provided for development, testing, and debugging. It can be particularly useful when developing services that build on top of Decred to more easily ensure edge conditions associated with invalid blocks and chain reorganization are being handled properly.
These RPCs do not apply to regular users and can safely be ignored outside of development.
See the following for API details:
reject
)The reject
peer-to-peer protocol message is now deprecated and is scheduled to be removed in a future release.
This message is a holdover from the original codebase where it was required, but it really is not a useful message and has several downsides:
--nodnsseed
)The --nodnsseed
command-line configuration option is now deprecated and will be removed in a future release. Use --noseeders
instead.
DNS seeding has not been used since the previous release.
A new github.com/decred/dcrd/container/apbf
module is now available that provides Age-Partitioned Bloom Filters (APBFs).
An APBF is a probabilistic lookup device that can quickly determine if it contains an element. It permits tracking large amounts of data while using very little memory at the cost of a controlled rate of false positives. Unlike classic Bloom filters, it is able to handle an unbounded amount of data by aging and discarding old items.
For a concrete example of actual savings achieved in Decred by making use of an APBF, the memory to track addresses known by 125 peers was reduced from ~200 MiB to ~5 MiB.
See the apbf module documentation for full details on usage, accuracy under workloads, expected memory usage, and performance benchmarks.
A new github.com/decred/dcrd/math/uint256
module is now available that provides highly optimized allocation free fixed precision unsigned 256-bit integer arithmetic.
The package has a strong focus on performance and correctness and features arithmetic, boolean comparison, bitwise logic, bitwise shifts, conversion to/from relevant types, and full formatting support - all served with an ergonomic API, full test coverage, and benchmarks.
Every operation is faster than the standard library big.Int
equivalent and the primary math operations provide reductions of over 90% in the calculation time. Most other operations are also significantly faster.
See the uint256 module documentation for full details on usage, including a categorized summary, and performance benchmarks.
A new github.com/decred/dcrd/txscript/v4/stdscript
package is now available that provides facilities for identifying and extracting data from transaction scripts that are considered standard by the default policy of most nodes.
The package is part of the github.com/decred/dcrd/txscript/v4
module.
See the stdscript package documentation for full details on usage and a list of the recognized standard scripts.
A new github.com/decred/dcrd/txscript/v4/stdaddr
package is now available that provides facilities for working with human-readable Decred payment addresses.
The package is part of the github.com/decred/dcrd/txscript/v4
module.
See the stdaddr package documentation for full details on usage and a list of the supported addresses.
This release consists of 875 commits from 16 contributors which total to 492 files changed, 77921 additional lines of code, and 30952 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
Published by davecgh over 3 years ago
This is a patch release of dcrd to introduce a quality of life change for lightweight clients, such as SPV wallets, by not sending them a certain class of announcements that only full nodes are equiped to handle.
This patch release consists of 2 commits from 1 contributor which total to 3 files changed, 55 additional lines of code, and 31 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
Published by davecgh over 3 years ago
This is a patch release of dcrd which includes the following changes:
This patch release consists of 3 commits from 1 contributor which total to 3 files changed, 30 additional lines of code, and 9 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
Published by davecgh over 3 years ago
This release of dcrd introduces a large number of updates. Some of the key highlights are:
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.
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.
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.
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:
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.
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:
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:
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.
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.
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.
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.
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.
The RPC server version as of this release is 6.2.0.
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.
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.
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.
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.
getpeerinfo
)The results of the getpeerinfo
RPC are now sorted by the id
field.
See the getpeerinfo JSON-RPC API Documentation for API details.
searchrawtransactions
)The maximum number of transactions returned by a single request to the searchrawtransactions
RPC is now limited to 10,000 transactions. This far exceeds the number of results for all typical cases; however, for the rare cases where it does not, the caller can make use of the skip
parameter in subsequent requests to access additional data if they require access to more results.
See the searchrawtransactions JSON-RPC API Documentation for API details.
getinfo
)The results of the getinfo
RPC now include txindex
and addrindex
fields that specify whether or not the respective indexes are active.
See the getinfo JSON-RPC API Documentation for API details.
Support for version 1 block filters is deprecated and is scheduled to be removed in the next release. Use
version 2 block filters with their associated block header commitment and inclusion proof instead.
This release consists of 616 commits from 17 contributors which total to 526 files changed, 63090 additional lines of code, and 26279 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
Published by davecgh almost 4 years ago
This release of dcrd introduces a large number of updates. Some of the key highlights are:
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.
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.
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.
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:
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.
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:
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:
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.
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.
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.
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.
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.
The RPC server version as of this release is 6.2.0.
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.
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.
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.
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.
getpeerinfo
)The results of the getpeerinfo
RPC are now sorted by the id
field.
See the getpeerinfo JSON-RPC API Documentation for API details.
searchrawtransactions
)The maximum number of transactions returned by a single request to the searchrawtransactions
RPC is now limited to 10,000 transactions. This far exceeds the number of results for all typical cases; however, for the rare cases where it does not, the caller can make use of the skip
parameter in subsequent requests to access additional data if they require access to more results.
See the searchrawtransactions JSON-RPC API Documentation for API details.
getinfo
)The results of the getinfo
RPC now include txindex
and addrindex
fields that specify whether or not the respective indexes are active.
See the getinfo JSON-RPC API Documentation for API details.
Support for version 1 block filters is deprecated and is scheduled to be removed in the next release. Use
version 2 block filters with their associated block header commitment and inclusion proof instead.
This release consists of 616 commits from 17 contributors which total to 526 files changed, 63085 additional lines of code, and 26274 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
Published by davecgh almost 4 years ago
This release of dcrd introduces a large number of updates. Some of the key highlights are:
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.
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.
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.
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:
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.
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:
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:
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.
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.
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.
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.
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.
The RPC server version as of this release is 6.2.0.
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.
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.
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.
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.
getpeerinfo
)The results of the getpeerinfo
RPC are now sorted by the id
field.
See the getpeerinfo JSON-RPC API Documentation for API details.
searchrawtransactions
)The maximum number of transactions returned by a single request to the searchrawtransactions
RPC is now limited to 10,000 transactions. This far exceeds the number of results for all typical cases; however, for the rare cases where it does not, the caller can make use of the skip
parameter in subsequent requests to access additional data if they require access to more results.
See the searchrawtransactions JSON-RPC API Documentation for API details.
getinfo
)The results of the getinfo
RPC now include txindex
and addrindex
fields that specify whether or not the respective indexes are active.
See the getinfo JSON-RPC API Documentation for API details.
Support for version 1 block filters is deprecated and is scheduled to be removed in the next release. Use
version 2 block filters with their associated block header commitment and inclusion proof instead.
This release consists of 615 commits from 17 contributors which total to 526 files changed, 62989 additional lines of code, and 26227 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
Published by davecgh almost 4 years ago
This release of dcrd introduces a large number of updates. Some of the key highlights are:
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.
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.
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.
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:
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.
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:
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:
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.
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.
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.
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.
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.
The RPC server version as of this release is 6.1.2.
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.
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.
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.
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.
getpeerinfo
)The results of the getpeerinfo
RPC are now sorted by the id
field.
See the getpeerinfo JSON-RPC API Documentation for API details.
searchrawtransactions
)The maximum number of transactions returned by a single request to the searchrawtransactions
RPC is now limited to 10,000 transactions. This far exceeds the number of results for all typical cases; however, for the rare cases where it does not, the caller can make use of the skip
parameter in subsequent requests to access additional data if they require access to more results.
See the searchrawtransactions JSON-RPC API Documentation for API details.
getinfo
)The results of the getinfo
RPC now include txindex
and addrindex
fields that specify whether or not the respective indexes are active.
See the getinfo JSON-RPC API Documentation for API details.
Support for version 1 block filters is deprecated and is scheduled to be removed in the next release. Use
version 2 block filters with their associated block header commitment and inclusion proof instead.
This release consists of 615 commits from 17 contributors which total to 526 files changed, 62562 additional lines of code, and 26160 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
Published by davecgh almost 4 years ago
This release of dcrd introduces a large number of updates. Some of the key highlights are:
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.
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.
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.
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:
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.
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:
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:
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.
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.
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.
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.
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.
The RPC server version as of this release is 6.1.2.
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.
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.
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.
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.
getpeerinfo
)The results of the getpeerinfo
RPC are now sorted by the id
field.
See the getpeerinfo JSON-RPC API Documentation for API details.
searchrawtransactions
)The maximum number of transactions returned by a single request to the searchrawtransactions
RPC is now limited to 10,000 transactions. This far exceeds the number of results for all typical cases; however, for the rare cases where it does not, the caller can make use of the skip
parameter in subsequent requests to access additional data if they require access to more results.
See the searchrawtransactions JSON-RPC API Documentation for API details.
getinfo
)The results of the getinfo
RPC now include txindex
and addrindex
fields that specify whether or not the respective indexes are active.
See the getinfo JSON-RPC API Documentation for API details.
Support for version 1 block filters is deprecated and is scheduled to be removed in the next release. Use version 2 block filters with their associated block header commitment and inclusion proof instead.
This release consists of 614 commits from 17 contributors which total to 525 files changed, 62548 additional lines of code, and 26153 deleted lines of code.
All commits since the last release may be viewed on GitHub here.
Published by davecgh almost 4 years ago
This release of dcrd introduces a large number of updates. Some of the key highlights are:
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.
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.
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.
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:
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.
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:
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:
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.
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.
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.
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.
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.
The RPC server version as of this release is 6.1.2.
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.
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.
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.
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.
getpeerinfo
)The results of the getpeerinfo
RPC are now sorted by the id
field.
See the getpeerinfo JSON-RPC API Documentation for API details.
searchrawtransactions
)The maximum number of transactions returned by a single request to the searchrawtransactions
RPC is now limited to 10,000 transactions. This far exceeds the number of results for all typical cases; however, for the rare cases where it does not, the caller can make use of the skip
parameter in subsequent requests to access additional data if they require access to more results.
See the searchrawtransactions JSON-RPC API Documentation for API details.
getinfo
)The results of the getinfo
RPC now include txindex
and addrindex
fields that specify whether or not the respective indexes are active.
See the getinfo JSON-RPC API Documentation for API details.
Support for version 1 block filters is deprecated and is scheduled to be removed in the next release. Use version 2 block filters with their associated block header commitment and inclusion proof instead.
This release consists of 605 commits from 17 contributors which total to 525 files changed, 61568 additional lines of code, and 25364 deleted lines of code.
All commits since the last release may be viewed on GitHub here.