March 15, 2019 10:56 pm

Dash Core v0.13.2 on Mainnet

Dash Community,

We are pleased to announce the release of Dash Core v0.13.2 to mainnet. This release contains several optimizations to Dash Core v0.13 to provide an easier user experience for masternode owners as well as fix a few bugs the team found during the initial rollout. This upgrade is non-mandatory, but is recommended for all users.

Below are a few highlights of this release.

Mandatory “masternodeblsprivkey” field when configuring and running a masternode
This field was not mandatory in previous versions that had to function with and without DIP3 (Deterministic Masternode List) activated. Now that DIP3 has activated, this field will be required to ensure that masternode owners enter their operator key. This field will check that the format of the key entered is valid, and return an error if the key format is incorrect.

Fix for consistency issues after sudden stopping of node
Previous versions saw inconsistencies between the chainstate and evodb when the node suddenly stopped working due to a crash, power failure, etc. This issue should also be resolved with this release.

Fixes for litemode node to not reject specific DIP3 transactions
Previous versions may cause litemode nodes to reject the mainnet chain after spork 15 activation due to less strict consensus rules in one specific case. Since litemode nodes have no knowledge of sporks, they would not know about changes to consensus rules. This release resolves the issue by defaulting to the behavior of activated spork 15 in this specific case when litemode is enabled.

Improvements of P2P protocol for SPV clients
Historically, SPV clients that needed the masternode list could use “0” as the base block hash to request the full masternode list. An issue was identified where “protx diff” and “getmnlistdiff” P2P requests were responding with errors when “0” was used as the base block hash. This update will resolve this problem (however, SPV nodes should use the full genesis hash until enough masternodes have upgraded to v0.13.2).

In addition, some SPV implementations are unable to process LLMQ quorum commitments when they are sent in partial/filtered blocks. This can result in the SPV clients banning nodes. Therefore, for the time being, the system will not include non-financial special transactions (which only consist of LLMQ commitments for now) when sending partial/filtered blocks to SPV clients, as SPV nodes are generally not interested in non-financial special transactions in blocks anyway. DIP3 transactions (ProRegTx, ProUpRegTx, etc.) are not affected and will still be included.

Read more about this in the release notes
https://github.com/dashpay/dash/blob/v0.13.2.0/doc/release-notes.md

Dash Core Group Roadmap