Skip to content

Releases: decred/dcrd

dcrd v2.0.4

28 Aug 20:33
release-v2.0.4
b4378f4
Compare
Choose a tag to compare

dcrd v2.0.4 Release Notes

This is a patch release of dcrd which includes the following changes:

  • Improved session formation for StakeShuffle mix transactions
  • Support for Internationalized Domain Names (IDNs) in hostnames
  • StakeShuffle mixing performance enhancements

Changelog

This patch release consists of 14 commits from 3 contributors which total to 17 files changed, 201 additional lines of code, and 97 deleted lines of code.

All commits since the last release may be viewed on GitHub here.

Mixing message relay (mix pool):

  • [release-v2.0] mixpool: Reject KEs submitted too early (decred/dcrd#3431)
  • [release-v2.0] mixclient: Use newest (fewest-PR) KEs to form alt sessions (decred/dcrd#3431)

RPC / gencerts utility changes:

  • [release-v2.0] certgen,gencerts: Punycode non-ASCII hostnames (decred/dcrd#3432)

Developer-related package and module changes:

Developer-related module management:

Misc:

Code Contributors (alphabetical order):

  • Dave Collins
  • Jamie Holdstock
  • Josh Rickmar

dcrd v2.0.3

20 Jun 15:51
release-v2.0.3
039a14a
Compare
Choose a tag to compare

dcrd v2.0.3 Release Notes

This is a patch release of dcrd which includes the following changes:

  • Improved sender privacy for transactions and mix messages via randomized announcements
  • Nodes now prefer to maintain at least three mixing-capable outbound connections
  • Recent transactions and mix messages will now be available to serve for longer
  • Reduced memory usage during periods of lower activity
  • Mixing-related performance enhancements

Changelog

This patch release consists of 26 commits from 2 contributors which total to 37 files changed, 4527 additional lines of code, and 499 deleted lines of code.

All commits since the last release may be viewed on GitHub here.

Protocol and network:

Mixing message relay (mix pool):

Documentation:

Developer-related package and module changes:

Developer-related module management:

Misc:

Code Contributors (alphabetical order):

  • Dave Collins
  • Josh Rickmar

dcrd v2.0.2

05 Jun 15:40
release-v2.0.2
5d864bf
Compare
Choose a tag to compare

This is a patch release of dcrd which includes the following key changes:

  • Nodes now prefer to maintain at least one mixing-capable outbound connection
  • Peers will no longer potentially be improperly banned due to missing mix messages
  • Mixing messages that are not available will now be obtained from elsewhere
  • Improves mixing message availability during network propagation

Changelog

This patch release consists of 26 commits from 3 contributors which total to 18 files changed, 468 additional lines of code, and 451 deleted lines of code.

All commits since the last release may be viewed on GitHub here.

Protocol and network:

Mixing message relay (mix pool):

Developer-related package and module changes:

Developer-related module management:

Misc:

Code Contributors (alphabetical order):

  • Dave Collins
  • David Hill
  • Josh Rickmar

dcrd v2.0.1

29 May 16:56
release-v2.0.1
4778a11
Compare
Choose a tag to compare

This is a patch release of dcrd which includes the following key changes:

  • Provides a new JSON-RPC API method named getmixmessage that can be used to query decentralized StakeShuffle mixing messages
  • No longer relays mixing messages when transaction relay is disabled
  • Transaction outputs with one confirmation may now be used as part of a mix
  • Improves best network address candidate selection
  • More consistent logging of banned peers along with the reason they were banned

Changelog

This 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.

Protocol and network:

RPC:

Mixing message relay (mix pool):

Documentation:

Developer-related package and module changes:

Developer-related module management:

Misc:

Code Contributors (alphabetical order):

  • Dave Collins
  • David Hill
  • Josh Rickmar

dcrd v2.0.0

17 May 14:17
release-v2.0.0
8a2a185
Compare
Choose a tag to compare

This is a new major release of dcrd. Some of the key highlights are:

  • Decentralized StakeShuffle mixing
  • Higher network throughput
  • Lightweight client sync time reduced by around 50%
  • Improved initial peer discovery
  • Reject protocol message removal
  • Various updates to the RPC server:
    • Dynamic TLS certificate reload
    • Proof-of-Work hash in block information
    • New JSON-RPC API additions related to decentralized StakeShuffle mixing
  • Quality assurance changes

Upgrade Required To Continue Participating in StakeShuffle Mixing

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.

Notable Changes

Decentralized 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.

Higher Network Throughput

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:

  • Reduced vote times since it allows blocks and transactions to propagate more quickly throughout the network
  • More responsive during traffic bursts and general network congestion

Lightweight client sync time reduced by around 50%

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.

Improved Initial Peer Discovery

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 Protocol Message Removal (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:

  • Nodes on the network must be trustless, which means anything relying on such a message is setting itself up for failure because nodes are not obligated to send it at all nor be truthful as to the reason
  • It can be harmful to privacy as it allows additional node fingerprinting
  • It can lead to security issues for implementations that don't handle it with proper sanitization practices
  • It can easily give software implementations the fully incorrect impression that it can be relied on for determining if transactions and blocks are valid
  • The only way it is actually used currently is to show a debug log message, however, all of that information is already available via the peer and/or wire logging anyway
  • It carries a non-trivial amount of development overhead to continue to support it when nothing actually uses it

RPC Server Changes

The RPC server version as of this release is 8.2.0.

Dynamic TLS Certificate Reload

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:

  • Certificates can now be updated without needing to shutdown and restart the process which enables things such as:
    • Updating the certificates to change the allowed domain name and/or IP addresses
    • Dynamically adding or removing authorized clients
    • Changing the cryptographic primitives used to newer supported variants
  • All existing connections will continue to use the certificates that were loaded at the time the connection was made
  • The existing working certs are retained if any errors are encountered when loading the new ones in order to avoid breaking a working config

New Proof-of-Work Hash Field in Block Info RPCs (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:

New StakeShuffle Mixing Pool (mixpool) Message Send RPC (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:

New StakeShuffle Mixing Pool (mixpool) Message WebSocket Notification RPCs (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:

Changelog

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.

Protocol and network:

Read more

dcrd v1.8.1

27 Sep 18:02
release-v1.8.1
26b2ae5
Compare
Choose a tag to compare

This is a patch release of dcrd that includes some updates to the RPC server and JSON-RPC API in light of the changes made by DCP0011 as follows:

  • The getblock and getblockheader RPCs now have an additional powhash field for the new Proof-of-Work hash
  • The getnetworkhashps 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 adjustment algorithm

The RPC server version as of this release is 8.1.0.

Changelog

This patch release consists of 5 commits from 2 contributors which total to 7 files changed, 47 additional lines of code, and 29 deleted lines of code.

All commits since the last release may be viewed on GitHub here.

RPC:

Developer-related package and module changes:

Misc:

Code Contributors (alphabetical order):

  • Dave Collins
  • Jonathan Chappelow

dcrd v1.8.0

13 Jun 20:15
release-v1.8.0
84df486
Compare
Choose a tag to compare

This is a new major release of dcrd. Some of the key highlights are:

  • Two new consensus vote agendas which allow stakeholders to decide whether or
    not to activate support for the following:
    • Changing the Proof-of-Work hashing algorithm to BLAKE3 and the difficulty algorithm to ASERT
    • Changing the Proof-of-Work and Proof-of-Stake subsidy split from 10%/80% to 1%/89%
  • Separation of block hash from Proof-of-Work hash
  • BLAKE3 CPU mining support
  • Initial sync time reduced by about 20%
  • Runtime memory management optimizations
  • Faster cryptographic signature validation
  • Low fee transaction rejection
  • Unspent transaction output set size reduction
  • No more checkpoints
  • Improved network protocol message responsiveness
  • Header proof commitment hash storage
  • Address index removal
  • Several CLI options deprecated
  • Various updates to the RPC server:
    • Total coin supply output correction
    • More stable global communication over WebSockets
    • Winning ticket notifications when unsynced mining on test networks
    • Several other notable updates, additions, and removals related to the JSON-RPC API
  • Infrastructure improvements
  • Miscellaneous network and protocol optimizations
  • Quality assurance changes

For those unfamiliar with the voting process in Decred, all code needed in order to support each of the aforementioned consensus changes is already included in this release, however it will remain
dormant until the stakeholders vote to activate it.

For reference, the consensus change work was originally proposed and approved for initial implementation via the following Politeia proposal:

The following Decred Change Proposals (DCPs) describe the proposed changes in detail and provide full technical specifications:

Upgrade Required

It is extremely important for everyone to upgrade their software to this latest release even if you don't intend to vote in favor of the agenda. This particularly applies to PoW miners as failure to upgrade will result in lost rewards after block height 777240. That is estimated to be around June 29th, 2023.

Downgrade Warning

The database format in v1.8.0 is not compatible with previous versions of the software. This only affects downgrades as users upgrading from previous versions will see a one time database migration.

Once this migration has been completed, it will no longer be possible to downgrade to a previous version of the software without having to delete the database and redownload the chain.

The database migration typically takes around 4-6 minutes on HDDs and 2-3 minutes on SSDs.

Notable Changes

Two New Consensus Change Votes

Two new consensus change votes are now available as of this release. After upgrading, stakeholders may set their preferences through their wallet.

Change PoW to BLAKE3 and ASERT

The first new vote available as of this release has the id blake3pow.

The primary goals of this change are to:

  • Increase decentralization of proof of work mining by obsoleting the current specialized hardware (ASICs) that is only realistically available to the existing highly centralized mining monopoly
  • Improve the proof of work mining difficulty adjustment algorithm responsiveness
  • Provide more equal profitability to steady state PoW miners versus hit and run miners

See the following for more details:

Change PoW/PoS Subsidy Split to 1/89 Vote

The second new vote available as of this release has the id changesubsidysplitr2.

The proposed modification to the subsidy split in tandem with the change to the PoW hashing function is intended to break up the mining cartel and further improve decentralization of the issuance process.

See the following for more details:

Separation of Block Hash from Proof-of-Work Hash

A new Proof-of-Work (PoW) hash that is distinct from the existing block hash is now used for all consensus rules related to PoW verification.

Block hashes have historically served multiple roles which include those related to proof of work (PoW). As of this release, the roles related to PoW are now solely the domain of the new PoW hash.

Some key points related to this change are:

  • The new PoW hash will be exactly the same as the existing block hash for all blocks prior to the activation of the stakeholder vote to change the PoW hashing algorithm
  • The block hash continues to use the existing hashing algorithm
  • The block hash will no longer have the typical pattern of leading zeros upon activation of the PoW hashing algorithm
  • The PoW hash will have the typical pattern of leading zeros both before and after the activation of the new PoW hashing algorithm

BLAKE3 CPU Mining Support

The internal CPU miner has been significantly optimized to provide much higher hash rates, especially when using multiple cores, and now automatically mines using the BLAKE3 algorithm when the blake3pow agenda is active.

Initial Sync Time Reduced by About 20%

The amount of time it takes to complete the initial chain synchronization process with default settings has been reduced by about 20% versus the previous release.

Runtime Memory Management Optimizations

The way memory is managed has been optimized to provide performance enhancements to both steady-state operation as well as the initial chain sync process.

The primary benefits are:

  • Lower maximum memory usage during transient periods of high demand
  • Approximately a 10% reduction to the duration of the initial sync process
  • Significantly reduced overall total memory allocations (~42%)
  • Less overall CPU usage for the same amount of work

Faster Cryptographic Signature Validation

Similar to the previous release, this release further improves some aspects of the underlying crypto code to increase its execution speed and reduce the number of memory allocations. The overall result is a 52% reduction in allocations and about a 1% reduction to the verification time for a single signature.

The primary benefits are:

  • Improved vote times since blocks and transactions propagate more quickly throughout the network
  • Approximately a 4% reduction to the duration of the initial sync process

Low Fee Transaction Rejection

The default transaction acceptance and relay policy is no longer based on priority and instead now immediately rejects all transactions that do not pay the minimum required fee.

This provides a better user experience for transactions that do not pay enough fees.

For some insight into the motivation for this change, prior to the introduction of support for child pays for parent (CPFP), it was possible for transactions to essentially become stuck forever if they didn't pay a high enough fee for miners to include them in a block.

In order to prevent this, a policy was introduced that allowed relaying transactions that do not pay enough fees based on a priority calculated from the fee as well as the age of coins being spent. The result is that the priority slowly increased over time as the coins aged to ensure such transactions would eventually be relayed and mined. In order to prevent abuse the behavior could otherwise allow, the policy also included additional rate-limiting of these types of transactions.

While the policy served its purpose, it had some downsides such as:

  • A confusing user experience where transactions that do not pay enough fees and also are not old enough to meet the dynamically changing priority requirements are rejected due to having insufficient priority instead of not paying enough fees as the user might expect
  • The priority requirements dynamically change over time which leads to non-deterministic behavior and thus ultimately results in what appear to be intermittent/transient failures to users

The policy is no longer necessary or desirable given such transactions can now use CPFP to increase the overall fee of the entire transaction chain thereby ensuring they are mined.

Unspent Transaction Output Set Size Reduction

The set of all unspent transaction outputs (UTXO set) no longer contains unspendable treasurybase outputs.

A treasurybase output is a special output that increases the balance of the decentralized treasury account which requires stakeholder approval to spend funds. As a result, they do not operate like normal transaction outputs and therefore are never directly spendable.

Removing these unspendable outputs from the UTXO set reduces its overall size.

No More Checkpoints

This release introduces a new model for deciding when to reject old forks to make use of the hard-coded assumed valid block that is updated with each release to a recent block thereby removing the final remaining usage of checkpoints.

Consequently, the --nocheckpoints command-line option and separate findcheckpoints utility have been removed.

Improved Network Protocol Message Responsiveness (getheaders/getcfilterv2)

All protocol message requests for headers (getheaders) and version 2 compact filters (getcfilterv2) will now receive empty responses when there is not any available data or the peer is o...

Read more

dcrd v1.7.7

07 Apr 14:33
release-v1.7.7
cd698cf
Compare
Choose a tag to compare

This is a patch release of dcrd that includes the following changes:

  • Use the latest network protocol version
  • Reduce bandwidth usage in certain scenarios by avoiding requests for inventory that is already known
  • Mitigate excessive CPU usage in some rare scenarios specific to the test network
  • Improve best address candidate selection efficiency

Changelog

This patch release consists of 19 commits from 3 contributors which total to 92 files changed, 1357 additional lines of code, and 1191 deleted lines of code.

All commits since the last release may be viewed on GitHub here.

Protocol and network:

Documentation:

Developer-related package and module changes:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Dave Collins
  • Eng Zer Jun
  • Jonathan Chappelow

dcrd v1.7.5

10 Oct 19:24
release-v1.7.5
f886cda
Compare
Choose a tag to compare

This is a patch release of dcrd that updates the utxo cache to improve its robustness, optimize it, and correct some hard to hit corner cases that involve a mix of manual block invalidation, conditional flushing, and successive unclean shutdowns.

Changelog

This patch release consists of 19 commits from 1 contributor which total to 13 files changed, 1118 additional lines of code, and 484 deleted lines of code.

All commits since the last release may be viewed on GitHub here.

Developer-related package and module changes:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Dave Collins

dcrd v1.7.4

03 Aug 18:57
release-v1.7.4
5cbec70
Compare
Choose a tag to compare

This is a patch release of dcrd to support modifications to version 3 of the test network as well as provide some minor improvements related to mining.

Changelog

This patch release consists of 10 commits from 2 contributors which total to 17 files changed, 225 additional lines of code, and 57 deleted lines of code.

All commits since the last release may be viewed on GitHub here and here.

Protocol and network:

Mining:

RPC:

Developer-related package and module changes:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Dave Collins
  • Jamie Holdstock