From f66a554da0e9d346bafe5a479fd0bbfc252a3665 Mon Sep 17 00:00:00 2001 From: thephez Date: Mon, 2 Aug 2021 15:49:58 -0400 Subject: [PATCH 01/17] docs: initial conversion md --- deterministic-instantsend.md | 180 +++++++++++++++++++++++++++++++++++ 1 file changed, 180 insertions(+) create mode 100644 deterministic-instantsend.md diff --git a/deterministic-instantsend.md b/deterministic-instantsend.md new file mode 100644 index 00000000..932b80a2 --- /dev/null +++ b/deterministic-instantsend.md @@ -0,0 +1,180 @@ +## DIP 00XX: Making InstantSend Deterministic with use of Quorum Cycles + +Authors: Samuel Westrich, UdjinM6 + +Special Thanks: Virgile Bartolo, Thephez + + +## Abstract + +This DIP aims to improve InstantSend messages to make them deterministically verifiable. + + +## Motivation + +LLMQ based InstantSend was introduced in DIP 10. In that implementation InstantSend locks are only verifiable by recent quorums, because the InstantSend lock does not include any block or time based information. In Dash Platform InstantSend Locks are used to add credit to Identities as they provide input finality. When blocks are replayed on the Platform Chain, all State Transitions need to be re-validated; it is possible that InstantSend signatures will need to be rechecked. However to recheck them one needs to know the quorum that signed them. In this DIP we will provide a mechanism to that end. + + +## Previous work + +[DIP-0006: Long-Living Masternode Quorums](https://github.com/dashpay/dips/blob/master/dip-0006.md) + +[DIP-0007: LLMQ Signing Requests / Sessions](https://github.com/dashpay/dips/blob/master/dip-0007.md) + +[DIP-0010: LLMQ InstantSend](https://github.com/dashpay/dips/blob/master/dip-0010.md) + + +## Versioning of ISLock messages + +Since "islock" messages were never versioned, a new message “ISDLock” will be created and the "islock" message will be deprecated. ISD stands for InstantSend Deterministic. The version of the ISDLock used in this document will be 1. We will still refer to "islock" messages, even though the message name has been changed. + +The “messageHash” for "islock" messages should now be calculated as `SHA256(version, txHash).` + + +## QuorumHash vs CycleHash + +The naive approach to fixing this problem would be to include the QuorumHash in the "islock" message. An "islock" would then be easily verifiable since the quorum that signed it is always known. The drawback of this approach is that any Quorum could sign any "islock" even if it does not have the responsibility to do it for the quorum cycle. + +A quorum cycle begins at a quorumBlock (as per [DIP-0006](https://github.com/dashpay/dips/blob/master/dip-0006.md#parametersvariables-of-a-llmq-and-dkg)) and lasts for a number of blocks that is equal to the quorumDkgInterval. During this time the set of valid quorums are not modified for a given quorum Type. If the quorumDkgInterval is set to 24 blocks then from block 100 to block 124 quorums of that type stay the same. During this period the quorum that is in charge of signing a specific "islock" will also always be the same. CycleHash is the blockHash of the first block in a cycle.hash of the most recent quorumBlock. + +By adding the CycleHash to the "islock" message, any node can follow the steps required to determine the appropriate quorumHash and verify the signature. + + +## Verification of the signature + +To calculate which LLMQ was responsible for the "islock" the verifier should perform the following: + + + +1. Take the LLMQ set that corresponds to the quorum cycle defined by cycle hash in the "islock" message. +2. Calculate the RequestID from data in the "islock" message by calculating `SHA256("islock", inputCount, prevTxHash1, prevTxOut1, prevTxHash2, prevTxOut2, ...)` +3. For each LLMQ of this quorum cycle’s set, calculate `SHA256(quorumType, quorumHash, requestId)` +4. Sort the list of LLMQs based on the result of step 3 in ascending order. +5. Use the first entry of the sorted list as the responsible LLMQ. +6. Create the SignID by calculating `SHA256(quorumHash, requestId, SHA256(version, txHash))` +7. Use the public key of responsible LLMQ and verify the signature against the SignID. + +Nodes receiving "islock" messages should verify them by using the above steps. Only `ISDLOCK` messages with valid signatures should be propagated further using the inventory system. + + +## The new ISDLock message + +When a masternode receives a recovered signature for a signing request in the quorum where it is active, it should use the signature to create a new p2p message, which is the `ISDLOCK` message. To figure out the cycle hash, take the quorum hash corresponding to the LLMQ that created the recovered signature. Then find the last known block where this quorum was responsible for signing the "islock" message. Often this is the current block, but in rare situations it might be a prior one if quorums have just cycled. From this last known block, find the first block of that cycle. This is the last block before quorums changed for the quorum type used for "islock" messages. + +It is possible that a quorum is active before and after quorum cycling. It is also possible that the quorum responsible for a signing request before and after cycling is the same. This could lead to the creation of two "islock" messages, distinct only by the fact that their cycle hash is different. + +The new message has the following structure: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Field + Type + Size + Description +
version + uint8 + 1 + The version of the islock message +
inputCount + compactSize uint + 1 - 9 + Number of inputs in the transaction +
inputs + COutpoint[] + inputCount * 36 + Inputs of the transaction. COutpoint is a uint256 (hash of previous transaction) and a uint32 (output index) +
txid + uint256 + 32 + txid/hash of the transaction +
cycleHash + uint256 + 32 + Block hash of first block of the cycle in which the quorum signing this "islock" is active +
sig + BLSSig + 96 + Recovered signature from the signing request/session +
+ + + +### **Choosing the active LLMQ to perform signing** + +Choosing the active LLMQ to perform signing should follow the same steps as defined in [DIP-0007 - Choosing the active LLMQ to perform signing](https://github.com/dashpay/dips/blob/master/dip-0007.md#choosing-the-active-llmq-to-perform-signing). + + + + + + + + + + + + + + + + + + + + + +
Field + Type + Size + Description +
txid + uint256 + 32 + txid/hash of the transaction +
sig + BLSSig + 96 + Recovered signature from the signing request/session +
From 345b16b97f0ebb31dc41b668555d99ae060ea5aa Mon Sep 17 00:00:00 2001 From: thephez Date: Mon, 2 Aug 2021 15:51:39 -0400 Subject: [PATCH 02/17] docs: add header and whitespace cleanup --- deterministic-instantsend.md | 31 ++++++++++++------------------- 1 file changed, 12 insertions(+), 19 deletions(-) diff --git a/deterministic-instantsend.md b/deterministic-instantsend.md index 932b80a2..88d01a70 100644 --- a/deterministic-instantsend.md +++ b/deterministic-instantsend.md @@ -1,20 +1,23 @@ -## DIP 00XX: Making InstantSend Deterministic with use of Quorum Cycles - -Authors: Samuel Westrich, UdjinM6 - -Special Thanks: Virgile Bartolo, Thephez - +
+DIP: 00xx
+Title: Making InstantSend Deterministic with use of Quorum Cycles
+Author: Samuel Westrich, UdjinM6
+Special-Thanks: Thephez, Virgile Bartolo
+Comments: No comments yet.
+Status: Draft
+Layer: Consensus (hard fork)
+Created: 2020-08-02
+License: MIT License
+
## Abstract This DIP aims to improve InstantSend messages to make them deterministically verifiable. - ## Motivation LLMQ based InstantSend was introduced in DIP 10. In that implementation InstantSend locks are only verifiable by recent quorums, because the InstantSend lock does not include any block or time based information. In Dash Platform InstantSend Locks are used to add credit to Identities as they provide input finality. When blocks are replayed on the Platform Chain, all State Transitions need to be re-validated; it is possible that InstantSend signatures will need to be rechecked. However to recheck them one needs to know the quorum that signed them. In this DIP we will provide a mechanism to that end. - ## Previous work [DIP-0006: Long-Living Masternode Quorums](https://github.com/dashpay/dips/blob/master/dip-0006.md) @@ -23,14 +26,12 @@ LLMQ based InstantSend was introduced in DIP 10. In that implementation InstantS [DIP-0010: LLMQ InstantSend](https://github.com/dashpay/dips/blob/master/dip-0010.md) - ## Versioning of ISLock messages Since "islock" messages were never versioned, a new message “ISDLock” will be created and the "islock" message will be deprecated. ISD stands for InstantSend Deterministic. The version of the ISDLock used in this document will be 1. We will still refer to "islock" messages, even though the message name has been changed. The “messageHash” for "islock" messages should now be calculated as `SHA256(version, txHash).` - ## QuorumHash vs CycleHash The naive approach to fixing this problem would be to include the QuorumHash in the "islock" message. An "islock" would then be easily verifiable since the quorum that signed it is always known. The drawback of this approach is that any Quorum could sign any "islock" even if it does not have the responsibility to do it for the quorum cycle. @@ -39,13 +40,10 @@ A quorum cycle begins at a quorumBlock (as per [DIP-0006](https://github.com/das By adding the CycleHash to the "islock" message, any node can follow the steps required to determine the appropriate quorumHash and verify the signature. - ## Verification of the signature To calculate which LLMQ was responsible for the "islock" the verifier should perform the following: - - 1. Take the LLMQ set that corresponds to the quorum cycle defined by cycle hash in the "islock" message. 2. Calculate the RequestID from data in the "islock" message by calculating `SHA256("islock", inputCount, prevTxHash1, prevTxOut1, prevTxHash2, prevTxOut2, ...)` 3. For each LLMQ of this quorum cycle’s set, calculate `SHA256(quorumType, quorumHash, requestId)` @@ -56,7 +54,6 @@ To calculate which LLMQ was responsible for the "islock" the verifier should per Nodes receiving "islock" messages should verify them by using the above steps. Only `ISDLOCK` messages with valid signatures should be propagated further using the inventory system. - ## The new ISDLock message When a masternode receives a recovered signature for a signing request in the quorum where it is active, it should use the signature to create a new p2p message, which is the `ISDLOCK` message. To figure out the cycle hash, take the quorum hash corresponding to the LLMQ that created the recovered signature. Then find the last known block where this quorum was responsible for signing the "islock" message. Often this is the current block, but in rare situations it might be a prior one if quorums have just cycled. From this last known block, find the first block of that cycle. This is the last block before quorums changed for the quorum type used for "islock" messages. @@ -65,7 +62,6 @@ It is possible that a quorum is active before and after quorum cycling. It is al The new message has the following structure: -
Field @@ -139,12 +135,9 @@ The new message has the following structure:
- - ### **Choosing the active LLMQ to perform signing** -Choosing the active LLMQ to perform signing should follow the same steps as defined in [DIP-0007 - Choosing the active LLMQ to perform signing](https://github.com/dashpay/dips/blob/master/dip-0007.md#choosing-the-active-llmq-to-perform-signing). - +Choosing the active LLMQ to perform signing should follow the same steps as defined in [DIP-0007 - Choosing the active LLMQ to perform signing](https://github.com/dashpay/dips/blob/master/dip-0007.md#choosing-the-active-llmq-to-perform-signing). From 43e821e39cd94c2fd53d40b9e5110272ccc639e4 Mon Sep 17 00:00:00 2001 From: thephez Date: Mon, 2 Aug 2021 16:30:01 -0400 Subject: [PATCH 03/17] docs: formatting and wording --- deterministic-instantsend.md | 136 ++++++----------------------------- 1 file changed, 21 insertions(+), 115 deletions(-) diff --git a/deterministic-instantsend.md b/deterministic-instantsend.md index 88d01a70..736c9104 100644 --- a/deterministic-instantsend.md +++ b/deterministic-instantsend.md @@ -16,15 +16,13 @@ This DIP aims to improve InstantSend messages to make them deterministically ver ## Motivation -LLMQ based InstantSend was introduced in DIP 10. In that implementation InstantSend locks are only verifiable by recent quorums, because the InstantSend lock does not include any block or time based information. In Dash Platform InstantSend Locks are used to add credit to Identities as they provide input finality. When blocks are replayed on the Platform Chain, all State Transitions need to be re-validated; it is possible that InstantSend signatures will need to be rechecked. However to recheck them one needs to know the quorum that signed them. In this DIP we will provide a mechanism to that end. +LLMQ based InstantSend was introduced in DIP10. In that implementation InstantSend locks are only verifiable by recent quorums, because the InstantSend lock does not include any block or time based information. In Dash Platform InstantSend Locks are used to add credit to Identities as they provide input finality. When blocks are replayed on the Platform Chain, all State Transitions need to be re-validated and it is possible that InstantSend signatures will need to be rechecked. However, to recheck them one needs to know the quorum that signed them. In this DIP we will provide a mechanism to that end. ## Previous work -[DIP-0006: Long-Living Masternode Quorums](https://github.com/dashpay/dips/blob/master/dip-0006.md) - -[DIP-0007: LLMQ Signing Requests / Sessions](https://github.com/dashpay/dips/blob/master/dip-0007.md) - -[DIP-0010: LLMQ InstantSend](https://github.com/dashpay/dips/blob/master/dip-0010.md) +* [DIP-0006: Long-Living Masternode Quorums](https://github.com/dashpay/dips/blob/master/dip-0006.md) +* [DIP-0007: LLMQ Signing Requests / Sessions](https://github.com/dashpay/dips/blob/master/dip-0007.md) +* [DIP-0010: LLMQ InstantSend](https://github.com/dashpay/dips/blob/master/dip-0010.md) ## Versioning of ISLock messages @@ -34,9 +32,9 @@ The “messageHash” for "islock" messages should now be calculated as `SHA256( ## QuorumHash vs CycleHash -The naive approach to fixing this problem would be to include the QuorumHash in the "islock" message. An "islock" would then be easily verifiable since the quorum that signed it is always known. The drawback of this approach is that any Quorum could sign any "islock" even if it does not have the responsibility to do it for the quorum cycle. +The naive approach to fixing this problem would be to include the QuorumHash in the `islock` message. An `islock` would then be easily verifiable since the quorum that signed it would always be known. The drawback of this approach is that any quorum could sign any `islock` even if it were not responsible to do so for that quorum cycle. -A quorum cycle begins at a quorumBlock (as per [DIP-0006](https://github.com/dashpay/dips/blob/master/dip-0006.md#parametersvariables-of-a-llmq-and-dkg)) and lasts for a number of blocks that is equal to the quorumDkgInterval. During this time the set of valid quorums are not modified for a given quorum Type. If the quorumDkgInterval is set to 24 blocks then from block 100 to block 124 quorums of that type stay the same. During this period the quorum that is in charge of signing a specific "islock" will also always be the same. CycleHash is the blockHash of the first block in a cycle.hash of the most recent quorumBlock. +A quorum cycle begins at a `quorumBlock` (as per [DIP-0006](https://github.com/dashpay/dips/blob/master/dip-0006.md#parametersvariables-of-a-llmq-and-dkg)) and lasts for a number of blocks that is equal to the `quorumDkgInterval`. During this time the set of valid quorums are not modified for a given quorum type. If the `quorumDkgInterval` is set to 24 blocks then from block 100 to block 124 quorums of that type stay the same. During this period the quorum that is in charge of signing a specific `islock` will also always be the same. CycleHash is the `blockHash` of the first block in a cycle. By adding the CycleHash to the "islock" message, any node can follow the steps required to determine the appropriate quorumHash and verify the signature. @@ -47,10 +45,10 @@ To calculate which LLMQ was responsible for the "islock" the verifier should per 1. Take the LLMQ set that corresponds to the quorum cycle defined by cycle hash in the "islock" message. 2. Calculate the RequestID from data in the "islock" message by calculating `SHA256("islock", inputCount, prevTxHash1, prevTxOut1, prevTxHash2, prevTxOut2, ...)` 3. For each LLMQ of this quorum cycle’s set, calculate `SHA256(quorumType, quorumHash, requestId)` -4. Sort the list of LLMQs based on the result of step 3 in ascending order. -5. Use the first entry of the sorted list as the responsible LLMQ. +4. Sort the list of LLMQs based on the result of step 3 in ascending order +5. Use the first entry of the sorted list as the responsible LLMQ 6. Create the SignID by calculating `SHA256(quorumHash, requestId, SHA256(version, txHash))` -7. Use the public key of responsible LLMQ and verify the signature against the SignID. +7. Use the public key of responsible LLMQ and verify the signature against the SignID Nodes receiving "islock" messages should verify them by using the above steps. Only `ISDLOCK` messages with valid signatures should be propagated further using the inventory system. @@ -62,112 +60,20 @@ It is possible that a quorum is active before and after quorum cycling. It is al The new message has the following structure: -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Field - Type - Size - Description -
version - uint8 - 1 - The version of the islock message -
inputCount - compactSize uint - 1 - 9 - Number of inputs in the transaction -
inputs - COutpoint[] - inputCount * 36 - Inputs of the transaction. COutpoint is a uint256 (hash of previous transaction) and a uint32 (output index) -
txid - uint256 - 32 - txid/hash of the transaction -
cycleHash - uint256 - 32 - Block hash of first block of the cycle in which the quorum signing this "islock" is active -
sig - BLSSig - 96 - Recovered signature from the signing request/session -
+| Field | Type | Size | Description | +|-|-|-|-| +| **version** | uint8 | 1 | The version of the islock message | +| inputCount | compactSize uint | 1 - 9 | Number of inputs in the transaction | +| inputs | COutpoint[] | `inputCount` * 36 | Inputs of the transaction. COutpoint is a uint256 (hash of previous transaction) and a uint32 (output index) | +| txid | uint256 | 32 | Transaction id (hash of the transaction) | +| **cycleHash** | uint256 | 32 | Block hash of first block of the cycle in which the quorum signing this `islock` is active +| sig | BLSSig | 96 | Recovered signature from the signing request/session | ### **Choosing the active LLMQ to perform signing** Choosing the active LLMQ to perform signing should follow the same steps as defined in [DIP-0007 - Choosing the active LLMQ to perform signing](https://github.com/dashpay/dips/blob/master/dip-0007.md#choosing-the-active-llmq-to-perform-signing). - - - - - - - - - - - - - - - - - - - -
Field - Type - Size - Description -
txid - uint256 - 32 - txid/hash of the transaction -
sig - BLSSig - 96 - Recovered signature from the signing request/session -
+| Field | Type | Size | Description | +|-|-|-|-| +| txid | uint256 | 32 | Transaction id (hash of the transaction) +| sig | BLSSig | 96 | Recovered signature from the signing request/session From 97fe53220d3538563478e8de7750a4a03a124709 Mon Sep 17 00:00:00 2001 From: thephez Date: Mon, 2 Aug 2021 16:36:13 -0400 Subject: [PATCH 04/17] docs: clarification --- deterministic-instantsend.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/deterministic-instantsend.md b/deterministic-instantsend.md index 736c9104..9507bfa9 100644 --- a/deterministic-instantsend.md +++ b/deterministic-instantsend.md @@ -56,9 +56,9 @@ Nodes receiving "islock" messages should verify them by using the above steps. O When a masternode receives a recovered signature for a signing request in the quorum where it is active, it should use the signature to create a new p2p message, which is the `ISDLOCK` message. To figure out the cycle hash, take the quorum hash corresponding to the LLMQ that created the recovered signature. Then find the last known block where this quorum was responsible for signing the "islock" message. Often this is the current block, but in rare situations it might be a prior one if quorums have just cycled. From this last known block, find the first block of that cycle. This is the last block before quorums changed for the quorum type used for "islock" messages. -It is possible that a quorum is active before and after quorum cycling. It is also possible that the quorum responsible for a signing request before and after cycling is the same. This could lead to the creation of two "islock" messages, distinct only by the fact that their cycle hash is different. +It is possible that a quorum is active before and after quorum cycling. It is also possible that the quorum responsible for a signing request before and after cycling is the same. This could lead to the creation of two `islock` messages, distinct only by the fact that their cycle hash is different. -The new message has the following structure: +The new message has the following structure (fields in bold are not present in the previously used `islock` message): | Field | Type | Size | Description | |-|-|-|-| @@ -66,7 +66,7 @@ The new message has the following structure: | inputCount | compactSize uint | 1 - 9 | Number of inputs in the transaction | | inputs | COutpoint[] | `inputCount` * 36 | Inputs of the transaction. COutpoint is a uint256 (hash of previous transaction) and a uint32 (output index) | | txid | uint256 | 32 | Transaction id (hash of the transaction) | -| **cycleHash** | uint256 | 32 | Block hash of first block of the cycle in which the quorum signing this `islock` is active +| **cycleHash** | uint256 | 32 | Block hash of first block of the cycle in which the quorum signing this `islock` is active | | sig | BLSSig | 96 | Recovered signature from the signing request/session | ### **Choosing the active LLMQ to perform signing** From cab9a73720e785b6ebf20a8895a05bafba3ec4da Mon Sep 17 00:00:00 2001 From: thephez Date: Mon, 2 Aug 2021 16:36:43 -0400 Subject: [PATCH 05/17] docs: formatting and wording --- deterministic-instantsend.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/deterministic-instantsend.md b/deterministic-instantsend.md index 9507bfa9..17405c44 100644 --- a/deterministic-instantsend.md +++ b/deterministic-instantsend.md @@ -26,9 +26,9 @@ LLMQ based InstantSend was introduced in DIP10. In that implementation InstantSe ## Versioning of ISLock messages -Since "islock" messages were never versioned, a new message “ISDLock” will be created and the "islock" message will be deprecated. ISD stands for InstantSend Deterministic. The version of the ISDLock used in this document will be 1. We will still refer to "islock" messages, even though the message name has been changed. +Since `islock` messages were never versioned, a new `ISDLOCK` message will be created and the `islock` message will be deprecated. ISD stands for InstantSend Deterministic. The version of the `ISDLOCK` used in this document will be 1. We will still refer to `islock` messages, even though the message name has been changed. -The “messageHash” for "islock" messages should now be calculated as `SHA256(version, txHash).` +The `messageHash` for `islock` messages should now be calculated as `SHA256(version, txHash).` ## QuorumHash vs CycleHash @@ -36,25 +36,25 @@ The naive approach to fixing this problem would be to include the QuorumHash in A quorum cycle begins at a `quorumBlock` (as per [DIP-0006](https://github.com/dashpay/dips/blob/master/dip-0006.md#parametersvariables-of-a-llmq-and-dkg)) and lasts for a number of blocks that is equal to the `quorumDkgInterval`. During this time the set of valid quorums are not modified for a given quorum type. If the `quorumDkgInterval` is set to 24 blocks then from block 100 to block 124 quorums of that type stay the same. During this period the quorum that is in charge of signing a specific `islock` will also always be the same. CycleHash is the `blockHash` of the first block in a cycle. -By adding the CycleHash to the "islock" message, any node can follow the steps required to determine the appropriate quorumHash and verify the signature. +By adding the CycleHash to the `islock` message, any node can follow the steps required to determine the appropriate `quorumHash` and verify the signature. ## Verification of the signature -To calculate which LLMQ was responsible for the "islock" the verifier should perform the following: +To calculate which LLMQ was responsible for the `islock` the verifier should perform the following: -1. Take the LLMQ set that corresponds to the quorum cycle defined by cycle hash in the "islock" message. -2. Calculate the RequestID from data in the "islock" message by calculating `SHA256("islock", inputCount, prevTxHash1, prevTxOut1, prevTxHash2, prevTxOut2, ...)` +1. Take the LLMQ set that corresponds to the quorum cycle defined by the cycle hash in the `islock` message +2. Calculate the RequestID from data in the `islock` message by calculating `SHA256("islock", inputCount, prevTxHash1, prevTxOut1, prevTxHash2, prevTxOut2, ...)` 3. For each LLMQ of this quorum cycle’s set, calculate `SHA256(quorumType, quorumHash, requestId)` 4. Sort the list of LLMQs based on the result of step 3 in ascending order 5. Use the first entry of the sorted list as the responsible LLMQ 6. Create the SignID by calculating `SHA256(quorumHash, requestId, SHA256(version, txHash))` 7. Use the public key of responsible LLMQ and verify the signature against the SignID -Nodes receiving "islock" messages should verify them by using the above steps. Only `ISDLOCK` messages with valid signatures should be propagated further using the inventory system. +Nodes receiving `islock` messages should verify them by using the above steps. Only `ISDLOCK` messages with valid signatures should be propagated further using the inventory system. ## The new ISDLock message -When a masternode receives a recovered signature for a signing request in the quorum where it is active, it should use the signature to create a new p2p message, which is the `ISDLOCK` message. To figure out the cycle hash, take the quorum hash corresponding to the LLMQ that created the recovered signature. Then find the last known block where this quorum was responsible for signing the "islock" message. Often this is the current block, but in rare situations it might be a prior one if quorums have just cycled. From this last known block, find the first block of that cycle. This is the last block before quorums changed for the quorum type used for "islock" messages. +When a masternode receives a recovered signature for a signing request in the quorum where it is active, it should use the signature to create a new p2p message, which is the `ISDLOCK` message. To figure out the cycle hash, take the quorum hash corresponding to the LLMQ that created the recovered signature. Then find the last known block where this quorum was responsible for signing the `islock` message. Often this is the current block, but in rare situations it might be a prior one if quorums have just cycled. From this last known block, find the first block of that cycle. This is the last block before quorums changed for the quorum type used for `islock` messages. It is possible that a quorum is active before and after quorum cycling. It is also possible that the quorum responsible for a signing request before and after cycling is the same. This could lead to the creation of two `islock` messages, distinct only by the fact that their cycle hash is different. From 682c9e8994bda8ee8a28a55ddd12832f4b667b1b Mon Sep 17 00:00:00 2001 From: thephez Date: Mon, 2 Aug 2021 16:51:45 -0400 Subject: [PATCH 06/17] chore: formatting --- deterministic-instantsend.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/deterministic-instantsend.md b/deterministic-instantsend.md index 17405c44..a1dc01d3 100644 --- a/deterministic-instantsend.md +++ b/deterministic-instantsend.md @@ -32,11 +32,11 @@ The `messageHash` for `islock` messages should now be calculated as `SHA256(vers ## QuorumHash vs CycleHash -The naive approach to fixing this problem would be to include the QuorumHash in the `islock` message. An `islock` would then be easily verifiable since the quorum that signed it would always be known. The drawback of this approach is that any quorum could sign any `islock` even if it were not responsible to do so for that quorum cycle. +The naive approach to fixing this problem would be to include the `quorumHash` in the `islock` message. An `islock` would then be easily verifiable since the quorum that signed it would always be known. The drawback of this approach is that any quorum could sign any `islock` even if it were not responsible to do so for that quorum cycle. -A quorum cycle begins at a `quorumBlock` (as per [DIP-0006](https://github.com/dashpay/dips/blob/master/dip-0006.md#parametersvariables-of-a-llmq-and-dkg)) and lasts for a number of blocks that is equal to the `quorumDkgInterval`. During this time the set of valid quorums are not modified for a given quorum type. If the `quorumDkgInterval` is set to 24 blocks then from block 100 to block 124 quorums of that type stay the same. During this period the quorum that is in charge of signing a specific `islock` will also always be the same. CycleHash is the `blockHash` of the first block in a cycle. +A quorum cycle begins at a `quorumBlock` (as per [DIP-0006](https://github.com/dashpay/dips/blob/master/dip-0006.md#parametersvariables-of-a-llmq-and-dkg)) and lasts for a number of blocks that is equal to the `quorumDkgInterval`. During this time the set of valid quorums are not modified for a given `quorumType`. If the `quorumDkgInterval` is set to 24 blocks then from block 100 to block 124 quorums of that type stay the same. During this period the quorum that is in charge of signing a specific `islock` will also always be the same. CycleHash is the `blockHash` of the first block in a cycle. -By adding the CycleHash to the `islock` message, any node can follow the steps required to determine the appropriate `quorumHash` and verify the signature. +By adding the `cycleHash` to the `islock` message, any node can follow the steps required to determine the appropriate `quorumHash` and verify the signature. ## Verification of the signature From 34d8217076bb448be75cb10b78d382f0c31c009e Mon Sep 17 00:00:00 2001 From: thephez Date: Tue, 3 Aug 2021 13:29:39 -0400 Subject: [PATCH 07/17] docs: minor cleanup --- deterministic-instantsend.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/deterministic-instantsend.md b/deterministic-instantsend.md index a1dc01d3..3a903952 100644 --- a/deterministic-instantsend.md +++ b/deterministic-instantsend.md @@ -16,7 +16,7 @@ This DIP aims to improve InstantSend messages to make them deterministically ver ## Motivation -LLMQ based InstantSend was introduced in DIP10. In that implementation InstantSend locks are only verifiable by recent quorums, because the InstantSend lock does not include any block or time based information. In Dash Platform InstantSend Locks are used to add credit to Identities as they provide input finality. When blocks are replayed on the Platform Chain, all State Transitions need to be re-validated and it is possible that InstantSend signatures will need to be rechecked. However, to recheck them one needs to know the quorum that signed them. In this DIP we will provide a mechanism to that end. +LLMQ based InstantSend was introduced in DIP10. In that implementation InstantSend locks are only verifiable by recent quorums because the InstantSend lock does not include any block or time based information. In Dash Platform InstantSend Locks are used to add credit to Identities as they provide input finality. When blocks are replayed on the Platform Chain, all State Transitions need to be re-validated and it is possible that InstantSend signatures will need to be rechecked. However, to recheck them one needs to know the quorum that signed them. In this DIP we will provide a mechanism to that end. ## Previous work @@ -26,7 +26,7 @@ LLMQ based InstantSend was introduced in DIP10. In that implementation InstantSe ## Versioning of ISLock messages -Since `islock` messages were never versioned, a new `ISDLOCK` message will be created and the `islock` message will be deprecated. ISD stands for InstantSend Deterministic. The version of the `ISDLOCK` used in this document will be 1. We will still refer to `islock` messages, even though the message name has been changed. +Since `islock` messages were never versioned, a new `ISDLOCK` message will be created and the `islock` message will be deprecated. ISD stands for InstantSend Deterministic. The version of the `ISDLOCK` used in this document will be `1`. We will still refer to `islock` messages, even though the message name has been changed. The `messageHash` for `islock` messages should now be calculated as `SHA256(version, txHash).` @@ -40,7 +40,7 @@ By adding the `cycleHash` to the `islock` message, any node can follow the steps ## Verification of the signature -To calculate which LLMQ was responsible for the `islock` the verifier should perform the following: +To calculate which LLMQ was responsible for the `islock`, the verifier should perform the following: 1. Take the LLMQ set that corresponds to the quorum cycle defined by the cycle hash in the `islock` message 2. Calculate the RequestID from data in the `islock` message by calculating `SHA256("islock", inputCount, prevTxHash1, prevTxOut1, prevTxHash2, prevTxOut2, ...)` @@ -48,7 +48,7 @@ To calculate which LLMQ was responsible for the `islock` the verifier should per 4. Sort the list of LLMQs based on the result of step 3 in ascending order 5. Use the first entry of the sorted list as the responsible LLMQ 6. Create the SignID by calculating `SHA256(quorumHash, requestId, SHA256(version, txHash))` -7. Use the public key of responsible LLMQ and verify the signature against the SignID +7. Use the public key of the responsible LLMQ and verify the signature against the SignID Nodes receiving `islock` messages should verify them by using the above steps. Only `ISDLOCK` messages with valid signatures should be propagated further using the inventory system. From 2714d27c7878d52227e25a529cab8dfcd7e2d6d8 Mon Sep 17 00:00:00 2001 From: thephez Date: Tue, 3 Aug 2021 15:00:13 -0400 Subject: [PATCH 08/17] docs: wrap at 100 chars --- deterministic-instantsend.md | 57 ++++++++++++++++++++++++++++-------- 1 file changed, 45 insertions(+), 12 deletions(-) diff --git a/deterministic-instantsend.md b/deterministic-instantsend.md index 3a903952..75b31609 100644 --- a/deterministic-instantsend.md +++ b/deterministic-instantsend.md @@ -16,7 +16,13 @@ This DIP aims to improve InstantSend messages to make them deterministically ver ## Motivation -LLMQ based InstantSend was introduced in DIP10. In that implementation InstantSend locks are only verifiable by recent quorums because the InstantSend lock does not include any block or time based information. In Dash Platform InstantSend Locks are used to add credit to Identities as they provide input finality. When blocks are replayed on the Platform Chain, all State Transitions need to be re-validated and it is possible that InstantSend signatures will need to be rechecked. However, to recheck them one needs to know the quorum that signed them. In this DIP we will provide a mechanism to that end. +LLMQ based InstantSend was introduced in DIP10. In that implementation InstantSend locks are only +verifiable by recent quorums because the InstantSend lock does not include any block or time based +information. In Dash Platform InstantSend Locks are used to add credit to Identities as they provide +input finality. When blocks are replayed on the Platform Chain, all State Transitions need to be +re-validated and it is possible that InstantSend signatures will need to be rechecked. However, to +recheck them one needs to know the quorum that signed them. In this DIP we will provide a mechanism +to that end. ## Previous work @@ -26,39 +32,64 @@ LLMQ based InstantSend was introduced in DIP10. In that implementation InstantSe ## Versioning of ISLock messages -Since `islock` messages were never versioned, a new `ISDLOCK` message will be created and the `islock` message will be deprecated. ISD stands for InstantSend Deterministic. The version of the `ISDLOCK` used in this document will be `1`. We will still refer to `islock` messages, even though the message name has been changed. +Since `islock` messages were never versioned, a new `ISDLOCK` message will be created and the +`islock` message will be deprecated. ISD stands for InstantSend Deterministic. The version of the +`ISDLOCK` used in this document will be `1`. We will still refer to `islock` messages, even though +the message name has been changed. The `messageHash` for `islock` messages should now be calculated as `SHA256(version, txHash).` ## QuorumHash vs CycleHash -The naive approach to fixing this problem would be to include the `quorumHash` in the `islock` message. An `islock` would then be easily verifiable since the quorum that signed it would always be known. The drawback of this approach is that any quorum could sign any `islock` even if it were not responsible to do so for that quorum cycle. +The naive approach to fixing this problem would be to include the `quorumHash` in the `islock` +message. An `islock` would then be easily verifiable since the quorum that signed it would always be +known. The drawback of this approach is that any quorum could sign any `islock` even if it were not +responsible to do so for that quorum cycle. -A quorum cycle begins at a `quorumBlock` (as per [DIP-0006](https://github.com/dashpay/dips/blob/master/dip-0006.md#parametersvariables-of-a-llmq-and-dkg)) and lasts for a number of blocks that is equal to the `quorumDkgInterval`. During this time the set of valid quorums are not modified for a given `quorumType`. If the `quorumDkgInterval` is set to 24 blocks then from block 100 to block 124 quorums of that type stay the same. During this period the quorum that is in charge of signing a specific `islock` will also always be the same. CycleHash is the `blockHash` of the first block in a cycle. +A quorum cycle begins at a `quorumBlock` (as per +[DIP-0006](https://github.com/dashpay/dips/blob/master/dip-0006.md#parametersvariables-of-a-llmq-and-dkg)) +and lasts for a number of blocks that is equal to the `quorumDkgInterval`. During this time the set +of valid quorums are not modified for a given `quorumType`. If the `quorumDkgInterval` is set to 24 +blocks then from block 100 to block 124 quorums of that type stay the same. During this period the +quorum that is in charge of signing a specific `islock` will also always be the same. CycleHash is +the `blockHash` of the first block in a cycle. -By adding the `cycleHash` to the `islock` message, any node can follow the steps required to determine the appropriate `quorumHash` and verify the signature. +By adding the `cycleHash` to the `islock` message, any node can follow the steps required to +determine the appropriate `quorumHash` and verify the signature. ## Verification of the signature To calculate which LLMQ was responsible for the `islock`, the verifier should perform the following: -1. Take the LLMQ set that corresponds to the quorum cycle defined by the cycle hash in the `islock` message -2. Calculate the RequestID from data in the `islock` message by calculating `SHA256("islock", inputCount, prevTxHash1, prevTxOut1, prevTxHash2, prevTxOut2, ...)` +1. Take the LLMQ set that corresponds to the quorum cycle defined by the cycle hash in the `islock` + message +2. Calculate the RequestID from data in the `islock` message by calculating `SHA256("islock", + inputCount, prevTxHash1, prevTxOut1, prevTxHash2, prevTxOut2, ...)` 3. For each LLMQ of this quorum cycle’s set, calculate `SHA256(quorumType, quorumHash, requestId)` 4. Sort the list of LLMQs based on the result of step 3 in ascending order 5. Use the first entry of the sorted list as the responsible LLMQ 6. Create the SignID by calculating `SHA256(quorumHash, requestId, SHA256(version, txHash))` 7. Use the public key of the responsible LLMQ and verify the signature against the SignID -Nodes receiving `islock` messages should verify them by using the above steps. Only `ISDLOCK` messages with valid signatures should be propagated further using the inventory system. +Nodes receiving `islock` messages should verify them by using the above steps. Only `ISDLOCK` +messages with valid signatures should be propagated further using the inventory system. ## The new ISDLock message -When a masternode receives a recovered signature for a signing request in the quorum where it is active, it should use the signature to create a new p2p message, which is the `ISDLOCK` message. To figure out the cycle hash, take the quorum hash corresponding to the LLMQ that created the recovered signature. Then find the last known block where this quorum was responsible for signing the `islock` message. Often this is the current block, but in rare situations it might be a prior one if quorums have just cycled. From this last known block, find the first block of that cycle. This is the last block before quorums changed for the quorum type used for `islock` messages. +When a masternode receives a recovered signature for a signing request in the quorum where it is +active, it should use the signature to create a new p2p message, which is the `ISDLOCK` message. To +figure out the cycle hash, take the quorum hash corresponding to the LLMQ that created the recovered +signature. Then find the last known block where this quorum was responsible for signing the `islock` +message. Often this is the current block, but in rare situations it might be a prior one if quorums +have just cycled. From this last known block, find the first block of that cycle. This is the last +block before quorums changed for the quorum type used for `islock` messages. -It is possible that a quorum is active before and after quorum cycling. It is also possible that the quorum responsible for a signing request before and after cycling is the same. This could lead to the creation of two `islock` messages, distinct only by the fact that their cycle hash is different. +It is possible that a quorum is active before and after quorum cycling. It is also possible that the +quorum responsible for a signing request before and after cycling is the same. This could lead to +the creation of two `islock` messages, distinct only by the fact that their cycle hash is different. -The new message has the following structure (fields in bold are not present in the previously used `islock` message): +The new message has the following structure (fields in bold are not present in the previously used +`islock` message): | Field | Type | Size | Description | |-|-|-|-| @@ -71,7 +102,9 @@ The new message has the following structure (fields in bold are not present in t ### **Choosing the active LLMQ to perform signing** -Choosing the active LLMQ to perform signing should follow the same steps as defined in [DIP-0007 - Choosing the active LLMQ to perform signing](https://github.com/dashpay/dips/blob/master/dip-0007.md#choosing-the-active-llmq-to-perform-signing). +Choosing the active LLMQ to perform signing should follow the same steps as defined in [DIP-0007 - +Choosing the active LLMQ to perform +signing](https://github.com/dashpay/dips/blob/master/dip-0007.md#choosing-the-active-llmq-to-perform-signing). | Field | Type | Size | Description | |-|-|-|-| From 8ea72cd5b2a4f51fb829987d2debf2eef8b5b9a1 Mon Sep 17 00:00:00 2001 From: thephez Date: Tue, 3 Aug 2021 15:09:42 -0400 Subject: [PATCH 09/17] docs: title adjustment --- deterministic-instantsend.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/deterministic-instantsend.md b/deterministic-instantsend.md index 75b31609..81acde2e 100644 --- a/deterministic-instantsend.md +++ b/deterministic-instantsend.md @@ -1,6 +1,6 @@ 
 DIP: 00xx
-Title: Making InstantSend Deterministic with use of Quorum Cycles
+Title: Making InstantSend Deterministic using Quorum Cycles
 Author: Samuel Westrich, UdjinM6
 Special-Thanks: Thephez, Virgile Bartolo
 Comments: No comments yet.

From a23cd7f85431f425e647bc6c0ea3e01f8dd80dfa Mon Sep 17 00:00:00 2001
From: thephez 
Date: Tue, 31 Aug 2021 13:42:23 -0400
Subject: [PATCH 10/17] docs: remove extraneous table

---
 deterministic-instantsend.md | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/deterministic-instantsend.md b/deterministic-instantsend.md
index 81acde2e..d3aeb050 100644
--- a/deterministic-instantsend.md
+++ b/deterministic-instantsend.md
@@ -105,8 +105,3 @@ The new message has the following structure (fields in bold are not present in t
 Choosing the active LLMQ to perform signing should follow the same steps as defined in [DIP-0007 -
 Choosing the active LLMQ to perform
 signing](https://github.com/dashpay/dips/blob/master/dip-0007.md#choosing-the-active-llmq-to-perform-signing).
-
-| Field | Type | Size | Description |
-|-|-|-|-|
-| txid | uint256 | 32 | Transaction id (hash of the transaction)
-| sig | BLSSig | 96 | Recovered signature from the signing request/session

From 9ecdcc3adce0475ad0ac9c9b3578f2ae6030e879 Mon Sep 17 00:00:00 2001
From: thephez 
Date: Thu, 7 Oct 2021 13:16:46 -0400
Subject: [PATCH 11/17] Update deterministic-instantsend.md

---
 deterministic-instantsend.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/deterministic-instantsend.md b/deterministic-instantsend.md
index d3aeb050..7bb6d543 100644
--- a/deterministic-instantsend.md
+++ b/deterministic-instantsend.md
@@ -37,7 +37,6 @@ Since `islock` messages were never versioned, a new `ISDLOCK` message will be cr
 `ISDLOCK` used in this document will be `1`. We will still refer to `islock` messages, even though
 the message name has been changed.
 
-The `messageHash` for `islock` messages should now be calculated as `SHA256(version, txHash).`
 
 ## QuorumHash vs CycleHash
 

From 8373f3ac55396db967185775cc13f834902ab386 Mon Sep 17 00:00:00 2001
From: thephez 
Date: Thu, 7 Oct 2021 13:17:14 -0400
Subject: [PATCH 12/17] Update deterministic-instantsend.md

---
 deterministic-instantsend.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/deterministic-instantsend.md b/deterministic-instantsend.md
index 7bb6d543..f1a6ce81 100644
--- a/deterministic-instantsend.md
+++ b/deterministic-instantsend.md
@@ -37,7 +37,6 @@ Since `islock` messages were never versioned, a new `ISDLOCK` message will be cr
 `ISDLOCK` used in this document will be `1`. We will still refer to `islock` messages, even though
 the message name has been changed.
 
-
 ## QuorumHash vs CycleHash
 
 The naive approach to fixing this problem would be to include the `quorumHash` in the `islock`

From e3a31e56c89d7af2cd5d4ad1d8fe4dd04ba0763e Mon Sep 17 00:00:00 2001
From: thephez 
Date: Mon, 11 Oct 2021 09:06:13 -0400
Subject: [PATCH 13/17] fix: change SignID calculation to match current

---
 deterministic-instantsend.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/deterministic-instantsend.md b/deterministic-instantsend.md
index f1a6ce81..f0755e76 100644
--- a/deterministic-instantsend.md
+++ b/deterministic-instantsend.md
@@ -66,7 +66,7 @@ To calculate which LLMQ was responsible for the `islock`, the verifier should pe
 3. For each LLMQ of this quorum cycle’s set, calculate `SHA256(quorumType, quorumHash, requestId)`
 4. Sort the list of LLMQs based on the result of step 3 in ascending order
 5. Use the first entry of the sorted list as the responsible LLMQ
-6. Create the SignID by calculating `SHA256(quorumHash, requestId, SHA256(version, txHash))`
+6. Create the SignID by calculating `SHA256(quorumHash, requestId, txHash)`
 7. Use the public key of the responsible LLMQ and verify the signature against the SignID
 
 Nodes receiving `islock` messages should verify them by using the above steps. Only `ISDLOCK`

From bc36b711c1a8b49897cc6634d5672b846cf12224 Mon Sep 17 00:00:00 2001
From: thephez 
Date: Mon, 11 Oct 2021 09:12:01 -0400
Subject: [PATCH 14/17] docs: set DIP number

---
 deterministic-instantsend.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/deterministic-instantsend.md b/deterministic-instantsend.md
index f0755e76..f022b3a5 100644
--- a/deterministic-instantsend.md
+++ b/deterministic-instantsend.md
@@ -1,5 +1,5 @@
 
-DIP: 00xx
+DIP: 0022
 Title: Making InstantSend Deterministic using Quorum Cycles
 Author: Samuel Westrich, UdjinM6
 Special-Thanks: Thephez, Virgile Bartolo

From d23f4979e578f205a8d5be7e6f3821c2cfd4bad8 Mon Sep 17 00:00:00 2001
From: thephez 
Date: Mon, 11 Oct 2021 09:19:38 -0400
Subject: [PATCH 15/17] docs: rename file to match DIP number and add to the
 Readme

---
 README.md                                   | 1 +
 deterministic-instantsend.md => dip-0022.md | 0
 2 files changed, 1 insertion(+)
 rename deterministic-instantsend.md => dip-0022.md (100%)

diff --git a/README.md b/README.md
index d6a7b579..5d84c7b3 100644
--- a/README.md
+++ b/README.md
@@ -35,6 +35,7 @@ Number | Layer | Title | Owner | Type | Status
 [16](dip-0016.md) | Applications | Headers First Synchronization on Simple Payment Verification Wallets | Samuel Westrich | Informational | Proposed
 [20](dip-0020.md) | Consensus | Dash Opcode Updates | Mart Mangus | Standard | Proposed
 [21](dip-0021.md) | Consensus | LLMQ DKG Data Sharing | dustinface | Standard | Proposed
+[22](dip-0022.md) | Consensus | Making InstantSend Deterministic using Quorum Cycles | Samuel Westrich, UdjinM6 | Standard | Proposed
 [23](dip-0023.md) | Consensus | Enhanced Hard Fork Mechanism | Pasta | Standard | Proposed
 
 ## License
diff --git a/deterministic-instantsend.md b/dip-0022.md
similarity index 100%
rename from deterministic-instantsend.md
rename to dip-0022.md

From 5969c7e4fe1af7bc664920779aa2f583cbf09066 Mon Sep 17 00:00:00 2001
From: thephez 
Date: Mon, 11 Oct 2021 14:52:39 -0400
Subject: [PATCH 16/17] Update dip-0022.md

Co-authored-by: gabriel-bjg 
---
 dip-0022.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dip-0022.md b/dip-0022.md
index f022b3a5..4f2c2bd7 100644
--- a/dip-0022.md
+++ b/dip-0022.md
@@ -48,7 +48,7 @@ A quorum cycle begins at a `quorumBlock` (as per
 [DIP-0006](https://github.com/dashpay/dips/blob/master/dip-0006.md#parametersvariables-of-a-llmq-and-dkg))
 and lasts for a number of blocks that is equal to the `quorumDkgInterval`. During this time the set
 of valid quorums are not modified for a given `quorumType`. If the `quorumDkgInterval` is set to 24
-blocks then from block 100 to block 124 quorums of that type stay the same. During this period the
+blocks then from block 100 to block 123 quorums of that type stay the same. During this period the
 quorum that is in charge of signing a specific `islock` will also always be the same. CycleHash is
 the `blockHash` of the first block in a cycle.
 

From 76753858e0d8b78d8e8aa06963a53d7687ce076a Mon Sep 17 00:00:00 2001
From: thephez 
Date: Thu, 21 Oct 2021 16:32:40 -0400
Subject: [PATCH 17/17] fix: correct Readme change

---
 README.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.md b/README.md
index 5d84c7b3..56627dff 100644
--- a/README.md
+++ b/README.md
@@ -33,8 +33,8 @@ Number | Layer | Title | Owner | Type | Status
 [14](dip-0014.md) | Applications | Extended Key Derivation using 256-Bit Unsigned Integers | Samuel Westrich | Informational | Proposed
 [15](dip-0015.md) | Applications | DashPay | Samuel Westrich, Eric Britten | Standard | Proposed
 [16](dip-0016.md) | Applications | Headers First Synchronization on Simple Payment Verification Wallets | Samuel Westrich | Informational | Proposed
-[20](dip-0020.md) | Consensus | Dash Opcode Updates | Mart Mangus | Standard | Proposed
-[21](dip-0021.md) | Consensus | LLMQ DKG Data Sharing | dustinface | Standard | Proposed
+[20](dip-0020.md) | Consensus | Dash Opcode Updates | Mart Mangus | Standard | Final
+[21](dip-0021.md) | Consensus | LLMQ DKG Data Sharing | dustinface | Standard | Final
 [22](dip-0022.md) | Consensus | Making InstantSend Deterministic using Quorum Cycles | Samuel Westrich, UdjinM6 | Standard | Proposed
 [23](dip-0023.md) | Consensus | Enhanced Hard Fork Mechanism | Pasta | Standard | Proposed