joshua/dash-docs
1
0
Fork 0
mirror of https://github.com/seigler/dash-docs synced 2025-07-27 01:36:13 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Content - Update InstantSend section with LLMQ-IS detail

Browse source
This commit is contained in:
thephez 2019-09-12 10:33:57 -04:00
parent 3a68e8987a
commit 2682f83775
1 changed files with 19 additions and 117 deletions
Download patch file Download diff file Expand all files Collapse all files

136
_includes/devdoc/guide_dash_features.md
View file

@ -32,108 +32,11 @@ economy.
{% autocrossref %} {% autocrossref %}
Dash Core's InstantSend feature provides a way to lock transaction inputs and 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 enable secure, instantaneous transactions. The network automatically attempts to
transaction is automatically upgraded to InstantSend by the network without a upgrade any qualifying transaction to InstantSend without a need for the sending
need for the sending wallet to explicitly request it. For these simple wallet to explicitly request it.
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 * To qualify for InstantSend, transaction inputs must either:
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
{% endautocrossref %}
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/n4PELomRiFY?rel=0;start=0" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
{% autocrossref %}
*InstantSend Data Flow*
| **InstantSend Client** | **Direction** | **Peers** | **Description** |
| `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](#quorum-selection) respond with votes
| `getdata` message (txlvote) | → | | Client requests vote
| | ← | `txlvote` message | 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 `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](https://github.com/dashpay/dips/blob/master/dip-0001.md).
* To be used in an InstantSend transaction, an input must have at least the number confirmations (block depth) indicated by the table below
| **Network** | **Confirmations Required** |
|---------|--------------|
| Mainnet | 6 Blocks |
| Testnet | 2 Blocks |
| Regtest | 2 Blocks |
| Devnet | 2 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.
{% endautocrossref %}
#### LLMQ InstantSend
{% include helpers/subhead-links.md %}
{% autocrossref %}
The introduction of Long-Living Masternode Quorums in Dash Core 0.14 provides
a foundation to further scale InstantSend. LLMQs enable the transaction input
locking process (and resulting network traffic) to occur within the quorum. This
enables further scaling without introducing network congestion since only the
output of the locking process is relayed to the entire Dash network.
LLMQ-based InstantSend also removes a number of previously required limitations
and simplifies the process by decreasing the number of P2P messages clients must
process. Rather than tracking individual masternode votes for each transaction
input, all required locking information is found within the single `islock` message.
During the evaluation and transition from standard InstantSend to LLMQ-based
InstantSend, Sporks 2 (`SPORK_2_INSTANTSEND_ENABLED`) and 20 (`SPORK_20_INSTANTSEND_LLMQ_BASED`)
will both be used. Spork 2 enables or disables the entire InstantSend feature,
while spork 20 determines which of the two InstantSend mechanisms is active when
InstantSend is enabled.
There are still some limitations on LLMQ-based InstantSend transactions:
* Transaction inputs must either:
* Be locked by InstantSend * Be locked by InstantSend
* Be in a block that has a ChainLock * Be in a block that has a ChainLock
* Have at least the number confirmations (block depth) indicated by the table below * Have at least the number confirmations (block depth) indicated by the table below
@ -141,24 +44,20 @@ There are still some limitations on LLMQ-based InstantSend transactions:
| **Network** | **Confirmations Required** | | **Network** | **Confirmations Required** |
|---------|--------------| |---------|--------------|
| Mainnet | 6 Blocks | | Mainnet | 6 Blocks |
| Testnet | 2 Blocks | | Testnet / Regtest / Devnet | 2 Blocks |
| Regtest | 2 Blocks |
| Devnet | 2 Blocks |
The introduction of Long-Living Masternode Quorums in Dash Core 0.14 provided
a foundation to scale InstantSend. The transaction input locking process (and
resulting network traffic) now occurs only within the quorum. This minimizes
network congestion since only the `islock` message produced by the locking
process is relayed to the entire Dash network. This message contains all the
information necessary to verify a successful transaction lock.
The improvements over the old InstantSend system include both the addition of new Sporks 2 (`SPORK_2_INSTANTSEND_ENABLED`) and 20 (`SPORK_20_INSTANTSEND_LLMQ_BASED`)
functionality and the removal of prior limitations. The following table details are used to manage InstantSend. Spork 2 enables or disables the entire
these improvements: InstantSend feature. Spork 20 was used to support the transition to LLMQ-based
InstantSend and is currently retained for backward compatibility. It will be
| **Status** | **Improvement** | deprecated in a future release.
|---------|--------------|
| New | Transactions can be chained if the inputs are from transactions that are also locked |
| New | InstantSend locks are attempted for all transactions (`tx` messages) - no need to request it via the special message (`ix` message) |
| New | Successful locks are indicated by a single `islock` message - no need to track votes (`txlvote` messages) for each input |
| Updated | Limit on number of inputs removed |
| Updated | Limit on transaction value removed |
| Updated | Timeout for locking removed - transaction locks will only be removed once the transaction is confirmed in a ChainLocked block |
| Updated | Custom InstantSend fee removed |
Note: A transaction will __not__ be included in the block template (from `getblocktemplate`) unless it: Note: A transaction will __not__ be included in the block template (from `getblocktemplate`) unless it:
@ -182,6 +81,9 @@ block.
| `getdata` message (islock) | → | | Client requests lock message | `getdata` message (islock) | → | | Client requests lock message
| | ← | `islock` message | Quorum responds with lock message | | ← | `islock` message | Quorum responds with lock message
Once a transaction lock is approved, the `instantlock` field of various RPCs
is set to `true` (e.g. the `getmempoolentry` RPC).
{% endautocrossref %} {% endautocrossref %}
### ChainLocks ### ChainLocks