The following information is deprecated and for historical reference only. It describes features that have been redesigned and no longer operate as described below.
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
|→||Client sends inventory for transaction lock request|
|←||Peer responds with request for transaction lock request|
|→||Client sends InstantSend transaction lock request|
|←||Masternodes in the quorum respond with votes|
|→||Client requests vote|
|←||Peer 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
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 (
- The lock request will fail if it has not been locked after 60 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
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).
Prior to Dash Core 0.13.0,
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 (
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.
Updated almost 2 years ago