Releases: dashpay/dash
Dash Core 0.17.0.3 Release Announcement
We are happy to announce the release of 0.17.0.3. This release includes binaries, which can be downloaded below.
About this release
Dash Core 0.17.0.3 is a hotfix release of the Dash Core 0.17.0.x series. This release contains a bugfix and we consider this a stable release. You can find detailed release notes at https://github.com/dashpay/dash/blob/v0.17.0.3/doc/release-notes.md.
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
This release adds some recently updated translations and help strings. It also fixes a couple of build issues and a rare crash on some linux systems.
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.17.0.2 Release Announcement
We are happy to announce the release of 0.17.0.2. This release includes binaries, which can be downloaded above.
About this release
Dash Core 0.17.0.2 is the first major release of the Dash Core 0.17.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.17.0.2/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
For a high level understanding of the features included in this release, please see the Product Brief. For details, please see the release notes.
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 v0.17.0.0 RC5
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.17.0.0 RC4
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.17.0.0 RC3
This is a release candidate and not meant for production. It is only meant for testnet deployments.
Note: this version includes breaking changes, all testnet nodes must be upgraded to rc3
This release was signed by keybase.io/pasta.
Dash Core v0.17.0.0 RC2
This is a release candidate and not meant for production. It is only meant for testnet deployments.
Note: RC1 was scrubbed due to changes needed to the build system after it was tagged.
This release was signed by keybase.io/pasta.
Note: RC3 has been released and includes breaking changes, do not use RC2 anymore
Dash Core 0.16.1.1 Release Announcement
We are happy to announce the release of 0.16.1.1. This release includes binaries, which can be downloaded below.
About this release
Dash Core 0.16.1.1 is a hotfix release of the Dash Core 0.16.x.x series. This release contains a bugfix and we consider this a stable release. You can find detailed release notes at https://github.com/dashpay/dash/blob/v0.16.1.1/doc/release-notes.md.
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
There was an unexpected behaviour of the "Encrypt wallet" menu item for unencrypted wallets which was showing users the "Decrypt wallet" dialog instead. This was a GUI only issue, internal encryption logic and RPC behaviour were not affected.
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.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.