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

Published by davecgh about 4 years ago

dcrd v1.5.2

This is a patch release of dcrd to address a potential denial of service vector.

Changelog

This patch release consists of 5 commits from 2 contributors which total to 4 files changed, 114 additional lines of code, and 20 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
  • David Hill
dcrd - dcrd v1.5.1

Published by davecgh over 4 years ago

dcrd v1.5.1

This is a patch release of dcrd to address a minor memory leak with authenticated RPC websocket clients on intermittent connections. It also updates the dcrctl utility to include the new auditreuse dcrwallet command.

Changelog

This patch release consists of 4 commits from 3 contributors which total to 4 files changed, 27 additional lines of code, and 6 deleted lines of code.

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

RPC:

dcrctl utility changes:

Misc:

Code Contributors (alphabetical order):

  • Dave Collins
  • Josh Rickmar
  • Matheus Degiovani
dcrd - dcrd v1.5.0

Published by davecgh over 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 block header commitments
  • More efficient block filters
  • Significant improvements to the mining infrastructure including asynchronous work notifications
  • Major performance enhancements for transaction script validation
  • Automatic external IP address discovery
  • Support for IPv6 over Tor
  • Various updates to the RPC server such as:
    • A new method to query information about the network
    • A method to retrieve the new version 2 block filters
    • More calls available to limited access users
  • Infrastructure improvements
  • Quality assurance changes

For those unfamiliar with the voting process in Decred, all code in order to support block header commitments is already included in this release, however its enforcement will remain dormant until the stakeholders vote to activate it.

For reference, block header commitments were 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.5.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

Block Header Commitments Vote

A new vote with the id headercommitments 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 increase the security and efficiency of lightweight clients, such as Decrediton in its lightweight mode and the dcrandroid/dcrios mobile wallets, as well as add infrastructure that paves the
way for several future scalability enhancements.

A high level overview aimed at a general audience including a cost benefit analysis can be found in the Politeia proposal.

In addition, a much more in-depth treatment can be found in the motivation section of DCP0005.

Version 2 Block Filters

The block filters used by lightweight clients, such as SPV (Simplified Payment Verification) wallets, have been updated to improve their efficiency, ergonomics, and include additional information such as the full ticket
commitment script. The new block filters are version 2. The older version 1 filters are now deprecated and scheduled to be removed in the next release, so consumers should update to the new filters as soon as possible.

An overview of block filters can be found in the block filters section of DCP0005.

Also, the specific contents and technical specification of the new version 2 block filters is available in the
version 2 block filters section of DCP0005.

Finally, there is a one time database update to build and store the new filters for all existing historical blocks which will likely take a while to complete (typically around 8 to 10 minutes on HDDs and 4 to 5 minutes on SSDs).

Mining Infrastructure Overhaul

The mining infrastructure for building block templates and delivering the work to miners has been significantly overhauled to improve several aspects as follows:

  • Support asynchronous background template generation with intelligent vote propagation handling
  • Improved handling of chain reorganizations necessary when the current tip is unable to obtain enough votes
  • Current state synchronization
  • Near elimination of stale templates when new blocks and votes are received
  • Subscriptions for streaming template updates

The standard getwork RPC that PoW miners currently use to perform the mining process has been updated to make use of this new infrastructure, so existing PoW miners will seamlessly get the vast majority of benefits without requiring any updates.

However, in addition, a new notifywork RPC is now available that allows miners to register for work to be delivered
asynchronously as it becomes available via a WebSockets work notification. These notifications include the same information that getwork provides along with an additional reason parameter which allows the miners to make better decisions about when they should instruct workers to discard the current template immediately or should be allowed to finish their current round before being provided with the new template.

Miners are highly encouraged to update their software to make use of the new asynchronous notification infrastructure since it is more robust, efficient, and faster than polling getwork to manually determine the aforementioned conditions.

The following is a non-exhaustive overview that highlights the major benefits of the changes for both cases:

  • Requests for updated templates during the normal mining process in between tip changes will now be nearly instant instead of potentially taking several seconds to build the new template on the spot
  • When the chain tip changes, requesting a template will now attempt to wait until either all votes have been received or a timeout occurs prior to handing out a template which is beneficial for PoW miners, PoS miners, and the network as a whole
  • PoW miners are much less likely to end up with template with less than the max number of votes which means they are less likely to receive a reduced subsidy
  • PoW miners will be much less likely to receive stale templates during chain tip changes due to vote propagation
  • PoS voters whose votes end up arriving to the miner slightly slower than the minimum number required are much less likely to have their votes excluded despite having voted simply due to propagation delay

PoW miners who choose to update their software, pool or otherwise, to make use of the asynchronous work notifications will receive additional benefits such as:

  • Ability to start mining a new block sooner due to receiving updated work as soon as it becomes available
  • Immediate notification with new work that includes any votes that arrive late
  • Periodic notifications with new work that include new transactions only when there have actually been new transaction
  • Simplified interface code due to removal of the need for polling and manually checking the work bytes for special cases such as the number of votes

NOTE: Miners that are not rolling the timestamp field as they mine should ensure their software is upgraded to roll the timestamp to the latest timestamp each time they hand work out to a miner. This helps ensure the block timestamps are as accurate as possible.

Transaction Script Validation Optimizations

Transaction script validation has been almost completely rewritten to significantly improve its speed and reduce the number of memory allocations. While this has many more benefits than enumerated here, probably the most
important ones for most stakeholders are:

  • Votes can be cast more quickly which helps reduce the number of missed votes
  • Blocks are able to propagate more quickly throughout the network, which in turn further improves votes times
  • The initial sync process is around 20-25% faster

Automatic External IP Address Discovery

In order for nodes to fully participate in the peer-to-peer network, they must be publicly accessible and made discoverable by advertising their external IP address. This is typically made slightly more complicated since most users run their nodes on networks behind Network Address Translation (NAT).

Previously, in addition to configuring the network firewall and/or router to allow inbound connections to port 9108 and forwarding the port to the internal IP address running dcrd, it was also required to manually set the public external IP address via the --externalip CLI option.

This release will now make use of other nodes on the network in a decentralized fashion to automatically discover the external IP address, so it is no longer necessary to manually set CLI option for the vast majority of users.

Tor IPv6 Support

It is now possible to resolve and connect to IPv6 peers over Tor in addition to the existing IPv4 support.

RPC Server Changes

New Version 2 Block Filter Query RPC (getcfilterv2)

A new RPC named getcfilterv2 is now available which can be used to retrieve the version 2 block filter
for a given block along with its associated inclusion proof. See the getcfilterv2 JSON-RPC API Documentation
for API details.

New Network Information Query RPC (getnetworkinfo)

A new RPC named getnetworkinfo is now available which can be used to query information related to the peer-to-peer network such as the protocol version, the local time offset, the number of current connections, the supported network protocols, the current transaction relay fee, and the external IP addresses for
the local interfaces. See the getnetworkinfo JSON-RPC API Documentation for API details.

Updates to Chain State Query RPC (getblockchaininfo)

The difficulty field of the getblockchaininfo RPC is now deprecated in favor of a new field named difficultyratio which matches the result returned by the getdifficulty RPC.

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

New Optional Version Parameter on Script Decode RPC (decodescript)

The decodescript RPC now accepts an additional optional parameter to specify the script version. The only currently supported script version in Decred is version 0 which means decoding scripts with versions other than 0 will be seen as non standard.

Removal of Deprecated Block Template RPC (getblocktemplate)

The previously deprecated getblocktemplate RPC is no longer available. All known miners are already using the preferred getwork RPC since Decred's block header supports more than enough nonce space to keep mining hardware busy without needing to resort to building custom templates with less efficient extra nonce coinbase workarounds.

Additional RPCs Available To Limited Access Users

The following RPCs that were previously unavailable to the limited access RPC user are now available to it:

  • estimatefee
  • estimatesmartfee
  • estimatestakediff
  • existsaddress
  • existsaddresses
  • existsexpiredtickets
  • existsliveticket
  • existslivetickets
  • existsmempoltxs
  • existsmissedtickets
  • getblocksubsidy
  • getcfilter
  • getcoinsupply
  • getheaders
  • getstakedifficulty
  • getstakeversioninfo
  • getstakeversions
  • getvoteinfo
  • livetickets
  • missedtickets
  • rebroadcastmissed
  • rebroadcastwinners
  • ticketfeeinfo
  • ticketsforaddress
  • ticketvwap
  • txfeeinfo

Single Mining State Request

The peer-to-peer protocol message to request the current mining state (getminings) is used when peers first connect to retrieve all known votes for the current tip block. This is only useful when the peer first connects because all future votes will be relayed once the connection has been established. Consequently, nodes will now only respond to a single mining state request. Subsequent requests are ignored.

Developer Go Modules

A full suite of versioned Go modules (essentially code libraries) are now available for use by applications written in Go that wish to create robust software with reproducible, verifiable, and verified builds.

These modules are used to build dcrd itself and are therefore well maintained, tested, documented, and relatively efficient.

Changelog

This release consists of 600 commits from 17 contributors which total to 537 files changed, 41494 additional lines of code, and 29215 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:

certgen utility changes:

dcrctl utility changes:

promptsecret utility changes:

Documentation:

Developer-related package and module changes:

Developer-related module management:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Aaron Campbell
  • Conner Fromknecht
  • Dave Collins
  • David Hill
  • Donald Adu-Poku
  • Hamid
  • J Fixby
  • Jamie Holdstock
  • JoeGruffins
  • Jonathan Chappelow
  • Josh Rickmar
  • Matheus Degiovani
  • Nicola Larosa
  • Olaoluwa Osuntokun
  • Roei Erez
  • Sarlor
  • Victor Oliveira
dcrd - dcrd v1.5.0-rc2

Published by davecgh almost 5 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 block header commitments
  • More efficient block filters
  • Significant improvements to the mining infrastructure including asynchronous work notifications
  • Major performance enhancements for transaction script validation
  • Automatic external IP address discovery
  • Support for IPv6 over Tor
  • Various updates to the RPC server such as:
    • A new method to query information about the network
    • A method to retrieve the new version 2 block filters
    • More calls available to limited access users
  • Infrastructure improvements
  • Quality assurance changes

For those unfamiliar with the voting process in Decred, all code in order to support block header commitments is already included in this release, however its enforcement will remain dormant until the stakeholders vote to activate it.

For reference, block header commitments were 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.5.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

Block Header Commitments Vote

A new vote with the id headercommitments 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 increase the security and efficiency of lightweight clients, such as Decrediton in its lightweight mode and the dcrandroid/dcrios mobile wallets, as well as add infrastructure that paves the
way for several future scalability enhancements.

A high level overview aimed at a general audience including a cost benefit analysis can be found in the Politeia proposal.

In addition, a much more in-depth treatment can be found in the motivation section of DCP0005.

Version 2 Block Filters

The block filters used by lightweight clients, such as SPV (Simplified Payment Verification) wallets, have been updated to improve their efficiency, ergonomics, and include additional information such as the full ticket
commitment script. The new block filters are version 2. The older version 1 filters are now deprecated and scheduled to be removed in the next release, so consumers should update to the new filters as soon as possible.

An overview of block filters can be found in the block filters section of DCP0005.

Also, the specific contents and technical specification of the new version 2 block filters is available in the
version 2 block filters section of DCP0005.

Finally, there is a one time database update to build and store the new filters for all existing historical blocks which will likely take a while to complete (typically around 8 to 10 minutes on HDDs and 4 to 5 minutes on SSDs).

Mining Infrastructure Overhaul

The mining infrastructure for building block templates and delivering the work to miners has been significantly overhauled to improve several aspects as follows:

  • Support asynchronous background template generation with intelligent vote propagation handling
  • Improved handling of chain reorganizations necessary when the current tip is unable to obtain enough votes
  • Current state synchronization
  • Near elimination of stale templates when new blocks and votes are received
  • Subscriptions for streaming template updates

The standard getwork RPC that PoW miners currently use to perform the mining process has been updated to make use of this new infrastructure, so existing PoW miners will seamlessly get the vast majority of benefits without requiring any updates.

However, in addition, a new notifywork RPC is now available that allows miners to register for work to be delivered
asynchronously as it becomes available via a WebSockets work notification. These notifications include the same information that getwork provides along with an additional reason parameter which allows the miners to make better decisions about when they should instruct workers to discard the current template immediately or should be allowed to finish their current round before being provided with the new template.

Miners are highly encouraged to update their software to make use of the new asynchronous notification infrastructure since it is more robust, efficient, and faster than polling getwork to manually determine the aforementioned conditions.

The following is a non-exhaustive overview that highlights the major benefits of the changes for both cases:

  • Requests for updated templates during the normal mining process in between tip changes will now be nearly instant instead of potentially taking several seconds to build the new template on the spot
  • When the chain tip changes, requesting a template will now attempt to wait until either all votes have been received or a timeout occurs prior to handing out a template which is beneficial for PoW miners, PoS miners, and the network as a whole
  • PoW miners are much less likely to end up with template with less than the max number of votes which means they are less likely to receive a reduced subsidy
  • PoW miners will be much less likely to receive stale templates during chain tip changes due to vote propagation
  • PoS voters whose votes end up arriving to the miner slightly slower than the minimum number required are much less likely to have their votes excluded despite having voted simply due to propagation delay

PoW miners who choose to update their software, pool or otherwise, to make use of the asynchronous work notifications will receive additional benefits such as:

  • Ability to start mining a new block sooner due to receiving updated work as soon as it becomes available
  • Immediate notification with new work that includes any votes that arrive late
  • Periodic notifications with new work that include new transactions only when there have actually been new transaction
  • Simplified interface code due to removal of the need for polling and manually checking the work bytes for special cases such as the number of votes

NOTE: Miners that are not rolling the timestamp field as they mine should ensure their software is upgraded to roll the timestamp to the latest timestamp each time they hand work out to a miner. This helps ensure the block timestamps are as accurate as possible.

Transaction Script Validation Optimizations

Transaction script validation has been almost completely rewritten to significantly improve its speed and reduce the number of memory allocations. While this has many more benefits than enumerated here, probably the most
important ones for most stakeholders are:

  • Votes can be cast more quickly which helps reduce the number of missed votes
  • Blocks are able to propagate more quickly throughout the network, which in turn further improves votes times
  • The initial sync process is around 20-25% faster

Automatic External IP Address Discovery

In order for nodes to fully participate in the peer-to-peer network, they must be publicly accessible and made discoverable by advertising their external IP address. This is typically made slightly more complicated since most users run their nodes on networks behind Network Address Translation (NAT).

Previously, in addition to configuring the network firewall and/or router to allow inbound connections to port 9108 and forwarding the port to the internal IP address running dcrd, it was also required to manually set the public external IP address via the --externalip CLI option.

This release will now make use of other nodes on the network in a decentralized fashion to automatically discover the external IP address, so it is no longer necessary to manually set CLI option for the vast majority of users.

Tor IPv6 Support

It is now possible to resolve and connect to IPv6 peers over Tor in addition to the existing IPv4 support.

RPC Server Changes

New Version 2 Block Filter Query RPC (getcfilterv2)

A new RPC named getcfilterv2 is now available which can be used to retrieve the version 2 block filter
for a given block along with its associated inclusion proof. See the getcfilterv2 JSON-RPC API Documentation
for API details.

New Network Information Query RPC (getnetworkinfo)

A new RPC named getnetworkinfo is now available which can be used to query information related to the peer-to-peer network such as the protocol version, the local time offset, the number of current connections, the supported network protocols, the current transaction relay fee, and the external IP addresses for
the local interfaces. See the getnetworkinfo JSON-RPC API Documentation for API details.

Updates to Chain State Query RPC (getblockchaininfo)

The difficulty field of the getblockchaininfo RPC is now deprecated in favor of a new field named difficultyratio which matches the result returned by the getdifficulty RPC.

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

New Optional Version Parameter on Script Decode RPC (decodescript)

The decodescript RPC now accepts an additional optional parameter to specify the script version. The only currently supported script version in Decred is version 0 which means decoding scripts with versions other than 0 will be seen as non standard.

Removal of Deprecated Block Template RPC (getblocktemplate)

The previously deprecated getblocktemplate RPC is no longer available. All known miners are already using the preferred getwork RPC since Decred's block header supports more than enough nonce space to keep mining hardware busy without needing to resort to building custom templates with less efficient extra nonce coinbase workarounds.

Additional RPCs Available To Limited Access Users

The following RPCs that were previously unavailable to the limited access RPC user are now available to it:

  • estimatefee
  • estimatesmartfee
  • estimatestakediff
  • existsaddress
  • existsaddresses
  • existsexpiredtickets
  • existsliveticket
  • existslivetickets
  • existsmempoltxs
  • existsmissedtickets
  • getblocksubsidy
  • getcfilter
  • getcoinsupply
  • getheaders
  • getstakedifficulty
  • getstakeversioninfo
  • getstakeversions
  • getvoteinfo
  • livetickets
  • missedtickets
  • rebroadcastmissed
  • rebroadcastwinners
  • ticketfeeinfo
  • ticketsforaddress
  • ticketvwap
  • txfeeinfo

Single Mining State Request

The peer-to-peer protocol message to request the current mining state (getminings) is used when peers first connect to retrieve all known votes for the current tip block. This is only useful when the peer first connects because all future votes will be relayed once the connection has been established. Consequently, nodes will now only respond to a single mining state request. Subsequent requests are ignored.

Developer Go Modules

A full suite of versioned Go modules (essentially code libraries) are now available for use by applications written in Go that wish to create robust software with reproducible, verifiable, and verified builds.

These modules are used to build dcrd itself and are therefore well maintained, tested, documented, and relatively efficient.

Changelog

This release consists of 600 commits from 17 contributors which total to 537 files changed, 41494 additional lines of code, and 29215 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:

certgen utility changes:

dcrctl utility changes:

promptsecret utility changes:

Documentation:

Developer-related package and module changes:

Developer-related module management:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Aaron Campbell
  • Conner Fromknecht
  • Dave Collins
  • David Hill
  • Donald Adu-Poku
  • Hamid
  • J Fixby
  • Jamie Holdstock
  • JoeGruffins
  • Jonathan Chappelow
  • Josh Rickmar
  • Matheus Degiovani
  • Nicola Larosa
  • Olaoluwa Osuntokun
  • Roei Erez
  • Sarlor
  • Victor Oliveira
dcrd - dcrd v1.5.0-rc1

Published by davecgh almost 5 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 block header commitments
  • More efficient block filters
  • Significant improvements to the mining infrastructure including asynchronous work notifications
  • Major performance enhancements for transaction script validation
  • Automatic external IP address discovery
  • Support for IPv6 over Tor
  • Various updates to the RPC server such as:
    • A new method to query information about the network
    • A method to retrieve the new version 2 block filters
    • More calls available to limited access users
  • Infrastructure improvements
  • Quality assurance changes

For those unfamiliar with the voting process in Decred, all code in order to support block header commitments is already included in this release, however its enforcement will remain dormant until the stakeholders vote to activate it.

For reference, block header commitments were 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.5.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

Block Header Commitments Vote

A new vote with the id headercommitments 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 increase the security and efficiency of lightweight clients, such as Decrediton in its lightweight mode and the dcrandroid/dcrios mobile wallets, as well as add infrastructure that paves the
way for several future scalability enhancements.

A high level overview aimed at a general audience including a cost benefit analysis can be found in the Politeia proposal.

In addition, a much more in-depth treatment can be found in the motivation section of DCP0005.

Version 2 Block Filters

The block filters used by lightweight clients, such as SPV (Simplified Payment Verification) wallets, have been updated to improve their efficiency, ergonomics, and include additional information such as the full ticket
commitment script. The new block filters are version 2. The older version 1 filters are now deprecated and scheduled to be removed in the next release, so consumers should update to the new filters as soon as possible.

An overview of block filters can be found in the block filters section of DCP0005.

Also, the specific contents and technical specification of the new version 2 block filters is available in the
version 2 block filters section of DCP0005.

Finally, there is a one time database update to build and store the new filters for all existing historical blocks which will likely take a while to complete (typically around 8 to 10 minutes on HDDs and 4 to 5 minutes on SSDs).

Mining Infrastructure Overhaul

The mining infrastructure for building block templates and delivering the work to miners has been significantly overhauled to improve several aspects as follows:

  • Support asynchronous background template generation with intelligent vote propagation handling
  • Improved handling of chain reorganizations necessary when the current tip is unable to obtain enough votes
  • Current state synchronization
  • Near elimination of stale templates when new blocks and votes are received
  • Subscriptions for streaming template updates

The standard getwork RPC that PoW miners currently use to perform the mining process has been updated to make use of this new infrastructure, so existing PoW miners will seamlessly get the vast majority of benefits without requiring any updates.

However, in addition, a new notifywork RPC is now available that allows miners to register for work to be delivered
asynchronously as it becomes available via a WebSockets work notification. These notifications include the same information that getwork provides along with an additional reason parameter which allows the miners to make better decisions about when they should instruct workers to discard the current template immediately or should be allowed to finish their current round before being provided with the new template.

Miners are highly encouraged to update their software to make use of the new asynchronous notification infrastructure since it is more robust, efficient, and faster than polling getwork to manually determine the aforementioned conditions.

The following is a non-exhaustive overview that highlights the major benefits of the changes for both cases:

  • Requests for updated templates during the normal mining process in between tip changes will now be nearly instant instead of potentially taking several seconds to build the new template on the spot
  • When the chain tip changes, requesting a template will now attempt to wait until either all votes have been received or a timeout occurs prior to handing out a template which is beneficial for PoW miners, PoS miners, and the network as a whole
  • PoW miners are much less likely to end up with template with less than the max number of votes which means they are less likely to receive a reduced subsidy
  • PoW miners will be much less likely to receive stale templates during chain tip changes due to vote propagation
  • PoS voters whose votes end up arriving to the miner slightly slower than the minimum number required are much less likely to have their votes excluded despite having voted simply due to propagation delay

PoW miners who choose to update their software, pool or otherwise, to make use of the asynchronous work notifications will receive additional benefits such as:

  • Ability to start mining a new block sooner due to receiving updated work as soon as it becomes available
  • Immediate notification with new work that includes any votes that arrive late
  • Periodic notifications with new work that include new transactions only when there have actually been new transaction
  • Simplified interface code due to removal of the need for polling and manually checking the work bytes for special cases such as the number of votes

NOTE: Miners that are not rolling the timestamp field as they mine should ensure their software is upgraded to roll the timestamp to the latest timestamp each time they hand work out to a miner. This helps ensure the block timestamps are as accurate as possible.

Transaction Script Validation Optimizations

Transaction script validation has been almost completely rewritten to significantly improve its speed and reduce the number of memory allocations. While this has many more benefits than enumerated here, probably the most
important ones for most stakeholders are:

  • Votes can be cast more quickly which helps reduce the number of missed votes
  • Blocks are able to propagate more quickly throughout the network, which in turn further improves votes times
  • The initial sync process is around 20-25% faster

Automatic External IP Address Discovery

In order for nodes to fully participate in the peer-to-peer network, they must be publicly accessible and made discoverable by advertising their external IP address. This is typically made slightly more complicated since most users run their nodes on networks behind Network Address Translation (NAT).

Previously, in addition to configuring the network firewall and/or router to allow inbound connections to port 9108 and forwarding the port to the internal IP address running dcrd, it was also required to manually set the public external IP address via the --externalip CLI option.

This release will now make use of other nodes on the network in a decentralized fashion to automatically discover the external IP address, so it is no longer necessary to manually set CLI option for the vast majority of users.

Tor IPv6 Support

It is now possible to resolve and connect to IPv6 peers over Tor in addition to the existing IPv4 support.

RPC Server Changes

New Version 2 Block Filter Query RPC (getcfilterv2)

A new RPC named getcfilterv2 is now available which can be used to retrieve the version 2 block filter
for a given block along with its associated inclusion proof. See the getcfilterv2 JSON-RPC API Documentation
for API details.

New Network Information Query RPC (getnetworkinfo)

A new RPC named getnetworkinfo is now available which can be used to query information related to the peer-to-peer network such as the protocol version, the local time offset, the number of current connections, the supported network protocols, the current transaction relay fee, and the external IP addresses for
the local interfaces. See the getnetworkinfo JSON-RPC API Documentation for API details.

Updates to Chain State Query RPC (getblockchaininfo)

The difficulty field of the getblockchaininfo RPC is now deprecated in favor of a new field named difficultyratio which matches the result returned by the getdifficulty RPC.

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

New Optional Version Parameter on Script Decode RPC (decodescript)

The decodescript RPC now accepts an additional optional parameter to specify the script version. The only currently supported script version in Decred is version 0 which means decoding scripts with versions other than 0 will be seen as non standard.

Removal of Deprecated Block Template RPC (getblocktemplate)

The previously deprecated getblocktemplate RPC is no longer available. All known miners are already using the preferred getwork RPC since Decred's block header supports more than enough nonce space to keep mining hardware busy without needing to resort to building custom templates with less efficient extra nonce coinbase workarounds.

Additional RPCs Available To Limited Access Users

The following RPCs that were previously unavailable to the limited access RPC user are now available to it:

  • estimatefee
  • estimatesmartfee
  • estimatestakediff
  • existsaddress
  • existsaddresses
  • existsexpiredtickets
  • existsliveticket
  • existslivetickets
  • existsmempoltxs
  • existsmissedtickets
  • getblocksubsidy
  • getcfilter
  • getcoinsupply
  • getheaders
  • getstakedifficulty
  • getstakeversioninfo
  • getstakeversions
  • getvoteinfo
  • livetickets
  • missedtickets
  • rebroadcastmissed
  • rebroadcastwinners
  • ticketfeeinfo
  • ticketsforaddress
  • ticketvwap
  • txfeeinfo

Single Mining State Request

The peer-to-peer protocol message to request the current mining state (getminings) is used when peers first connect to retrieve all known votes for the current tip block. This is only useful when the peer first connects because all future votes will be relayed once the connection has been established. Consequently, nodes will now only respond to a single mining state request. Subsequent requests are ignored.

Developer Go Modules

A full suite of versioned Go modules (essentially code libraries) are now available for use by applications written in Go that wish to create robust software with reproducible, verifiable, and verified builds.

These modules are used to build dcrd itself and are therefore well maintained, tested, documented, and relatively efficient.

Changelog

This release consists of 600 commits from 17 contributors which total to 537 files changed, 41494 additional lines of code, and 29215 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:

certgen utility changes:

dcrctl utility changes:

promptsecret utility changes:

Documentation:

Developer-related package and module changes:

Developer-related module management:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Aaron Campbell
  • Conner Fromknecht
  • Dave Collins
  • David Hill
  • Donald Adu-Poku
  • Hamid
  • J Fixby
  • Jamie Holdstock
  • JoeGruffins
  • Jonathan Chappelow
  • Josh Rickmar
  • Matheus Degiovani
  • Nicola Larosa
  • Olaoluwa Osuntokun
  • Roei Erez
  • Sarlor
  • Victor Oliveira
dcrd - dcrd 1.4.0

Published by davecgh over 5 years ago

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:

Developer-related package and module changes:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Corey Osman
  • Dave Collins
  • David Hill
  • Dmitry Fedorov
  • Donald Adu-Poku
  • ggoranov
  • githubsands
  • J Fixby
  • Jonathan Chappelow
  • Josh Rickmar
  • Matheus Degiovani
  • Sarlor
  • zhizhongzhiwai
dcrd - dcrd v1.4.0-rc3

Published by davecgh over 5 years ago

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:

Developer-related package and module changes:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Corey Osman
  • Dave Collins
  • David Hill
  • Dmitry Fedorov
  • Donald Adu-Poku
  • ggoranov
  • githubsands
  • J Fixby
  • Jonathan Chappelow
  • Josh Rickmar
  • Matheus Degiovani
  • Sarlor
  • zhizhongzhiwai
dcrd - dcrd v1.4.0-rc1

Published by davecgh almost 6 years ago

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:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Corey Osman
  • Dave Collins
  • David Hill
  • Dmitry Fedorov
  • Donald Adu-Poku
  • ggoranov
  • githubsands
  • J Fixby
  • Jonathan Chappelow
  • Josh Rickmar
  • Matheus Degiovani
  • Sarlor
  • zhizhongzhiwai
dcrd - dcrd v1.3.0

Published by davecgh about 6 years ago

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:

Developer-related package and module changes:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Dave Collins
  • David Hill
  • Dmitry Fedorov
  • Donald Adu-Poku
  • harzo
  • hypernoob
  • J Fixby
  • Jonathan Chappelow
  • Josh Rickmar
  • Markus Richter
  • matadormel
  • Matheus Degiovani
  • Michael Eze
  • Orthomind
  • Shuai Qi
  • Tibor Bősze
  • Victor Oliveira
dcrd - dcrd v1.3.0-rc2

Published by davecgh about 6 years ago

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:

Developer-related package and module changes:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Dave Collins
  • David Hill
  • Dmitry Fedorov
  • Donald Adu-Poku
  • harzo
  • hypernoob
  • J Fixby
  • Jonathan Chappelow
  • Josh Rickmar
  • Markus Richter
  • matadormel
  • Matheus Degiovani
  • Michael Eze
  • Orthomind
  • Shuai Qi
  • Tibor Bősze
  • Victor Oliveira
dcrd - dcrd v1.3.0-rc1

Published by davecgh about 6 years ago

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:

Developer-related package changes:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Dave Collins
  • David Hill
  • Dmitry Fedorov
  • Donald Adu-Poku
  • harzo
  • hypernoob
  • J Fixby
  • Jonathan Chappelow
  • Josh Rickmar
  • Markus Richter
  • matadormel
  • Matheus Degiovani
  • Michael Eze
  • Orthomind
  • Shuai Qi
  • Tibor Bősze
  • Victor Oliveira
dcrd - dcrd v1.2.0

Published by davecgh over 6 years ago

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:

Testing and Quality Assurance:

Misc:

Code Contributors (alphabetical order):

  • Andrew Chiw
  • Daniel Krawsiz
  • Dave Collins
  • David Hill
  • Donald Adu-Poku
  • Javed Khan
  • Jolan Luff
  • Jon Gillham
  • Josh Rickmar
  • Markus Richter
  • Matheus Degiovani
  • Ryan Vacek
dcrd - v1.1.0

Published by dajohi about 7 years ago

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
dcrd - v0.0.4

Published by jcvernaleo over 8 years ago

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

dcrd - v0.0.2

Published by jcvernaleo over 8 years ago

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

dcrd - v0.0.1

Published by jcvernaleo over 8 years ago

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

dcrd - v0.0

Published by jcvernaleo over 8 years ago

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

Package Rankings
Top 0.9% on Proxy.golang.org
Badges
Extracted from project README
Build Status ISC License Doc Go Report Card
Related Projects
go-crypto-wallet

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

04 Aug 2018 83
bitcoin

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

23 Sep 2023 28
solana-go

Go SDK library and RPC client for the Solana Blockchain

29 Jun 2021 672