Dash Core v18: What's new?

In August 2022, Dash Core Group released Dash Core v18, a mandatory update for masternodes, users and miners.

The v18 hard fork happened on block 1737792. If not updated, older nodes won't be able to process so they will get stuck.

How to upgrade?

• Shut it down the old version if you run it.
• It might take a few minutes for older versions, so wait until it has completely shut down
• Run the installer (on Windows)or just copy over /Applications/Dash-Qt (on Mac) or dashd/dash-qt (on Linux). If you upgrade after DIP0003 activation and you were using version < 0.13 you will have to reindex (start with -reindex-chainstate or -reindex) to make sure your wallet has all the new data synced.
• Upgrading from version 0.13 should not require any additional actions.

When upgrading from a version prior to 18.0.1, the first startup of Dash Core will run a migration process which can take anywhere from a few minutes to thirty minutes to finish. After the migration, a downgrade to an older version is only possible with a reindex (or reindex-chainstate).

What to do if you got stuck?

All clients working on v17 might get stuck at the block 1737792.
Get yourself the newest version of wallet, then go to console and execute these commands one after another:
invalidateblock 0000000000000001342be9c0b75ad40c276beaad91616423c4d9cb101b3db438
mnsync reset
clearbanned
reconsiderblock 0000000000000001342be9c0b75ad40c276beaad91616423c4d9cb101b3db438
If this solution does not help please contact [e-mail] for further guidance.

Now let's jump to the updates.

InstantSend locks

There used to be an easy but pointless attack which was possible on InstantSend locks due to the fact that they are not timestamped. The attack relied on abusing the way quorums are renewed and could result in the creation of contradictory Instantsend locks. There was little incentive in the past
years, but with the incoming introduction of platform this attack would have become problematic as it would have enabled double spending on platform and the main chain. We thus introduced an updated quorum renewal mechanism for InstantSend quorums which nullifies this attack.
Following this update, to forge contradictory signatures from an ItantSend quorum, an attacker would need 25+ % of the quorum as byzantine nodes while holding an enormous hash power and a large infrastructure to carry out the attack while at the same time accounting for unstable real life
parameters such as exact knowledge of pings to succeed the attack. On top, this attack would have to be launched during a very short window of time. This attack is in practice today impossible.

Key changes introduced as part of the update are:

• Quorums will now be indexed. We already had a stable number of quorums but now they are ordered. Future updates might be able to leverage this.
• The selection of quorums for signature is simplified thanks to this indexing.
• The selection algorithm is updated to spread masternodes more efficiently among InstantSend quorums, thus the load on the network will be much more evenly spread, resulting in less undeserved bans of well provisioned Masternodes -Quorum will be formed out of 4 quarters, one such quarter will be renewed per cycle.

A few parameters also were changed:

• The threshold of instantsend quorums is now 75 %
• There are more InstantSend quorums
• The InstantSend quorums are composed of more nodes

Quorum rotation

Up until now, one quorum of each enabled LLMQ type was created every corresponding DKG interval blocks. This resulted in a full renewal of all quorums every DKG interval * signingQuorumCount blocks.
With rotation, a full set of signingQuorumCount quorums are created every DKG interval blocks. This is achieved by initiating all DKG sessions in parallel.

On top of that, changes were also made to the quorum member selection algorithm. Previously, all members were renewed each interval. With rotation, only 25% of members are renewed in every interval. This is achieved with a new deterministic and stateful algorithm that writes all information required to re-calculate new shares into a node's persistent storage called evoDB. The same information is transmitted back to SPV clients when requested so that they can easily calculate new shares and verify the new rotated quorums.

Last but not least, quorum rotation doesn't replace the current way of handling quorums: both algorithms are supported. Once the v18 hard fork happens, the new LLMQ type, LLMQ_60_75, will be created with rotation, replacing LLMQ_50_60 for Deterministic InstantSend signing.

Governance

Several improvements have been made to Dash’s DAO governance system. The governance proposal fee has been reduced from 5 Dash to 1 Dash following a vote by masternode owners to do so. For improved security and flexibility, proposal payouts to pay-to-script-hash (P2SH) addresses are now supported.

These changes have been activated with the DIP0024 hard fork.

Governance proposals can now be viewed in GUI Governance tab (must be enabled in Preferences first).

Read more in the release notes about enhanced hard fork support, network improvements and other updates.