release-notes.md

2022-10-12

Install

To install Decrediton desktop wallet, download, uncompress, and run Decrediton Linux AppImage or Decrediton Linux tar or Decrediton macOS amd64 or Decrediton macOS arm64 or Decrediton Windows.

To install the command-line tools, please see dcrinstall.

See decred-v1.7.5-manifest.txt and the other manifest files for SHA-256 hashes and the associated .asc signature files to confirm those hashes.

See README.md for more info on verifying the files.

Contents

• dcrd
• dcrwallet
• Decrediton

dcrd v1.7.5

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

Changelog

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

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

Developer-related package and module changes:

• blockchain: Misc consistency cleanup pass (decred/dcrd#3006)
• blockchain: Pre-allocate in-flight utxoview tx map (decred/dcrd#3006)
• blockchain: Remove unused utxo cache add entry err (decred/dcrd#3006)
• blockchain: Fix rare unclean utxo cache recovery (decred/dcrd#3006)
• blockchain: Don't fetch trsy{base,spend} inputs (decred/dcrd#3006)
• blockchain: Don't add treasurybase utxos (decred/dcrd#3006)
• blockchain: Separate utxo cache vs view state (decred/dcrd#3006)
• blockchain: Improve utxo cache spend robustness (decred/dcrd#3006)
• blockchain: Split regular/stake view tx connect (decred/dcrd#3006)
• blockchain: Bypass utxo cache for zero conf spends (decred/dcrd#3006)
• main: Use backported blockchain updates (decred/dcrd#3007)

Testing and Quality Assurance:

• blockchain: Address some linter complaints (decred/dcrd#3005)
• blockchain: Allow tests to override cache flushing (decred/dcrd#3006)
• blockchain: Improve utxo cache initialize tests (decred/dcrd#3006)
• blockchain: Consolidate utxo cache test entries (decred/dcrd#3006)
• blockchain: Rework utxo cache spend entry tests (decred/dcrd#3006)
• blockchain: Rework utxo cache commit tests (decred/dcrd#3006)
• blockchain: Rework utxo cache add entry tests (decred/dcrd#3006)

Misc:

• release: Bump for 1.7.5 (decred/dcrd#3008)

Code Contributors (alphabetical order):

• Dave Collins

dcrwallet v1.7.5

This release includes minor fixes and improvements for the wallet.

In addition to the fixes and new features listed below, the wallet has also been updated to follow the TestNet3 hard fork which throttles the difficulty changes allowed as hashpower is quickly increased on the network. This was an unvoted hard fork that only affects the test network, and all users of the test network must upgrade.

Bug fixes

• The SFNodeCF service flag was removed from the required services of nodes connected to in SPV mode. Version 2 compact filters are now required by consensus rules and there is no service flag to identify their support.

• An issue preventing the signrawtransaction JSON-RPC method from using private keys in the request parameters was corrected.

• The automated ticket buyer no longer attempts to mix change if the StakeShuffle server is not specified in the application config (--csppserver) or the gRPC requests that started the buyer.

New features

• The gRPC methods VotingService.TreasuryPolicies and VotingService.SetTreasuryPolicies were added for gRPC clients to be able to view and set the treasury voting policies of a ticket with VSPs.

• An importpubkey JSON-RPC method was introduced to import raw secp256k1 public keys and their derived P2PKH address to the imported account. This method is only usable on watching-only wallets.

Changelog

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

Code Contributors (alphabetical order)

• bgptr
• Dave Collins
• David Hill
• Josh Rickmar
• Matheus Degiovani

Decrediton v1.7.5

This release is mainly due to a critical fix that was included in DEX 0.5.4.

There are other small bug fixes and improvements included as well.

Bug fixes

• Fix never ending loading button on Treasury Spending tab.

• Add Ticket Spent entry to the Revocation tx details page.

• Fix placeholder size in TextInput

• Rename cspp to StakeShuffle throughout.

• Refresh DEX window with F5 key now working as expected.

• Add testnet PiKeys on testnet for treasury spending tab.

Changelog

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

Code Contributors (alphabetical order)

• Alex Yocom-Piatt

• bgptr
• Jonathan Chappelow (@chappjc)

2022-05-18

Install

To install Decrediton desktop wallet, download, uncompress, and run Decrediton Linux AppImage or Decrediton Linux tar or Decrediton macOS amd64 or Decrediton macOS arm64 or Decrediton Windows.

To install the command-line tools, please see dcrinstall.

See decred-v1.7.2-manifest.txt and the other manifest files for SHA-256 hashes and the associated .asc signature files to confirm those hashes.

See README.md for more info on verifying the files.

Contents

• Decrediton

Decrediton v1.7.3

This is a small patch release that fixes an issue with macOS 10.15 (Catalina) not being able to launch dcrd and dcrwallet properly.

We also fixed an issue with updating Treasury Spending failing due to dcrwallet not having an rpc implemented.

A couple other minor styling issues that were found in v1.7.2 were fixed as well.

Changelog

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

Code Contributors (alphabetical order)

• Alex Yocom-Piatt
• bgptr

2022-05-11

Install

To install Decrediton desktop wallet, download, uncompress, and run Decrediton Linux AppImage or Decrediton Linux tar or Decrediton macOS amd64 or Decrediton macOS arm64 or Decrediton Windows.

To install the command-line tools, please see dcrinstall.

See decred-v1.7.2-manifest.txt and the other manifest files for SHA-256 hashes and the associated .asc signature files to confirm those hashes.

See README.md for more info on verifying the files.

Contents

• dcrd
• dcrwallet
• Decrediton

dcrd v1.7.2

This is a patch release of dcrd to resolve a rare and hard to hit case when optional indexing is enabled.

Changelog

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

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

Protocol and network:

• server: Fix syncNotified race (decred/dcrd#2931)

Developer-related package and module changes:

• indexers: fix subscribers race (decred/dcrd#2921)
• main: Use backported blockchain updates (decred/dcrd#2935)

Misc:

• release: Bump for 1.7.2 (decred/dcrd#2936)

Code Contributors (alphabetical order):

• Dave Collins
• Donald Adu-Poku

dcrwallet v1.7.2

This release updates the wallet in light of the activation of DCP0009 on all Decred networks, as well as providing various other fixes.

Bug fixes

• All ticket revoking functionality has been removed or disabled due to the activation of DCP0009 which modified consensus rules to require miners to include revocations for new expired or missed tickets. The wallet will no longer log warnings and errors due to revocations being created in response to missed tickets, and all RPCs which manually revoked tickets have been deprecated and no longer perform any action. Old unspent tickets will be revoked by project members, eliminating the need for the wallet to ever create a revocation of its own.

• The verifymessage JSON-RPC method and MessageVerificationService.VerifyMessage gRPC method were corrected to return success when the message is validly signed by the keys associated with a P2PKH address. P2PK addresses are no longer valid inputs and an appropriate error will be returned if one is used.

• The walletpubpassphrasechange JSON-RPC method was enabled. This method was already implemented but the method was not exposed in the RPC API.

• Some options in the sample configuration were rewritten to move comments that described various options to their own lines. This prevents parsing and/or runtime errors if an option was uncommented due to the configuration not ignoring comments that do not begin at the start of a line.

New features

• The WalletService.GetTicket gRPC method now provides the VSP host associated with a ticket.

Changelog

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

Code Contributors (alphabetical order)

• bgptr
• Dave Collins
• Josh Rickmar

Decrediton v1.7.2

This Decrediton release includes various bug fixes for issues found during v1.7.1 usage. DCRDEX has been updated to 0.4.3. We have also added a few new features that should improve usage before the next big release.

Bug fixes

• Fix 'account not found' error when registering for DCRDEX. There was a corner case that could be triggered due to using an incorrect password when creating a DEX account.

• Launcher now allows for completion of wallets that had not completed their creation steps.

• Improved performance of Transaction/Ticket history pages. Better scroll and saving previous place where they were viewing.

• Automatically set the 'per-account encryption' during wallet creation since the passphrase is available.

New features

• Ticket transaction details now show their associated VSP Host and a button that allows for the user to check the tickets' status at that VSP.

• Due to the recent network upgrade, we've removed all of the Revoke buttons.

• We've removed DEX login step once the user has successfully launched the DEX window for the first time.

• Add Treasury Spending tab on the Governance Page. This allows for stakeholders to approve or deny the public keys that sign the tspends.

Changelog

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

Code Contributors (alphabetical order)

• Alex Yocom-Piatt

• Amir Massarwa (@amassarwi)
• bgptr
• Jonathan Chappelow (@chappjc)

2022-02-17

Install

To install Decrediton desktop wallet, download, uncompress, and run Decrediton Linux AppImage or Decrediton Linux tar or Decrediton macOS amd64 or Decrediton macOS arm64 or Decrediton Windows.

To install the command-line tools, please see dcrinstall.

See decred-v1.7.1-manifest.txt and the other manifest files for SHA-256 hashes and the associated .asc signature files to confirm those hashes.

See README.md for more info on verifying the files.

Contents

• dcrd
• dcrwallet
• Decrediton

dcrd v1.7.1

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

• Resolve an issue related to RPC authentication of limited users

Changelog

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

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

RPC:

• rpcserver: Fix websocket auth failure (decred/dcrd#2879)

Misc:

• release: Bump for 1.7.1 (decred/dcrd#2880)

Code Contributors (alphabetical order):

• Dave Collins
• 刘昆

dcrwallet v1.7.1

This release includes vote policy bug fixes for VSP users.

Bug fixes

• The setvotechoice JSON-RPC method, when setting a vote choice for a particular ticket, will use the VSP recorded with the ticket from the database rather than using the VSP in the current application configuration.

• An issue where vote choices were sometimes not communicated with the VSP for all unexpired tickets was corrected.

• The settreasurypolicy and settspendpolicy JSON-RPC methods now validate that the length of a ticket hash is exactly 32 bytes.

Changelog

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

Code Contributors (alphabetical order)

• Alex Yocom-Piatt
• Jamie Holdstock

Decrediton v1.7.1

This patch release fixes a few outstanding issues found after the initial release of v1.7.0. We have also included the new design for the Settings page and LN wallet creation.

Bug Fixes

• Live tickets were not showing fee status.

• Autobuyer wasn't working due to minimum ticketbuyer limit being 0.

• Update treasury balance to combine legacy and new treasury balances.

• Fix issue when creating DEX account that allowed for users to proceed on bad passphrase entry.

• Update menu items when changing from SPV mode for DEX access.

• Various styling issue.

Changelog

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

Code Contributors (alphabetical order)

• Alex Yocom-Piatt
• bgptr
• Jamie Holdstock
• Jonathan Chappelow
• Matheus Degiovani

2021-01-24

Install

To install Decrediton desktop wallet, download, uncompress, and run Decrediton Linux AppImage or Decrediton Linux tar or Decrediton macOS amd64 or Decrediton macOS arm64 or Decrediton Windows.

To install the command-line tools, please see dcrinstall.

See decred-v1.7.0-manifest.txt and the other manifest files for SHA-256 hashes and the associated .asc signature files to confirm those hashes.

See README.md for more info on verifying the files.

Contents

• dcrd
• dcrwallet
• Decrediton

dcrd v1.7.0

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

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

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

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

• Decentralized Treasury Spending
• Explicit Version Upgrades Consensus Change
• Automatic Ticket Revocations Consensus Change
• Change PoW/PoS Subsidy Split From 60/30 to 10/80

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

• DCP0007
• DCP0008
• DCP0009
• DCP0010

Upgrade Required

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

Downgrade Warning

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

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

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

Notable Changes

Four New Consensus Change Votes

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

Revert Treasury Maximum Expenditure Policy Vote

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

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

See DCP0007 for the full technical specification.

Explicit Version Upgrades Vote

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

The primary goals of this change are to:

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

See the following for more details:

• Politeia proposal
• DCP0008

Automatic Ticket Revocations Vote

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

The primary goals of this change are to:

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

See the following for more details:

• Politeia proposal
• DCP0009

Change PoW/PoS Subsidy Split to 10/80 Vote

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

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

See the following for more details:

• Politeia proposal
• DCP0010

Substantially Reduced Initial Sync Time

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

Unspent Transaction Output Overhaul

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

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

Unspent Transaction Output Cache

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

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

Some key properties of the cache are as follows:

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

Faster Cryptographic Signature Validation

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

The primary benefits are:

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

Significant Improvements to Network Synchronization

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

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

Support for Configurable Assumed Valid Block

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

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

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

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

Specifying a block hash closer to the current best chain tip allows for faster syncing. This is useful since the validation requirements increase the longer a particular release build is out as the default known good block becomes deeper in the chain.

Block Index Memory Usage Reduction

The block index that keeps track of block status and connectivity now occupies around 30MiB less memory and scales better as more blocks are added to the chain.

Asynchronous Indexing

The various optional indexes are now created asynchronously versus when blocks are processed as was previously the case.

This permits blocks to be validated more quickly when the indexes are enabled since the validation no longer needs to wait for the indexing operations to complete.

In order to help keep consistent behavior for RPC clients, RPCs that involve interacting with the indexes will not return results until the associated indexing operation completes when the indexing tip is close to the current best chain tip.

One side effect of this change that RPC clients should be aware of is that it is now possible to receive sync timeout errors on RPCs that involve interacting with the indexes if the associated indexing tip gets so far behind it would end up delaying results for too long. In practice, errors of this type are rare and should only ever be observed during the initial sync process before the associated indexes are current. However, callers should be aware of the possibility and handle the error accordingly.

The following RPCs are affected:

• existsaddress
• existsaddresses
• getrawtransaction
• searchrawtransactions

Version 1 Block Filters Removal

The previously deprecated version 1 block filters are no longer available on the peer-to-peer network. Use version 2 block filters with their associated block header commitment and inclusion proof instead.

RPC Server Changes

The RPC server version as of this release is 7.0.0.

Max Request Limits

The RPC server now imposes the following additional per-connection read limits to help further harden it against potential abuse in non-standard configurations on poorly-configured networks:

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

In practice, these changes will not have any noticeable effect for the vast majority of nodes since the RPC server is not publicly accessible by default and also requires authentication.

Nevertheless, it can still be useful for scenarios such as authenticated fuzz testing and improperly-configured networks that have disabled all other security measures.

More Strict Cross Origin Request (CORS) Policy

The CORS policy for WebSocket clients is now more strict and rejects requests from other domains.

In practice, CORS requests will be rejected before ever reaching that point due to the use of a self-signed TLS certificate and the requirement for authentication to issue any commands. However, additional protection mechanisms make it that much more difficult to attack by providing defense in depth.

Alternative Client Authentication Method Based on TLS Certificates

A new alternative method for TLS clients to authenticate to the RPC server by presenting a client certificate in the TLS handshake is now available.

Under this authentication method, the certificate authority for a client certificate must be added to the RPC server as a trusted root in order for it to trust the client. Once activated, clients will no longer be required to provide HTTP Basic authentication nor use the authenticate RPC in the case of WebSocket clients.

Note that while TLS client authentication has the potential to ultimately allow more fine grained access controls on a per-client basis, it currently only supports clients with full administrative privileges. In other words, it is not currently compatible with the --rpclimituser and --rpclimitpass mechanism, so users depending on the limited user settings should avoid the new authentication method for now.

The new authentication type can be activated with the --authtype=clientcert configuration option.

By default, the trusted roots are loaded from the clients.pem file in dcrd's application data directory, however, that location can be modified via the --clientcafile option if desired.

Updates to Transaction Output Query RPC (gettxout)

The gettxout RPC has the following modifications:

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

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

Removal of Stake Difficulty Notification RPCs (notifystakedifficulty and stakedifficulty)

The deprecated notifystakedifficulty and stakedifficulty WebSocket-only RPCs are no longer available. This notification is unnecessary since the difficulty change interval is well defined. Callers may obtain the difficulty via getstakedifficulty at the appropriate difficulty change intervals instead.

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

Removal of Version 1 Filter RPCs (getcfilter and getcfilterheader)

The deprecated getcfilter and getcfilterheader RPCs, which were previously used to obtain version 1 block filters via RPC are no longer available. Use getcfilterv2 instead.

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

New Median Time Field on Block Query RPCs (getblock and getblockheader)

The verbose results of the getblock and getblockheader RPCs now include a mediantime field that specifies the median block time associated with the block.

See the following for API details:

• getblock JSON-RPC API Documentation
• getblockheader JSON-RPC API Documentation

New Scripting Language Version Field on Raw Transaction RPCs (getrawtransaction, decoderawtransaction, searchrawtransactions, and getblock)

The verbose results of the getrawtransaction, decoderawtransaction, searchrawtransactions, and getblock RPCs now include a version field in the child scriptPubKey JSON object that identifies the scripting language version.

See the following for API details:

• getrawtransaction JSON-RPC API Documentation
• decoderawtransaction JSON-RPC API Documentation
• searchrawtransactions JSON-RPC API Documentation
• getblock JSON-RPC API Documentation

New Treasury Add Transaction Filter on Mempool Query RPC (getrawmempool)

The transaction type parameter of the getrawmempool RPC now accepts tadd to only include treasury add transactions in the results.

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

New Manual Block Invalidation and Reconsideration RPCs (invalidateblock and reconsiderblock)

A new pair of RPCs named invalidateblock and reconsiderblock are now available. These RPCs can be used to manually invalidate a block as if it had violated consensus rules and reconsider a block for validation and best chain selection by removing any invalid status from it and its ancestors, respectively.

This capability is provided for development, testing, and debugging. It can be particularly useful when developing services that build on top of Decred to more easily ensure edge conditions associated with invalid blocks and chain reorganization are being handled properly.

These RPCs do not apply to regular users and can safely be ignored outside of development.

See the following for API details:

• invalidateblock JSON-RPC API Documentation
• reconsiderblock JSON-RPC API Documentation

Reject Protocol Message Deprecated (reject)

The reject peer-to-peer protocol message is now deprecated and is scheduled to be removed in a future release.

This message is a holdover from the original codebase where it was required, but it really is not a useful message and has several downsides:

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

No DNS Seeds Command-Line Option Deprecated (--nodnsseed)

The --nodnsseed command-line configuration option is now deprecated and will be removed in a future release. Use --noseeders instead.

DNS seeding has not been used since the previous release.

Notable New Developer Modules

Age-Partitioned Bloom Filters

A new github.com/decred/dcrd/container/apbf module is now available that provides Age-Partitioned Bloom Filters (APBFs).

An APBF is a probabilistic lookup device that can quickly determine if it contains an element. It permits tracking large amounts of data while using very little memory at the cost of a controlled rate of false positives. Unlike classic Bloom filters, it is able to handle an unbounded amount of data by aging and discarding old items.

For a concrete example of actual savings achieved in Decred by making use of an APBF, the memory to track addresses known by 125 peers was reduced from ~200 MiB to ~5 MiB.

See the apbf module documentation for full details on usage, accuracy under workloads, expected memory usage, and performance benchmarks.

Fixed-Precision Unsigned 256-bit Integers

A new github.com/decred/dcrd/math/uint256 module is now available that provides highly optimized allocation free fixed precision unsigned 256-bit integer arithmetic.

The package has a strong focus on performance and correctness and features arithmetic, boolean comparison, bitwise logic, bitwise shifts, conversion to/from relevant types, and full formatting support - all served with an ergonomic API, full test coverage, and benchmarks.

Every operation is faster than the standard library big.Int equivalent and the primary math operations provide reductions of over 90% in the calculation time. Most other operations are also significantly faster.

See the uint256 module documentation for full details on usage, including a categorized summary, and performance benchmarks.

Standard Scripts

A new github.com/decred/dcrd/txscript/v4/stdscript package is now available that provides facilities for identifying and extracting data from transaction scripts that are considered standard by the default policy of most nodes.

The package is part of the github.com/decred/dcrd/txscript/v4 module.

See the stdscript package documentation for full details on usage and a list of the recognized standard scripts.

Standard Addresses

A new github.com/decred/dcrd/txscript/v4/stdaddr package is now available that provides facilities for working with human-readable Decred payment addresses.

The package is part of the github.com/decred/dcrd/txscript/v4 module.

See the stdaddr package documentation for full details on usage and a list of the supported addresses.

Changelog

This release consists of 877 commits from 16 contributors which total to 492 files changed, 77937 additional lines of code, and 30961 deleted lines of code.

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

See the dcrd's own release notes for a categorized breakdown of all commits since the last release.

Code Contributors (alphabetical order):

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

dcrwallet v1.7.0

This release focuses on implementing a mixing protocol change to add additional post-quantum security in the key exchanges, improvements to VSP ticketbuying, and adding support for current dcrd consensus agendas.

This prerelease software contains a database upgrade. Testers are advised to backup their wallet databases before upgrading.

New features

• Mixing support now uses a different, incompatible protocol for extra security. Users of the cspp.decred.org mix server are advised to updated their configurations to use mix.decred.org. A new server certificate will need to be downloaded as well.

• New JSON-RPC methods (settreasurypolicy, settspendpolicy, treasurypolicy, tspendpolicy) were added to control the approval policy of treasury expenditure transactions. Policies are set on a per-key basis with overriding policies for particular transaction hashes.

• The purchaseticket JSON-RPC method now respects mixing configurations and will buy mixed tickets when these settings are used.

• A mixsplitlimit config option was added to control how many concurrent connections may be made to the mixer server for a given output value for account and change mixing.

• The walletinfo JSON-RPC method now returns whether the wallet is in SPV mode or not.

• The validateaddress JSON-RPC and WalletService.ValidateAddress gRPC methods now include additional wallet information for decoded wallet address, including the account and branch paths.

• It is now possible to import extended xpriv accounts that are derived from arbitrary seeds. This is intended for importing accounts for voting and is performed with the WalletService.ImportVotingAccountFromSeed gRPC method.

• The getblock, getblockheader, getcfilterv2, getcurrentnet gettxout, and JSON-RPC methods are now supported under SPV mode.

• The median time is now included reported by the getblock JSON-RPC response.

• The WalletService.DiscoverUsage gRPC method was added to force address and account discovery.

• The WalletService.ImportExtendedPublicKey gRPC method was added to import xpubs as accounts (providing the same functionality as the importxpub JSON-RPC method).

• Ticket tracking in the database now records which VSP (if any) a ticket was purchased for. This allows the VSP client to check the status of previously-bought tickets without the polling every VSP for the ticket info. VSP tickets will also processed even if no current VSP is configured in the current application settings.

• The ticketbuyer.limit option now defaults to 1.

• A logsize config option was added to control how large log files may become before they are rotated and compressed.

Bug fixes

• The wallet no longer attempts to perform votes or revocations if the wallet only has an imported address or pubkey but no private key to sign the transaction inputs.

• The ticketbuyer.limit config option now controls how many separate connections are made to the mix server with distinct groups of transaction inputs to mix. This reduces mix correlation of larger sets of inputs with their change output.

• The WalletService.Accounts gRPC method response now contains the last returned account indexes rather than the total number of keys in an account, which more accurately reflects account usage due to how the gap limit is internally handled by the wallet.

• A bug negatively affecting performance and memory usage related to address watching was corrected.

• Several issues preventing blockchain reorganization from being handled correctly in SPV mode were fixed.

• Several deadlocks in the SPV implementation mode were corrected.

• Transaction size and fee estimation for multisig transactions was improved.

• Data races were corrected.

Changelog

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

Code Contributors (alphabetical order)

• Alex Yocom-Piatt
• David Hill
• Matheus Degiovani
• Jamie Holdstock
• JoeGruffins
• Jonathan Chappelow
• Josh Rickmar
• Victor Oliveira
• Wisdom Arerosuoghene

Decrediton v1.7.0

This release of Decrediton includes numerous bug fixes and refinement across all pages/tabs.

We have overhauled the security of Decrediton so that we can keep using electron in the future, with a decent amount of assurance that it's safe and not prone to intrusion. The overal gist of the work done could be described simply as: layer/context isolation. We reduced the total number of dependencies as well as the access those dependencies may have to private information. Users will be shown some new modals while confirming wallet seeds and confirming destination addresses.

DCRDEX is now at 0.4.0 and considered to be fully integrated with Decrediton.
Some extra work has been done to improve bitcoin config handling and overall stability of new DEX account creation. Users are now able to restore their DEX accounts with a seed from their DCRDEX windows. This should help users avoid paying fees to trading servers unnecessarily. There are a few remaining features that will be added in the future (dcrwallet SPV and ETH support), but overall is feature complete in terms of decrediton pieces.

We have begun to implement redesigns to some areas of decrediton. The Governance and LN pages got full redesigns. Changes were also made to the confirm seed view screen. There will be more of these redesigns implemented in the near future: Settings and Launcher (wallet selection) coming up next!

We have also added test coverage to all of the tabs on the Transactions page. Ideally, as we increase test coverage we will avoid bugs caused by regressions or oversight.

Lastly, we have begun the process of using our react component library: pi-ui. Things like text inputs, paginators, toggles, radio buttons are now from pi-ui. Centralizing these components should streamline the look and feel across many Decred products (politeia, cms, decrediton).

New features

• We have added a few new tools that will hopefully reduce the amount of support requests that are commonly issued. First, when restoring a wallet from seed users are now given the option to 'disable coin type upgrades' which will allow older wallet (pre-2017) to be restored on the previous coin type. We have also added a 'gap limit' setting when restoring, this should help avoid address indexes being not correctly synced which could result in incorrect balances being shown. Note: If the gap limit is changed on restore, then that gap limit will be used for that wallet from then on.

  For wallets that have already been restored that may have incorrect address indices, we have replaced the Gap Limit in settings with a 'discover usage' tool. This will allow users to properly determine their address indices and balances.

• We have added the ability to revoke tickets while in SPV mode. This seems to be a common request in support. The new 'revoke ticket' button is found in the transaction details for any non-spent ticket. Users will be presented with a confirmation modal that informs them of the risk of attempting to revoke before that confirm that the ticket is missed on dcrdata. (They would have to Abandon the 'bad' revocation transaction and rescan.)

• We have decided to hide the legacy ticket purchase area. We will wait until a later date to remove the components and code itself, but after 1.7.0 users will only be able to purchase private/acccount-less tickets.

Bug Fixes

• Fix issues with the Sync VSP Tickets dropdown

• Various fixes for Trezor wallets.

• VSPD ticket processing has been fixed and revamped. A new status of 'confirmed' has been added. This should reduce the number of misses that some users have encountered during the changeover from legacy ticket purchasing.

• Fix issue that caused large input transactions (eg PoW mining payouts) to crash decrediton. These transactions caused large numbers of addresses to be validated within dcrwallet which lead to resource exhaustion.

• Make sure that the unmixed account was unlocked when using the ticket autobuyer. This could cause funds not to be spent during auto-buying. We never had any reports of this, so unsure of the overall usage of autobuyer in general.

• Fix duplicate ticket transactions being shown in the Ticket History. Each are now labeled appropriately (eg Vote, Voted, Revoke, Revoked)

• Add insufficient balance check for the account mixer. Previously the mixer could be started even if there was no balance to mix.

Changelog

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

Code Contributors (alphabetical order)

• Alex Yocom-Piatt
• Amir Massarwa
• bgptr
• Degeri
• Guilherme Marques
• Jamie Holdstock
• Joe Gruffins
• Jonathan Chappelow
• Jonathan Zeppettini
• Matheus Degiovani
• Victor Oliveira

2021-05-12

Install

To install Decrediton desktop wallet, download, uncompress, and run Decrediton Linux or Decrediton macOS or Decrediton Windows.

To install the command-line tools, please see dcrinstall.

See decred-v1.6.3-manifest.txt and the other manifest files for SHA-256 hashes and the associated .asc signature files to confirm those hashes.

See README.md for more info on verifying the files.

Contents

• dcrwallet
• Decrediton
• DCRDEX

dcrwallet v1.6.3

This release focuses on bug fixes and feature improvements for VSP ticket buying.

New features

• An AccountUnlocked gRPC method was added to query if an account is individually encrypted and its current locked state.

• A GetTrackedVSPTickets gRPC method was added for clients to gain insight into what tickets and fees are currently being processed by the VSP client.

• A syncstatus JSON-RPC method was added to query whether the wallet is known to be synchronized with the network or not, or whether it is still performing initial synchronization.

Bug Fixes

• Additional situations which caused unexpected "low balance" bugs when purchasing tickets with a VSP have been fixed by attempting to create the additional split transaction.

• Reliability improvements were made to ensuring that fees are correctly paid to the VSP. This will result in lower missed ticket rates.

• A bug preventing correct key derivation for keys in a locked individually-encrypted account when all other wallet accounts were unlocked was fixed by deriving the pubkey, rather than erroring when attempting to derive the private key.

• A data race dealing with the synchronization of managing locked outputs was fixed.

• The automated ticketbuyer no longer errors for unlocking the wallet with an empty passphrase if the account is individually-encrypted and is unlocked by another method.

Changelog

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

Code Contributors (alphabetical order)

• Alex Yocom-Piatt
• David Hill
• Jamie Holdstock
• Josh Rickmar
• Matheus Degiovani
• Victor Oliveira
• Wisdom Arerosuoghene

Decrediton v1.6.3

This release of Decrediton includes the initial DEX integration, as well as many other graphical improvements, security upgrades, and bug fixes.

New features

• This release includes our first iteration of DCRDEX being available directly within Decrediton. There is a new page available, 'DEX' on the sidebar.
  Initially, users will be presented with the option to "enable" DEX on their wallet. Currently, we suggest using a separate wallet to use for DEX trading, instead of a users' main wallet. While we believe the wallet is still secure, the DEX integration has increased the attack surface of the wallet, so it is worth taking extra precaution while using this feature.

  Once enabled, users need to set a DEX passphrase. This passphrase is what they will use to Login and to submit orders etc. Next they need to select or create a new account for DEX. Theses funds are what will be accessible inside of the DCRDEX trading platform.

  Users must then connect their DCR and BTC wallets to DEX. Once connected, they will be guided to register their DEX account and pay the required fee.

  Once these steps are complete they will be able to launch the trading platform. Upon attempting to close Decrediton, there will be an attempt to logout of the DEX. If there are any open orders, Decrediton will not be allowed to close. This is to ensure that the swaps are able to complete successfully.

• With the introduction of DEX and privacy into Decrediton, we've decided to upgrade some of the security features in the wallet. While most of this is invisible to the user (Electron/Webpack upgrades), we have added per-account locking. Previously, when any action occured the whole wallet was unlocked and then relocked upon completion. Now only the pertinent account for the transcation will be unlocked. This will protect other accounts for situations like DEX and mixing where accounts will be unlocked for long periods of time.

• We have improved the new vspd ticket tracking so fees are now paid more frequently and process managed tickets is only shown when the user hasn't yet fully confirmed their tickets with the vspd.

Changelog

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

Code Contributors (alphabetical order)

• Alex Yocom-Piatt
• Amir Massarwa
• bgptr
• Guilherme Marques
• Jamie Holdstock
• Joe Gruffins
• Matheus Degiovani
• Scott Christian
• Victor Oliveira

DCRDEX v0.2.0

This release includes a large number of improvements to the UI, the communications protocol, and software design.

The most notable new features are:

• Numerous UI and usability enhancements including responsive design and depth chart interactivity
• Support client control by the Decrediton GUI wallet and use of its accounts
• Experimental Bitcoin Cash (BCH) support
• Initial changes to support SPV (light) wallets in the next release
• Account import/export

The latest 1.6 release of dcrd and dcrwallet is required for this release of DCRDEX. At the time of release, this corresponds to the v1.6.2 releases. Bitcoin Core 0.20 and 0.21 are both supported.

Important Notices

Although DCRDEX looks and feels like a regular exchange, the "decentralized" aspect brings an expanded role to the client. Please take the time to read and understand the following:

• Ensure your nodes (and wallets) are fully synchronized with the blockchain network before placing orders.
• Never shutdown your wallets with dexc running. When shutting down, always stop dexc before stopping your wallets.
• If you have to restart dexc with active orders or swaps, you must immediately login again with your app password when dexc starts up.
• There is an "inaction timeout" when it becomes your client's turn to broadcast a transaction, so be sure not to stop dexc or lose connectivity for longer than that or you risk having your active orders and swaps/matches revoked. If you do have to restart dexc, remember to login as soon as you start it up again.
• Only one dexc (client) process should be running for a given user account at any time. For example, if you have identical dexc configurations on two computers and you run dexc and login on both, neither dexc instance will be adequately connected to successfully negotiate swaps. Also note that order history is not synchronized between different installations.
• Your DEX server accounts exist inside the dexc.db file, the location of which depends on operating system, but is typically in ~/.dexc/mainnet/dexc.db or %HOMEPATH%\Local\Dexc\mainnet\dexc.db. Do not delete this file.
• If you use a non-default bitcoin wallet name, don't forget to set it in bitcoin.conf with a wallet=wallet_name_here line so that bitcoind will load it each time it starts. Otherwise, dexc will give you a "wallet not found" error on startup and login.
• bitcoind's "smart" fee estimation needs plenty of time to warm up or it is not so smart. When possible, keep your bitcoind running for at least 6 blocks, especially if had not been running for more than an hour, or ensure that the value returned from a bitcoin-cli call to estimatesmartfee 1 returns a "feerate" close to what https://mempool.space/ reports as "High priority".

Client (dexc)

Features and Improvements

• Experimental support for Bitcoin Cash (BCH). (542ed9b)
• Show confirmations for swaps transactions on the Order page when a swap has not yet reached the required number of confirmations. (ecbfebd)
• Open dialogs can be closed by hitting the "Escape" key. (7c978cd)
• Allow changing the dex client "application password". (8d7163c)
• Responsive browser UI design. (c91bde4)
• Differentiate between buy/sell orders in confirmation modal dialog. (2bdf81f)
• Clearer revocation notifications. (c8c9729)
• Raw transaction data is now transmitted to counterparties in the 'audit' and 'match_status' requests. This is a prerequisite for SPV clients. (3704513)
• More chart interactivity. (a) Indicators on the depth chart for the user's orders. When the mouse hovers near the indicator, the order is highlighted in the "Your Orders" table. Conversely, when the mouse hovers over a row in the "Your Orders" table, the indicator is highlighted on the chart. (b) Move the legend and hover info to the top. (c) When a rate is entered in the order form for a limit order, display a line indicator at that rate on the depth chart. (d) When the user hovers over an order in the buy/sell tables, display an indicator at that rate on the depth chart. (e) Last zoom level is saved across markets and reloads. (f) Display the total buy/sell volume. (fb6f3ea, 08ec4ac)
• Multiple authorized browser sessions are now permitted. This refers to logging in to dexc from two different browsers that do not share a cookie store. This is now permitted, however, signing out of one session signs out of all sessions. (030173b)
• A wallet's connection settings and private passphrase can be changed at the same time. Developers should see the ReconfigureWallet change. (761e3e1)
• Add account import/export functions. (1a38c4d)
• Add account disable function. (f414a87)
• Starting dexc when a configured DEX server is unreachable starts a reconnect attempt loop. Previously it was necessary to restart dexc later and hope the server was back. (c782ffb)
• Account-based DCR wallet locking support. With dcrwallet 1.6, accounts may be individually encrypted, with a unique password, in contrast to whole-wallet locking. This allows working with such accounts by using the accountunlocked dcrwallet RPC to determine the locking scheme for an account, and the unlockaccount/lockaccount RPCs instead of walletpassphrase/walletlock. The "beta" simnet DCR harness now uses an individually-encrypted "default" account. (ff4e76c, 37cdc9e)
• Handling of new server-provided fee rates. This will support SPV clients, and helps ensure that both redeem and order funding transactions are not created with low fee rates when the client's wallet/node is not providing good estimates. (79a1cb0)
• Network-specific loopback IPs for the webserver and RPC server listen addresses. Now by default, dexc listens on 127.0.0.1 for mainnet, 127.0.0.2 for testnet, and 127.0.0.3 for simnet. Users are still be able to specify custom addresses with webaddr and rpcaddr. (08ec4ac)
• Maximum order size estimates on order dialog. Get maximum order estimates based on wallet balances and, in the case of buy orders, the rate in the rate input field. The data is shown in the UI as a small message above the rate field. When you click on the label, the quantity fields are pre-populated with the max order. (920d1ac)
• dexcctl / RPC server: Add a matches list to the myorders response. (3bef6ba)
• When orders are placed, the client remembers the expected maximum fee rate, and verifies that the rate provided by the server at match time does not exceed this amount. (2123f10)
• Add a "fee rate limit" setting to each wallet that is checked against the max fee rate set by the server's config. Orders are blocked by the client if the server specifies a max fee rate that exceeds the client's limit. (414ffcc)
• On shutdown, the active orders are logged, and inactive trades have their coins released to the wallet if they were not already. (41749a8)
• Add sample config files. (also server) (792602b)
• The 'init' and 'redeem' requests are now run asynchronously so most other actions are not blocked while waiting for a response. This is generally an internal change, but it may improve the overall responsiveness of the dexc application. (a0538bb)
• Preimage request handling is reworked to prevent blocking for a long period given an incoming preimage request for an unknown order. (1b66492)
• Add a custom webserver "site" directory argument. (4506406)
• Favor confirmed UTXOs in BTC order funding. This is primarily an internal change, but it can defend against swaps that take too long to confirm. (3f6e429)
• "Long" execution times (more than 250ms) for incoming message handling and track ticks are now logged. (529cb0d)

Developer

• When Core is shut down, wallets are locked when the Run method returns. Previously, wallets were only locked if the consumer used PromptShutdown. (8976d8d) This change was in 0.1.5, but it is reiterated here as it is an significant change in behavior that Go consumers should note.
• Updates to the User struct returned by the User and Exchanges methods of client/core.Core. The client/core.Market has replaced the {Base,Quote}{Order,Contract}Locked fields with methods. (167efd4)
• When specifying TLS certificates, allow either a filename or the contents of the certificate file. This applies to the Register, GetFee, and GetDEXConfig methods of client/core.Core. (44a3363)
• Notification subjects are now package-level constants. (3aef72d)
• ReconfigureWallet has a new pass input (nil indicates no password change). (761e3e1)
• New order fee estimate API. See the new (*Core).PreOrder method and the new returned OrderEstimate type. Also see the PreSwap and PreRedeem methods of client/asset.Wallet, and the new types of the same name. (5394cea)
• New isinitialized http API endpoint and Core method. (b767a23)
• Add the (*Core).GetDEXConfig method and a corresponding http API endpoint getdexinfo the functions similar to getfee by making a temporary connection to a DEX with no existing account, except that it returns the server's entire config. (d85f6bc)
• Check the server's API version and each asset's version that are now returned in the server's 'config' response. (e59b47f, 205e802, 1bc0cc9)
• Only active orders are listed by the User and Exchanges methods of Core. Completed orders that are pending retirement are excluded. (6358d97)
• Add profiling switches to dcrdex. A CPU profile file may be specified with --cpuprofile. The http profiler may be started with --httpprof. (c17baf9)
• (internal) DCR asset backends now use rpcclient/v6, which provide cancelable requests. (312397a, 9d65d55)
• (internal) BTC's asset backend now uses Decred's rpcclient package for cancellation capability. All request now use RawRequest. (cefe6a5)
• (internal) All incoming response and notification message handlers are wrapped for panic recovery. (829a661)
• (internal) Message unmarshalling is now more robust with respect to null payloads. (9bf1a3e)
• Many third party Go dependency updates. (go.mod diff)
• Update site build system to Webpack 5, and update most other deps. (a8e76ea)
• Add an ETH simnet harness for support of upcoming ETH support. (ea10f5a)
• The simnet harnesses now listen on all interfaces. (4e246cf)
• The Decred wallet harnesses now start dcrwallet with http profiling enabled. (b96f546)
• Rework the db.MetaMatch struct. (db3df62)

Fixes

In addition to numerous fixes that were also in the 0.1.x releases, the most notable fixes are:

• No longer show the Register dialog if the server for the only registered DEX happens to be down at the time. (b6ea0ea)
• Correct handling of IPv6 listen addresses. (also on server) (f0ef965)
• Update the browser UI when orders are placed via dexcctl. (8cc1502)
• Better error reporting on the DEX registration dialog. (2617d75)
• More robust recovery for orders that become unfunded (e.g. user spends coins that were reserved for an order). (122277e)
• No longer prematurely broadcast Decred refund transactions. (03cdf2d)
• Commitment checksum handling in the presence of missed preimage is now handled the same way as on the server by including the all epoch order commitments in the csum computation, not just the ones with revealed preimages. (25e3679, 7d71ffd)
• Never show negative confirmations for swap transactions even before they have been checked. (fb39b97)
• The mouse wheel only zooms when hovering over the depth chart, no longer scrolling the page at the same time. (736b005)

Server (dcrdex)

• Swapper resumes on startup from DB rather than a state file. (a676e07)
• Market data API endpoints. /spots is the spot price and booked volume of all markets. /candles is candlestick data, available in bin sizes of 24h, 1h, 15m, and per-epoch sticks. e.g. /candles/dcr/btc/15m. /orderbook is already a WebSocket route, but is now also accessible by HTTP. An example URL is /orderbook/dcr/btc. /config is another WebSocket route that is also now available over HTTP too. (08afde3)
• Configurable trade limits with the new --inittakerlotlimit and --abstakerlotlimit dcrdex switches, and userBookedLotLimit set in markets.json. (5771186)
• Provide API and asset versions in the 'config' response. (e59b47f, 205e802, 1bc0cc9)
• Begin sending TxData (raw tx) in audit and match_status requests to counterparty. This will support SPV clients. (370451)
• Experimental Bitcoin Cash (BCH) support. (542ed9b)
• Version the DB scheme and implement initial updates to populate historical market data in the epoch_reports table. (d000f19)
• The outgoing preimage request now includes the commitment for the preimage being requested. (850e8a6)
• Provide fee rate estimates to the clients in certain messages: orderbook, epoch_report, and the new fee_rate route. With this data provided to the clients, minimum fee rates of zero-conf funding coins are enforced. (79a1cb0, 9885bf1)
• Fix market suspension not purging the outgoing book router's orders list. The actual book was purged, but clients would still pull a book snapshot listing orders if they restarted after a purge. (a25d14e)
• Order priority queue automatic reallocation and smaller initial capacity. (3750cce)
• New administrative endpoints: orderbook, epochorders, and matches. (0ce3ec7)
• Add order ID to cancel route error message. (0a7157b)
• Various test harness improvements. (ca9882d)
• Active order counts are logged when a user authenticates. (945cb4a)
• Drop the dependency on the deprecated golang.org/x/crypto/ssh/terminal repository. (cae9f5a)
• The /api/market/{marketID}/matches endpoint now returns decoded swap/redeem coin IDs and an idiomatic JSON response. (a1fbdc0)

Build requirements

• Go 1.15 or 1.16
• Node 14 is the minimum supported version for building the site assets.
• dcrd and dcrwallet must still be built from their release-v1.6 branches.
• The minimum required dcrwallet RPC server version is 8.5.0, which corresponds to the v1.6.2 patch release of dcrwallet, but the latest release-v1.6.x tag should be used.

Code Summary

166 commits, 287 files changed, 40,296 insertions(+), 18,072 deletions(-)

https://github.com/decred/dcrdex/compare/4517832...release-v0.2

9 contributors

• Amir Massarwa (@amassarwi)
• Brian Stafford (@buck54321)
• David Hill (@dajohi)
• Joe Gruffins (@JoeGruffins)
• Jonathan Chappelow (@chappjc)
• Kevin Wilde (@kevinstl)
• @peterzen
• Victor Oliveira (@vctt94)
• Wisdom Arerosuoghene (@itswisdomagain)

2021-04-08

Install

To install Decrediton desktop wallet, download, uncompress, and run Decrediton Linux or Decrediton macOS or Decrediton Windows.

To install the command-line tools, please see dcrinstall.

See decred-v1.6.2-manifest.txt and the other manifest files for SHA-256 hashes and the associated .asc signature files to confirm those hashes.

See README.md for more info on verifying the files.

Contents

• dcrd
• dcrwallet
• Decrediton

dcrd v1.6.2

This is a patch release of dcrd to introduce a quality of life change for lightweight clients, such as SPV wallets, by not sending them a certain class of announcements that only full nodes are equiped to handle.

Changelog

This patch release consists of 2 commits from 1 contributor which total to 3 files changed, 55 additional lines of code, and 31 deleted lines of code.

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

Protocol and Network

• server: Only send fast block anns to full nodes (decred/dcrd#2609)

Misc

• release: Bump for 1.6.2 (decred/dcrd#2629)

Code Contributors (alphabetical order)

• Dave Collins

dcrwallet v1.6.2

This release focuses on bug fixes and feature improvements for VSP ticketbuying and change mixing.

New Features

• A accountunlocked JSON-RPC method was added, allowing clients to determine whether an account has been encrypted with a unique passphrase, and if it is currently unlocked if so.

• The setvotechoices JSON-RPC method will now use the vspd client to set vote choices at the VSP, if any is configured in the application settings and the ticket was bought for the VSP.

Bug Fixes

• A UTXO selection issue which caused "low balance" errors during the additional split transaction sometimes necessary when purchasing tickets with a VSP was fixed. Some UTXOs of the account were not always being considered during the creation of this transaction, which led to the balance errors.

• A check for a too-low fee when mixing at the smallest common amount was added. This previously was causing "invalid submission" errors, as the server would reject the submission for not paying enough fee.

Changelog

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

Code Contributors (alphabetical order)

• Jonathan Chappelow
• Josh Rickmar

Decrediton v1.6.2

This patch release for Decrediton includes just a few small changes for copy and buttons missing text.

Bug Fixes

• Missing Legacy Ticket purchase button text.

• Incorrect copy on Governance for thresholds for upgrading the network.

Changelog

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

Code Contributors (alphabetical order)

• Alex Yocom-Piatt
• Amir Massarwa
• bgptr
• Matheus Degiovani

2021-02-23

Install

To install Decrediton desktop wallet, download, uncompress, and run Decrediton Linux or Decrediton macOS or Decrediton Windows.

To install the command-line tools, please see dcrinstall.

See decred-v1.6.1-manifest.txt and the other manifest files for SHA-256 hashes and the associated .asc signature files to confirm those hashes.

See README.md for more info on verifying the files.

Contents

• dcrd
• dcrwallet
• Decrediton
• dcrdex

dcrd v1.6.1

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

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

Changelog

This patch release consists of 3 commits from 1 contributor which total to 3 files changed, 30 additional lines of code, and 9 deleted lines of code.

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

Protocol and Network

• server: Notify block mgr later and track ntfn (decred/dcrd#2588)
• server: Force PoW upgrade to v8 (decred/dcrd#2597)

Misc

• release: Bump for 1.6.1 (decred/dcrd#2600)

Code Contributors (alphabetical order)

• Dave Collins

dcrwallet v1.6.1

This release focuses on fixing issues with the new VSP fee payments and account mixing.

New Features

• A WalletServer.SetVspdVoteChoice gRPC method was added, allowing clients to update the agenda preferences for the new VSP software.

Bug Fixes

• An additional transaction may be created now when an account does not have enough UTXOs to pay for both a ticket and a VSP fee. This avoids insufficient balance errors where possible and prevents the user from needing to split a UTXO themselves.

• Several issues causing double spends when dealing with unpublished transactions were corrected. This improves the reliability of paying the VSP fee.

• Account balances no longer report the outputs of unpublished transactions as spendable with minconf=0. Instead, these balances are added to the unconfirmed balance.

• Account and output mixing now considers the required fee necessary when selecting which common output amount and output count to mix with. This fixes mixing for some outputs which are currently being rejected by the CoinShuffle++ server due to not paying enough of the required transaction fee.

• The signrawtransaction JSON-RPC method was changed to return an error if the transaction being signed has no inputs.

• The salsa20 and blake2b dependencies were updated to prevent possible memory corruption caused by smashing the SP register in optimized assembly implementations.

Changelog

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

Code Contributors (alphabetical order)

• Josh Rickmar

Decrediton v1.6.1

This patch release fixes several issues discovered in the v1.6.0 release.

Most changes are focused on improving the staking experience with the new VSP system: unexpected insufficient balance error is fixed, successes and failures of various staking operations are better reported now, setting consensus vote choices on the new VSP was implemented.

Updates

• Consensus change voting is now working as expected. When a user sets their vote choice, it is updated in their local wallet and also sent to any legacy VSP. Every live ticket they have assigned with a new VSP is updated as well.

• Due to the way the coins (UTXOs) are handled when purchasing tickets, there is a possibility of the underlying dcrwallet purchasing fewer tickets than what the user requested. This condition is now explained with a better message, to help the user understand why, for example, they only got 1 ticket when trying to buy 2.

• Labels on the Staking tab have been updated to make things more clear with the new tickets and the old tickets.

• An initial Traditional Chinese translation was completed by @smartwojak and verified by long-standing community member Hugo Chang (@changhugo).

• Running or attempting multiple things at the same time is no longer allowed to avoid possible issues or unexpected errors. For instance, when the mixer is running, users may not purchase tickets or run the autobuyer, and vice versa. To perform an action, the user needs to turn off a running activity before proceeding. Several tooltips have been added to make the user aware of the situation.

• Loading indicators have been added to various buttons related to ticket purchasing, to indicate that the user should wait for a long-running operation (like mixed ticket purchasing) to complete.

• Success and failure messages have been added to various new ticket purchasing actions. Now users will be shown a message when they successfully complete (or receive errors for) the following actions: verify that visible tickets are assigned to VSPs and have their fees paid (Process Managed), discover tickets not yet assigned to a VSP and pay their fees (Process Unmanaged), and sync failed VSP tickets.

Bug Fixes

• Added a timeout when not receiving VSP status response within 5 seconds.

• Transaction history filtering has been fixed and now allows to select multiple types of transactions at once.

• Tickets will now show as "Processing", "Error" or "Paid" shortly after purchase. Previously they would be shown as "Solo" until a restart or another block was mined.

• Added explicit wallet lock calls to ensure that wallet is locked after mixing or ticket autobuyer requests.

• There were a few reports of incorrectly created legacy ticket purchases due to a still unknown cause. To work-around this we've added sanity checks prior to purchase request to dcrwallet to avoid any potential malformed requests from being sent. This won't solve the core issue, but should at least notify users of something wrong occuring and give us data to investigate further.

Changelog

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

Code Contributors (alphabetical order)

• Alex Yocom-Piatt
• Amir Massarwa
• bgptr
• Guilherme Marques
• JoeGruffins
• Matheus Degiovani
• Scott Christian
• smartwojak
• Victor Oliveira

dcrdex v0.1.5

This patch release provides several important bug fixes.

Please read the initial release (v0.1.0) notes for important information and instructions.

Client (dexc)

Features and Improvements

• The user's account ID is now logged on connection and authentication with a DEX server. (8ce328)

Fixes

• Fix a possible panic when reconfiguring a wallet that is not connected. (dfe4cd)

• When resuming trades on startup and login, counterparty contract audits now retry repeatedly, as is the case when an audit request is initially received. This prevents a match from being incorrectly revoked on startup if the wallet/node fails to locate the counterparty contract immediately. (dfe4cd)

• The client's database subsystem is always started first and stopped last. This is a prerequisite for the following wallet lock-on-shutdown change. (b4ef3f)

• On shutdown of client Core, the wallets are now locked even if the PromptShutdown function is not used. This does not affect dexc users, only direct Go consumers of the client/core.Core type. (70044e)

• Fix a possible interruption of the DEX reconnect loop if the config response timed out. (4df683)

• Update the crypto/x/blake2 dependency to prevent silent memory corruption from the hash function's assembly code. (c67af3)

• Handle orders that somehow lose their funding coins. Previously, such orders would forever be logged at startup but never retired, and any matches from such orders that required swap negotiation of other recovery would have been improperly abandoned. (a7b5aa)

Server (dcrdex)

There are no substantive server changes, just a few logging improvements.

Code Summary

11 commits, 13 files changed, 564 insertions(+), and 254 deletions(-)

https://github.com/decred/dcrdex/compare/v0.1.4...v0.1.5

3 contributors

• Brian Stafford (@buck54321) (review)
• David Hill (@dajohi) (blake2 fix)
• Jonathan Chappelow (@chappjc)

2021-01-25

Install

To install the command line tools, please see dcrinstaller. To install decrediton download, uncompress, and run decrediton Linux or decrediton macOS or decrediton Windows.

See manifest-v1.6.0.txt, and the package specific manifest files for sha256 sums and the associated .asc files to confirm those shas.

See README.md for more info on verifying the files.

Contents

• dcrd
• dcrwallet
• decrediton
• dcrlnd
• dcrdex

dcrd v1.6.0

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

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

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

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

• Decentralized Treasury Consensus Change

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

• DCP0006

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

Downgrade Warning

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

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

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

Notable Changes

Decentralized Treasury Vote

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

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

See the initial Politeia proposal for more details.

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

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

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

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

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

HTTPS Seeding

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

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

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

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

Signature Validation And Other Crypto Operation Optimizations

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

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

Proactive Signature Cache Eviction

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

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

Orphan Transaction Relay Policy Refinement

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

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

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

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

Ticket Exhaustion Prevention

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

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

New Initial State Protocol Messages (getinitstate/initstate)

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

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

Mining State Protocol Messages Deprecated (getminings/minings)

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

RPC Server Changes

The RPC server version as of this release is 6.2.0.

New Treasury Balance Query RPC (gettreasurybalance)

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

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

New Treasury Spend Vote Query RPC (gettreasuryspendvotes)

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

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

New Force Mining Template Regeneration RPC (regentemplate)

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

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

New Unspent Transaction Output Set Query RPC (gettxoutsetinfo)

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

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

Updates to Peer Information Query RPC (getpeerinfo)

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

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

Enforced Results Limit on Transaction Search RPC (searchrawtransactions)

The maximum number of transactions returned by a single request to the searchrawtransactions RPC is now limited to 10,000 transactions. This far exceeds the number of results for all typical cases; however, for the rare cases where it does not, the caller can make use of the skip parameter in subsequent requests to access additional data if they require access to more results.

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

New Index Status Fields on Info Query RPC (getinfo)

The results of the getinfo RPC now include txindex and addrindex fields that specify whether or not the respective indexes are active.

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

Version 1 Block Filters Deprecated

Support for version 1 block filters is deprecated and is scheduled to be removed in the next release. Use version 2 block filters with their associated block header commitment and inclusion proof instead.

Changelog

This release consists of 616 commits from 17 contributors which total to 526 files changed, 63090 additional lines of code, and 26279 deleted lines of code.

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

See the dcrd's own release notes for a categorized breakdown of all commits since the last release.

Code Contributors (Alphabetical Order)

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

dcrwallet v1.6.0

This release focuses on adding support for the decentralized Decred treasury, improved SPV syncing with version 2 committed filters, and client support for the new privacy-conscious VSP implementation to make mixed VSP ticketbuying viable.

A comprehensive list of improvements and bug fixes follows.

Notable Changes

Decentralized Treasury

• Support for the decentralized treasury consensus change is added. Two new JSON-RPC methods sendtotreasury and spendfromtreasury are added, to send to and spend from value in the treasury, respectively. The vote version and current agendas have been updated to allow stakeholders to vote on the activation of the decentralized treasury.

SPV Mode

• Version 2 committed filters are now used, rather than the previous version 1 filters. These filters are consensus validated by proof-of-work miners as part of the commitments in the block header. Version 2 filters are smaller and also do not require knowledge of the exact outputs spent, but rather only the previous output script (or address).

• The fundrawtransaction JSON-RPC method is now directly implemented by dcrwallet, rather than delegating this method to dcrd through RPC passthrough. This allows the method to be usable under SPV mode.

• A WalletService.GetRawCFilters gRPC method was added to query the wallet-stored version 2 committed filter for specified blocks.

• Both a getpeerinfo JSON-RPC method and WalletService.GetPeerInfo gRPC method were implemented to provide peer info in SPV mode. The JSON-RPC method continues to return results from a connected dcrd when syncing in RPC mode.

• A sendrawtransaction implementation has been added to the JSON-RPC server. This allows arbitrary transactions to be published under SPV mode.

Staking

• A client for the new vspd server was added, and dcrwallet supports this client functionality from both the ticket autobuyer and through various gRPC methods.

• A ticketinfo JSON-RPC method was added to provide detailed status information regarding all tickets from the wallet.

• Vote preferences may now be specified on a per-ticket basis with added optional parameters to the setvotechoice JSON-RPC method. This feature is used by the new vspd server.

• The stakepooluserinfo JSON-RPC method has been reintroduced, after being removed from prior releases. This is used by the new vspd server.

• Unpublished transactions are now supported. When an unpublished transaction is saved to the database, the outputs it spends are tallied in balance results and are not spendable by other transactions. Unpublishd transactions will not be automatically rebroadast to the network when the wallet starts up and begins syncing. Unpublished transactions are used to record transactions paying vspd fees prior to the vspd instance accepting the client's ticket request.

• A --manualtickets flag was added to the application config. This setting disables discovering any tickets from the network syncing, instead requiring any tickets to be manually added to the wallet using addtransaction. This feature is used by the new vspd server to avoid voting on unprocessed tickets which used a vspd voting address. The current state of this setting is reported in the walletinfo JSON-RPC result.

• The WalletService.PurchaseTickets gRPC method gained a dont_sign_tx parameter to support unsigned ticket purchasing and eventual hardware wallet signing.

• Ticket purchasing will now attempt to buy fewer tickets than requested when there is a low balance, either due to a bad estimate of how many tickets could be purchased, or due to outputs being reserved to pay the fees for the new vspd server.

Mixing

• An AccountMixerService was added to the gRPC server to perform CoinShuffle++ mixing on all funds received by an account.

• The WalletService.PurchaseTickets method gained support for specifying CoinShuffle++ options for mixed ticket buying.

• The getcoinjoinsbyacct JSON-RPC method and WalletService.GetCoinjoinOutputspByAcct gRPC methods were added to discover probable CoinJoin transactions and report them by account.

• Outputs which are being mixed are now locked to prevent accidental spending before the mix completes.

• Mix denominations above the ticket price are now avoided when mixing large value outputs. This improves pairing with the large volume of mixes occurring from ticket buying, as there are many pairings occurring at the standard denominations below the ticket price to mix CoinJoin change outputs.

• Mixed ticketbuying using the autobuyer will now default to buy one ticket per client connection if the limit is unset. Setting a larger limit will continue to buy at most limit number of tickets per client connection.

Wallet Encryption and Authentication

• A walletpassphrasechange JSON-RPC method was added to modify the wallet's public data encryption passphrase. Changing to the default insecure value "public" effectively removes any prompts for the public passphrase at startup.

• Accounts are now able to be encrypted using separate, per-account passphrases. Unlocking an account only provides access to that account's private keys, and no others. Account passphrases may be set using the setaccountpassphrase JSON-RPC method, and locked and unlocked by the unlockaccount and lockaccount methods.

• JSON-RPC clients may now be authenticated using TLS client certificates, and this authentication is now required for the gRPC server. The feature may be enabled for JSON-RPC by using the --jsonrpcauthtype=clientcert config flag. Client certificates read from a clients.pem file in the application directory are trusted by default, and this file may be modified by the --clientcafile config flag. Additionally, an --issueclientcert flag is provided which causes the wallet to issue and send an ephemeral client certificate and key over the TX pipe to the parent process which forked dcrwallet. Client certificates may be generated by the gencerts tool, which is now part of the Decred CLI distribution.

• gRPC methods to lock and unlock the wallet's global keys and individually-encrypted accounts are now added, and the passphrase in all requests which required an unlocked wallet are now optional. As the gRPC server now requires client authentication, there is no a risk of an unauthenticated client from quickly hitting an already-unlocked wallet or account and using private keys it should not otherwise have access to.

• The scrypt KDF used for wallet encryption keys now defaults to weaker parameters on simnet. This is primarily done for quicker unit tests, but will also affect real dcrwallet simnet instances by requiring less time and memory to derive keys.

Other Improvements

• A createsignature JSON-RPC method was introduced, analogous to the gRPC WalletService.CreateSignature method.

• A discoverusage JSON-RPC method was introduced, which triggers the same address and account discovery as performed on startup when there are new blocks available. However, this method is more general purpose and is useful when correcting issues with prior discoveries, at it allows specifying the exact starting blocks and a BIP0044 gap limit to use.

• A WalletService.SignHashes gRPC method was added to sign an arbitrary number of 32-byte hashes. This method was used by the now-defunct TumbleBit implementation.

• A WalletService.Spender gRPC method was added to query the transaction and input index which spends a wallet output.

• The WalletService.TransactionNotifications gRPC method now provides more details about the block headers which were detached during a reorganize, rather than only their hashes.

• An addtransaction JSON-RPC method was added, allowing transactions to be manually added to the wallet, mined in a specified block, without discovering the transaction through the network.

• A NetworkService.GetRawBlock gRPC method was added to fetch raw blocks using the wallet's peer-to-peer implementation.

• An optional account parameter was added to the listunspent and listlockunspent JSON-RPC methods to filter results for a particular account.

• The listunspent JSON-RPC method now includes the hex encoding of a redeem script when the output is P2SH and the redeem script is known.

• Peer-to-peer seeding is now performed over an HTTPS API rather than DNS. This improves reliability (HTTPS is authenticated), as well as greater control of filtering results by various URL parameters.

• The LOGFLAGS environment variable may now include a UTC flag to cause the wallet to always log with UTC timestamps, regardless of the current system timezone.

• Many log messages were added, removed, or rewritten to better reflect the operational state of the application.

• Imported scripts are now recorded in plain text and the wallet does not need to be unlocked to retrieve the full script for the P2SH address. This change is made under the assumption that imported redeem scripts should not be secrets themselves, but still require a signature check at the very least.

• Importing an already-existing redeem script from the importscript JSON-RPC method no longer starts a rescan.

• Output locking no longer considers differences between the regular and stake transaction trees.

• Wallet setup may now be performed by providing answers to the prompts from piped output or a redirected file, as long as the passphrase is provided using the --pass flag.

• Newly created simnet wallets now always use the SLIP0044 coin type. This ensures that the printed mining address during the creation process will not become invalid after a coin type upgrade from the legacy to the SLIP0044 coin type following address discovery.

• The latest peer-to-peer protocol version is now supported. The miningstate and initstate messages which are expected in this version are replied to with empty responses.

Bug Fixes

• A memory leak of requests and responses made to a dcrd websocket server was plugged.

• Imported xpub accounts no longer produce errors while trying to read the account's xpriv.

• Created transactions are now checked against the current network's maximum transaction size limit, to avoid creating transactions which are too long for consensus-validating nodes to accept.

• An out-of-bounds panic seen during address discovery of imported xpub accounts was corrected.

• A data race during the subscribing of transaction notifications involving wallet addresses was fixed.

• The getaddressesbyaccount JSON-RPC method now returns results for the imported account.

• The database implementation used by dcrwallet (bbolt) was fixed and updated to remove invalid usage of Go's unsafe programming features.

• The peer-to-peer implementation now allows the same block to be requested concurrently by the same peer. This fixes some occasional errors which stopped the SPV syncer under normal wallet usage.

• The autobuyer will no longer mix the change account when the wallet is not up to date with other peers on the network. This avoids submitting mix requests involving outputs which may have already been spent.

• A memory leak of wallet address private keys when operating a wallet that remained always unlocked was plugged.

• The stakebase script found in vote transactions is now included when creating the unsigned vote, rather than during signing. This fix ensures that the correct stakebase script for the active network is always used, instead of filling in the script for a different network.

• UTXO selection is now aware of output maturity and will not include immature outputs.

Changelog

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

Code Contributors

In alphabetical order:

• Alex Yocom-Piatt
• Brian Stafford
• Dave Collins
• David Hill
• Donald Adu-Poku
• Jamie Holdstock
• Jonathan Chappelow
• Josh Rickmar
• Julian Yap
• Kifen
• Marco Peereboom
• Matheus Degiovani
• Matt Hawkins
• Mike Belopuhov
• peterzen
• Victor Oliveira
• Wisdom Arerosuoghene

decrediton v1.6.0

This release includes two major functionality improvements for staking and privacy. The past privacy improvements that were available for dcrwallet are now implemented in decrediton for ticket purchasing and account mixing. Accountless VSP ticket purchasing has been added as well that should greatly simplify the staking process and increase privacy.

There have been numerous graphical improvements and bug fixes that will hopefully lead to a smoother UX and reduce support questions and intervention.

New Features

Privacy

We have added a new menu item that covers Privacy and Security tools. Users should go there to 'enable' privacy on their wallets. This enabling process is not done automatically yet, mostly due to required user intervention with private passphrase entry to create needed mixed and unmixed accounts. Hopefully in the future we will add this step to the wallet launcher.

Once enabled, the privacy page will transform into an account mixer form that allows users to mix funds from the unmixed account into the mixed account. To follow what dcrwallet is doing, there is a log window below. In the future, we may add better messaging that will allow updates to the mixing process instead of just showing raw logs.

Once privacy is enabled, spending to external addresses is only allowed from the mixed account. This is to ensure privacy is not broken by spending from any unmixed account. Additionally, it is not allowed to manually generate addresses in the mixed account, since only funds that have been properly mixed should be allowed to end up there.

There is a checkbox that allows users to forgo the external spending restriction. There is a dominant warning and users must confirm the risks they are imposing by spending from unmixed accounts.

Accountless VSP Staking with Optional Mixing

The new accountless VSP ticket purchasing process has been added. Now there is no need to create an account at VSP's website, add its API key in Decrediton and backup redeem scripts. Users may now simply go to the tickets page, select the VSP they'd like to use and the number of tickets to purchase.

This new way of staking is more private even without mixing enabled since it eliminates address reuse and the use of email. It is recommended that users migrate their tickets to this new system sooner. Read more here.

If privacy is enabled, the process of purchasing a ticket requires there to be a successful mix to occur. Mix sessions happen every 20 minutes and participating in a single session is usually (though not always) sufficient. If successful, the mixed split ticket funding transaction, the ticket, and the ticket's fee, should all be seen on the overview. But as you may notice, the ticket's fee is not yet broadcast onto the network by the VSP until the ticket has been confirmed by 6 blocks. If any tickets have missing or errored fees, the user will be notified if they try to close Decrediton.

Other Updates

• Menu was reorganized and optimized to accomodate added tabs and tools. Since we are quickly adding functionality we need to make sure the left-hand sidebar menu is as efficient as possible without becoming bloated with items. Hopefully the current layout allows for more growth for tools and functionality.

• Peer count is now shown on the side bar. This should alleviate issues where people don't know why their transactions aren't getting mined.

• An SPV indicator has been added to the sidebar. Previously there was no way of understanding what mode the wallet was running in without looking at Settings page.

• Unmined transactions are now able to be abandoned under transaction details. This should fix issues that people previously had unminable transactions "stuck" in their wallet. If the network doesn't know about the transaction, then they should be able to be abandoned and the funds unreserved.

• A full refactor of components into functional components is now mostly complete. This should now allow for more agile development moving forward.

Code Contributors

In alphabetical order:

• Alex Yocom-Piatt
• Amir Massarwa
• artikozel
• bgptr
• David Hill
• degeri
• Fernando Guisso
• Guilherme Marques
• Jamie Holdstock
• JoeGruffins
• Jonathan Zeppettini
• karamble
• Matheus Degiovani
• Nicola Larosa
• Piotr Delikat
• Thiago F. Figueiredo
• unimere
• Victor Oliveira
• Victor Guedes
• Zubair Zia

Welcome our new additions to the decrediton team: Amir Massarwa, bgptr, Fernando Guisso, JoeGruffins, Guilherme Marques, Victor Guedes.

dcrlnd v0.3.0

Please note that while Bitcoin's Lightning Network has been in production for a few years, Decred's version still hasn't seen extensive use in mainnet. Users should be mindful of the total amount of funds committed to dcrlnd wallets and channels.

This is a major dcrlnd release including significant amount of changes.

This release brings dcrlnd in line with the upstream lnd release v0.11.1 and also includes ports for versions v0.11.0, v0.10.0 and v0.9.0.

Vulnerability Fixes

This release includes fixes for CVE-2020-26896 and CVE-2020-895 made in the upstream lnd project. Fixes for these were released in upstream versions v0.11.0 and v0.10.0 respectively and the underlying issues were fully disclosed in Oct 20, 2020.

Additional context for the vulnerabilities and its impact in LN implementations, written by the original discoverer can be found here and here

Database Migrations

This release contains database migrations for the new TLV encoding of invoices, payment address indexing and close summary information. Old versions of dcrlnd cannot use the new database version once these migrations are applied.

Changelog

The major Decred-specific feature introduced in this release is the ability to run a dcrlnd instance connected to a dcrwallet running in SPV mode. This is useful mostly for Decrediton users that will now have the option to run dcrlnd even when their wallet is using the SPV configuration.

Node Syncing Config

CLI users now have two options for the --node argument:

• --node=dcrd instructs dcrlnd to connect to a dcrd instance for on-chain operations.
• --node=dcrw instructs dcrlnd to use the underlying dcrwallet instance for on-chain operations.

When using --node=dcrd, the --dcrd.-namespaced options should be used to configure the connection to the underlying dcrd node.

When using --node=dcrw, either the --dcrd.-namespaced options should be used, in order to use an embedded dcrwallet instance (that is, dcrwallet runs automatically inside dcrlnd) or the --dcrw.-namespaced options should be used to configure a remote dcrwallet instance.

Note that SPV mode is only supported on remote dcrwallet instances.

For hub nodes (that is, nodes that are online most of the time and offer the ability to receive open channel requests) the recommended config setting is to use embedded wallets with a dcrd instance.

Wumbo Channel Support

This release adapts the Wumbo feature for the realities of Decred. Wumbo channel support can be enabled by running dcrlnd with --protocol.wumbo-channels and has a global maximum channel size of 500 DCR.

Relevant Upstream Changes

The following is a non-exhaustive list of the relevant upstream changes that were ported to dcrlnd. These include changes from the upstream v0.9, v0.10 and v0.11 lines. Please refer to the respective upstream releases for additional information.

• Multi Path Payment (MPP) support so that a single payment can be split among multiple channels.
• Track payments with a new Payment Address field.
• Additional TLV data sent in payments, which allows creating new use cases to deliver payload data via LN payments.
• Keysend payment experiment which allows spontaneous payments without the need for a precreated invoice.
• Upfront shutdown script support to enforce channel closure to pay to pre-configured addresses.
• HTLC Interception API to allow creation of custom payment forwarding engines.
• Additional data in Channel Close Summaries.
• Add ability to limit max remote pending HTLC amount during channel opening.
• Anchor outputs experimental feature.
• External channel funding experimental feature.
• Healthchecks to ensure adequate operating conditions of the node
• Several bug fixes throughout the app.

Porting Effort

A total of 450 upstream PRs were considered for inclusion. The list of of PRs can be found in the acompanying upstream-prs.csv doc.

Decred Contributors (Alphabetical Order)

• Fernando Guisso
• Matheus Degiovani
• Ole Andre Birkedal

Acknowledgement

The majority of the work included in this release is from features and bugfixes performed by the contributors to the upstream lnd project that were ported to Decred.

We wish to sincerely thank them for providing such a high quality project and hope we can continue to contribute in building a large scale and cross-coin LN ecosystem.

dcrdex v0.1.4

This patch release makes a number of small UI improvments, including showing the user's account ID on the settings page, focusing password field, and colorizing various buy/sell elements, and fixes several bugs. The main bug fixes deal with wallet settings changes, deposit address revalidation, Decred withdraws working for the full balance, and historical order and match display.

Please read the initial release (v0.1.0) notes for important information and instructions.

Client (dexc)

Features and Improvements

• The account ID for each configured DEX server is now displayed on the settings page. When not logged in, there is a placeholder that says to login to display the account ID. (1a5c070)
• Focus password field in order dialogs. (5eb9fb2)
• Colorize the "Side" column in the orders table. (83b07cd)
• The registration fee address is no longer logged if there is a funding error since there is nothing a user can do with the address other than shoot themselves in the foot and send to it manually. Registration fee payment should only be done via the app. (dc67cdb)
• Wallet balances are updated on all wallet settings changes. (8ff4d94)
• Wallet sync status is more consistently checked on wallet (re)connect events, and continually check sync status on RPC errors as it is common for node/wallet startup to initially error and then start reporting status (e.g. bitcoind's "verifying blocks..." error while starting up). (1c9ca02, 53194c6)

Fixes

• Fix changing wallet settings possibly interrupting active swaps. (f0a304f)
• Fix a case where a wallet can become unlockable without restarting dexc if dexc were started with both active orders and an unlocked wallet. (f8c47a1)
• Fix duplicate notify_fee requests that resulted from multiple fee coin waiters being created for the same coin. (ee1bd84)
• Fix retrieving the full list of historical orders (2846814)
• Fix incorrect year displayed for a match's date. (a347b0f)
• Wallet deposit addresses are validated and more often refreshed whenever the wallet is connected (c3990c7, 6a66a1c)
• Correctly handle chain sync status when in initial block download state, but blocks are up-to-date with headers. This is only possible in practice with simnet. (3523de1)
• Fix DCR withdraws in various cases. (d0ba1e5)
• Allow dexc to shutdown without hanging if a wallet was unexpectedly shutdown first. (7321c36)
• When loading active matches on login, correctly skip adding cancel order matches to the trades map. (61697bb)
• Prevent login while already logged in from re-creating the entries in the trades map. (b6f81ad)
• Resolve a data race on wallet reconfigure for DCR. (bca1325)
• Avoid a possible deadlock on wallet reconfigure. (4bed3e2)

Developer

• Simnet harnesses are quicker to start, being based on archives, and more well funded. (0de8945)
• Update simnet trade tests for current wallet unlocking system and more well funded harnesses. (e198b1f)

Server (dcrdex)

Create a fee rate scaling administrative endpoint. (7a3f183) The endpoint is api/asset/{sym}/setfeescale/{scale}, using a GET request instead of POST for convenience.

Code Summary

27 commits, 52 files changed, 1582 insertions(+), and 890 deletions(-)

https://github.com/decred/dcrdex/compare/v0.1.3...v0.1.4

6 contributors

• Amir Massarwa (@amassarwi)
• Brian Stafford (@buck54321)
• David Hill (@dajohi)
• Jonathan Chappelow (@chappjc)
• Kevin Wilde (@kevinstl)
• @peterzen

dcrdex v0.1.3

This patch release includes a workaround for a bug in the Safari browser, an important fix to a possible deadlock (client hang), and a minor fix to the client's validation of the server's order matching.

NOTE: If you use the dexcctl program (an optional command line tool), you will need to move any dexcctl.conf file from the ".dexc" folder to a new ".dexcctl" folder.

Please read the initial release (v0.1.0) notes for important information and instructions.

Client (dexc)

Fixes

• Eliminate a possible deadlock (hang) introduced in v0.1.2. (65c9830)
• Fix the client's validation of the server's deterministic epoch matching result. This avoids an error message in the logs, but the bug was otherwise not a problem. (10b4689)

Other

The location of the dexcctl.conf file is now in ~/.dexcctl instead of ~/.dexc (or the corresponding "appdata" folders on Windows and macOS) (16a0fb0)

Server (dcrdex)

There are no server changes.

Code Summary

5 commits, 17 files changed, 188 insertions(+), and 174 deletions(-)

https://github.com/decred/dcrdex/compare/v0.1.2...v0.1.3

2 contributors

• Brian Stafford (@buck54321)
• Jonathan Chappelow (@chappjc)

dcrdex v0.1.2

This patch release improves handling of slow contract audits, fixes a bug on 32-bit systems, automatically unlocks wallets to avoid swap failures if the wallet unexpectedly became locked, and improves the display of canceled orders. There are also a few usability improvements for developers.

Please read the initial release (v0.1.0) notes for important information and instructions.

Client (dexc)

Features and Improvements

User-facing

• When already logged in, automatically attempt to unlock wallets as needed for trades. This helps prevent users from breaking their swaps by accidentally locking their wallets. (de40913)
• Display cancel order matches differently from trade matches. (b013581)

Developer

• Create a Ready method so consumer packages know when the client core is done starting up. (c3d9e80)
• Increase notification channel capacity to prevent dropped notifications when there are many simultaneous events. (2de62a3)
• Remove the obsolete (and incomplete) terminal UI. (75ff8d0)

Fixes

• Workaround for 64-bit atomic variable access on 32-bit platforms. (3abaf43)
• Prevent contract auditing from blocking incoming messages. Continue to search for counterparty contracts until it succeeds or the match is revoked, and log a warning of the audit is taking a long time. (23f2f36)

Server (dcrdex)

There are no server changes.

Code Summary

9 commits, 44 files changed, 621 insertions(+), and 2,652 deletions(-)

https://github.com/decred/dcrdex/compare/v0.1.1...v0.1.2

3 contributors

• Brian Stafford (@buck54321)
• David Hill (@dajohi)
• Jonathan Chappelow (@chappjc)

dcrdex v0.1.1

This patch release addresses two important match recovery bugs, and a number of minor bugs. This release also includes several improvements to the client's user interface. New client features include Tor proxy support and new deposit address generation.

Please read the initial release (v0.1.0) notes for important information and instructions.

Client (dexc)

Features and Improvements

• Add the mainnet "client quick start" guide. (a383d5e)
• Tor support for connections with DEX servers. (824f1c0) WARNING: This should be used with caution since Tor is slow and unreliable.
• On dexc start-up, display a link (URL) to the browser page, and if there are active orders, warn the user. (a01e403)
• Add the ability to generate new deposit addresses. (860af3e)
• Various browser UI improvements, including order dialog wording and button formatting. (dbf9d2c)
• Dialogs now have a close/cancel button. (6716b58)
• Taker redemption transactions are more readily batched, potentially requiring fewer transactions for a taker order that matches with multiple maker orders. (3ea75a9)
• When any node (e.g. bitcoind and dcrd) is still synchronizing with the network, new orders cannot be placed. (2cac73a)

Fixes

• Match recover is more robust, with fixes to revoked match handling on reconnect or restart. (9790fb1)
• Resolve a potential deadlock during match status resolution, (c09017d)
• Explicitly set js Content-Type in webserver to workaround misconfigured operating systems, such as Windows with misconfigured CLASSES_ROOT registry entries. (f632893)
• Delete obsolete notifications on frontend. (8a69e99)
• Avoid harmless but confusing warnings about returning zero coins when resumed trades are later completed. (a01e403)
• Avoid redundant swap negotiation invocations on restart with unknown matches reported from a server. (c0adb26)
• Orphaned cancel orders that could be created in certain circumstances are now retired during status resolution of the linked trade. (867ba89)

Server (dcrdex)

• Fix book purge heap orientation. (eb6ccd4)
• Avoid orphaned epoch status orders when shutting down via SIGINT without a preceding suspend command. (d463439)
• When any node (e.g. bitcoind and dcrd) is still synchronizing with the network, relevant markets will not accept new orders. (2cac73a)

Code Summary

17 commits, 66 files changed, 2216 insertions(+), 566 deletions(-)

https://github.com/decred/dcrdex/compare/release-v0.1.0...release-v0.1.1

3 contributors

• Brian Stafford (@buck54321)
• David Hill (@dajohi)
• Jonathan Chappelow (@chappjc)

dcrdex v0.1.0 (beta)

Important Notices

• Ensure your nodes (and wallets) are fully synchronized with the blockchain network before placing orders. The software will verify this for you in the next patch release.
• Never shutdown your wallets with dexc running. When shutting down, always stop dexc before stopping your wallets.
• If you have to restart dexc with active orders or swaps, you must immediately login again with your app password when dexc starts up. The next patch release wil inform you on startup if this is required.
• There is a ~10 minute "inaction timeout" when it becomes your client's turn to broadcast a transaction, so be sure not to stop dexc or lose connectivity for longer than that or you risk having your active orders and swaps/matches revoked. If you do have to restart dexc, remember to login as soon as you start it up again.
• Only one dexc process should be running for a given user account at any time. For example, if you have identical dexc configurations on two computers and you run and login on both, neither dexc instance will be adequately connected to successfully negotiate swaps. Also note that order history is not synchronized between different installations at this time.
• Your DEX server accounts exist inside the dexc.db file, the location of which depends on operating system, but is typically in ~/.dexc/mainnet/dexc.db or %HOMEPATH%\Local\Dexc\mainnet\dexc.db. Do not delete this account or you will need to register again at whatever server was configured in it.

Overview

This release of DCRDEX includes a client program called dexc and a server called dcrdex. Users run their own wallets (e.g. dcrwallet or bitcoind), which dexc works with to perform trades via atomic swaps. dcrdex facilitates price discovery by maintaining an order book for one or more markets, and coordinates atomic swaps directly between pairs of traders that are matched according to their orders. The server is generally run on a remote system, but anyone may operate a dcrdex server.

This release supports Decred, Bitcoin, and Litecoin.

Client (dexc)

• Provides a browser-based interface, which is self-hosted by the dexc program, for configuring wallets, displaying market data such as order books, and placing and monitoring orders.
• Communicates with any user-specified dcrdex server.
• Funds orders and executes atomic swaps by controlling the external wallets (dcrwallet, etc.).

Server (dcrdex)

• Accepts orders from clients who prove ownership of on-chain coins to fund the order.
• Books and matches orders with an epoch-based matching algorithm.
• Relays swap data between matched parties, allowing the clients to perform the transactions themselves directly on the assets' blockchains.
• Has a one-time nominal (e.g. 1 DCR) registration fee, which acts as an anti-spam measure and to incentivize completing swaps.
• Enforces the code of community conduct by suspending accounts that repeatedly violate the rules.

Features

Markets and Orders

The server maintains a familiar market of buy and sell orders, each with a quantity and a rate. A market is defined by a pair of assets, where one asset is referred to as the base asset. For example, in the "DCR-BTC" market, DCR is the base asset and BTC is known as the quote asset. A market is also specified by a lot size, which is a quantity of the base asset. Order quantity must be a multiple of lot size, with the exception of market buy orders that are necessarily specified in units of the quote asset that is offered in the trade. The intent of a client to execute an atomic swap of one asset for another is communicated by submitting orders to a specific market on a dcrdex server.

The two types of trade orders are market orders, which have a quantity but no rate, and limit orders, which also specify a rate. Limit orders also have a time-in-force that specifies if the order should be allowed to become booked or if it should only be allowed to match with other orders when it is initially processed. The time-in-force options are referred to as "standing" or "immediate", where standing indicates the order is allowed to become booked while immediate restricts that order to being a taker order by only allowing a match when it is initially processed.

The following image is an example order submission dialog from a testnet DCR-BTC market with a 40 DCR lot size that demonstrates limit order buying 2 lots (80 DCR) at a rate of 0.001207 BTC/DCR using a standing time-in-force to allow the order to become booked if it is not filled:

Checking the "Match for one epoch only" box above specifies that the limit order's time-in-force should be immediate, while unchecking it allows the order to be booked if it does not match with another order at first. The concept of epochs is described in the Epoch section.

Order Funding

Since orders must be funded by coins from the user's wallets, placing an order "locks" an amount in the relevant wallet. For example, a buy order on the DCR-BTC market marks a certain quantity of BTC as locked with the user's wallet. (This involves no transactions or movement of funds.) This amount will be shown in the "locked" row of the Balances table.

It is important to note that the amount that is locked by the order may be larger than the order quantity since the "locked" amount is dependent on the size of the UTXO (for UTXO-based assets like Bitcoin and Decred) that is reserved for use as an input to the swap transaction, where the amount that does not enter the contract goes in a change address. This is no different from when you make a regular transaction, however because the input UTXOs are locked in advance of broadcasting the actual transaction that spends them, you will see the amount locked in the wallet until the swap actually takes place.

Depending on the asset, there may be a wallet setting on the Wallets page to pre-size funding UTXOs to avoid this over-locking, but (1) it involves an extra transaction that pays to yourself before placing the order, which has on-chain transaction fees that may be undesirable on chains like BTC, and (2) it is only applied for limit orders with standing time-in-force since the the UTXOs are only locked until the swap transaction is broadcasted, which is relatively brief for taker-only orders that are never booked.

Epochs

An important concept with DCRDEX is that newly submitted orders are processed in short windows of time called epochs, the length of which is part of the server's market configuration, but is typically on the order of 10 seconds. When a valid order is received by the server, it enters into the pool of epoch orders before it is matched and/or booked. The motivation for this approach is described in detail in the DCRDEX specification. The Your Orders table will show the status of such orders as "epoch" until they are matched at the end of the epoch, as described in the next section.

Order cancellation requests are also processed in the epoch with trade (market/limit) orders since a cancellation is actually a type of order. However, from the user's perspective, cancelling an order is simply a matter clicking the cancel icon for one of their booked orders.

Matching

When the end of an epoch is reached, the orders it includes are then matched with the orders that are already on the book. A key concept of DCRDEX order matching is a deterministic algorithm for shuffling the epoch orders so that it is difficult for a user to game the system. To perform the shuffling of the closed epoch prior to matching, clients with orders in the epoch must provide to the server a special value for each of their orders called a preimage, which must correspond to another value that was provided when the order was initially submitted called the commitment. This is done automatically by dexc, requiring no action from the user.

If an order fails to match with another order, it will become either booked or executed with no part of the order filled. The Your Orders table displays the current status and remaining quantity of each of a user's orders. If an order does match with another trade order, the order status will become settling, and atomic swap negotiation begins.

Settlement

When maker orders (on the book) are matched with taker orders from an epoch, the atomic swap sequence begins. No action is required from either user during the process.

In the current atomic swap protocol, the maker initiates by broadcasting a transaction with a swap contract on the relevant asset network, and informing the server of the transaction and the full contract. The server audits the contract, and if it is successfully validated, the information is relayed to the taker, who independently audits the contract to ensure it meets their expectations. The transaction containing the maker's swap contract must then be mined and reach the swap confirmation requirement, which is also a market setting. For example, Bitcoin might require 3 confirmations while other chains like Litecoin might be considerably more. When the required number of confirmations is reached, the taker participates by broadcasting a transaction with their swap contract and informing the server. Again, the server and the counterparty audit the contract and wait for that asset's swap confirmation requirement. When the required confirmations are reached, the maker redeems the taker's contract and informs the server of the redemption transaction. This is the end of the process for the maker, as the redemption spends the taker's contract, paying to an address controlled by the maker. The server relays the maker's redeem data to the taker, and the taker redeems immediately, ending the swap.

The Order Details page shows each match associated with an order. For example, a match where the user was the taker is shown below with links to block explorers for each of the transactions described above. The maker will have their redemption listed, but not the taker's.

Orders may be partially filled in increments of the lot size. Hence a single order may have more than one match (and thus swap) associated with it, each of which will be shown on the Order Details page.

Wallet balances will change during swap negotiation. When the client broadcasts their swap contract, the amount locked in that contract will go into the "locked" row for the asset that funded the order. When the counterparty redeems their contract, that amount will be reduced by the contract amount, and the user will redeem the counterparty contract, thus adding to the balance of the other asset. This is the essence of the atomic swap. Note that until the redemption transactions are confirmed, the redeemed amount may remain in the wallet's "immature" balance category, but this depends on the asset.

Revoked Matches

While the atomic swap process requires no party to trust the other, a swap may be forced into an alternate path ending in one or both users refunding themselves by spending their own contract after the lock time expires. This happens when one of the parties fails to act in the expected time frame, an inaction timeout. When an inaction timeout occurs the following happens:

• The match is revoked, and both parties are notified.
• The at-fault user has their order revoked (if it was partially filled and still booked) and is notified.
• The at-fault user has their score adjusted according to type of match failure. See below for descriptions of each type and the associated user score adjustments.

The general categories of match failures are:

• NoMakerSwap: A match is made, but the maker does not initiate the swap. No transactions are created in this case.
• NoTakerSwap: The maker (initiator) broadcasts their swap contract transaction and informs the server, but the taker (participant) fails to broadcast their swap contract and inform the server. The maker will automatically refund their contract when it expires after 20 hrs.
• NoMakerRedeem: The taker broadcasts their swap and informs the server, but the maker does not redeem it. The taker will refund when their contract expires after 8 hrs. Note that the taker's client begins watching for an unannounced redeem of their contract by the maker, which reveals the secret and permits the taker to redeem as well, completing the swap although in a potentially extended time frame.
• NoTakerRedeem: The maker redeems the taker's contract and informs the server, but the taker fails to redeem the maker's contract even though they can do so at any time. This case is not disruptive to the counterparty, and is only detrimental to the takers, so it is of minimal concern.

NOTE: The order remaining amounts are still reduced at match time although they did not settle that portion of the order.

User Scoring

Users have an incentive to respond with their preimage for their submitted orders and to complete swaps as the match negotiation protocol specifies, and if they repeatedly fail to act as required, their account may be suspended. This may require either communicating an excusable reason for the issue to the server operator, or registering a new account. However, a reasonable scoring system is established to balance the need to deter intentional disruptions with the reality of unreliable consumer networks and other such technical issues.

In this release, there are two primary inaction violations that adjust a users score: (1) failure to respond with a preimage for an order when the epoch for that order is closed (preimage miss), and (2) swap negotiation resulting in match revocation as described in the previous section.

The score threshold at which an account becomes suspended (ban score) is an operator set variable, but the default is 20.

The adjustment to the at-fault user's score depends on the match failure:

Match Outcome	Points	Notes
NoMakerSwap	4	book spoof, taker needs new order, no locked funds
NoTakerSwap	11	maker has contract stuck for 20 hrs
NoMakerRedeem	7	taker has contract stuck for 8 hrs
NoTakerRedeem	1	counterparty not inconvenienced, only self
Success	-1	offsets violations

A preimage miss adds 2 points to the users score.

The above scoring system should be considered tentative while it is evaluated in the wild.

Order Size Limits

This release uses an experimental system to set the maximum order quantity based on their swap history. It is likely to change, but it is described in PR #750.

Code Summary

This release consists of 473 pull requests comprising 506 commits from 12 contributors.

Contributors (alphabetical order):

• Brian Stafford (@buck54321)
• David Hill (@dajohi)
• @degeri
• Donald Adu-Poku (@dnldd)
• Fernando Abolafio (@fernandoabolafio)
• Joe Gruffins (@JoeGruffins)
• Jonathan Chappelow (@chappjc)
• Kevin Wilde (@kevinstl)
• @song50119
• Victor Oliveira (@vctt94)
• Wisdom Arerosuoghene (@itswisdomagain)
• @zeoio

(there is no previous release to which a diff can be made)

2020-08-27

Install

To install the command line tools, please see dcrinstaller. To install decrediton download, uncompress, and run decrediton Linux or decrediton macOS or decrediton Windows.

See decred-v1.5.2-manifest.txt, and the package specific manifest files for sha256 sums and the associated .asc files to confirm those shas.

See README.md for more info on verifying the files.

Contents

• dcrd
• decrediton

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:

• blockmanager: handle notfound messages from peers (decred/dcrd#2344)
• blockmanager: limit the requested maps (decred/dcrd#2344)
• server: increase ban score for notfound messages (decred/dcrd#2344)
• server: return whether addBanScore disconnected the peer (decred/dcrd#2344)

Misc:

• release: Bump for 1.5.2(decred/dcrd#2345)

Code Contributors (alphabetical order):

• Dave Collins
• David Hill

decrediton v1.5.2

Decrediton has no code changes for 1.5.2, but includes a dcrd which has the required fix.

2019-01-28

Install

To install the command line tools, please see dcrinstaller. To install decrediton download, uncompress, and run decrediton Linux or decrediton macOS or decrediton Windows.

See manifest-v1.5.1.txt, and the package specific manifest files for sha256 sums and the associated .asc files to confirm those shas.

See README.md for more info on verifying the files.

Contents

• dcrd
• dcrwallet
• decrediton

dcrd v1.5.1

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