Skip to content

Releases: decred/dcrd

dcrd v1.4.0-rc3

28 Jan 19:23
release-v1.4.0-rc3
e3e8c47
Compare
Choose a tag to compare
dcrd v1.4.0-rc3 Pre-release
Pre-release

This release of dcrd introduces a new consensus vote agenda which allows the
stakeholders to decide whether or not to activate changes needed to modify the
sequence lock handling which is required for providing full support for the
Lightning Network. For those unfamiliar with the voting process in Decred, this
means that all code in order to make the necessary changes is already included
in this release, however its enforcement will remain dormant until the
stakeholders vote to activate it.

It also contains smart fee estimation, performance enhancements for block relay
and processing, a major internal restructuring of how unspent transaction
outputs are handled, support for whitelisting inbound peers to ensure service
for your own SPV (Simplified Payment Verification) wallets, various updates to
the RPC server such as a new method to query the state of the chain and more
easily supporting external RPC connections over TLS, infrastructure
improvements, and other quality assurance changes.

The following Decred Change Proposals (DCP) describes the proposed changes in detail:

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

Downgrade Warning

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

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

Notable Changes

Fix Lightning Network Sequence Locks Vote

In order to fully support the Lightning Network, the current sequence lock
consensus rules need to be modified. A new vote with the id fixlnseqlocks is
now available as of this release. After upgrading, stakeholders may set their
preferences through their wallet or Voting Service Provider's (VSP) website.

Smart Fee Estimation (estimatesmartfee)

A new RPC named estimatesmartfee is now available which returns a suitable
fee rate for transactions to use in order to have a high probability of them
being mined within a specified number of confirmations. The estimation is based
on actual network usage and thus varies according to supply and demand.

This is important in the context of the Lightning Network (LN) and, more
generally, it provides services and users with a mechanism to choose how to
handle network congestion. For example, payments that are high priority might
be willing to pay a higher fee to help ensure the transaction is mined more
quickly, while lower priority payments might be willing to wait longer in
exchange for paying a lower fee. This estimation capability provides a way to
obtain a fee that will achieve the desired result with a high probability.

Support for Whitelisting Inbound Peers

When peers are whitelisted via the --whitelist option, they will now be
allowed to connect even when they would otherwise exceed the maximum number of
peers. This is highly useful in cases where users have configured their wallet
to use SPV mode and only connect to dcrd instances that they control for
increased privacy and guaranteed service.

Several Speed Optimizations

Similar to previous releases, this release also contains several enhancements to
improve speed for the initial sync process, validation, and network operations.

In order to achieve these speedups, there is a lengthy one time database
migration, as previously mentioned, that typically takes anywhere from 30
minutes to an hour to complete depending on hardware.

Faster Tip Block Relay

Blocks that extend the current best chain are now relayed to the network
immediately after they pass the initial sanity and contextual checks, most
notably valid proof of work. This allows blocks to propagate more quickly
throughout the network, which in turn improves vote times.

UTXO Set Restructuring

The way the unspent transaction outputs are handled internally has been
overhauled to significantly decrease the time it takes to validate blocks and
transactions. While this has many benefits, probably the most important one
for most stakeholders is that votes can be cast more quickly which helps reduce
the number of missed votes.

RPC Server Changes

New Chain State Query RPC (getblockchaininfo)

A new RPC named getblockchaininfo is now available which can be used to query
the state of the chain including details such as its overall verification
progress during initial sync, the maximum supported block size, and that status
of consensus changes (deployments) which require stakeholder votes. See the
JSON-RPC API Documentation
for API details.

Removal of Vote Creation RPC (createrawssgen)

The deprecated createrawssgen, which was previously used to allow creating a
vote via RPC is no longer available. Votes are time sensitive and thus it does
not make sense to create them offline.

Updates to Block and Transaction RPCs

The getblock, getblockheader, getrawtransaction, and
searchrawtransactions RPCs now contain additional information such as the
extradata field in the header, the expiry field in transactions, and the
blockheight and blockindex of the block that contains a transaction if it
has been mined. See the JSON-RPC API Documentation
for API details.

Built-in Support for Enabling External TLS RPC Connections

A new command line parameter (--altdnsnames) and environment variable
(DCRD_ALT_DNSNAMES) can now be used before the first launch of drcd to specify
additional external IP addresses and DNS names to add during the certificate
creation that are permitted to connect to the RPC server via TLS. Previously,
a separate tool was required to accomplish this configuration.

Changelog

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

Protocol and network:

Transaction relay (memory pool):

RPC:

dcrd command-line flags and configuration:

Documentation:

Read more

dcrd v1.4.0-rc1

12 Dec 23:43
release-v1.4.0-rc1
3542bcc
Compare
Choose a tag to compare
dcrd v1.4.0-rc1 Pre-release
Pre-release

This release of dcrd contains smart fee estimation, performance enhancements for
block relay and processing, a major internal restructuring of how unspent
transaction outputs are handled, support for whitelisting inbound peers to
ensure service for your own SPV (Simplified Payment Verification) wallets,
various updates to the RPC server such as a new method to query the state of the
chain and more easily supporting external RPC connections over TLS,
infrastructure improvements, and other quality assurance changes.

It is highly recommended that everyone upgrade to this latest release as it
contains many important scalability improvements and smart fee estimation.

Downgrade Warning

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

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

Notable Changes

Smart Fee Estimation (estimatesmartfee)

A new RPC named estimatesmartfee is now available which returns a suitable
fee rate for transactions to use in order to have a high probability of them
being mined within a specified number of confirmations. The estimation is based
on actual network usage and thus varies according to supply and demand.

This is important in the context of the Lightning Network (LN) and, more
generally, it provides services and users with a mechanism to choose how to
handle network congestion. For example, payments that are high priority might
be willing to pay a higher fee to help ensure the transaction is mined more
quickly, while lower priority payments might be willing to wait longer in
exchange for paying a lower fee. This estimation capability provides a way to
obtain a fee that will achieve the desired result with a high probability.

Support for Whitelisting Inbound Peers

When peers are whitelisted via the --whitelist option, they will now be
allowed to connect even when they would otherwise exceed the maximum number of
peers. This is highly useful in cases where users have configured their wallet
to use SPV mode and only connect to dcrd instances that they control for
increased privacy and guaranteed service.

Several Speed Optimizations

Similar to previous releases, this release also contains several enhancements to
improve speed for the initial sync process, validation, and network operations.

In order to achieve these speedups, there is a lengthy one time database
migration, as previously mentioned, that typically takes anywhere from 30
minutes to an hour to complete depending on hardware.

Faster Tip Block Relay

Blocks that extend the current best chain are now relayed to the network
immediately after they pass the initial sanity and contextual checks, most
notably valid proof of work. This allows blocks to propagate more quickly
throughout the network, which in turn improves vote times.

UTXO Set Restructuring

The way the unspent transaction outputs are handled internally has been
overhauled to significantly decrease the time it takes to validate blocks and
transactions. While this has many benefits, probably the most important one
for most stakeholders is that votes can be cast more quickly which helps reduce
the number of missed votes.

RPC Server Changes

New Chain State Query RPC (getblockchaininfo)

A new RPC named getblockchaininfo is now available which can be used to query
the state of the chain including details such as its overall verification
progress during initial sync, the maximum supported block size, and that status
of consensus changes (deployments) which require stakeholder votes. See the
JSON-RPC API Documentation
for API details.

Removal of Vote Creation RPC (createrawssgen)

The deprecated createrawssgen, which was previously used to allow creating a
vote via RPC is no longer available. Votes are time sensitive and thus it does
not make sense to create them offline.

Updates to Block and Transaction RPCs

The getblock, getblockheader, getrawtransaction, and
searchrawtransactions RPCs now contain additional information such as the
extradata field in the header, the expiry field in transactions, and the
blockheight and blockindex of the block that contains a transaction if it
has been mined. See the JSON-RPC API Documentation
for API details.

Built-in Support for Enabling External TLS RPC Connections

A new command line parameter (--altdnsnames) and environment variable
(DCRD_ALT_DNSNAMES) can now be used before the first launch of drcd to specify
additional external IP addresses and DNS names to add during the certificate
creation that are permitted to connect to the RPC server via TLS. Previously,
a separate tool was required to accomplish this configuration.

Changelog

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

Protocol and network:

Transaction relay (memory pool):

RPC:

dcrd command-line flags and configuration:

Documentation:

Developer-related package and module changes:

Read more

dcrd v1.3.0

19 Sep 15:30
release-v1.3.0
0fe5649
Compare
Choose a tag to compare

This release of dcrd contains significant performance enhancements for startup
speed, validation, and network operations that directly benefit lightweight
clients, such as SPV (Simplified Payment Verification) wallets, a policy change
to reduce the default minimum transaction fee rate, a new public test network
version, removal of bloom filter support, infrastructure improvements, and other
quality assurance changes.

It is highly recommended that everyone upgrade to this latest release as it
contains many important scalability improvements and is required to be able to
use the new public test network.

Downgrade Warning

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

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

Notable Changes

Reduction of Default Minimum Transaction Fee Rate Policy

The default setting for the policy which specifies the minimum transaction fee
rate that will be accepted and relayed to the rest of the network has been
reduced to 0.0001 DCR/kB (10,000 atoms/kB) from the previous value of 0.001
DCR/kB (100,000 atoms/kB).

Transactions should not attempt to use the reduced fee rate until the majority
of the network has upgraded to this release as otherwise the transactions will
likely have issues relaying through the network since old nodes that have not
updated their policy will reject them due to not paying a high enough fee.

Several Speed Optimizations

This release contains several enhancements to improve speed for startup,
the initial sync process, validation, and network operations.

In order to achieve these speedups, there is a one time database migration, as
previously mentioned, that typically only takes a few seconds to complete on
most hardware.

Further Improved Startup Speed

The startup time has been improved by roughly 2x on both slower hard disk drives
(HDDs) and solid state drives (SSDs) as compared to v1.2.0.

Significantly Faster Network Operations

The ability to serve information to other peers on the network has received
several optimizations which, in addition to generally improving the overall
scalability and throughput of the network, also directly benefits SPV
(Simplified Payment Verification) clients by delivering the block headers they
require roughly 3x to 4x faster.

Signature Hash Calculation Optimization

Part of validating that transactions are only spending coins that the owner has
authorized involves ensuring the validity of cryptographic signatures. This
release provides a speedup of about 75% to a key portion of that validation
which results in a roughly 20% faster initial sync process.

Bloom Filters Removal

Bloom filters were deprecated as of the last release in favor of the more recent
privacy-preserving GCS committed filters. Consequently, this release removes
support for bloom filters completely. There are no known clients which use
bloom filters, however, if there are any unknown clients which use them, those
clients will need to be updated to use the GCS committed filters accordingly.

Public Test Network Version 3

The public test network has been reset and bumped to version 3. All of the new
consensus rules voted in by version 2 of the public test network have been
retained and are therefore active on the new version 3 test network without
having to vote them in again.

Changelog

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

Protocol and network:

Transaction relay (memory pool):

RPC:

dcrd command-line flags and configuration:

dcrctl utility changes:

Documentation:

Read more

dcrd v1.3.0-rc2

31 Aug 20:45
release-v1.3.0-rc2
5bb4840
Compare
Choose a tag to compare
dcrd v1.3.0-rc2 Pre-release
Pre-release

This release of dcrd contains significant performance enhancements for startup
speed, validation, and network operations that directly benefit lightweight
clients, such as SPV (Simplified Payment Verification) wallets, a policy change
to reduce the default minimum transaction fee rate, a new public test network
version, removal of bloom filter support, infrastructure improvements, and other
quality assurance changes.

It is highly recommended that everyone upgrade to this latest release as it
contains many important scalability improvements and is required to be able to
use the new public test network.

Downgrade Warning

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

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

Notable Changes

Reduction of Default Minimum Transaction Fee Rate Policy

The default setting for the policy which specifies the minimum transaction fee
rate that will be accepted and relayed to the rest of the network has been
reduced to 0.0001 DCR/kB (10,000 atoms/kB) from the previous value of 0.001
DCR/kB (100,000 atoms/kB).

Transactions should not attempt to use the reduced fee rate until the majority
of the network has upgraded to this release as otherwise the transactions will
likely have issues relaying through the network since old nodes that have not
updated their policy will reject them due to not paying a high enough fee.

Several Speed Optimizations

This release contains several enhancements to improve speed for startup,
the initial sync process, validation, and network operations.

In order to achieve these speedups, there is a one time database migration, as
previously mentioned, that typically only takes a few seconds to complete on
most hardware.

Further Improved Startup Speed

The startup time has been improved by roughly 2x on both slower hard disk drives
(HDDs) and solid state drives (SSDs) as compared to v1.2.0.

Significantly Faster Network Operations

The ability to serve information to other peers on the network has received
several optimizations which, in addition to generally improving the overall
scalability and throughput of the network, also directly benefits SPV
(Simplified Payment Verification) clients by delivering the block headers they
require roughly 3x to 4x faster.

Signature Hash Calculation Optimization

Part of validating that transactions are only spending coins that the owner has
authorized involves ensuring the validity of cryptographic signatures. This
release provides a speedup of about 75% to a key portion of that validation
which results in a roughly 20% faster initial sync process.

Bloom Filters Removal

Bloom filters were deprecated as of the last release in favor of the more recent
privacy-preserving GCS committed filters. Consequently, this release removes
support for bloom filters completely. There are no known clients which use
bloom filters, however, if there are any unknown clients which use them, those
clients will need to be updated to use the GCS committed filters accordingly.

Public Test Network Version 3

The public test network has been reset and bumped to version 3. All of the new
consensus rules voted in by version 2 of the public test network have been
retained and are therefore active on the new version 3 test network without
having to vote them in again.

Changelog

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

Protocol and network:

Transaction relay (memory pool):

RPC:

dcrd command-line flags and configuration:

dcrctl utility changes:

Documentation:

Read more

dcrd v1.3.0-rc1

08 Aug 14:56
release-v1.3.0-rc1
553c8a6
Compare
Choose a tag to compare
dcrd v1.3.0-rc1 Pre-release
Pre-release

This release of dcrd contains significant performance enhancements for startup
speed, validation, and network operations that directly benefit lightweight
clients, such as SPV (Simplified Payment Verification) wallets, a policy change
to reduce the default minimum transaction fee rate, a new public test network
version, removal of bloom filter support, infrastructure improvements, and other
quality assurance changes.

It is highly recommended that everyone upgrade to this latest release as it
contains many important scalability improvements and is required to be able to
use the new public test network.

Downgrade Warning

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

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

Notable Changes

Reduction of Default Minimum Transaction Fee Rate Policy

The default setting for the policy which specifies the minimum transaction fee
rate that will be accepted and relayed to the rest of the network has been
reduced to 0.0001 DCR/kB (10,000 atoms/kB) from the previous value of 0.001
DCR/kB (100,000 atoms/kB).

Transactions should not attempt to use the reduced fee rate until the majority
of the network has upgraded to this release as otherwise the transactions will
likely have issues relaying through the network since old nodes that have not
updated their policy will reject them due to not paying a high enough fee.

Several Speed Optimizations

This release contains several enhancements to improve speed for startup,
the initial sync process, validation, and network operations.

In order to achieve these speedups, there is a one time database migration, as
previously mentioned, that typically only takes a few seconds to complete on
most hardware.

Further Improved Startup Speed

The startup time has been improved by roughly 2x on both slower hard disk drives
(HDDs) and solid state drives (SSDs) as compared to v1.2.0.

Significantly Faster Network Operations

The ability to serve information to other peers on the network has received
several optimizations which, in addition to generally improving the overall
scalability and throughput of the network, also directly benefits SPV
(Simplified Payment Verification) clients by delivering the block headers they
require roughly 3x to 4x faster.

Signature Hash Calculation Optimization

Part of validating that transactions are only spending coins that the owner has
authorized involves ensuring the validity of cryptographic signatures. This
release provides a speedup of about 75% to a key portion of that validation
which results in a roughly 20% faster initial sync process.

Bloom Filters Removal

Bloom filters were deprecated as of the last release in favor of the more recent
privacy-preserving GCS committed filters. Consequently, this release removes
support for bloom filters completely. There are no known clients which use
bloom filters, however, if there are any unknown clients which use them, those
clients will need to be updated to use the GCS committed filters accordingly.

Public Test Network Version 3

The public test network has been reset and bumped to version 3. All of the new
consensus rules voted in by version 2 of the public test network have been
retained and are therefore active on the new version 3 test network without
having to vote them in again.

Changelog

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

Protocol and network:

Transaction relay (memory pool):

RPC:

dcrd command-line flags and configuration:

dcrctl utility changes:

Documentation:

Read more

dcrd v1.2.0

27 May 12:26
release-v1.2.0
Compare
Choose a tag to compare

This release of dcrd contains significant performance enhancements,
infrastructure improvements, improved access to chain-related information for
providing better SPV (Simplified Payment Verification) support, and other
quality assurance changes.

A significant amount of infrastructure work has also been done this release
cycle towards being able to support several planned scalability optimizations.

Downgrade Warning

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

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

Notable Changes

Significantly Faster Startup

The startup time has been improved by roughly 17x on slower hard disk drives
(HDDs) and 8x on solid state drives (SSDs).

In order to achieve these speedups, there is a one time database migration, as
previously mentioned, that will likely take a while to complete (typically
around 5 to 6 minutes on HDDs and 2 to 3 minutes on SSDs).

Support For DNS Seed Filtering

In order to better support the forthcoming SPV wallets, support for finding
other peers based upon their enabled services has been added. This is useful
for both SPV wallets and full nodes since SPV wallets will require access to
full nodes in order to retrieve the necessary proofs and full nodes are
generally not interested in making outgoing connections to SPV wallets.

Committed Filters

With the intention of supporting light clients, such as SPV wallets, in a
privacy-preserving way while still minimizing the amount of data that needs to
be downloaded, this release adds support for committed filters. A committed
filter is a combination of a probalistic data structure that is used to test
whether an element is a member of a set with a predetermined collision
probability along with a commitment by consensus-validating full nodes to that
data.

A committed filter is created for every block which allows light clients to
download the filters and match against them locally rather than uploading
personal data to other nodes.

A new service flag is also provided to allow clients to discover nodes that
provide access to filters.

There is a one time database update to build and store the filters for all
existing historical blocks which will likely take a while to complete (typically
around 2 to 3 minutes on HDDs and 1 to 1.5 minutes on SSDs).

Updated Atomic Swap Contracts

The standard checks for atomic swap contracts have been updated to ensure the
contracts enforce the secret size for safer support between chains with
disparate script rules.

RPC Server Changes

New getchaintips RPC

A new RPC named getchaintips has been added which allows callers to query
information about the status of known side chains and their branch lengths.
It currently only provides support for side chains that have been seen while the
current instance of the process is running. This will be further improved in
future releases.

Changelog

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

Protocol and network:

Transaction relay (memory pool):

RPC:

dcrd command-line flags and configuration:

checkdevpremine utility changes:

Documentation:

Developer-related package changes:

Read more

v1.1.0

22 Sep 21:13
v1.1.0
Compare
Choose a tag to compare

This release of dcrd primarily introduces a new consensus vote agenda which
allows the stakeholders to decide whether or not to activate the features needed
for providing full support for Lightning Network. For those unfamiliar with the
voting process in Decred, this means that all code in order to support these
features is already included in this release, however its enforcement will
remain dormant until the stakeholders vote to activate it.

The following Decred Change Proposals (DCPs) describe the proposed changes in detail:

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

Notable Changes

Lightning Network Features Vote

In order to fully support many of the benefits that the Lightning Network will
bring, there are some primitives that involve changes to the current consensus
that need to be enabled. A new vote with the id lnfeatures is now available
as of this release. After upgrading, stakeholders may set their preferences
through their wallet or stake pool's website.

Transaction Finality Policy

The standard policy for transaction relay has been changed to use the median
time of the past several blocks instead of the current network adjusted time
when examining lock times to determine if a transaction is final. This provides
a more deterministic check across all peers and prevents the possibility of
miners attempting to game the timestamps in order to include more transactions.

Consensus enforcement of this change relies on the result of the aforementioned
lnfeatures vote.

Relative Time Locks Policy

The standard policy for transaction relay has been modified to enforce relative
lock times for version 2 transactions via their sequence numbers and a new
OP_CHECKSEQUENCEVERIFY opcode.

Consensus enforcement of this change relies on the result of the aforementioned
lnfeatures vote.

OP_SHA256 Opcode

In order to better support cross-chain interoperability, a new opcode to compute
the SHA-256 hash is being proposed. Since this opcode is implemented as a hard
fork, it will not be available for use in scripts unless the aforementioned
lnfeatures vote passes.

Changelog

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

Protocol and network:

Transaction relay (memory pool):

RPC:

dcrd command-line flags:

  • config: Extend --profile cmd line option to allow interface to be specified decred/dcrd#838

Documentation

Developer-related package changes:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Alex Yocom-Piatt
  • Dave Collins
  • David Hill
  • Donald Adu-Poku
  • Jason Zavaglia
  • Jean-Christophe Mincke
  • Jolan Luff
  • Josh Rickmar

v0.0.4

24 Feb 16:01
Compare
Choose a tag to compare

This release has been moved to Decred-release v0.0.4.

v0.0.2

08 Feb 20:29
Compare
Choose a tag to compare

This release has been moved to Decred-release v0.0.2.

v0.0.1

07 Feb 18:53
Compare
Choose a tag to compare

This release has been moved to Decred-release v0.0.1.