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

Minor review updates

Browse source 
- listunspent RPC - remove RBF-related text
 - InstantSend
   - Convert improvement list to table
   - Add some additional detail
   - Update limitation list
This commit is contained in:
thephez 2019-05-13 11:47:15 -04:00
parent ebe222c4f3
commit c523af4ca9
2 changed files with 24 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

2
_includes/devdoc/dash-core/rpcs/rpcs/listunspent.md
View file

@ -136,7 +136,7 @@ the *spendable* field in the results described below.
- n: "→ →<br>`safe`" - n: "→ →<br>`safe`"
t: "bool" t: "bool"
p: "Required<br>(exactly 1)" p: "Required<br>(exactly 1)"
d: "*Added in Bitcoin Core 0.15.0*<br><br>Whether this output is considered safe to spend. Unconfirmed transactions from outside keys and unconfirmed replacement transactions are considered unsafe and are not eligible for spending by `fundrawtransaction` and `sendtoaddress`." d: "*Added in Bitcoin Core 0.15.0*<br><br>Whether this output is considered safe to spend. Unconfirmed transactions from outside keys are considered unsafe and are not eligible for spending by `fundrawtransaction` and `sendtoaddress`."
{% enditemplate %} {% enditemplate %}

34
_includes/devdoc/guide_dash_features.md
View file

@ -115,9 +115,16 @@ had already been confirmed to a block depth of 5 in the blockchain.
{% autocrossref %} {% autocrossref %}
The introduction of Long-Living Masternode Quorums in Dash Core 0.14 provides The introduction of Long-Living Masternode Quorums in Dash Core 0.14 provides
a foundation to further scale InstantSend. LLMQ-based InstantSend removes a a foundation to further scale InstantSend. LLMQs enable the transaction input
number of previously required limitations and simplifies the process by decreasing locking process (and resulting network traffic) to occur within the quorum. This
the number of P2P messages clients must use. 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
for a transaction.
During the evaluation and transition from standard InstantSend to LLMQ-based 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`) InstantSend, Sporks 2 (`SPORK_2_INSTANTSEND_ENABLED`) and 20 (`SPORK_20_INSTANTSEND_LLMQ_BASED`)
@ -128,6 +135,7 @@ InstantSend is enabled.
There are still some limitations on LLMQ-based InstantSend transactions: There are still some limitations on LLMQ-based InstantSend transactions:
* Transaction inputs must either: * Transaction inputs must either:
* 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
@ -139,15 +147,19 @@ There are still some limitations on LLMQ-based InstantSend transactions:
| Devnet | 2 Blocks | | Devnet | 2 Blocks |
Improvements from the old InstantSend system: The improvements over the old InstantSend system include both the addition of new
functionality and the removal of prior limitations. The following table details
these improvements:
* Changed: Transactions can be chained if the inputs are from transactions that are also locked | **Status** | **Improvement** |
* Changed: InstantSend locks are attempted for all transactions (`tx` messages) - no need to request it via the special message (`ix` message) |---------|--------------|
* Changed: Only need to receive a single `islock` message - no need to track votes (`txlvote` messages) for each input | New | Transactions can be chained if the inputs are from transactions that are also locked |
* Removed: Limit on number of inputs | New | InstantSend locks are attempted for all transactions (`tx` messages) - no need to request it via the special message (`ix` message) |
* Removed: Limit on transaction value | New | Successful locks are indicated by a single `islock` message - no need to track votes (`txlvote` messages) for each input |
* Removed: Timeout for lock - transaction locks will only be removed once the transaction is confirmed in a ChainLocked block | Updated | Limit on number of inputs removed |
* Removed: Custom InstantSend fee | 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: