dash-docs/_includes/devdoc/guide_dash_features.md at 3495dbbdf592110fbfd4667470d15943adf9d947

mirror of https://github.com/seigler/dash-docs synced 2025-07-27 01:36:13 +00:00

thephez 3495dbbdf5 Add/update glossary terms

Fix some cross-reference issues

2018-01-02 09:25:28 -05:00

20 KiB

Raw Blame History

{% comment %} This file is licensed under the MIT License (MIT) available on http://opensource.org/licenses/MIT. {% endcomment %} {% assign filename="_includes/devdoc/guide_dash_features.md" %}

Dash Features

{% include helpers/subhead-links.md %}

{% autocrossref %}

Dash aims to be the most user-friendly and scalable payments-focused cryptocurrency in the world. The Dash network features instant transaction confirmation, double spend protection, anonymity equal to that of physical cash, a self-governing, self-funding model driven by incentivized full nodes and a clear roadmap for on-chain scaling to up to 400MB blocks using custom-developed open source hardware.

While Dash is based on Bitcoin and compatible with many key components of the Bitcoin ecosystem, its two-tier network structure offers significant improvements in transaction speed, anonymity and governance. This section of the documentation describes these key features that set Dash apart in the blockchain economy.

{% endautocrossref %}

InstantSend

{% include helpers/subhead-links.md %}

{% autocrossref %}

Dash Core's InstantSend feature provides a way to lock transaction inputs and enable secure, instantaneous transactions.

InstantSend Data Flow

Once a sufficient number of votes approve the transaction lock, the InstantSend transaction is approved and shows 5 confirmations (DEFAULT_INSTANTSEND_DEPTH). 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:

To be used in an InstantSend transaction, an input must have 6+ confirmations (INSTANTSEND_CONFIRMATIONS_REQUIRED)
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 minimum fee (0.001 Dash) is required since the transaction involves the masternodes in addition to miners. Activation of DIP-0001 will reduce the fee by an order of magnitude (to 0.0001 Dash).

{% endautocrossref %}

PrivateSend

{% include helpers/subhead-links.md %}

{% autocrossref %}

Dash Core's PrivateSend feature provides a way to improve privacy by performing coin-mixing without relinquishing custodial access. For additional details, reference this Official Documentation PrivateSend page.

PrivateSend Data Flow

{% endautocrossref %}

Masternode Payment

{% include helpers/subhead-links.md %}

{% autocrossref %}

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.

{% endautocrossref %}

Masternode Sync

{% include helpers/subhead-links.md %}

{% autocrossref %}

Dash Core performs full masternode synchronization as required. There are several conditions that initiate a start/restart the sync process:

Initial startup of Dash Core
More than 60 minutes have passed since the last activation
A failure occurred during the last sync attempt (after a 1 minute cooldown before sync restarts)
Issuing a mnsync reset RPC command

Initial Masternode Sync

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

The following table details the data flow of P2P messages exchanged during initial masternode synchronization.

Masternode Sync Status

There are several status values used to track masternode synchronization. They are used in both ssc messages and the mnsync RPC.

Ongoing Masternode 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.

Recurring Ping

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

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

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.

Governance

After the initial governance synchronization, governance information is kept current by the govobj messages and govobjvote messages relayed on the network. Unsynchronized peers may send govsync messages to request governance sync.

Masternode Sync Schedule

The following tables detail the timing of various functions used to keep the masternodes in sync with each other. This information is derived from ThreadCheckPrivateSend in src/privatesend.cpp.

The following actions only run when the masternode sync is past MASTERNODE_SYNC_WAITING status.

{% endautocrossref %}

Governance

{% include helpers/subhead-links.md %}

{% autocrossref %}

Synchronization

Dash Core synchronizes the governance system via the Masternode network as the last stage of the Masternode sync process (following the sync of sporks, the Masternode list, and Masternode payments).

The govsync message initiates a sync of the governance system. Masternodes ignore this request if they are not fully synced.

There are two distinct stages of governance sync:

Initial request (object sync) - requests the governance objects only via a govsync message sent with a hash of all zeros.
Follow up request(s) (vote sync) - request governance object votes for a specific object via a govsync message containing the hash of the object. One message is required for each object. Dash Core periodically (~ every 6 seconds) sends messages to connected nodes until all the governance objects have been synchronized.

{% highlight text %} Dash Core limits how frequently the first type of sync (object sync) can be requested. Frequent requests will result in the node being banned. {% endhighlight %}

Masternodes respond to the govsync message with several items:

First, the Masternode sends one ssc message (Sync Status Count) for govobj objects and one for govobjvote objects. These messages indicate how many inventory items will be sent.
Second, the Masternode sends inv messages for the govobj and govobjvote objects.

Once the syncing node receives the counts and inventories, it may request any govobj and govobjvote objects from the masternode via a getdata message.

Governance Sync Data Flow

Sentinel

Sentinel is a Python application that connects to a masternode's local dashd instance to run as an autonomous agent for persisting, processing, and automating Dash 12.1+ governance objects and tasks. Sentinel abstracts some governance details away from Dash Core for easier extensibility of the governance system in the future. This will allow the integration between Evolution and Dash Core to proceed more smoothly and enable new governance object additions with minimal impact to Dash Core.

Sentinel runs periodically and performs four main tasks as described below: governance sync, ping, governance object pruning, and superblock management. The governance object data is stored in a SQLite database.

Sentinel Sync

Sentinel issues a gobject list RPC command and updates its database with the results returned from dashd. When objects are removed from the network, they are purged from the Sentinel database.

Sentinel Ping

In Dash Core 12.2, use of the watchdog governance object type was replaced by integrating sentinel information into the masternode ping (mnp message) via Pull Request #1491. Sentinel calls the sentinelping RPC which updates the masternode info to prevent it from entering a MASTERNODE_WATCHDOG_EXPIRED state.

Sentinel Prune

Sentinel 1.1.0 introduced proposal pruning which automatically votes to delete expired proposals following approximately half of a superblock cycle. This delay period ensures that proposals are not deleted prematurely. Prior to this, proposals remained in memory unless a sufficient number of masternodes manually voted to delete them.

Sentinel Superblock

Sentinel manages superblock creation, voting, and submission to dashd for network propagation.

{% endautocrossref %}

Quorum Selection

{% include helpers/subhead-links.md %}

{% autocrossref %}

Dash quorums are used to facilitate the operation of masternode provided features in a decentralized, deterministic way.

Quorum Type	Members	Consensus	Description
InstantSend	10	Majority	A set of 10 masternodes are selected for each input of the InstantSend transaction. A majority (6+) of them must agree to lock the input. If all inputs in the transaction can be locked, it becomes a successful InstantSend.
MN Payments	10	Majority	A set of 10 masternodes are selected for each block. A majority (6+) of them must agree on the masternode payee for the next block.
MN Broadcast	10	Majority	If a majority (6+) of nodes agree, a new `mnb` message is not required.

{% endautocrossref %}

20 KiB Raw Blame History

Dash Features

InstantSend

PrivateSend

Masternode Payment

Masternode Sync

Initial Masternode Sync

Ongoing Masternode Sync

Masternode Sync Schedule

Governance

Synchronization

Sentinel

Sentinel Sync

Sentinel Ping

Sentinel Prune

Sentinel Superblock

Quorum Selection

20 KiB

Raw Blame History