Dash Core

Dash Core Developer Documentation

Welcome to the Dash Core developer documentation. You'll find guides and documentation to help you start working with Dash Core as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    Guides

Historical Reference

❗️

Deprecated Content

The following information is deprecated and for historical reference only. It describes features that have been redesigned and no longer operate as described below.

InstantSend (original)

🚧

Please see here for details of the current InstantSend design.

Dash Core's InstantSend feature provides a way to lock transaction inputs and enable secure, instantaneous transactions. Since Dash Core 0.13.0, any qualifying transaction is automatically upgraded to InstantSend by the network without a need for the sending wallet to explicitly request it. For these simple transactions (those containing 4 or fewer inputs), the previous requirement for a special InstantSend transaction fee was also removed. The criteria for determining eligibility can be found in the lists of limitations below.

The following video provides an overview with a good introduction to the details including the InstantSend vulnerability that was fixed in Dash Core 0.12.2. Some specific points in the video are listed here for quick reference:

  • 2:00 - InstantSend restrictions
  • 5:00 - Masternode quorum creation
  • 6:00 - Input locking
  • 7:45 - Quorum score calculation / Requirement for block confirmations
  • 9:00 - Description of Dash Core pre-0.12.2 InstantSend vulnerability
  • 13:00 - Description of vulnerability fix / Post Dash Core 0.12.2 operation

InstantSend Data Flow

InstantSend ClientDirectionPeersDescription
inv message (ix)β†’Client sends inventory for transaction lock request
←getdata message (ix)Peer responds with request for transaction lock request
ix message→Client sends InstantSend transaction lock request
←inv message (txlvote)Masternodes in the quorum respond with votes
getdata message (txlvote)β†’Client requests vote
←txlvote messagePeer responds with vote

Once an InstantSend lock has been requested, the instantsend field of various RPCs (e.g. the getmempoolentry RPC) is set to true. Then, if a sufficient number of votes approve the transaction lock, the InstantSend transaction is approved the instantlock field of the RPC is set to true.

If an InstantSend transaction is a valid transaction but does not receive a transaction lock, it reverts to being a standard transaction.

There are a number of limitations on InstantSend transactions:

  • The lock request will timeout 15 seconds after the first vote is seen (INSTANTSEND_LOCK_TIMEOUT_SECONDS)
  • The lock request will fail if it has not been locked after 60 seconds (INSTANTSEND_FAILED_TIMEOUT_SECONDS)
  • A β€œper-input” fee of 0.0001 DASH per input is required for non-simple transactions (inputs >=5) since they place a higher load on the masternodes. This fee was most recently decreased by DIP-0001.
  • To be used in an InstantSend transaction, an input must have at least the number confirmations (block depth) indicated by the table below
NetworkConfirmations Required
Mainnet6 Blocks
Testnet2 Blocks
Regtest2 Blocks
Devnet2 Blocks

There are some further limitations on Automatic InstantSend transactions:

  • DIP3 must be active
  • Spork 16 must be enabled
  • Mempool usage must be lower than 10% (AUTO_IX_MEMPOOL_THRESHOLD). As of Dash Core 0.13.0, this corresponds to a mempool size of 30 MB (DEFAULT_MAX_MEMPOOL_SIZE = 300 MB).

Historical Note

Prior to Dash Core 0.13.0, instantsend and instantlock values were not available via RPC. At that time, the InstantSend system worked as described below.

Once a sufficient number of votes approved the transaction lock, the InstantSend transaction was approved and showed 5 confirmations (DEFAULT_INSTANTSEND_DEPTH).

NOTE: The 5 "pseudo-confirmations" were shown to convey confidence that the transaction was secure from double-spending and DID NOT indicate the transaction had already been confirmed to a block depth of 5 in the blockchain.

Masternode Payment (original)

🚧

The following information is for historical reference only. It describes the masternode payment process that was used prior to the deterministic masternode list update in Dash Core v0.13 that implemented DIP3.

Please see here for details of the current system

Prior to DIP3, the masternode payment process operated as described below.

Masternode payment uses a verifiable process to determine which masternode is paid in each block. When a new block is processed, a quorum of MNPAYMENTS_SIGNATURES_TOTAL (10) masternodes vote on the next masternode payee. The quorum is calculated deterministically based on the distance between masternode's hash and the block's proof of work.

Each member of the quorum issues a 'mnw' message that is relayed to the network. The payee is selected from a subset of masternodes made up of 10% of eligible nodes that have been waiting the longest since their last payment. The winner is then determined based on a number of parameters including the distance between the its hash and the block's proof of work. For additional detail, reference this Official Documentation Payment Logic page.

Nodes receiving a mnw message verify the validity of the message before relaying it to their peers. If the message is invalid, the sending node may be treated as misbehaving and have its ban score increased.

Masternode Sync (original)

🚧

The following information is for historical reference only. It describes the masternode sync process that was used prior to the deterministic masternode list update in Dash Core v0.13 that implemented DIP3.

Please see here for details of the current system

Initial Sync

This diagram shows the order in which P2P messages are sent to perform masternode synchronization initially after startup.

Masternode Sync (Initial)Masternode Sync (Initial)

The following table details the data flow of P2P messages exchanged during initial masternode synchronization before the activation of DIP3 and Spork 15.

Syncing Node MessageDirectionMasternode ResponseDescription
1. Sporks
getsporks message→Syncing node requests sporks
←spork message(s)
2. Masternode ListSync Masternode list from other connected clients
dseg message→Syncing node requests masternode list
←ssc messageNumber of entries in masternode list (MASTERNODE_SYNC_LIST)

Only sent if requesting entire list
←inv message(s) (mnb)MSG_MASTERNODE_ANNOUNCE
←inv message(s) (mnp)MSG_MASTERNODE_PING
getdata message(s) (mnb)β†’(Optional)
getdata message(s) (mnp)β†’(Optional)
←mnb message(s)(If requested) Masternode announce message
←mnp message(s)(If requested) Masternode ping message
3. Masternode paymentsAsk node for all payment votes it has (new nodes will only return votes for future payments)
mnget message→Syncing node requests masternode payment sync
←ssc messageNumber of entries in masternode payment list
←inv message(s) (mnw)MSG_MASTERNODE_PAYMENT_VOTE
getdata message(s) (mnw)β†’(Optional)
←mnw message(s)(If requested) Masternode payment vote message
4. GovernanceSee Governance sync

Ongoing Sync

Once a masternode completes an initial full sync, continuing synchronization is maintained by the exchange of P2P messages with other nodes. This diagram shows an overview of the messages exchanged to keep the masternode list, masternode payments, and governance objects synchronized between masternodes.

Masternode Sync (Ongoing)Masternode Sync (Ongoing)

Recurring Ping

🚧

Note: Deprecated following activation of DIP3.

Each masternode issues a ping (mnp message) periodically to notify the network that it is still online. Masternodes that do not issue a ping for 3 hours will be put into the MASTERNODE_NEW_START_REQUIRED state and will need to issue a masternode announce (mnb message).

Masternode List

🚧

Note: Deprecated following activation of DIP3.

After the initial masternode list has been received, it is kept current by a combination of the periodic mnp messages received from other masternodes, the mnb messages sent by masternodes as they come online, and mnv messages to verify that other masternodes are valid.

Also, dseg messages can be sent to request masternode info when messages are received that have been signed by an unrecognized masternode (most masternode/governance messages include a vin value that can be used to verify the masternode's unspent 1000 Dash).

Unsynchronized peers may send a dseg message to request the entire masternode list.

Masternode Payment

🚧

Note: Deprecated following activation of DIP3.

After the initial masternode payment synchronization, payment information is kept current via the mnw messages relayed on the network. Unsynchronized peers may send a mnget message to request masternode payment sync.

Sync Schedule

Prior to the deterministic masternode system introduced by DIP3 in Dash Core 0.13, the following additional sync actions were also required.

Period (seconds)ActionDescription
1MN CheckWarning iconWarning icon Deprecated following activation of DIP3 and Spork 15

Check the state of each masternode that is still funded and not banned. The action occurs once per second, but individual masternodes are only checked at most every 5 seconds (only a subset of masternodes are checked each time it runs) (masternodeman.cpp)
60MN Check/RemoveWarning iconWarning icon Deprecated following activation of DIP3 and Spork 15

Remove spent masternodes and check the state of inactive ones (masternodeman.cpp)
60MN Payment Check/RemoveWarning iconWarning icon Deprecated following activation of DIP3 and Spork 15

Remove old masternode payment votes/blocks (masternode-payments.cpp)
300Full verificationWarning iconWarning icon Deprecated following activation of DIP3 and Spork 15

Verify masternodes via direct requests (mnv messages - note time constraints in the Developer Reference section) (masternodeman.cpp)
600Manage StateWarning iconWarning icon Deprecated following activation of DIP3 and Spork 15

Sends masternode pings (mnp message). Also sends initial masternode broadcast (mnb message) for local masternodes. (activemasternode.cpp)

Updated about a year ago


What's Next

Block Chain

Historical Reference


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.