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:
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).
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
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
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".
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=<path> option now accepts full paths instead of requiring wallets to be located in the
--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
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
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.
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.
Two new sporks were introduced in this version:
SPORK_21_QUORUM_ALL_CONNECTEDallows to control Concentrated Recovery and Masternode Probing activation;
SPORK_22_PS_MORE_PARTICIPANTSraises the number of users that can participate in a single PrivateSend mixing transaction to 20.
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.
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
leveldb subtrees were updated to newer versions.
There are a few changes in existing RPC interfaces in this release:
getpeerinfohas new field
masternodeto indicate whether connection was due to masternode connection attempt
denomsfield was replaced by
listunspenthas new filter option
coinTypeto be able to filter different types of coins (all, mixed etc.)
protx diffreturns more detailed information about new quorums
quorumConnectionsfor each LLMQ with detailed information about each participating masternode
quorum signhas an optional
quorumHashargument to pick the exact quorum
getnetworkinforpc shows the socket events mode, either
There are also new RPC commands:
quorum selectquorumreturns the quorum that would/should sign a request
There are also new RPC commands backported from Bitcoin Core 0.16:
help-consolefor more info about using console in Qt
loadwalletloads a wallet from a wallet file or directory
rescanblockchainrescans the local blockchain for wallet related transactions
savemempooldumps the mempool to disk
Please check Bitcoin Core 0.16 release notes in a section below and
help <command> in rpc for more information.
Changes in existing cmd-line options:
New cmd-line options:
Few cmd-line options are no longer supported:
There are also new command-line options backported from Bitcoin Core 0.16:
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
A lot of refactoring, code cleanups and other small fixes were done in this release.