github decred/dcrd release-v2.0.0
dcrd v2.0.0
on GitHub

latest releases: release-v2.0.1, v1.9.1, mixing/v0.2.0...
15 days ago

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:

Mining:

RPC:

dcrd command-line flags and configuration:

Documentation:

Contrib changes:

Developer-related package and module changes:

Developer-related module management:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Billy Zelani Malik
  • Dave Collins
  • David Hill
  • Matheus Degiovani
  • Nicola Larosa
  • peicuiping
  • Peter Zen
  • Jamie Holdstock
  • Jonathan Chappelow
  • Josh Rickmark
  • SeedHammer
Check out latest releases or
releases around decred/dcrd release-v2.0.0

Don't miss a new dcrd release

NewReleases is sending notifications on new releases.

Get notifications