We are happy to announce the release of 0.16.0.1. This release includes binaries, which can be downloaded above.

About this release

Dash Core 0.16.0.1 is the first major release of the Dash Core 0.16.x.x series. This major release contains new features, improvements and bugfixes and we consider this a stable release. You can find detailed release notes at https://github.com/dashpay/dash/blob/v0.16.0.1/doc/release-notes.md.

This release is mandatory for all nodes.

Verification of Downloads

This release was signed by https://keybase.io/pasta (GPG fingerprint: 2959 0362 EC87 8A81 FD3C 202B 5252 7BED ABE8 7984).

It is important to verify the binaries you download by following one of these guides:

Notable changes

Block Reward Reallocation

This version implements Block Reward Reallocation which was proposed in order to slow the growth rate of Dash’s circulating supply by encouraging the formation of masternodes and was voted in by the network. The resulting allocation will split all non-proposal block rewards 40% toward miners and 60% toward masternodes in the end-state once the transition period is complete.

The reallocation will take place over 4.5 years with a total of 18 reallocation periods between the start and end state. The transition is being made gradually to avoid market volatility and minimize network disruption.

Note that this is a hardfork which must be activated by miners. To do this they should start creating blocks signalling bit 5 in the version field of the block header.

Each reallocation period will last three superblock cycles (approximately one quarter). Please see Reallocation periods section in detailed release notes for the exact split of the non-proposal block rewards during each period.

Dynamic Activation Thresholds

In Dash we have used lower thresholds (80% vs 95% in BTC) to activate upgrades via a BIP9-like mechanism for quite some time. While it's preferable to have as much of the network hashrate signal update readiness as possible, this can result in quite lengthy upgrades if one large non-upgraded entity stalls all progress. Simply lowering thresholds even further can result in network upgrades occurring too quickly and potentially introducing network instability. This version implements BIP9-like dynamic activation thresholds which drop from some initial level to a minimally acceptable one over time at an increasing rate. This provides a safe non-blocking way of activating proposals.

This mechanism applies to the Block Reward Reallocation proposal mentioned above. Its initial threshold is 80% and it will decrease to a minimum of 60% over the course of 10 periods. Each period is 4032 blocks (approximately one week).

Concentrated Recovery

In the current system, signature shares are propagated to all LLMQ members until one of them has collected enough shares to recover the signature. All members keep propagating and verifying each share until this recovered signature is propagated in the LLMQ. This causes significant load on the LLMQ and results in decreased throughput.

This new system initially sends all shares to a single deterministically selected node, so that this node can recover the signature and propagate the recovered signature. This way only the recovered signature needs to be propagated and verified by all members. After sending their share to this node, each member waits for a timeout and then sends their share to another deterministically selected member. This process is repeated until a recovered signature is finally created and propagated.

This timeout begins at two seconds and increases exponentially up to ten seconds (i.e. 2,4,8,10,10) for each node that times out. This is to minimize the time taken to generate a signature if the recovery node is down, while also minimizing the traffic generated when the network is under stress.

The new system is activated with the newly added SPORK_21_QUORUM_ALL_CONNECTED which has two hardcoded values with a special meaning: 0 activates Concentrated Recovery for every LLMQ and 1 excludes 400_60 and 400_85 quorums.

Increased number of masternode connections

To implement "Concentrated Recovery", it is now necessary for all members of a LLMQ to connect to all other members of the same LLMQ. This significantly increases the general connection count for masternodes. Although these intra-quorum connections are less resource intensive than normal p2p connections (as they only exchange LLMQ/masternode related messages), masternode hardware and network requirements will still be higher than before.

Initially this change will only be activated for the smaller LLMQs (50 members). Eventually it may be activated for larger quorums (400 members).

This is also controlled via SPORK_21_QUORUM_ALL_CONNECTED.

Masternode Connection Probing

While each LLMQ member must have a connection to each other member, it's not necessary for all members to actually connect to all other members. This is because only one of a pair of two masternodes need to initiate the connection while the other one can wait for an incoming connection. Probing is done in the case where a masternode doesn't really need an outbound connection, but still wants to verify that the other side has its port open. This is done by initiating a short lived connection, waiting for MNAUTH to succeed and then disconnecting again.

After this process, each member of a LLMQ knows which members are unable to accept connections, after which they will vote on these members to be "bad".

Masternode Minimum Protocol Version Checks

Members of LLMQs will now also check all other members for minimum protocol versions while in DKG. If a masternode determines that another LLMQ member has a protocol version that is too low, it will vote for the other member to be "bad".

PoSe punishment/banning

If 80% of all LLMQ members voted for the same member to be bad, it is excluded in the final stages of the DKG. This causes the bad masternode to get PoSe punished and then eventually PoSe banned.

Network performance improvements

This version of Dash Core includes multiple optimizations to the network and p2p message handling code. The most important one is the introduction of epoll on linux-based systems. This removes most of the CPU overhead caused by the sub-optimal use of select, which could easily use up 50-80% of the CPU time spent in the network thread when many connections were involved.

Since these optimizations are exclusive to linux, it is possible that masternodes hosted on windows servers will be unable to handle the network load and should consider migrating to a linux based operating system.

Other improvements were made to the p2p message handling code, so that LLMQ related connections do less work than full/normal p2p connections.

Wallet files

The --wallet=<path> option now accepts full paths instead of requiring wallets to be located in the -walletdir directory.

If --wallet=<path> is specified with a path that does not exist, it will now create a wallet directory at the specified location (containing a wallet.dat data file, a db.log file, and database/log.?????????? files) instead of just creating a data file at the path and storing log files in the parent directory. This should make backing up wallets more straightforward than before because the specified wallet path can just be directly archived without having to look in the parent directory for transaction log files.

For backwards compatibility, wallet paths that are names of existing data files in the --walletdir directory will continue to be accepted and interpreted the same as before.

When Dash Core is not started with any --wallet=<path> options, the name of the default wallet returned by getwalletinfo and listwallets RPCs is now the empty string "" instead of "wallet.dat". If Dash Core is started with any --wallet=<path> options, there is no change in behavior, and the name of any wallet is just its <path> string.

PrivateSend coin management improvements

A new algorithm for the creation of mixing denominations was implemented which should reduce the number of the smallest inputs created and give users more control on soft and hard caps. A much more accurate fee management algorithm was also implemented which should fix issues for users who have custom fees specified in wallet config or in times when network is under load.

There is a new "PrivateSend" tab in the GUI which allows spending fully mixed coins only. The CoinControl feature was also improved to display coins based on the tab it was opened in, to protect users from accidentally spending mixed and non-mixed coins in the same transaction and to give better overview of spendable mixed coins.

PrivateSend Random Round Mixing

Some potential attacks on PrivateSend assume that all inputs had been mixed for the same number of rounds (up to 16). While this assumption alone is not enough to break PrivateSend privacy, it could still provide some additional information for other methods like cluster analysis and help to narrow results.

With Random Round Mixing, an input will be mixed to N rounds like prior. However, at this point, a salted hash of each input is used to pick ~50% of inputs to be mixed for another round. This rule is then executed again on the new inputs. This results in an exponential decay where if you mix a set of inputs, half of those inputs will be mixed for N rounds, 1/4 will be mixed N+1, 1/8 will be mixed N+2, etc. Current implementation caps it at N+3 which resultsin mixing an average of N+0.875 rounds and sounds like a reasonable compromise
given the privacy gains.

GUI changes

All dialogs, tabs, icons, colors and interface elements were reworked to improve user experience, let the wallet look more consistent and to make the GUI more flexible. There is a new "Appearance setup" dialog that will show up on the first start of this version and a corresponding tab has been added to the options which allows the user to pick a theme and to tweak the font family, the font weight and the font size. This feature specifically should help users who had font size/scaling issues previously.

For advanced users and developers there is a new way to control the wallet's look by specifying a path to custom css files via --custom-css-dir. Additionally, the new --debug-ui will force Dash Core to reload the custom css files as soon as they get updated which makes it possible to see and debug all css adjustments live in the running GUI.

From now on the "Pay To" field in "Send" and "PrivateSend" tabs also accepts Dash URIs. The Dash address and the amount from the URI are assigned to corresponding fields automatically if a Dash URI gets pasted into the field.

Sporks

Two new sporks were introduced in this version:

SPORK_21_QUORUM_ALL_CONNECTED allows to control Concentrated Recovery and Masternode Probing activation;
SPORK_22_PS_MORE_PARTICIPANTS raises the number of users that can participate in a single PrivateSend mixing transaction to 20.

Sporks SPORK_15_DETERMINISTIC_MNS_ENABLED, SPORK_16_INSTANTSEND_AUTOLOCKS and SPORK_20_INSTANTSEND_LLMQ_BASED which were previously deprecated in v0.15 are completely removed now. SPORK_6_NEW_SIGS was never activated on mainnet and was also removed in this version.

Build system

The minimum version of the GCC compiler required to compile Dash Core is now 4.8. The minimum version of Qt is now 5.5.1. Some packages in depends/ as well as secp256k1 and leveldb subtrees were updated to newer versions.

RPC changes

There are a few changes in existing RPC interfaces in this release:

getpeerinfo has new field masternode to indicate whether connection was due to masternode connection attempt
getprivatesendinfo denoms field was replaced by denoms_goal and denoms_hardcap
listunspent has new filter option coinType to be able to filter different types of coins (all, mixed etc.)
protx diff returns more detailed information about new quorums
quorum dkgstatus shows quorumConnections for each LLMQ with detailed information about each participating masternode
quorum sign has an optional quorumHash argument to pick the exact quorum
socketevents in getnetworkinfo rpc shows the socket events mode, either epoll, poll or select

There are also new RPC commands:

quorum selectquorum returns the quorum that would/should sign a request

There are also new RPC commands backported from Bitcoin Core 0.16:

help-console for more info about using console in Qt
loadwallet loads a wallet from a wallet file or directory
rescanblockchain rescans the local blockchain for wallet related transactions
savemempool dumps the mempool to disk

Please check Bitcoin Core 0.16 release notes in a section below and help <command> in rpc for more information.

Command-line options

Changes in existing cmd-line options:

New cmd-line options:

--custom-css-dir
--debug-ui
--disablegovernance
--font-family
--font-scale
--font-weight-bold
--font-weight-normal
--llmqdevnetparams
--llmqtestparams
--privatesenddenomsgoal
--privatesenddenomshardcap
--socketevents

Few cmd-line options are no longer supported:

--litemode
--privatesenddenoms

There are also new command-line options backported from Bitcoin Core 0.16:

--addrmantest
--debuglogfile
--deprecatedrpc
--enablebip61
--getinfo
--stdinrpcpass

Please check Bitcoin Core 0.16 release notes in a section below and Help -> Command-line options in Qt wallet or dashd --help for more information.

Backports from Bitcoin Core 0.16

Most of the changes between Bitcoin Core 0.15 and Bitcoin Core 0.16 have been backported into Dash Core 0.16. We only excluded backports which do not align with Dash, like SegWit or RBF related changes.

You can read about changes brought by backporting from Bitcoin Core 0.16 in following docs:

Some other individual PRs were backported from versions 0.17+, you can find the full list of backported PRs and additional fixes in release-notes-0.16-backports.md

Miscellaneous

A lot of refactoring, code cleanups and other small fixes were done in this release.

Credits

Thanks go out to all Dash Core contributors, everyone who submitted issues, reviewed pull requests or helped translating on Transifex and also to Bitcoin Core Developers.

dashpay/dash v0.16.0.1 Dash Core 0.16.0.1 Release Announcement on GitHub