Releases: dashpay/dash
Dash Core 0.16.1.0 Release Announcement
We are happy to announce the release of 0.16.1.0. This release includes binaries, which can be downloaded below.
About this release
Dash Core 0.16.1.0 is a minor release of the Dash Core 0.16.x.x series. This release contains various bugfixes and improvements and we consider this a stable release. You can find detailed release notes at https://github.com/dashpay/dash/blob/v0.16.1.0/doc/release-notes.md.
This is NOT a mandatory upgrade. Users of the wallet should upgrade to 0.16.1.0 if they encounter any bugs. Masternodes may see a small benefit in network usage by upgrading to 0.16.1.0. Miners do not need to upgrade to 0.16.1.0.
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:
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.
Dash Core 0.16.0.1 Release Announcement
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...
Dash Core v0.16.0.0 RC3
This is a release candidate and not meant for production. It is only meant for testnet deployments.
This release was signed by keybase.io/pasta.
Dash Core v0.16.0.0 RC2
codablock
Alexander Block
This is a release candidate and not meant for production. It is only meant for testnet deployments.
This release was signed by keybase.io/codablock.
Dash Core v0.16.0.0 RC1
This is a release candidate and not meant for production. It is only meant for testnet deployments.
This release was signed by keybase.io/pasta.
Dash Core 0.15.0.0 Release Announcement
We are happy to announce the release of 0.15.0.0. This release includes binaries, which can be downloaded above.
About this Release
Dash Core 0.15.0.0 is the first major release of the Dash Core 0.15.x.x series.
This major release contains new features, improvements and bugfixes and we consider this a stable release.
Notable changes
Removal of the p2p alert system
The p2p alert system was designed to send messages to all nodes supporting it by someone who holds
so called alert keys to notify such nodes in case of severe network issues. This version removes the alert p2p message and --alert option. Internal alerts, partition detection warnings and the --alertnotify option features remain.
Removal of the legacy InstantSend system
Version 0.14 introduced the new LLMQ-based InstantSend system which is designed to be much more scalable than the legacy one without sacrificing security. The new system also allows all transactions to be treated as InstantSend transactions. The legacy system was disabled together with the successful deployment of ChainLocks, but we had to keep supporting the legacy system for a while to ensure a smooth transition period. This version finally drops the legacy system completely.
Read more about ChainLocks: https://github.com/dashpay/dips/blob/master/dip-0008.md
Read more about LLMQ-based InstantSend: https://github.com/dashpay/dips/blob/master/dip-0010.md
Sporks
The security level of ChainLocks and LLMQ-based InstantSend made sporks SPORK_5_INSTANTSEND_MAX_VALUE and SPORK_12_RECONSIDER_BLOCKS obsolete, so they are removed now. Sporks SPORK_15_DETERMINISTIC_MNS_ENABLED, SPORK_16_INSTANTSEND_AUTOLOCKS and SPORK_20_INSTANTSEND_LLMQ_BASED have no code logic behind them anymore because they were used as part of the DIP0003, DIP0008 and DIP0010 activation process which is finished now. They are still kept and relayed only to ensure smooth operation of v0.14 clients and will be removed in some future version.
Mempool sync improvements
Nodes joining the network will now try to sync their mempool from other v0.15+ peers via the mempool p2p message. This behaviour can be disabled via the new --syncmempool option. Nodes serving such requests will now also push inv p2p messages for InstandSend locks which are held for transactions in their mempool. These two changes should help new nodes to quickly catchup on start and detect any potential double-spend as soon as possible. This should also help wallets to slightly improve UX by showing the correct status of unconfirmed transactions locked via InstandSend, if they were sent while the receiving wallet was offline. Note that bloom-filters still apply to such inv messages, just like they do for transactions and locks that are relayed on a regular basis.
PrivateSend improvements
This version decouples the so called "Lite Mode" and client-side PrivateSend mixing, which allows client-side mixing on pruned nodes running with --litemode option. Such nodes will have to also specify the newly redefined --enableprivatesend option. Non-prunned nodes do not have to do this but they can use --enableprivatesend option to disable mixing completely instead. Please note that specifying this option does not start mixing automatically anymore (which was the case in previous versions). To automatically start mixing, use the new --privatesendautostart option in addition to --enableprivatesend. Additionally, PrivateSend can always be controlled with the privatesend RPC.
Thanks to LLMQ-based InstantSend and its ability to lock chains of unconfirmed transactions (and not only a single one like in the legacy system), PrivateSend mixing speed has improved significantly. In such an environment Liquidity Provider Mode, which was introduced a long time ago to support mixing volume, is no longer needed and is removed now. As such the --liquidityprovider option is not available anymore.
Some other improvements were also introduced to speed up mixing, e.g. by joining more queues or dropping potential malicious mixing participants faster by checking some rules earlier etc. Lots of related code was refactored to further improve its readability, which should make it easier for someone to re-implement PrivateSend correctly in other wallets if there is a desire to do so.
Wallet changes
Wallet internals were optimized to significantly improve performance which should be especially notable for huge wallets with tens of thousands of transactions or more. The GUI for such wallets should be much more responsive too now.
Running Masternodes from local wallets was deprecated a long time ago and starting from this version we disable wallet functionality on Masternodes completely.
GUI changes
The Qt GUI went through a refresh to follow branding color guides and to make it feel lighter. All old themes besides the Traditional one (the one with a minimal styling) were removed and instead a new Dark theme was added.
In this version we made a lot of optimizations to remove various lags and lockups, the GUI in general should feel much more smoother now, especially for huge wallets or when navigating through the masternode list. The latter has a few new columns (collateral, owner and voting addresses) which give more options to filter and/or sort the list. All issues with hi-dpi monitors should also be fixed now.
The "Send" popup dialog was slightly tweaked to improve the language and provide a bit more information about inputs included in the transaction, its size and the actual resulting fee rate. It will also show the number of inputs a PrivateSend transaction is going to consume and display a warning regarding sender privacy if this number is 10 or higher.
Changes in regtest and devnet p2p/rpc ports
Default p2p and rpc ports for devnets and regtest were changed to ensure their consistency and to avoid
any potential interference with bitcoin's regtests. New default p2p/rpc ports for devnet are 19799/19798,
for regtest - 19899/19898 respectively.
ZMQ changes
Added two new messages rawchainlocksig and rawtxlocksig which return the raw data of the block/transaction concatenated with the corresponding clsig/islock message respectively.
Crash reports and stack traces
Binaries built with Gitian (including all official releases) will from now on always have crash reports and
crash hooks enabled. This means, that all binaries will print some information about the stack trace at the
time of a crash. If no debug information is present at crash time (which is usually the case), the binaries
will print a line that looks like this:
2020-01-06 14:41:08 Windows Exception: EXCEPTION_ACCESS_VIOLATION
No debug information available for stacktrace. You should add debug information and then run:
dashd.exe -printcrashinfo=bvcgc43iinzgc43ijfxgm3yba....
If you encounter such a crash, include these lines when you report the crash and we will be able to debug it
further. Anyone interested in running the specified -printcrashinfo command can do so after copying the debug info file from the Gitian build to the same place where the binary is located. This will then print a detailed stack trace.
RPC changes
There are a few changes in existing RPC interfaces in this release:
- no more
instantsendfield in various RPC commands use-IS,use_isandinstantsendoptions are deprecated in various RPC commands and have no effect anymore- added new
merkleRootQuorumsfield ingetblockRPC results - individual Dash-specific fields which were used to display soft-fork progress in
getblockchaininfoare replaced with the backportedstatisticsobject privatesend_balancefield is shown in all related RPC results regardless of the Lite Mode or PrivateSend state- added
pubKeyOperatorfield for each masternode inquorum infoRPC response
There are also new RPC commands:
getbestchainlockgetmerkleblocksgetprivatesendinfo
getpoolinfo was deprecated in favor of getprivatesendinfo and no longer returns any data.
There are also new RPC commands backported from Bitcoin Core 0.15:
abortrescancombinerawtransactiongetblockstatsgetchaintxstatslistwalletslogginguptime
Make sure to check Bitcoin Core 0.15 release notes in a section below for more RPC changes.
See help command in rpc for more info.
Command-line options
Changes in existing cmd-line options:
--enableprivatesendoption has a new meaning now, see PrivateSend section for more info
New cmd-line options:
--printcrashinfo--syncmempool--privatesendautostart
Few cmd-line options are no longer supported:
--alerts--masternode, deprecated, specifying--masternodeblsprivkeyoption alone is enough to enable masternode mode now--liquidityprovider--enableinstantsend, dropped due to removal of the Legacy InstantSend
Make sure to check Bitcoin Core 0.15 release notes in a section below for more changes in command-line options.
See Help -> Command-line options in Qt wallet or dashd --help for more info.
Build system
This version always includes stacktraces in binaries now, --enable-stacktraces option is no longer available. Instead you can choose if you want to hook crash reporting into various types of crashes by using --enable-crash-hooks option (default is no). When using this option on macOS make sure to build binaries with make -C src osx_debug.
Backports from Bitcoin C...
Dash Core v0.15.0.0 RC4
codablock
Alexander Block
This is a release candidate and not meant for production. It is only meant for testnet deployments.
Dash Core v0.15.0.0 RC3
codablock
Alexander Block
This is a release candidate and not meant for production. It is only meant for testnet deployments.
Dash Core 0.14.0.5 Release Announcement
We are happy to announce the release of 0.14.0.5. This release includes binaries, which can be downloaded above.
About this Release
Dash Core 0.14.0.5 is a minor release of the Dash Core 0.14.0.x series.
This is a new minor version release, bringing various bugfixes and improvements. We consider this a stable release. We suggest every node (including masternodes and non-masternode) operator to upgrade to 0.14.0.5 as this release contains a fix for a serious DoS vector.
Notable changes
Fix for a DoS vector
This release fixes a serious DoS vector which allows to cause memory exhaustion until the point of out-of-memory related crashes. We highly recommend upgrading all nodes. Thanks to Bitcoin ABC developers for finding and reporting this issue to us.
Better handling of non-locked transactions in mined blocks
We observed multiple cases of ChainLocks failing on mainnet. We tracked this down to a situation where PrivateSend mixing transactions were first rejected by parts of the network (0.14.0.4 nodes) while other parts (<=0.14.0.3) accepted the transaction into the mempool. This caused InstantSend locking to fail for these transactions, while non-upgraded miners still included the transactions into blocks after 10 minutes which in its turn caused blocks to not get ChainLocked for at least 10 minutes. This release improves an already existent fallback mechanism (retroactive InstantSend locking) to also work for transaction which are already partially known in the network. This should cause ChainLocks to succeed in such situations.
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.
Dash Core 0.14.0.4 Release Announcement
We are happy to announce the release of 0.14.0.4. This release includes binaries, which can be downloaded above.
About this Release
Dash Core 0.14.0.4 is a minor release of the Dash Core 0.14.0.x series.
This is a new minor version release, bringing various bugfixes and improvements. We consider this a stable release. We suggest every masternode operator to upgrade to 0.14.0.4 as this release contains multiple improvements in regard to mempool consistency and orphan handling, which is important for InstantSend stability. These fixes and improvements are the results of the stress tests which were performed by an unknown actor in the last few weeks.
We also suggest to upgrade regular nodes as this release also includes a fix to CVE-2017-18350.
Notable changes
Fix respends of freshly received InstantSend transactions
A bug in Dash Core caused respends to not work before a received InstantSend transaction was confirmed in at least one block. This is fixed in this release, so that InstantSend locked mempool transactions can be respent immediately in Dash Core (other wallets were not affected).
Deprecation of SPORK_16_INSTANTSEND_AUTOLOCKS
With the activation of SPORK_20_INSTANTSEND_LLMQ_BASED a few month ago, all transactions started to be locked via InstantSend, which already partly deprecated SPORK_16_INSTANTSEND_AUTOLOCKS. This release removes the last use of SPORK_16_INSTANTSEND_AUTOLOCKS, which caused InstantSend to stop working when the mempool got too large.
Improve orphan transaction limit handling
Instead of limiting orphan transaction by number of transaction, we limit orphans by total size in bytes now. This allows to have thousands of orphan transactions before hitting the limit.
Discrepancies in orphan sets between nodes and handling of those was one of the major limiting factors in
the stress tests performed by an unknown entity on mainnet.
Improve re-requesting for already known transactions
Previously, Dash would re-request old transactions even though they were already known locally. This happened when the outputs were respent very shortly after confirmation of the transaction. This lead to wrongly handling these transactions as orphans, filling up the orphan set and hitting limits very fast. This release fixes this for nodes which have txindex enabled, which is the case for all masternodes. Normal nodes (without txindex) can ignore the issue as they are not involved in active InstantSend locking.
Another issue fixed in this release is the re-requesting of transactions after an InstantSend lock invalidated a conflicting transaction.
Multiple improvements to PrivateSend
Multiple improvements to PrivateSend are introduced in this release, leading to faster mixing and more reasonable selection of UTXOs when sending PrivateSend funds.
Fix for CVE-2017-18350
Bitcoin silently implemented a hidden fix for CVE-2017-18350 in Bitcoin v0.15.1. This release of Dash Core includes a backport of this fix.
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.