Multiple updates regarding LLMQs (#42)

* Add description of new LLMQ merkle roots to DIP4

* Rename deletedMNcount -> deletedMNsCount

* Add quorumType to parameter description and DIP6 P2P messages

* Remove quorumMinMemberAge from parameter description

This was never implemented

* Rename badVotesThreshold -> quorumDkgBadVotesThreshold

* Update testing LLMQ type to LLMQ_5_60

* Better describe active LLMQs in DIP6 and DIP7

* Bump CbTx version

* Handle review comments
This commit is contained in:
Alexander Block 2019-04-29 14:20:26 +02:00 committed by thephez
parent 60ade37fee
commit 745adcee3f
4 changed files with 75 additions and 10 deletions

View file

@ -69,13 +69,14 @@ We will refer to these parameters and variables multiple times in the following
| Parameter | Description |
|--|--|
| quorumType | An unsigned 8 bit integer identifying the LLMQ type |
| quorumSize | The size of the quorum, e.g. 10, 200 or 400. This parameter has the highest influence on the performance of the DKG. A small DKG for a small LLMQ can be performed in a few seconds, while a large LLMQ can take more than a hour to complete. This is identical to the “n” in m-of-n. |
| quorumMinSize | Minimum number of valid members for quorum to be considered valid after the DKG has removed bad members. |
| quorumThreshold | The minimum number of threshold signature shares required to recover a threshold signature. It also influences the DKG as it is the minimum number of valid members to create a valid premature commitment and final commitment. This value should be at least 51% of the quorumSize. This is identical to the “m” in m-of-n. |
| quorumMinMemberAge | Minimum number of blocks a deterministic masternode must be confirmed on-chain before it is considered as a LLMQ member |
| quorumDkgInterval | The number of blocks between two DKG sessions. If set to 576 for example, a new DKG session will start once per day. |
| quorumDkgPhaseBlocks | Number of blocks a single DKG phase is active. It must be high enough to allow all members to exchange all required messages. It must also be high enough to take block time variances into account. |
| badVotesThreshold | Threshold for votes on bad members. If >=badVotesThreshold members have voted on another member to be bad, that member is also considered bad locally. |
| quorumDkgBadVotesThreshold | Threshold for votes on bad members. If >=badVotesThreshold members have voted on another member to be bad, that member is also considered bad locally. |
| quorumSigningActiveQuorumCount | Maximum number of LLMQs in the active LLMQs set |
List of variables per DKG session:
@ -179,6 +180,7 @@ The internal Dash message name is `qcontrib` and the format of the message is:
| Field | Type | Size | Description |
|--|--|--|--|
| llmqType | uint8_t | 1 | The LLMQ type
| quorumHash | uint256 | 32 | The quorum identifier
| proTxHash | uint256 | 32 | The proTxHash of the contributing member
| vvecSize | compactSize uint | 1-9 | The size of the verification vector
@ -220,6 +222,7 @@ The internal Dash message name is `qcomplaint` and the format of the message is:
| Field | Type | Size | Description |
|--|--|--|--|
| llmqType | uint8_t | 1 | The LLMQ type
| quorumHash | uint256 | 32 | The quorum identifier
| proTxHash | uint256 | 32 | The proTxHash of the complaining member
| badBitSize | compactSize uint | 1-9 | Number of bits in the bad members bitvector
@ -255,6 +258,7 @@ The internal Dash message name is `qjustify` and the format of the message is:
| Field | Type | Size | Description |
|--|--|--|--|
| llmqType | uint8_t | 1 | The LLMQ type
| quorumHash | uint256 | 32 | The quorum identifier
| proTxHash | uint256 | 32 | The proTxHash of the justifying member
| skContributionsCount | compactSize uint | 1-9 | Number of unencrypted secret key contributions
@ -300,6 +304,7 @@ The internal Dash message name is `qpcommit` and the format of the message is:
| Field | Type | Size | Description |
|--|--|--|--|
| llmqType | uint8_t | 1 | The LLMQ type
| quorumHash | uint256 | 32 | The quorum identifier
| proTxHash | uint256 | 32 | The proTxHash of the committing member
| validMembersSize | compactSize uint | 1-9 | Bit size of the validMembers bitvector
@ -364,7 +369,7 @@ The internal Dash message name is `qfcommit` and the format of the message is:
| 1 | LLMQ_50_60 | 50 | 30 (60%) | 1 Hour | |
| 2 | LLMQ_400_60 | 400 | 240 (60%) | 12 Hours | |
| 3 | LLMQ_400_85 | 400 | 340 (85%) | 24 Hours | |
| 100 | LLMQ_10_60 | 10 | 6 (60%) | 1 Hour | For testing only |
| 100 | LLMQ_5_60 | 5 | 3 (60%) | 1 Hour | For testing only |
### 7. Mining phase
@ -399,10 +404,17 @@ The format of the "quorum commitment" special TX payload with type=6 is:
| height | uint32_t | 4 | The height of the block in which this commitment is included
| commitment | qfcommit | Variable | This equals the payload of the "qfcommit" P2P message
## Activated LLMQs and threshold signing
## Active LLMQ sets
After a DKG finishes and the final commitment has been mined, a LLMQ becomes active and can start participating in signing requests/sessions.
The set of currently active LLMQs is a limited list with a maximum size of "quorumSigningActiveQuorumCount". When the active
set reaches the maximum size, the oldest entry is removed each time a new LLMQ becomes active.
A merkle root of all active LLMQ sets is calculated and included into [DIP4 CbTx](https://github.com/dashpay/dips/blob/master/dip-0004.md) with version >= 2.
## Signing sessions/requests
The details of the signing process are handled in [DIP007](https://github.com/dashpay/dips/blob/master/dip-0007.md). The individual use cases for LLMQs are handled in specialized DIPs.
## Copyright