Dash Core 0.13.2 Release Announcement
We are happy to announce the release of 0.13.2.0. This release includes binaries, which can be downloaded above.
About this Release
Dash Core 0.13.2.0 is a minor release of the Dash Core 0.13.x.x series.
This minor release contains new features, improvements and bugfixes and we consider this a stable release.
Note that there is no protocol bump in this version and thus active masternodes updating from v0.13.0.0 or v0.13.1.0 do not require any additional actions (no need to issue
masternode start command).
Providing "masternodeblsprivkey" is now mandatory when the node is launched as a masternode ("masternode=1")
In previous versions, "masternodeblsprivkey" was not mandatory as these versions had to function with and without DIP3 activation. Now that DIP3 has activated on mainnet and testnet, we can make "masternodeblsprivkey" mandatory when configuring and running a masternode. Please note that your masternode will fail to start when "masternodeblsprivkey" is not specified. This also means that 0.13.2.0 will only work with masternodes which have already registered their DIP3 masternode. This enforcement was added to catch misconfigurations of masternodes which would otherwise stay unnoticed until spork 15 activation and thus surprise and hurt masternode owners.
Fix for consistency issues after sudden stopping of node
Previous versions resulted in inconsistency between the chainstate and evodb when the node crashed or otherwise suddenly stopped (e.g. power failure). This should be fixed in 0.13.2.0.
Fix for litemode nodes to not reject specific DIP3 transactions
Previous versions might cause litemode nodes to reject the mainnet chain after spork 15 activation. This is due to a consensus rule being less strict in one specific case when spork 15 is active. Litemode nodes can not know about the change in consensus rules as they have no knowledge about sporks. In 0.13.2.0, when litemode is enabled, we default to the behaviour of activated spork15 in this specific case, which fixes the issue. The restriction will be completely removed in the next major release.
Fix incorrect behavior for "protx diff" and the P2P message "GETMNLISTDIFF"
Both were responding with errors when "0" was used as base block hash. DIP4 defines "0" to be equivalent with the genesis block, so that it's easy for peers to request the full masternode list. This is mostly important for SPV nodes (e.g. mobile wallets) which need the masternode list. Right now, all nodes in the network will respond with an error when "0" is provided in "GETMNLISTDIFF". Until enough masternodes have upgraded to 0.13.2.0, SPV nodes should use the full genesis hash to circumvent the error.
Exclusion of LLMQ quorum commitments from partial blocks
SPV nodes are generally not interested in non-financial special transactions in blocks, so we're omitting them now when sending partial/filtered blocks to SPV clients. This currently only filters LLMQ quorum commitments, which also caused some SPV implementations to ban nodes as they were not able to process these. DIP3 transactions (ProRegTx, ProUpRegTx, ...) are not affected and are still included in partial/filtered blocks as these might also move funds.
masternode list json and
protx list will now include the collateral address of masternodes.
Bug fixes/Other improvements
There are few bug fixes in this release:
- Fixed a crash on shutdown
- Fixed a misleading error message in the RPC "protx update_registrar"
- Slightly speed up initial sync by not running DIP3 logic in old blocks
- Add build number (CLIENT_VERSION_BUILD) to MacOS bundle information
You can find detailed release notes at https://github.com/dashpay/dash/blob/v0.13.2.0/doc/release-notes.md.