v1.6.0-rc1

2020-10-21

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

dcrd v1.6.0-rc1

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

New Treasury Balance Query RPC (gettreasurybalance)

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

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

New Treasury Spend Vote Query RPC (gettreasuryspendvotes)

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

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

New Force Mining Template Regeneration RPC (regentemplate)

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

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

New Unspent Transaction Output Set Query RPC (gettxoutsetinfo)

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

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

Updates to Peer Information Query RPC (getpeerinfo)

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

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

Enforced Results Limit on Transaction Search RPC (searchrawtransactions)

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

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

New Index Status Fields on Info Query RPC (getinfo)

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

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

Version 1 Block Filters Deprecated

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

Changelog

This release consists of 605 commits from 17 contributors which total to 525 files changed, 61568 additional lines of code, and 25364 deleted lines of code.

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

See the individual dcrd release notes for a cateogrized 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-rc1

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.

New features

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

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

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

• 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 WalletService.TransactionNotifications gRPC method now provides more details about the block headers which were detached during a reorganize, rather than only their hashes.

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

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

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

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

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

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

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

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

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

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

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

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

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

• Support for the decentralized treasury hard fork 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.

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

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

Other improvements

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

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

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

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

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

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

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

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.

decrediton v1.6.0-rc1

This release includes some great new features and also includes a large portion of refactor of the codebase that will, hopefully, lead to more
efficient development in the future.

We are proud to include the first iteration of our privacy implementation in this release. Users may not set up their wallet to be a "privacy" wallet which will allow them to mix funds from a set unmixed account into a clean mixed account. This new privacy mode also restricts spending to external addresses if turned on to avoid privacy leakage. Once set up, spending out of the wallet must only be done from the mixed account.

We have also included the new ticket purchasing schema for VSP v3. No longer do users have to set up VSP accounts. Tickets are purchased and then the tickets are paid for by paying a small fee upfront.

With the addition of this new ticket purchasing without accounts, we can now mix staking funds with CSPP just like has been available on CLI for some time. Once privacy is enabled, users may start their autobuyer which will mix funds as new tickets are purchased.

JoeGruffins went through and updated the whole trezor implementation to work with their new trezor-connect changes upstream.

I'd like to welcome our new additions to the decrediton team:

• guilhermemntt
• victorgcramos
• amassarwi
• bgptr
• JoeGruffins
• fguisso

New features

• Individual ticket purchasing and auto buyer for VSP v3 tickets is implemented and will be improved upon in the coming releases. The Legacy method is still available while people migrate away from those set ups.

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

Other improvements

• A full refactor of components into functional components is now mostly complete.

• An SPV indicator has been added to the sidebar. This should help people figure out an issues they may be encountering.

• Unmined transactions are now able to be abandoned under transaction details.

Changelog

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

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.

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.