dcrd

Decred daemon in Go (golang).

ISC License

Stars
730
Committers
140
View Code on GitHub Visit Website View on X
Ecosystems: Go

Bot releases are visible (Hide)

dcrd - dcrd v2.0.1 Latest Release

Published by davecgh 5 months ago

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 - dcrd v2.0.0

Published by davecgh 5 months 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
dcrd - dcrd v1.8.1

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:

  • 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 ajustement 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 - dcrd v1.8.0

Published by davecgh over 1 year ago

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

Header Proof Commitment Hash Storage

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.

Address Index Removal (--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.

Several CLI Options Deprecated

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.

RPC Server Changes

The RPC server version as of this release is 8.0.0.

Total Coin Supply Output Correction (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.

More Stable Global Communication over WebSockets

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.

Winning Ticket Notifications when Unsynced Mining on Test Networks (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:

Transaction Fee Priority Fields on Mempool RPC Deprecated (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.

Removal of Raw Transaction Search RPC (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.

Removal of Address Index Status Field on Info RPC (getinfo)

The addrindex field of the getinfo RPC is no longer available.

See the getinfo JSON-RPC API Documentation for API details.

Removal of Missed and Expired Ticket RPCs

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

Updates to Work RPC (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.

Changelog

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.

Protocol and network:

Transaction relay (memory pool):

Mining:

RPC:

dcrd command-line flags and configuration:

dcrd server runtime interface changes:

findcheckpoint utility changes:

Documentation:

Contrib changes:

Developer-related package and module changes:

Developer-related module management:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Abirdcfly
  • Dave Collins
  • David Hill
  • Donald Adu-Poku
  • Eng Zer Jun
  • Jamie Holdstock
  • JoeGruff
  • Jonathan Chappelow
  • Josh Rickmar
  • Julian Y
  • Matheus Degiovani
  • Ryan Staudt
  • Sef Boukenken
  • arjundashrath
  • matthawkins90
  • norwnd
  • peterzen
  • 刘昆
dcrd - dcrd v1.7.7

Published by davecgh over 1 year ago

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 - dcrd v1.7.5

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.

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 - dcrd v1.7.4

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.

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
dcrd - dcrd v1.7.2

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.

Changelog

This patch release consists of 4 commits from 2 contributors which total to 11 files changed, 158 additional lines of code, and 15 deleted lines of code.

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

Protocol and network:

Developer-related package and module changes:

Misc:

Code Contributors (alphabetical order):

  • Dave Collins
  • Donald Adu-Poku
dcrd - dcrd v1.7.1

Published by davecgh over 2 years ago

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

  • Resolve an issue related to RPC authentication of limited users

Changelog

This patch release consists of 2 commits from 2 contributors which total to 3 files changed, 170 additional lines of code, and 35 deleted lines of code.

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

RPC:

Misc:

Code Contributors (alphabetical order):

  • Dave Collins
  • 刘昆
dcrd - dcrd v1.7.0

Published by davecgh over 2 years ago

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

  • Four new consensus vote agendas which allow stakeholders to decide whether or not to activate support for the following:
    • Reverting the Treasury maximum expenditure policy
    • Enforcing explicit version upgrades
    • Support for automatic ticket revocations for missed votes
    • Changing the Proof-of-Work and Proof-of-Stake subsidy split from 60%/30% to 10%/80%
  • Substantially reduced initial sync time
  • Major performance enhancements to unspent transaction output handling
  • Faster cryptographic signature validation
  • Significant improvements to network synchronization
  • Support for a configurable assumed valid block
  • Block index memory usage reduction
  • Asynchronous indexing
  • Version 1 block filters removal
  • Various updates to the RPC server:
    • Additional per-connection read limits
    • A more strict cross origin request policy
    • A new alternative client authentication mechanism based on TLS certificates
    • Availability of the scripting language version for transaction outputs
    • Several other notable updates, additions, and removals related to the JSON-RPC API
  • New developer modules:
    • Age-Partitioned Bloom Filters
    • Fixed-Precision Unsigned 256-bit Integers
    • Standard Scripts
    • Standard Addresses
  • Infrastructure improvements
  • Quality assurance changes

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

For reference, the consensus change work for each of the four changes was originally proposed and approved for initial implementation via the following Politeia proposals:

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

Upgrade Required

It is extremely important for everyone to upgrade their software to this latest release even if you don't intend to vote in favor of the agendas. This particularly applies to PoW miners as failure to upgrade will result in lost rewards after block height 635775. That is estimated to be around Feb 21st, 2022.

Downgrade Warning

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

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

The database migration typically takes around 40-50 minutes on HDDs and 20-30 minutes on SSDs.

Notable Changes

Four New Consensus Change Votes

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

Revert Treasury Maximum Expenditure Policy Vote

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

The primary goal of this change is to revert the currently active maximum expenditure policy of the decentralized Treasury to the one specified in the original Politeia proposal.

See DCP0007 for the full technical specification.

Explicit Version Upgrades Vote

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

The primary goals of this change are to:

  • Provide an easy, reliable, and efficient method for software and hardware to determine exactly which rules should be applied to transaction and script versions
  • Further embrace the increased security and other desirable properties that hard forks provide over soft forks

See the following for more details:

Automatic Ticket Revocations Vote

The third new vote available as of this release has the id autorevocations.

The primary goals of this change are to:

  • Improve the Decred stakeholder user experience by removing the requirement for stakeholders to manually revoke missed and expired tickets
  • Enable the recovery of funds for users who lost their redeem script for the legacy VSP system (before the release of vspd, which removed the need for the redeem script)

See the following for more details:

Change PoW/PoS Subsidy Split to 10/80 Vote

The fourth new vote available as of this release has the id changesubsidysplit.

The proposed modification to the subsidy split is intended to substantially diminish the ability to attack Decred's markets with mined coins and improve decentralization of the issuance process.

See the following for more details:

Substantially Reduced Initial Sync Time

The amount of time it takes to complete the initial chain synchronization process has been substantially reduced. With default settings, it is around 48% faster versus the previous release.

Unspent Transaction Output Overhaul

The way unspent transaction outputs (UTXOs) are handled has been significantly reworked to provide major performance enhancements to both steady-state operation as well as the initial chain sync process as follows:

  • Each UTXO is now tracked independently on a per-output basis
  • The UTXOs now reside in a dedicated database
  • All UTXO reads and writes now make use of a cache

Unspent Transaction Output Cache

All reads and writes of unspent transaction outputs (utxos) now go through a cache that sits on top of the utxo set database which drastically reduces the amount of reading and writing to disk, especially during the initial sync process when a very large number of blocks are being processed in quick succession.

This utxo cache provides significant runtime performance benefits at the cost of some additional memory usage. The maximum size of the cache can be configured with the new --utxocachemaxsize command-line configuration option. The default value is 150 MiB, the minimum value is 25 MiB, and the maximum value is 32768 MiB (32 GiB).

Some key properties of the cache are as follows:

  • For reads, the UTXO cache acts as a read-through cache
    • All UTXO reads go through the cache
    • Cache misses load the missing data from the disk and cache it for future lookups
  • For writes, the UTXO cache acts as a write-back cache
    • Writes to the cache are acknowledged by the cache immediately, but are only periodically flushed to disk
  • Allows intermediate steps to effectively be skipped thereby avoiding the need to write millions of entries to disk
  • On average, recent UTXOs are much more likely to be spent in upcoming blocks than older UTXOs, so only the oldest UTXOs are evicted as needed in order to maximize the hit ratio of the cache
  • The cache is periodically flushed with conditional eviction:
    • When the cache is NOT full, nothing is evicted, but the changes are still written to the disk set to allow for a quicker reconciliation in the case of an unclean shutdown
    • When the cache is full, 15% of the oldest UTXOs are evicted

Faster Cryptographic Signature Validation

Some aspects of the underlying crypto code has been updated to further improve its execution speed and reduce the number of memory allocations resulting in about a 1% reduction to signature verification time.

The primary benefits are:

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

Significant Improvements to Network Synchronization

The method used to obtain blocks from other peers on the network is now guided entirely by block headers. This provides a wide variety of benefits, but the most notable ones for most users are:

  • Faster initial synchronization
  • Reduced bandwidth usage
  • Enhanced protection against attempted DoS attacks
  • Percentage-based progress reporting
  • Improved steady state logging

Support for Configurable Assumed Valid Block

This release introduces a new model for deciding when several historical validation checks may be skipped for blocks that are an ancestor of a known good block.

Specifically, a new AssumeValid parameter is now used to specify the aforementioned known good block. The default value of the parameter is updated with each release to a recent block that is part of the main chain.

The default value of the parameter can be overridden with the --assumevalid command-line 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 hash

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

Block Index Memory Usage Reduction

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.

Asynchronous Indexing

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

Version 1 Block Filters Removal

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.

RPC Server Changes

The RPC server version as of this release is 7.0.0.

Max Request Limits

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:

  • 0 B / 8 MiB for pre and post auth HTTP connections
  • 4 KiB / 16 MiB for pre and post auth WebSocket connections

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.

More Strict Cross Origin Request (CORS) Policy

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.

Alternative Client Authentication Method Based on TLS Certificates

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.

Updates to Transaction Output Query RPC (gettxout)

The gettxout RPC has the following modifications:

  • An additional tree parameter is now required in order to explicitly identify the exact transaction output being requested
  • The transaction version field is no longer available in the primary JSON object of the results
  • The child scriptPubKey JSON object in the results now includes a new version field that identifies the scripting language version

See the gettxout JSON-RPC API Documentation for API details.

Removal of Stake Difficulty Notification RPCs (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.

Removal of Version 1 Filter RPCs (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.

New Median Time Field on Block Query RPCs (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:

New Scripting Language Version Field on Raw Transaction RPCs (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:

New Treasury Add Transaction Filter on Mempool Query RPC (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.

New Manual Block Invalidation and Reconsideration RPCs (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 Protocol Message Deprecated (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:

  • 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

No DNS Seeds Command-Line Option Deprecated (--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.

Notable New Developer Modules

Age-Partitioned Bloom Filters

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.

Fixed-Precision Unsigned 256-bit Integers

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.

Standard Scripts

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.

Standard Addresses

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.

Changelog

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.

Protocol and network:

Transaction relay (memory pool):

Mining:

RPC:

dcrd command-line flags and configuration:

gencerts utility changes:

addblock utility changes:

findcheckpoint utility changes:

Documentation:

Contrib changes:

Developer-related package and module changes:

Developer-related module management:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • briancolecoinmetrics
  • Dave Collins
  • David Hill
  • degeri
  • Donald Adu-Poku
  • J Fixby
  • Jamie Holdstock
  • Joe Gruffins
  • Jonathan Chappelow
  • Josh Rickmar
  • lolandhold
  • Matheus Degiovani
  • Naveen
  • Ryan Staudt
  • Youssef Boukenken
  • Wisdom Arerosuoghene
dcrd - dcrd v1.7.0-rc2

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.

Changelog

This updated release candidate consists of 1 commit from 1 contributor which total to 2 files changed, 14 additional lines of code, and 7 deleted lines of code.

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

RPC:

Code Contributors (alphabetical order):

  • Dave Collins
dcrd - dcrd v1.7.0-rc1

Published by davecgh almost 3 years ago

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

  • Four new consensus vote agendas which allow stakeholders to decide whether or not to activate support for the following:
    • Reverting the Treasury maximum expenditure policy
    • Enforcing explicit version upgrades
    • Support for automatic ticket revocations for missed votes
    • Changing the Proof-of-Work and Proof-of-Stake subsidy split from 60%/30% to 10%/80%
  • Substantially reduced initial sync time
  • Major performance enhancements to unspent transaction output handling
  • Faster cryptographic signature validation
  • Significant improvements to network synchronization
  • Support for a configurable assumed valid block
  • Block index memory usage reduction
  • Asynchronous indexing
  • Version 1 block filters removal
  • Various updates to the RPC server:
    • Additional per-connection read limits
    • A more strict cross origin request policy
    • A new alternative client authentication mechanism based on TLS certificates
    • Availability of the scripting language version for transaction outputs
    • Several other notable updates, additions, and removals related to the JSON-RPC API
  • New developer modules:
    • Age-Partitioned Bloom Filters
    • Fixed-Precision Unsigned 256-bit Integers
    • Standard Scripts
    • Standard Addresses
  • Infrastructure improvements
  • Quality assurance changes

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

For reference, the consensus change work for each of the four changes was originally proposed and approved for initial implementation via the following Politeia proposals:

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

It is important for everyone to upgrade their software to this latest release even if you don't intend to vote in favor of the agenda.

Downgrade Warning

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

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

The database migration typically takes around 40-50 minutes on HDDs and 20-30 minutes on SSDs.

Notable Changes

Four New Consensus Change Votes

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

Revert Treasury Maximum Expenditure Policy Vote

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

The primary goal of this change is to revert the currently active maximum expenditure policy of the decentralized Treasury to the one specified in the original Politeia proposal.

See DCP0007 for the full technical specification.

Explicit Version Upgrades Vote

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

The primary goals of this change are to:

  • Provide an easy, reliable, and efficient method for software and hardware to determine exactly which rules should be applied to transaction and script versions
  • Further embrace the increased security and other desirable properties that hard forks provide over soft forks

See the following for more details:

Automatic Ticket Revocations Vote

The third new vote available as of this release has the id autorevocations.

The primary goals of this change are to:

  • Improve the Decred stakeholder user experience by removing the requirement for stakeholders to manually revoke missed and expired tickets
  • Enable the recovery of funds for users who lost their redeem script for the legacy VSP system (before the release of vspd, which removed the need for the redeem script)

See the following for more details:

Change PoW/PoS Subsidy Split to 10/80 Vote

The fourth new vote available as of this release has the id changesubsidysplit.

The proposed modification to the subsidy split is intended to substantially diminish the ability to attack Decred's markets with mined coins and improve decentralization of the issuance process.

See the following for more details:

Substantially Reduced Initial Sync Time

The amount of time it takes to complete the initial chain synchronization process has been substantially reduced. With default settings, it is around 48% faster versus the previous release.

Unspent Transaction Output Overhaul

The way unspent transaction outputs (UTXOs) are handled has been significantly reworked to provide major performance enhancements to both steady-state operation as well as the initial chain sync process as follows:

  • Each UTXO is now tracked independently on a per-output basis
  • The UTXOs now reside in a dedicated database
  • All UTXO reads and writes now make use of a cache

Unspent Transaction Output Cache

All reads and writes of unspent transaction outputs (utxos) now go through a cache that sits on top of the utxo set database which drastically reduces the amount of reading and writing to disk, especially during the initial sync process when a very large number of blocks are being processed in quick succession.

This utxo cache provides significant runtime performance benefits at the cost of some additional memory usage. The maximum size of the cache can be configured with the new --utxocachemaxsize command-line configuration option. The default value is 150 MiB, the minimum value is 25 MiB, and the maximum value is 32768 MiB (32 GiB).

Some key properties of the cache are as follows:

  • For reads, the UTXO cache acts as a read-through cache
    • All UTXO reads go through the cache
    • Cache misses load the missing data from the disk and cache it for future lookups
  • For writes, the UTXO cache acts as a write-back cache
    • Writes to the cache are acknowledged by the cache immediately, but are only periodically flushed to disk
  • Allows intermediate steps to effectively be skipped thereby avoiding the need to write millions of entries to disk
  • On average, recent UTXOs are much more likely to be spent in upcoming blocks than older UTXOs, so only the oldest UTXOs are evicted as needed in order to maximize the hit ratio of the cache
  • The cache is periodically flushed with conditional eviction:
    • When the cache is NOT full, nothing is evicted, but the changes are still written to the disk set to allow for a quicker reconciliation in the case of an unclean shutdown
    • When the cache is full, 15% of the oldest UTXOs are evicted

Faster Cryptographic Signature Validation

Some aspects of the underlying crypto code has been updated to further improve its execution speed and reduce the number of memory allocations resulting in about a 1% reduction to signature verification time.

The primary benefits are:

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

Significant Improvements to Network Synchronization

The method used to obtain blocks from other peers on the network is now guided entirely by block headers. This provides a wide variety of benefits, but the most notable ones for most users are:

  • Faster initial synchronization
  • Reduced bandwidth usage
  • Enhanced protection against attempted DoS attacks
  • Percentage-based progress reporting
  • Improved steady state logging

Support for Configurable Assumed Valid Block

This release introduces a new model for deciding when several historical validation checks may be skipped for blocks that are an ancestor of a known good block.

Specifically, a new AssumeValid parameter is now used to specify the aforementioned known good block. The default value of the parameter is updated with each release to a recent block that is part of the main chain.

The default value of the parameter can be overridden with the --assumevalid command-line option by setting it as follows:

  • --assumevalid=0: Disable the feature resulting in no skipped validation checks
  • --assumevalid=[blockhash]: Set AssumeValid to the specified block hash

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

Block Index Memory Usage Reduction

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.

Asynchronous Indexing

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

Version 1 Block Filters Removal

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.

RPC Server Changes

The RPC server version as of this release is 7.0.0.

Max Request Limits

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:

  • 0 B / 8 MiB for pre and post auth HTTP connections
  • 4 KiB / 16 MiB for pre and post auth WebSocket connections

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.

More Strict Cross Origin Request (CORS) Policy

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.

Alternative Client Authentication Method Based on TLS Certificates

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.

Updates to Transaction Output Query RPC (gettxout)

The gettxout RPC has the following modifications:

  • An additional tree parameter is now required in order to explicitly identify the exact transaction output being requested
  • The transaction version field is no longer available in the primary JSON object of the results
  • The child scriptPubKey JSON object in the results now includes a new version field that identifies the scripting language version

See the gettxout JSON-RPC API Documentation for API details.

Removal of Stake Difficulty Notification RPCs (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.

Removal of Version 1 Filter RPCs (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.

New Median Time Field on Block Query RPCs (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:

New Scripting Language Version Field on Raw Transaction RPCs (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:

New Treasury Add Transaction Filter on Mempool Query RPC (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.

New Manual Block Invalidation and Reconsideration RPCs (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 Protocol Message Deprecated (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:

  • 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

No DNS Seeds Command-Line Option Deprecated (--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.

Notable New Developer Modules

Age-Partitioned Bloom Filters

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.

Fixed-Precision Unsigned 256-bit Integers

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.

Standard Scripts

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.

Standard Addresses

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.

Changelog

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.

Protocol and network:

Transaction relay (memory pool):

Mining:

RPC:

dcrd command-line flags and configuration:

gencerts utility changes:

addblock utility changes:

findcheckpoint utility changes:

Documentation:

Contrib changes:

Developer-related package and module changes:

Developer-related module management:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • briancolecoinmetrics
  • Dave Collins
  • David Hill
  • degeri
  • Donald Adu-Poku
  • J Fixby
  • Jamie Holdstock
  • Joe Gruffins
  • Jonathan Chappelow
  • Josh Rickmar
  • lolandhold
  • Matheus Degiovani
  • Naveen
  • Ryan Staudt
  • Youssef Boukenken
  • Wisdom Arerosuoghene
dcrd - dcrd v1.6.2

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.

Changelog

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.

Protocol and network:

Misc:

Code Contributors (alphabetical order):

  • Dave Collins
dcrd - dcrd v1.6.1

Published by davecgh over 3 years ago

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

  • Correct a hard to hit issue where connections might not be reestablished after a network outage under some rare circumstances
  • Allow stakeholders to make use of the staking system to force proof-of-work miners to upgrade to the latest version so voting on the new consensus changes can commence

Changelog

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.

Protocol and network:

Misc:

Code Contributors (alphabetical order):

  • Dave Collins
dcrd - dcrd v1.6.0

Published by davecgh over 3 years ago

This release of dcrd introduces a large number of updates. Some of the key highlights are:

  • A new consensus vote agenda which allows the stakeholders to decide whether or not to activate support for a decentralized treasury
  • Aggregate fee transaction selection in block templates (Child Pays For Parent)
  • Improved peer discovery via HTTPS seeding with filtering capabilities
  • Major performance enhancements for signature validation and other cryptographic operations
  • Approximately 15% less overall resident memory usage
  • Proactive signature cache eviction
  • Improved support for single-party Schnorr signatures
  • Ticket exhaustion prevention
  • Various updates to the RPC server such as:
    • A new method to retrieve the current treasury balance
    • A new method to query treasury spend transaction vote details
  • Infrastructure improvements
  • Quality assurance changes

For those unfamiliar with the voting process in Decred, all code needed in order to support a decentralized treasury is already included in this release, however it will remain dormant until the stakeholders vote to activate it.

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

The following Decred Change Proposal (DCP) describes the proposed changes in detail and provides a full technical specification:

It is important for everyone to upgrade their software to this latest release even if you don't intend to vote in favor of the agenda.

Downgrade Warning

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

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

The database migration typically takes about 5 to 10 minutes on HDDs and 2 to 4 minutes on SSDs.

Notable Changes

Decentralized Treasury Vote

A new vote with the id treasury is now available as of this release. After upgrading, stakeholders may set their preferences through their wallet or Voting Service Provider's (VSP) website.

The primary goal of this change is to fully decentralize treasury spending so that it is controlled by the stakeholders via ticket voting.

See the initial Politeia proposal for more details.

Aggregate Fee Block Template Transaction Selection (Child Pays For Parent)

The transactions that are selected for inclusion in block templates that Proof-of-Work miners solve now prioritize the overall fees of the entire
transaction ancestor graph.

This is beneficial for both miners and end users as it:

  • Helps maximize miner profit by ensuring that unconfirmed transaction chains with higher aggregate fees are given priority over others with lower aggregate fees
  • Provides a mechanism for users to increase the priority of an unconfirmed transaction by spending its outputs with another transaction that pays higher fees

This is commonly referred to as Child Pays For Parent (CPFP) as the spending ("child") transaction is able to increase the priority of the spent ("parent") transaction.

HTTPS Seeding

The initial bootstrap process that contacts seeders to discover other nodes to connect to now uses a REST-based API over HTTPS.

This change will be imperceptible for most users, with the exception that it accelerates the process of finding suitable candidate nodes that support desired services, particularly in the case of recently-introduced services that have not yet achieved widespread adoption on the network.

The following are some key benefits of HTTPS seeders over the previous DNS-based seeders:

  • Support for non-standard ports
  • Advertisement of supported service
  • Better scalability both in terms of network load and new features
  • Native support for TLS-secured communication channels
  • Native support for proxies which allows the use of anonymous overlay networks such as Tor and I2P
  • No need for a large DNSSEC dependency surface
  • Uses better audited infrastructure
  • More secure
  • Increases flexibility

Signature Validation And Other Crypto Operation Optimizations

The underlying crypto code has been reworked to significantly improve its execution speed and reduce the number of memory allocations. While this has more benefits than enumerated here, probably the most important ones for most stakeholders are:

  • Improved vote times since blocks and transactions propagate more quickly throughout the network
  • The initial sync process is around 15% faster

Proactive Signature Cache Eviction

Signature cache entries that are nearly guaranteed to no longer be useful are now immediately and proactively evicted resulting in overall faster validation during steady state operation due to fewer cache misses.

The primary purpose of the cache is to avoid double checking signatures that are already known to be valid.

Orphan Transaction Relay Policy Refinement

Transactions that spend outputs which are not known to nodes relaying them, known as orphan transactions, now have the same size restrictions applied to them as standard non-orphan transactions.

This ensures that transactions chains are not artificially hindered from relaying regardless of the order they are received.

In order to keep memory usage of the now potentially larger orphan transactions under control, more intelligent orphan eviction has been implemented and the maximum number of allowed orphans before random eviction occurs has been lowered.

These changes, in conjunction with other related changes, mean that nodes are better about orphan transaction management and thus missing ancestors will typically either be broadcast or mined fairly quickly resulting in fewer overall orphans and smaller actual run-time orphan pools.

Ticket Exhaustion Prevention

Mining templates that would lead to the chain becoming unrecoverable due to inevitable ticket exhaustion will no longer be generated.

This is primarily aimed at the testing networks, but it could also theoretically affect the main network in some far future if the demand for tickets were to ever dry up for some unforeseen reason.

New Initial State Protocol Messages (getinitstate/initstate)

This release introduces a pair of peer-to-peer protocol messages named getinitstate and initstate which support querying one or more pieces of information that are useful to acquire when a node first connects in a consolidated fashion.

Some examples of the aforementioned information are the mining state as of the current tip block and, with the introduction of the decentralized treasury, any outstanding treasury spend transactions that are being voted on.

Mining State Protocol Messages Deprecated (getminings/minings)

Due to the addition of the previously-described initial state peer-to-peer protocol messages, the getminings and minings protocol messages are now deprecated. Use the new getinitstate and initstate messages with the headblocks and headblockvotes state types instead.

RPC Server Changes

The RPC server version as of this release is 6.2.0.

New Treasury Balance Query RPC (gettreasurybalance)

A new RPC named gettreasurybalance is now available to query the current balance of the decentralized treasury. Please note that this requires the decentralized treasury vote to pass and become active, so it will return an appropriate error indicating the decentralized treasury is inactive until that time.

See the gettreasurybalance JSON-RPC API Documentation for API details.

New Treasury Spend Vote Query RPC (gettreasuryspendvotes)

A new RPC named gettreasuryspendvotes is now available to query vote information about one or more treasury spend transactions. Please note that this requires the decentralized treasury vote to pass and become active to produce a meaningful result since treasury spend transactions are invalid until that time.

See the gettreasuryspendvotes JSON-RPC API Documentation for API details.

New Force Mining Template Regeneration RPC (regentemplate)

A new RPC named regentemplate is now available which can be used to force the current background block template to be regenerated.

See the regentemplate JSON-RPC API Documentation for API details.

New Unspent Transaction Output Set Query RPC (gettxoutsetinfo)

A new RPC named gettxoutsetinfo is now available which can be used to retrieve statistics about the current global set of unspent transaction outputs (UTXOs).

See the gettxoutsetinfo JSON-RPC API Documentation for API details.

Updates to Peer Information Query RPC (getpeerinfo)

The results of the getpeerinfo RPC are now sorted by the id field.

See the getpeerinfo JSON-RPC API Documentation for API details.

Enforced Results Limit on Transaction Search RPC (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.

New Index Status Fields on Info Query RPC (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.

Version 1 Block Filters Deprecated

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.

Changelog

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.

Protocol and network:

Transaction relay (memory pool):

Mining:

RPC:

dcrd command-line flags and configuration:

gencerts utility changes:

dcrctl utility changes:

Documentation:

Developer-related package and module changes:

Developer-related module management:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Brian Stafford
  • Dave Collins
  • David Hill
  • degeri
  • Donald Adu-Poku
  • Jamie Holdstock
  • Joe Gruffins
  • Josh Rickmar
  • Julian Yap
  • Marco Peereboom
  • Matheus Degiovani
  • Matt Hawkins
  • Ryan Riley
  • Ryan Staudt
  • Wisdom Arerosuoghene
  • Youssef Boukenken
  • zhizhongzhiwai
dcrd - dcrd v1.6.0-rc5

Published by davecgh almost 4 years ago

This release of dcrd introduces a large number of updates. Some of the key highlights are:

  • A new consensus vote agenda which allows the stakeholders to decide whether or not to activate support for a decentralized treasury
  • Aggregate fee transaction selection in block templates (Child Pays For Parent)
  • Improved peer discovery via HTTPS seeding with filtering capabilities
  • Major performance enhancements for signature validation and other cryptographic operations
  • Approximately 15% less overall resident memory usage
  • Proactive signature cache eviction
  • Improved support for single-party Schnorr signatures
  • Ticket exhaustion prevention
  • Various updates to the RPC server such as:
    • A new method to retrieve the current treasury balance
    • A new method to query treasury spend transaction vote details
  • Infrastructure improvements
  • Quality assurance changes

For those unfamiliar with the voting process in Decred, all code needed in order to support a decentralized treasury is already included in this release, however it will remain dormant until the stakeholders vote to activate it.

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

The following Decred Change Proposal (DCP) describes the proposed changes in detail and provides a full technical specification:

It is important for everyone to upgrade their software to this latest release even if you don't intend to vote in favor of the agenda.

Downgrade Warning

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

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

The database migration typically takes about 5 to 10 minutes on HDDs and 2 to 4 minutes on SSDs.

Notable Changes

Decentralized Treasury Vote

A new vote with the id treasury is now available as of this release. After upgrading, stakeholders may set their preferences through their wallet or Voting Service Provider's (VSP) website.

The primary goal of this change is to fully decentralize treasury spending so that it is controlled by the stakeholders via ticket voting.

See the initial Politeia proposal for more details.

Aggregate Fee Block Template Transaction Selection (Child Pays For Parent)

The transactions that are selected for inclusion in block templates that Proof-of-Work miners solve now prioritize the overall fees of the entire
transaction ancestor graph.

This is beneficial for both miners and end users as it:

  • Helps maximize miner profit by ensuring that unconfirmed transaction chains with higher aggregate fees are given priority over others with lower aggregate fees
  • Provides a mechanism for users to increase the priority of an unconfirmed transaction by spending its outputs with another transaction that pays higher fees

This is commonly referred to as Child Pays For Parent (CPFP) as the spending ("child") transaction is able to increase the priority of the spent ("parent") transaction.

HTTPS Seeding

The initial bootstrap process that contacts seeders to discover other nodes to connect to now uses a REST-based API over HTTPS.

This change will be imperceptible for most users, with the exception that it accelerates the process of finding suitable candidate nodes that support desired services, particularly in the case of recently-introduced services that have not yet achieved widespread adoption on the network.

The following are some key benefits of HTTPS seeders over the previous DNS-based seeders:

  • Support for non-standard ports
  • Advertisement of supported service
  • Better scalability both in terms of network load and new features
  • Native support for TLS-secured communication channels
  • Native support for proxies which allows the use of anonymous overlay networks such as Tor and I2P
  • No need for a large DNSSEC dependency surface
  • Uses better audited infrastructure
  • More secure
  • Increases flexibility

Signature Validation And Other Crypto Operation Optimizations

The underlying crypto code has been reworked to significantly improve its execution speed and reduce the number of memory allocations. While this has more benefits than enumerated here, probably the most important ones for most stakeholders are:

  • Improved vote times since blocks and transactions propagate more quickly throughout the network
  • The initial sync process is around 15% faster

Proactive Signature Cache Eviction

Signature cache entries that are nearly guaranteed to no longer be useful are now immediately and proactively evicted resulting in overall faster validation during steady state operation due to fewer cache misses.

The primary purpose of the cache is to avoid double checking signatures that are already known to be valid.

Orphan Transaction Relay Policy Refinement

Transactions that spend outputs which are not known to nodes relaying them, known as orphan transactions, now have the same size restrictions applied to them as standard non-orphan transactions.

This ensures that transactions chains are not artificially hindered from relaying regardless of the order they are received.

In order to keep memory usage of the now potentially larger orphan transactions under control, more intelligent orphan eviction has been implemented and the maximum number of allowed orphans before random eviction occurs has been lowered.

These changes, in conjunction with other related changes, mean that nodes are better about orphan transaction management and thus missing ancestors will typically either be broadcast or mined fairly quickly resulting in fewer overall orphans and smaller actual run-time orphan pools.

Ticket Exhaustion Prevention

Mining templates that would lead to the chain becoming unrecoverable due to inevitable ticket exhaustion will no longer be generated.

This is primarily aimed at the testing networks, but it could also theoretically affect the main network in some far future if the demand for tickets were to ever dry up for some unforeseen reason.

New Initial State Protocol Messages (getinitstate/initstate)

This release introduces a pair of peer-to-peer protocol messages named getinitstate and initstate which support querying one or more pieces of information that are useful to acquire when a node first connects in a consolidated fashion.

Some examples of the aforementioned information are the mining state as of the current tip block and, with the introduction of the decentralized treasury, any outstanding treasury spend transactions that are being voted on.

Mining State Protocol Messages Deprecated (getminings/minings)

Due to the addition of the previously-described initial state peer-to-peer protocol messages, the getminings and minings protocol messages are now deprecated. Use the new getinitstate and initstate messages with the headblocks and headblockvotes state types instead.

RPC Server Changes

The RPC server version as of this release is 6.2.0.

New Treasury Balance Query RPC (gettreasurybalance)

A new RPC named gettreasurybalance is now available to query the current balance of the decentralized treasury. Please note that this requires the decentralized treasury vote to pass and become active, so it will return an appropriate error indicating the decentralized treasury is inactive until that time.

See the gettreasurybalance JSON-RPC API Documentation for API details.

New Treasury Spend Vote Query RPC (gettreasuryspendvotes)

A new RPC named gettreasuryspendvotes is now available to query vote information about one or more treasury spend transactions. Please note that this requires the decentralized treasury vote to pass and become active to produce a meaningful result since treasury spend transactions are invalid until that time.

See the gettreasuryspendvotes JSON-RPC API Documentation for API details.

New Force Mining Template Regeneration RPC (regentemplate)

A new RPC named regentemplate is now available which can be used to force the current background block template to be regenerated.

See the regentemplate JSON-RPC API Documentation for API details.

New Unspent Transaction Output Set Query RPC (gettxoutsetinfo)

A new RPC named gettxoutsetinfo is now available which can be used to retrieve statistics about the current global set of unspent transaction outputs (UTXOs).

See the gettxoutsetinfo JSON-RPC API Documentation for API details.

Updates to Peer Information Query RPC (getpeerinfo)

The results of the getpeerinfo RPC are now sorted by the id field.

See the getpeerinfo JSON-RPC API Documentation for API details.

Enforced Results Limit on Transaction Search RPC (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.

New Index Status Fields on Info Query RPC (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.

Version 1 Block Filters Deprecated

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.

Changelog

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.

Protocol and network:

Transaction relay (memory pool):

Mining:

RPC:

dcrd command-line flags and configuration:

gencerts utility changes:

dcrctl utility changes:

Documentation:

Developer-related package and module changes:

Developer-related module management:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Brian Stafford
  • Dave Collins
  • David Hill
  • degeri
  • Donald Adu-Poku
  • Jamie Holdstock
  • Joe Gruffins
  • Josh Rickmar
  • Julian Yap
  • Marco Peereboom
  • Matheus Degiovani
  • Matt Hawkins
  • Ryan Riley
  • Ryan Staudt
  • Wisdom Arerosuoghene
  • Youssef Boukenken
  • zhizhongzhiwai
dcrd - dcrd v1.6.0-rc4

Published by davecgh almost 4 years ago

This release of dcrd introduces a large number of updates. Some of the key highlights are:

  • A new consensus vote agenda which allows the stakeholders to decide whether or not to activate support for a decentralized treasury
  • Aggregate fee transaction selection in block templates (Child Pays For Parent)
  • Improved peer discovery via HTTPS seeding with filtering capabilities
  • Major performance enhancements for signature validation and other cryptographic operations
  • Approximately 15% less overall resident memory usage
  • Proactive signature cache eviction
  • Improved support for single-party Schnorr signatures
  • Ticket exhaustion prevention
  • Various updates to the RPC server such as:
    • A new method to retrieve the current treasury balance
    • A new method to query treasury spend transaction vote details
  • Infrastructure improvements
  • Quality assurance changes

For those unfamiliar with the voting process in Decred, all code needed in order to support a decentralized treasury is already included in this release, however it will remain dormant until the stakeholders vote to activate it.

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

The following Decred Change Proposal (DCP) describes the proposed changes in detail and provides a full technical specification:

It is important for everyone to upgrade their software to this latest release even if you don't intend to vote in favor of the agenda.

Downgrade Warning

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

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

The database migration typically takes about 5 to 10 minutes on HDDs and 2 to 4 minutes on SSDs.

Notable Changes

Decentralized Treasury Vote

A new vote with the id treasury is now available as of this release. After upgrading, stakeholders may set their preferences through their wallet or Voting Service Provider's (VSP) website.

The primary goal of this change is to fully decentralize treasury spending so that it is controlled by the stakeholders via ticket voting.

See the initial Politeia proposal for more details.

Aggregate Fee Block Template Transaction Selection (Child Pays For Parent)

The transactions that are selected for inclusion in block templates that Proof-of-Work miners solve now prioritize the overall fees of the entire
transaction ancestor graph.

This is beneficial for both miners and end users as it:

  • Helps maximize miner profit by ensuring that unconfirmed transaction chains with higher aggregate fees are given priority over others with lower aggregate fees
  • Provides a mechanism for users to increase the priority of an unconfirmed transaction by spending its outputs with another transaction that pays higher fees

This is commonly referred to as Child Pays For Parent (CPFP) as the spending ("child") transaction is able to increase the priority of the spent ("parent") transaction.

HTTPS Seeding

The initial bootstrap process that contacts seeders to discover other nodes to connect to now uses a REST-based API over HTTPS.

This change will be imperceptible for most users, with the exception that it accelerates the process of finding suitable candidate nodes that support desired services, particularly in the case of recently-introduced services that have not yet achieved widespread adoption on the network.

The following are some key benefits of HTTPS seeders over the previous DNS-based seeders:

  • Support for non-standard ports
  • Advertisement of supported service
  • Better scalability both in terms of network load and new features
  • Native support for TLS-secured communication channels
  • Native support for proxies which allows the use of anonymous overlay networks such as Tor and I2P
  • No need for a large DNSSEC dependency surface
  • Uses better audited infrastructure
  • More secure
  • Increases flexibility

Signature Validation And Other Crypto Operation Optimizations

The underlying crypto code has been reworked to significantly improve its execution speed and reduce the number of memory allocations. While this has more benefits than enumerated here, probably the most important ones for most stakeholders are:

  • Improved vote times since blocks and transactions propagate more quickly throughout the network
  • The initial sync process is around 15% faster

Proactive Signature Cache Eviction

Signature cache entries that are nearly guaranteed to no longer be useful are now immediately and proactively evicted resulting in overall faster validation during steady state operation due to fewer cache misses.

The primary purpose of the cache is to avoid double checking signatures that are already known to be valid.

Orphan Transaction Relay Policy Refinement

Transactions that spend outputs which are not known to nodes relaying them, known as orphan transactions, now have the same size restrictions applied to them as standard non-orphan transactions.

This ensures that transactions chains are not artificially hindered from relaying regardless of the order they are received.

In order to keep memory usage of the now potentially larger orphan transactions under control, more intelligent orphan eviction has been implemented and the maximum number of allowed orphans before random eviction occurs has been lowered.

These changes, in conjunction with other related changes, mean that nodes are better about orphan transaction management and thus missing ancestors will typically either be broadcast or mined fairly quickly resulting in fewer overall orphans and smaller actual run-time orphan pools.

Ticket Exhaustion Prevention

Mining templates that would lead to the chain becoming unrecoverable due to inevitable ticket exhaustion will no longer be generated.

This is primarily aimed at the testing networks, but it could also theoretically affect the main network in some far future if the demand for tickets were to ever dry up for some unforeseen reason.

New Initial State Protocol Messages (getinitstate/initstate)

This release introduces a pair of peer-to-peer protocol messages named getinitstate and initstate which support querying one or more pieces of information that are useful to acquire when a node first connects in a consolidated fashion.

Some examples of the aforementioned information are the mining state as of the current tip block and, with the introduction of the decentralized treasury, any outstanding treasury spend transactions that are being voted on.

Mining State Protocol Messages Deprecated (getminings/minings)

Due to the addition of the previously-described initial state peer-to-peer protocol messages, the getminings and minings protocol messages are now deprecated. Use the new getinitstate and initstate messages with the headblocks and headblockvotes state types instead.

RPC Server Changes

The RPC server version as of this release is 6.2.0.

New Treasury Balance Query RPC (gettreasurybalance)

A new RPC named gettreasurybalance is now available to query the current balance of the decentralized treasury. Please note that this requires the decentralized treasury vote to pass and become active, so it will return an appropriate error indicating the decentralized treasury is inactive until that time.

See the gettreasurybalance JSON-RPC API Documentation for API details.

New Treasury Spend Vote Query RPC (gettreasuryspendvotes)

A new RPC named gettreasuryspendvotes is now available to query vote information about one or more treasury spend transactions. Please note that this requires the decentralized treasury vote to pass and become active to produce a meaningful result since treasury spend transactions are invalid until that time.

See the gettreasuryspendvotes JSON-RPC API Documentation for API details.

New Force Mining Template Regeneration RPC (regentemplate)

A new RPC named regentemplate is now available which can be used to force the current background block template to be regenerated.

See the regentemplate JSON-RPC API Documentation for API details.

New Unspent Transaction Output Set Query RPC (gettxoutsetinfo)

A new RPC named gettxoutsetinfo is now available which can be used to retrieve statistics about the current global set of unspent transaction outputs (UTXOs).

See the gettxoutsetinfo JSON-RPC API Documentation for API details.

Updates to Peer Information Query RPC (getpeerinfo)

The results of the getpeerinfo RPC are now sorted by the id field.

See the getpeerinfo JSON-RPC API Documentation for API details.

Enforced Results Limit on Transaction Search RPC (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.

New Index Status Fields on Info Query RPC (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.

Version 1 Block Filters Deprecated

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.

Changelog

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.

Protocol and network:

Transaction relay (memory pool):

Mining:

RPC:

dcrd command-line flags and configuration:

gencerts utility changes:

dcrctl utility changes:

Documentation:

Developer-related package and module changes:

Developer-related module management:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Brian Stafford
  • Dave Collins
  • David Hill
  • degeri
  • Donald Adu-Poku
  • Jamie Holdstock
  • Joe Gruffins
  • Josh Rickmar
  • Julian Yap
  • Marco Peereboom
  • Matheus Degiovani
  • Matt Hawkins
  • Ryan Riley
  • Ryan Staudt
  • Wisdom Arerosuoghene
  • Youssef Boukenken
  • zhizhongzhiwai
dcrd - dcrd v1.6.0-rc3

Published by davecgh almost 4 years ago

This release of dcrd introduces a large number of updates. Some of the key highlights are:

  • A new consensus vote agenda which allows the stakeholders to decide whether or not to activate support for a decentralized treasury
  • Aggregate fee transaction selection in block templates (Child Pays For Parent)
  • Improved peer discovery via HTTPS seeding with filtering capabilities
  • Major performance enhancements for signature validation and other cryptographic operations
  • Approximately 15% less overall resident memory usage
  • Proactive signature cache eviction
  • Improved support for single-party Schnorr signatures
  • Ticket exhaustion prevention
  • Various updates to the RPC server such as:
    • A new method to retrieve the current treasury balance
    • A new method to query treasury spend transaction vote details
  • Infrastructure improvements
  • Quality assurance changes

For those unfamiliar with the voting process in Decred, all code needed in order to support a decentralized treasury is already included in this release, however it will remain dormant until the stakeholders vote to activate it.

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

The following Decred Change Proposal (DCP) describes the proposed changes in detail and provides a full technical specification:

It is important for everyone to upgrade their software to this latest release even if you don't intend to vote in favor of the agenda.

Downgrade Warning

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

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

The database migration typically takes about 5 to 10 minutes on HDDs and 2 to 4 minutes on SSDs.

Notable Changes

Decentralized Treasury Vote

A new vote with the id treasury is now available as of this release. After upgrading, stakeholders may set their preferences through their wallet or Voting Service Provider's (VSP) website.

The primary goal of this change is to fully decentralize treasury spending so that it is controlled by the stakeholders via ticket voting.

See the initial Politeia proposal for more details.

Aggregate Fee Block Template Transaction Selection (Child Pays For Parent)

The transactions that are selected for inclusion in block templates that Proof-of-Work miners solve now prioritize the overall fees of the entire
transaction ancestor graph.

This is beneficial for both miners and end users as it:

  • Helps maximize miner profit by ensuring that unconfirmed transaction chains with higher aggregate fees are given priority over others with lower aggregate fees
  • Provides a mechanism for users to increase the priority of an unconfirmed transaction by spending its outputs with another transaction that pays higher fees

This is commonly referred to as Child Pays For Parent (CPFP) as the spending ("child") transaction is able to increase the priority of the spent ("parent") transaction.

HTTPS Seeding

The initial bootstrap process that contacts seeders to discover other nodes to connect to now uses a REST-based API over HTTPS.

This change will be imperceptible for most users, with the exception that it accelerates the process of finding suitable candidate nodes that support desired services, particularly in the case of recently-introduced services that have not yet achieved widespread adoption on the network.

The following are some key benefits of HTTPS seeders over the previous DNS-based seeders:

  • Support for non-standard ports
  • Advertisement of supported service
  • Better scalability both in terms of network load and new features
  • Native support for TLS-secured communication channels
  • Native support for proxies which allows the use of anonymous overlay networks such as Tor and I2P
  • No need for a large DNSSEC dependency surface
  • Uses better audited infrastructure
  • More secure
  • Increases flexibility

Signature Validation And Other Crypto Operation Optimizations

The underlying crypto code has been reworked to significantly improve its execution speed and reduce the number of memory allocations. While this has more benefits than enumerated here, probably the most important ones for most stakeholders are:

  • Improved vote times since blocks and transactions propagate more quickly throughout the network
  • The initial sync process is around 15% faster

Proactive Signature Cache Eviction

Signature cache entries that are nearly guaranteed to no longer be useful are now immediately and proactively evicted resulting in overall faster validation during steady state operation due to fewer cache misses.

The primary purpose of the cache is to avoid double checking signatures that are already known to be valid.

Orphan Transaction Relay Policy Refinement

Transactions that spend outputs which are not known to nodes relaying them, known as orphan transactions, now have the same size restrictions applied to them as standard non-orphan transactions.

This ensures that transactions chains are not artificially hindered from relaying regardless of the order they are received.

In order to keep memory usage of the now potentially larger orphan transactions under control, more intelligent orphan eviction has been implemented and the maximum number of allowed orphans before random eviction occurs has been lowered.

These changes, in conjunction with other related changes, mean that nodes are better about orphan transaction management and thus missing ancestors will typically either be broadcast or mined fairly quickly resulting in fewer overall orphans and smaller actual run-time orphan pools.

Ticket Exhaustion Prevention

Mining templates that would lead to the chain becoming unrecoverable due to inevitable ticket exhaustion will no longer be generated.

This is primarily aimed at the testing networks, but it could also theoretically affect the main network in some far future if the demand for tickets were to ever dry up for some unforeseen reason.

New Initial State Protocol Messages (getinitstate/initstate)

This release introduces a pair of peer-to-peer protocol messages named getinitstate and initstate which support querying one or more pieces of information that are useful to acquire when a node first connects in a consolidated fashion.

Some examples of the aforementioned information are the mining state as of the current tip block and, with the introduction of the decentralized treasury, any outstanding treasury spend transactions that are being voted on.

Mining State Protocol Messages Deprecated (getminings/minings)

Due to the addition of the previously-described initial state peer-to-peer protocol messages, the getminings and minings protocol messages are now deprecated. Use the new getinitstate and initstate messages with the headblocks and headblockvotes state types instead.

RPC Server Changes

The RPC server version as of this release is 6.1.2.

New Treasury Balance Query RPC (gettreasurybalance)

A new RPC named gettreasurybalance is now available to query the current balance of the decentralized treasury. Please note that this requires the decentralized treasury vote to pass and become active, so it will return an appropriate error indicating the decentralized treasury is inactive until that time.

See the gettreasurybalance JSON-RPC API Documentation for API details.

New Treasury Spend Vote Query RPC (gettreasuryspendvotes)

A new RPC named gettreasuryspendvotes is now available to query vote information about one or more treasury spend transactions. Please note that this requires the decentralized treasury vote to pass and become active to produce a meaningful result since treasury spend transactions are invalid until that time.

See the gettreasuryspendvotes JSON-RPC API Documentation for API details.

New Force Mining Template Regeneration RPC (regentemplate)

A new RPC named regentemplate is now available which can be used to force the current background block template to be regenerated.

See the regentemplate JSON-RPC API Documentation for API details.

New Unspent Transaction Output Set Query RPC (gettxoutsetinfo)

A new RPC named gettxoutsetinfo is now available which can be used to retrieve statistics about the current global set of unspent transaction outputs (UTXOs).

See the gettxoutsetinfo JSON-RPC API Documentation for API details.

Updates to Peer Information Query RPC (getpeerinfo)

The results of the getpeerinfo RPC are now sorted by the id field.

See the getpeerinfo JSON-RPC API Documentation for API details.

Enforced Results Limit on Transaction Search RPC (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.

New Index Status Fields on Info Query RPC (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.

Version 1 Block Filters Deprecated

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.

Changelog

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.

Protocol and network:

Transaction relay (memory pool):

Mining:

RPC:

dcrd command-line flags and configuration:

gencerts utility changes:

dcrctl utility changes:

Documentation:

Developer-related package and module changes:

Developer-related module management:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Brian Stafford
  • Dave Collins
  • David Hill
  • degeri
  • Donald Adu-Poku
  • Jamie Holdstock
  • Joe Gruffins
  • Josh Rickmar
  • Julian Yap
  • Marco Peereboom
  • Matheus Degiovani
  • Matt Hawkins
  • Ryan Riley
  • Ryan Staudt
  • Wisdom Arerosuoghene
  • Youssef Boukenken
  • zhizhongzhiwai
dcrd - dcrd v1.6.0-rc2

Published by davecgh almost 4 years ago

This release of dcrd introduces a large number of updates. Some of the key highlights are:

  • A new consensus vote agenda which allows the stakeholders to decide whether or not to activate support for a decentralized treasury
  • Aggregate fee transaction selection in block templates (Child Pays For Parent)
  • Improved peer discovery via HTTPS seeding with filtering capabilities
  • Major performance enhancements for signature validation and other cryptographic operations
  • Approximately 15% less overall resident memory usage
  • Proactive signature cache eviction
  • Improved support for single-party Schnorr signatures
  • Ticket exhaustion prevention
  • Various updates to the RPC server such as:
    • A new method to retrieve the current treasury balance
    • A new method to query treasury spend transaction vote details
  • Infrastructure improvements
  • Quality assurance changes

For those unfamiliar with the voting process in Decred, all code needed in order to support a decentralized treasury is already included in this release, however it will remain dormant until the stakeholders vote to activate it.

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

The following Decred Change Proposal (DCP) describes the proposed changes in detail and provides a full technical specification:

It is important for everyone to upgrade their software to this latest release even if you don't intend to vote in favor of the agenda.

Downgrade Warning

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

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

The database migration typically takes about 5 to 10 minutes on HDDs and 2 to 4 minutes on SSDs.

Notable Changes

Decentralized Treasury Vote

A new vote with the id treasury is now available as of this release. After upgrading, stakeholders may set their preferences through their wallet or Voting Service Provider's (VSP) website.

The primary goal of this change is to fully decentralize treasury spending so that it is controlled by the stakeholders via ticket voting.

See the initial Politeia proposal for more details.

Aggregate Fee Block Template Transaction Selection (Child Pays For Parent)

The transactions that are selected for inclusion in block templates that Proof-of-Work miners solve now prioritize the overall fees of the entire transaction ancestor graph.

This is beneficial for both miners and end users as it:

  • Helps maximize miner profit by ensuring that unconfirmed transaction chains with higher aggregate fees are given priority over others with lower aggregate fees
  • Provides a mechanism for users to increase the priority of an unconfirmed transaction by spending its outputs with another transaction that pays higher fees

This is commonly referred to as Child Pays For Parent (CPFP) as the spending ("child") transaction is able to increase the priority of the spent ("parent") transaction.

HTTPS Seeding

The initial bootstrap process that contacts seeders to discover other nodes to connect to now uses a REST-based API over HTTPS.

This change will be imperceptible for most users, with the exception that it accelerates the process of finding suitable candidate nodes that support desired services, particularly in the case of recently-introduced services that have not yet achieved widespread adoption on the network.

The following are some key benefits of HTTPS seeders over the previous DNS-based seeders:

  • Support for non-standard ports
  • Advertisement of supported service
  • Better scalability both in terms of network load and new features
  • Native support for TLS-secured communication channels
  • Native support for proxies which allows the use of anonymous overlay networks
    such as Tor and I2P
  • No need for a large DNSSEC dependency surface
  • Uses better audited infrastructure
  • More secure
  • Increases flexibility

Signature Validation And Other Crypto Operation Optimizations

The underlying crypto code has been reworked to significantly improve its execution speed and reduce the number of memory allocations. While this has more benefits than enumerated here, probably the most important ones for most stakeholders are:

  • Improved vote times since blocks and transactions propagate more quickly throughout the network
  • The initial sync process is around 15% faster

Proactive Signature Cache Eviction

Signature cache entries that are nearly guaranteed to no longer be useful are now immediately and proactively evicted resulting in overall faster validation during steady state operation due to fewer cache misses.

The primary purpose of the cache is to avoid double checking signatures that are already known to be valid.

Orphan Transaction Relay Policy Refinement

Transactions that spend outputs which are not known to nodes relaying them, known as orphan transactions, now have the same size restrictions applied to them as standard non-orphan transactions.

This ensures that transactions chains are not artificially hindered from relaying regardless of the order they are received.

In order to keep memory usage of the now potentially larger orphan transactions under control, more intelligent orphan eviction has been implemented and the maximum number of allowed orphans before random eviction occurs has been lowered.

These changes, in conjunction with other related changes, mean that nodes are better about orphan transaction management and thus missing ancestors will typically either be broadcast or mined fairly quickly resulting in fewer overall orphans and smaller actual run-time orphan pools.

Ticket Exhaustion Prevention

Mining templates that would lead to the chain becoming unrecoverable due to inevitable ticket exhaustion will no longer be generated.

This is primarily aimed at the testing networks, but it could also theoretically affect the main network in some far future if the demand for tickets were to ever dry up for some unforeseen reason.

New Initial State Protocol Messages (getinitstate/initstate)

This release introduces a pair of peer-to-peer protocol messages named getinitstate and initstate which support querying one or more pieces of information that are useful to acquire when a node first connects in a consolidated fashion.

Some examples of the aforementioned information are the mining state as of the current tip block and, with the introduction of the decentralized treasury, any outstanding treasury spend transactions that are being voted on.

Mining State Protocol Messages Deprecated (getminings/minings)

Due to the addition of the previously-described initial state peer-to-peer protocol messages, the getminings and minings protocol messages are now deprecated. Use the new getinitstate and initstate messages with the headblocks and headblockvotes state types instead.

RPC Server Changes

The RPC server version as of this release is 6.1.2.

New Treasury Balance Query RPC (gettreasurybalance)

A new RPC named gettreasurybalance is now available to query the current balance of the decentralized treasury. Please note that this requires the decentralized treasury vote to pass and become active, so it will return an appropriate error indicating the decentralized treasury is inactive until that time.

See the gettreasurybalance JSON-RPC API Documentation for API details.

New Treasury Spend Vote Query RPC (gettreasuryspendvotes)

A new RPC named gettreasuryspendvotes is now available to query vote information about one or more treasury spend transactions. Please note that this requires the decentralized treasury vote to pass and become active to produce a meaningful result since treasury spend transactions are invalid until that time.

See the gettreasuryspendvotes JSON-RPC API Documentation for API details.

New Force Mining Template Regeneration RPC (regentemplate)

A new RPC named regentemplate is now available which can be used to force the current background block template to be regenerated.

See the regentemplate JSON-RPC API Documentation for API details.

New Unspent Transaction Output Set Query RPC (gettxoutsetinfo)

A new RPC named gettxoutsetinfo is now available which can be used to retrieve statistics about the current global set of unspent transaction outputs (UTXOs).

See the gettxoutsetinfo JSON-RPC API Documentation for API details.

Updates to Peer Information Query RPC (getpeerinfo)

The results of the getpeerinfo RPC are now sorted by the id field.

See the getpeerinfo JSON-RPC API Documentation for API details.

Enforced Results Limit on Transaction Search RPC (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.

New Index Status Fields on Info Query RPC (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.

Version 1 Block Filters Deprecated

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.

Changelog

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.

Protocol and network:

Transaction relay (memory pool):

Mining:

RPC:

dcrd command-line flags and configuration:

gencerts utility changes:

dcrctl utility changes:

Documentation:

Developer-related package and module changes:

Developer-related module management:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Brian Stafford
  • Dave Collins
  • David Hill
  • degeri
  • Donald Adu-Poku
  • Jamie Holdstock
  • Joe Gruffins
  • Josh Rickmar
  • Julian Yap
  • Marco Peereboom
  • Matheus Degiovani
  • Matt Hawkins
  • Ryan Riley
  • Ryan Staudt
  • Wisdom Arerosuoghene
  • Youssef Boukenken
  • zhizhongzhiwai
dcrd - dcrd v1.6.0-rc1.1

Published by davecgh almost 4 years ago

This release of dcrd introduces a large number of updates. Some of the key highlights are:

  • A new consensus vote agenda which allows the stakeholders to decide whether or not to activate support for a decentralized treasury
  • Aggregate fee transaction selection in block templates (Child Pays For Parent)
  • Improved peer discovery via HTTPS seeding with filtering capabilities
  • Major performance enhancements for signature validation and other cryptographic operations
  • Approximately 15% less overall resident memory usage
  • Proactive signature cache eviction
  • Improved support for single-party Schnorr signatures
  • Ticket exhaustion prevention
  • Various updates to the RPC server such as:
    • A new method to retrieve the current treasury balance
    • A new method to query treasury spend transaction vote details
  • Infrastructure improvements
  • Quality assurance changes

For those unfamiliar with the voting process in Decred, all code needed in order to support a decentralized treasury is already included in this release, however it will remain dormant until the stakeholders vote to activate it.

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

The following Decred Change Proposal (DCP) describes the proposed changes in detail and provides a full technical specification:

It is important for everyone to upgrade their software to this latest release even if you don't intend to vote in favor of the agenda.

Downgrade Warning

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

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

The database migration typically takes about 5 to 10 minutes on HDDs and 2 to 4 minutes on SSDs.

Notable Changes

Decentralized Treasury Vote

A new vote with the id treasury is now available as of this release. After upgrading, stakeholders may set their preferences through their wallet or Voting Service Provider's (VSP) website.

The primary goal of this change is to fully decentralize treasury spending so that it is controlled by the stakeholders via ticket voting.

See the initial Politeia proposal for more details.

Aggregate Fee Block Template Transaction Selection (Child Pays For Parent)

The transactions that are selected for inclusion in block templates that Proof-of-Work miners solve now prioritize the overall fees of the entire transaction ancestor graph.

This is beneficial for both miners and end users as it:

  • Helps maximize miner profit by ensuring that unconfirmed transaction chains with higher aggregate fees are given priority over others with lower aggregate fees
  • Provides a mechanism for users to increase the priority of an unconfirmed transaction by spending its outputs with another transaction that pays higher fees

This is commonly referred to as Child Pays For Parent (CPFP) as the spending ("child") transaction is able to increase the priority of the spent ("parent") transaction.

HTTPS Seeding

The initial bootstrap process that contacts seeders to discover other nodes to connect to now uses a REST-based API over HTTPS.

This change will be imperceptible for most users, with the exception that it accelerates the process of finding suitable candidate nodes that support desired services, particularly in the case of recently-introduced services that have not yet achieved widespread adoption on the network.

The following are some key benefits of HTTPS seeders over the previous DNS-based seeders:

  • Support for non-standard ports
  • Advertisement of supported service
  • Better scalability both in terms of network load and new features
  • Native support for TLS-secured communication channels
  • Native support for proxies which allows the use of anonymous overlay networks such as Tor and I2P
  • No need for a large DNSSEC dependency surface
  • Uses better audited infrastructure
  • More secure
  • Increases flexibility

Signature Validation And Other Crypto Operation Optimizations

The underlying crypto code has been reworked to significantly improve its execution speed and reduce the number of memory allocations. While this has more benefits than enumerated here, probably the most important ones for most stakeholders are:

  • Improved vote times since blocks and transactions propagate more quickly throughout the network
  • The initial sync process is around 15% faster

Proactive Signature Cache Eviction

Signature cache entries that are nearly guaranteed to no longer be useful are now immediately and proactively evicted resulting in overall faster validation during steady state operation due to fewer cache misses.

The primary purpose of the cache is to avoid double checking signatures that are already known to be valid.

Orphan Transaction Relay Policy Refinement

Transactions that spend outputs which are not known to nodes relaying them, known as orphan transactions, now have the same size restrictions applied to them as standard non-orphan transactions.

This ensures that transactions chains are not artificially hindered from relaying regardless of the order they are received.

In order to keep memory usage of the now potentially larger orphan transactions under control, more intelligent orphan eviction has been implemented and the maximum number of allowed orphans before random eviction occurs has been lowered.

These changes, in conjunction with other related changes, mean that nodes are better about orphan transaction management and thus missing ancestors will typically either be broadcast or mined fairly quickly resulting in fewer overall orphans and smaller actual run-time orphan pools.

Ticket Exhaustion Prevention

Mining templates that would lead to the chain becoming unrecoverable due to inevitable ticket exhaustion will no longer be generated.

This is primarily aimed at the testing networks, but it could also theoretically affect the main network in some far future if the demand for tickets were to ever dry up for some unforeseen reason.

New Initial State Protocol Messages (getinitstate/initstate)

This release introduces a pair of peer-to-peer protocol messages named getinitstate and initstate which support querying one or more pieces of information that are useful to acquire when a node first connects in a consolidated fashion.

Some examples of the aforementioned information are the mining state as of the current tip block and, with the introduction of the decentralized treasury, any outstanding treasury spend transactions that are being voted on.

Mining State Protocol Messages Deprecated (getminings/minings)

Due to the addition of the previously-described initial state peer-to-peer protocol messages, the getminings and minings protocol messages are now deprecated. Use the new getinitstate and initstate messages with the headblocks and headblockvotes state types instead.

RPC Server Changes

The RPC server version as of this release is 6.1.2.

New Treasury Balance Query RPC (gettreasurybalance)

A new RPC named gettreasurybalance is now available to query the current balance of the decentralized treasury. Please note that this requires the decentralized treasury vote to pass and become active, so it will return an appropriate error indicating the decentralized treasury is inactive until that time.

See the gettreasurybalance JSON-RPC API Documentation for API details.

New Treasury Spend Vote Query RPC (gettreasuryspendvotes)

A new RPC named gettreasuryspendvotes is now available to query vote information about one or more treasury spend transactions. Please note that this requires the decentralized treasury vote to pass and become active to produce a meaningful result since treasury spend transactions are invalid until that time.

See the gettreasuryspendvotes JSON-RPC API Documentation for API details.

New Force Mining Template Regeneration RPC (regentemplate)

A new RPC named regentemplate is now available which can be used to force the current background block template to be regenerated.

See the regentemplate JSON-RPC API Documentation for API details.

New Unspent Transaction Output Set Query RPC (gettxoutsetinfo)

A new RPC named gettxoutsetinfo is now available which can be used to retrieve statistics about the current global set of unspent transaction outputs (UTXOs).

See the gettxoutsetinfo JSON-RPC API Documentation for API details.

Updates to Peer Information Query RPC (getpeerinfo)

The results of the getpeerinfo RPC are now sorted by the id field.

See the getpeerinfo JSON-RPC API Documentation for API details.

Enforced Results Limit on Transaction Search RPC (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.

New Index Status Fields on Info Query RPC (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.

Version 1 Block Filters Deprecated

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.

Changelog

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.

Protocol and network:

Transaction relay (memory pool):

Mining:

RPC:

dcrd command-line flags and configuration:

gencerts utility changes:

dcrctl utility changes:

Documentation:

Developer-related package and module changes:

Developer-related module management:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Brian Stafford
  • Dave Collins
  • David Hill
  • degeri
  • Donald Adu-Poku
  • Jamie Holdstock
  • Joe Gruffins
  • Josh Rickmar
  • Julian Yap
  • Marco Peereboom
  • Matheus Degiovani
  • Matt Hawkins
  • Ryan Riley
  • Ryan Staudt
  • Wisdom Arerosuoghene
  • Youssef Boukenken
  • zhizhongzhiwai
Package Rankings
Top 0.9% on Proxy.golang.org
Badges
Extracted from project README
Build Status ISC License Doc Go Report Card
Related Projects
bitcoin

a comprehensive and versatile Go library for all your Bitcoin transaction needs. offers robust su...

23 Sep 2023 28
go-crypto-wallet

Cryptocurrency wallet for trading for Bitcoin, Bitcoin cash, Ethereum, ERC20, Ripple

04 Aug 2018 83
solana-go

Go SDK library and RPC client for the Solana Blockchain

29 Jun 2021 672