• v0.14.0.0
Assets 11

Dash Core 0.14.0.0 Release Announcement

We are happy to announce the release of 0.14.0.0. This release includes binaries, which can be downloaded above.

About this Release

Dash Core 0.14.0.0 is the first major release of the Dash Core 0.14.x.x series.

This major release contains new features, improvements and bugfixes and we consider this a stable release.

Notable changes

DIP0004 - Coinbase Payload v2

Coinbase Payload v2 introduces new field merkleRootQuorums which represents the merkle root of all the hashes of the final quorum commitments of all active LLMQ sets. This allows SPV clients to verify active LLMQ sets and use this information to further verify ChainLocks and LLMQ-based InstantSend messages. Coinbase Payload v2 relies on DIP0008 (bit 4) activation.

https://github.com/dashpay/dips/blob/master/dip-0004.md#calculating-the-merkle-root-of-the-active-llmqs

DIP0008 - ChainLocks

This version introduces ChainLocks, a technology for near-instant confirmation of blocks and finding near-instant consensus on the longest valid/accepted chain. ChainLocks leverages LLMQ Signing Requests/Sessions to accomplish this. ChainLocks relies on DIP0008 (bit 4) activation and SPORK_19_CHAINLOCKS_ENABLED spork.

Read more: https://github.com/dashpay/dips/blob/master/dip-0008.md

DIP0010 - LLMQ-based InstantSend

InstantSend is a feature to allow instant confirmations of payments. It works by locking transaction inputs through masternode quorums. It has been present in Dash for a few years and been proven to work. Nevertheless, there are some limits which could theoretically be removed in the old system but doing so would have created risks in terms of scalability and security.

We introduce LLMQ-based InstantSend which is designed to be much more scalable without sacrificing security and which allows all transactions to be treated as InstantSend transactions. The old system differentiated transactions as InstantSend transactions by using the P2P message “ix” instead of “tx”. Since this distinction is not required in the new system, the P2P message “ix” will be removed after DIP0008 deployment (for now, transactions sent via "ix" message will be relayed further via "tx" message).

Read more: https://github.com/dashpay/dips/blob/master/dip-0010.md

Network

Legacy messages mnw, mnwb, mnget, mnb, mnp, dseg, mnv, qdcommit and their corresponding inventory types (7, 10, 14, 15, 19, 22) are no longer suported.

Message version is extended with a 256 bit field - a challenge sent to a masternode. Masternode which received such a challenge must reply with new p2p message mnauth directly after verack. This mnauth message must include a signed challenge that was previously sent via version.

Mining

Due to changes in coinbase payload this version requires for miners to signal their readiness via BIP9-like mechanism - by setting bit 4 of the block version to 1. Note that if your mining software simply uses coinbase_payload field from getblocktemplate RPC and doesn't construct coinbase payload manually then there should be no changes to your mining software required. We however encourage pools and solo-miners to check their software compatibility on testnet to ensure flawless migration.

PrivateSend

The wallet will try to create and consume denoms a bit more accurately now. It will also only create a limited number of inputs for each denominated amount to prevent bloating itself with mostly the smallest denoms. You can control this number of inputs via new -privatesenddenoms cmd-line option (default is 300).

InstantSend

Legacy InstantSend is going to be superseded by the newly implemented LLMQ-based one once DIP0008 (bit 4) is active and SPORK_20_INSTANTSEND_LLMQ_BASED spork is ON.

Sporks

There are two new sporks introduced in this version - SPORK_19_CHAINLOCKS_ENABLED and SPORK_20_INSTANTSEND_LLMQ_BASED. SPORK_17_QUORUM_DKG_ENABLED was introduced in v0.13 but was kept OFF. It will be turned on once 80% masternodes are upgraded to v0.14 which will enable DKG and DKG-based PoSe.

QR codes

Wallet can now show QR codes for addresses in the address book, receiving addresses and addresses identified in transactions list (right click -> "Show QR-code").

RPC, ZMQ and command-line changes

This release introduced various changes to these subsystems, please see detailed release notes for more info.

Release Notes

You can find detailed release notes at https://github.com/dashpay/dash/blob/v0.14.0.0/doc/release-notes.md. The release notes also contain instructions and links to further documentation for masternode operators and miners.

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.

  • v0.13.3.0
Assets 11

Dash Core 0.13.3 Release Announcement

We are happy to announce the release of 0.13.3.0. This release includes binaries, which can be downloaded above.

About this Release

Dash Core 0.13.3.0 is a minor release of the Dash Core 0.13.x.x series.

This minor release only contains bugfixes and we consider this a stable release.

As spork15 has been activated on mainnet, there is no need for masternode start anymore. Upgrading a masternode now only involves replacing binaries and restarting the node.

Notable changes

Number of false-positives from anti virus software should be reduced

We have removed all mining code from Windows and Mac binaries, which should avoid most of the false-positive alerts from anti virus software. Linux builds are not affected. The mining code found in dash-qt and dashd are only meant for regression/integration tests and devnets, so there is no harm in removing this code from non-linux builds.

Fixed an issue with invalid merkle blocks causing SPV nodes to ban other nodes

A fix that was introduces in the last minor version caused creation of invalid merkle blocks, which in turn cause SPV nodes to ban 0.13.2 nodes. This can be observed on mobile clients which have troubles maintaining connections. This release fixes this issue and should allow SPV/mobile clients to sync with upgraded nodes.

Hardened spork15 value to 1047200

We've hardened the spork15 block height to 1047200, which makes sure that syncing from scratch will always work, no matter if spork15 is received in-time or not.

Bug fixes/Other improvements

There are few bug fixes in this release:

  • Fixed an issue with transaction sometimes not being fully zapped when -zapwallettxes is used
  • Fixed an issue with the protx revoke RPC and REASON_CHANGE_OF_KEYS

You can find detailed release notes at Click to view release notes.

  • v0.13.2.0

released at 15/03/2019

Assets 11

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).

Notable changes

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.

RPC changes

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 Click to view release notes.

  • v0.13.1.0

released at 08/02/2019

Assets 11

Dash Core 0.13.1 Release Announcement

We are happy to announce the release of 0.13.1.0. This release includes binaries, which can be downloaded above.

About this Release

Dash Core 0.13.1.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 do not require any additional actions (no need to issue masternode start command).

Notable changes

DIP0003 block signaling

Miners running v0.13.1.0 are going to signal DIP3 regardles of the readiness of the corresponding masternode. With 70%+ masternodes already running on v0.13.0.0 we believe it's safe to slightly speed up the migration this way. This is fully backwards compatible and no update is required for (non-mining) nodes running on v0.13.0.0.

GUI changes

Masternodes tab has a new checkbox that should filter masternode list by using keys stored in the wallet. This should make it much easier for masternode owners to find their masternodes in the list.

RPC changes

There is a new RPC command getspecialtxes which returns an array of special transactions found in the specified block with different level of verbosity. Also, various protx commands show extended help text for each parameter now (instead of referencing protx register).

Bug fixes/Other improvements

There are few bug fixes in this release:

  • Block size should be calculated correctly for blocks with quorum commitments when constructing new block;
  • Special transactions should be checked for mempool acceptance at the right time (nodes could ban each other in some rare cases otherwise);
  • Signature verification and processing of special transactions is decoupled to avoid any potential issues.

You can find detailed release notes at Click to view release notes.