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

A few (mostly trivial) updates (#54)

Browse source 
* Drop quorumMinMemberAge from LLMQ init phase

* Clarify that "hash" is "SHA256" in multiple cases

* Switch few quotes to apostrophes
This commit is contained in:
UdjinM6 2019-11-11 15:59:14 +03:00 • committed by thephez
parent 5660fcdd27
commit 41fc2c9413
6 changed files with 27 additions and 28 deletions
Download patch file Download diff file Expand all files Collapse all files

10
dip-0003.md
View file

@ -93,7 +93,7 @@ P2PK/P2PKH/P2SH script, `<payoutStr>` must be set to the hex representation of t
3. `<operatorReward>`: The operatorReward field of the ProRegTx.
4. `<ownerKeyAddress>`: The Dash address corresponding to the keyIdOwner field of the ProRegTx.
5. `<votingKeyAddress>`: The Dash address corresponding to the keyIdVoting field of the ProRegTx.
6. `<payloadHash>`: The hash of the ProRegTx payload with the payloadSig being empty.
6. `<payloadHash>`: The SHA256 hash of the ProRegTx payload with the payloadSig being empty.
This signature is only required for external collaterals. If collateralOutpoint refers to an output of the ProRegTx,
the fact that the ProRegTx was able to move the collateral acts as an implicit proof of ownership. In this case the
@ -125,7 +125,7 @@ The transaction consists of the following data in the payload area:
| operatorReward | uint_16 | 2 | A value from 0 to 10000. |
| scriptPayoutSize | compactSize uint | 1-9 | Size of the Payee Script. |
| scriptPayout | Script | Variable | Payee script (p2pkh/p2sh) |
| inputsHash | uint256 | 32 | Hash of all the outpoints of the transaction inputs |
| inputsHash | uint256 | 32 | The SHA256 hash of all the outpoints of the transaction inputs |
| payloadSigSize | compactSize uint | 1-9 | Size of the Signature |
| payloadSig | unsigned char[] | Variable | Signature of the hash of the ProTx fields. Signed with the key corresponding to the collateral outpoint in case the collateral is not part of the ProRegTx itself, empty otherwise. |
@ -159,7 +159,7 @@ The transaction consists of the following data in the payload area:
| port | uint_16 | 2 | Port (network byte order) |
| scriptOperatorPayoutSize | compactSize uint | 1-9 | Size of the Payee Script. |
| scriptOperatorPayout | Script | Variable | Payee script (p2pkh/p2sh) |
| inputsHash | uint256 | 32 | Hash of all the outpoints of the transaction inputs |
| inputsHash | uint256 | 32 | The SHA256 hash of all the outpoints of the transaction inputs |
| payloadSig | BLSSig | 96 | Signature of the hash of the ProUpServTx fields. Signed by the Operator. |
### Updating Registrar of Masternode (ProUpRegTx)
@ -181,7 +181,7 @@ The transaction consists of the following data in the payload area:
| KeyIdVoting | CKeyID | 20 | The public key hash used for voting. |
| scriptPayoutSize | compactSize uint | 1-9 | Size of the Payee Script. |
| scriptPayout | Script | Variable | Payee script (p2pkh/p2sh) |
| inputsHash | uint256 | 32 | Hash of all the outpoints of the transaction inputs |
| inputsHash | uint256 | 32 | The SHA256 hash of all the outpoints of the transaction inputs |
| payloadSigSize | compactSize uint | 1-9 | Size of the Signature |
| payloadSig | unsigned char[] | Variable | Signature of the hash of the ProTx fields. Signed by the Owner. |
@ -202,7 +202,7 @@ The transaction consists of the following data in the payload area:
| version | uint_16 | 2 | ProUpRevTx version number. Currently set to 1. |
| proTXHash | uint256 | 32 | The hash of the provider transaction |
| reason | uint_16 | 2 | The reason for revoking the key. |
| inputsHash | uint256 | 32 | Hash of all the outpoints of the transaction inputs |
| inputsHash | uint256 | 32 | The SHA256 hash of all the outpoints of the transaction inputs |
| payloadSig | BLSSig | 96 | Signature of the hash of the ProTx fields. Signed by the Operator. |
## Rules for Updating the Masternode List

19
dip-0006.md
View file

@ -140,11 +140,10 @@ Each phase lasts for multiple blocks (quorumDkgPhaseBlocks) to ensure that all m
In this phase, the members of the new quorum are determined. This process is fully deterministic and results in exactly the same list seen by all members and observers.
1. Retrieve the deterministic masternode list which is valid at quorumHeight
2. Remove all entries from the list that are not confirmed on-chain in at least quorumMinMemberAge blocks
3. Calculate hash(proTxHash, quorumHash) for each entry in the list
4. Sort the resulting list by the calculated hashes
5. Take the first quorumSize entries from this list and use the corresponding masternodes as members list
6. Check if our masternode is part of this list. If not, we stop participating in the DKG.
2. Calculate `SHA256(proTxHash, quorumHash)` for each entry in the list
3. Sort the resulting list by the calculated hashes
4. Take the first quorumSize entries from this list and use the corresponding masternodes as members list
5. Check if our masternode is part of this list. If not, we stop participating in the DKG.
After the members list is built, the LLMQ members start to initiate the connections to the deterministic set of quorum connections as described in the “Intra-Quorum Communication” section.
@ -199,7 +198,7 @@ Each receiver of a complaint message must first perform some validation of the m
1. The quorumHash must match the current DKG session
2. The proTxHash must belong to a member of the LLMQ
3. The byte size of the bad members and complaints bitvectors must match “(quorumSize + 7) / 8”
3. The byte size of the bad members and complaints bitvectors must match `(quorumSize + 7) / 8`
4. No out-of-range bits should be set in byte representation of the bad members and complaints bitvectors
5. The signature of the message must be valid and signed with the operator key of the contributing masternode
@ -275,7 +274,7 @@ The quorum verification vector is calculated by aggregating all valid member’s
The member must then create a premature commitment message which contains the quorum public key, the hash of the quorum verification vector and a bitset of the valid members.
The message is not signed as usual, but instead a commitment hash is created and then signed twice, once with the members operator key and once with the calculated threshold secret key share. The commitment hash is “hash(quorumHash, validMembers, quorumPublicKey, quorumVvecHash)”.
The message is not signed as usual, but instead a commitment hash is created and then signed twice, once with the members operator key and once with the calculated threshold secret key share. The commitment hash is `SHA256(quorumHash, validMembers, quorumPublicKey, quorumVvecHash)`.
The operator signature allows other members to verify that the message originated from this member. The threshold signature allows other members to verify that the commitment is valid and that the member successfully calculated his secret key share. Both signatures later also allow to aggregate multiple premature commitments into a final commitment.
@ -283,7 +282,7 @@ Each receiver of a premature commitment message must first perform some basic va
1. The quorumHash must match the current DKG session
2. The proTxHash must belong to a member of the LLMQ
3. The byte size of the validMembers bitvector must match “(quorumSize + 7) / 8”
3. The byte size of the validMembers bitvector must match `(quorumSize + 7) / 8`
4. No out-of-range bits should be set in the byte representation of of the validMembers bitvector
5. The number of set bits in the validMembers bitvector must be at least >= quorumThreshold
6. The sig must validate against the commitmentHash and the committing member’s operator key
@ -311,7 +310,7 @@ The internal Dash message name is `qpcommit` and the format of the message is:
| validMembersSize | compactSize uint | 1-9 | Bit size of the validMembers bitvector
| validMembers | byte[] | (bitSize + 7) / 8 | Bitset of valid members in this commitment
| quorumPublicKey | BLSPubKey | 48 | The quorum public key
| quorumVvecHash | uint256 | 32 | The hash of the quorum verification vector
| quorumVvecHash | uint256 | 32 | The SHA256 hash of the quorum verification vector
| quorumSig | BLSSig | 96 | Threshold signature, signed with the threshold signature share of the committing member
| sig | BLSSig | 96 | BLS signature, signed with the operator key of the contributing masternode
@ -359,7 +358,7 @@ The internal Dash message name is `qfcommit` and the format of the message is:
| validMembersSize | compactSize uint | 1-9 | Bit size of the validMembers bitvector
| validMembers | byte[] | (bitSize + 7) / 8 | Bitset of valid members in this commitment
| quorumPublicKey | BLSPubKey | 48 | The quorum public key
| quorumVvecHash | uint256 | 32 | The hash of the quorum verification vector
| quorumVvecHash | uint256 | 32 | The SHA256 hash of the quorum verification vector
| quorumSig | BLSSig | 96 | Recovered threshold signature
| sig | BLSSig | 96 | Aggregated BLS signatures from all included commitments

4
dip-0006/bls_signature_scheme.md
View file

@ -84,11 +84,11 @@ The following operations are possible in the BLS signature scheme. Inside Dash,
### Sign(secretKey, messageHash, publicKey)
Creates a signature using the secret key and Hash(messageHash, publicKey). Hashing the concatenation of the messageHash and the public key is done to ensure uniqueness of the actually signed message and serves as a protection against the rogue public key attack.
Creates a signature using the secret key and `SHA256(messageHash, publicKey)`. Hashing the concatenation of the messageHash and the public key is done to ensure uniqueness of the actually signed message and serves as a protection against the rogue public key attack.
### Verify(sig, messageHash, publicKey)
Verifies the given signature against the public key and Hash(messageHash, publicKey)..
Verifies the given signature against the public key and `SHA256(messageHash, publicKey)`.
### VerifyAggregated(aggregatedSig, messageHashes, publicKeys)

12
dip-0007.md
View file

@ -51,7 +51,7 @@ The message hash must be supplied along with the requestId. For InstantSend, the
A signing request can only be initiated once and should never be performed multiple times by the same masternode. This in turn results in “one vote per member” on each individual signing request and makes it impossible to have conflicting recovered signatures for the same signing request.
As a result of a (non-conflicting) signing request, the member must create a threshold signature share. It does this by calculating `hash(quorumHash, requestId, messageHash)` and then signing the resulting hash with the members individual threshold secret key share. After signing, the signature share must be propagated to all LLMQ members (explained later).
As a result of a (non-conflicting) signing request, the member must create a threshold signature share. It does this by calculating `SHA256(quorumHash, requestId, messageHash)` and then signing the resulting hash with the members individual threshold secret key share. After signing, the signature share must be propagated to all LLMQ members (explained later).
## Signing session
@ -69,7 +69,7 @@ To calculate which LLMQ is responsible for a signing request, each masternode sh
1. Take the active LLMQ set from 8 blocks before the current chain tip. Active LLMQ sets are described in
[DIP6 - Long-Living Masternode Quorums](https://github.com/dashpay/dips/blob/master/dip-0004.md) section "Active LLMQ sets".
2. For each LLMQ of the active set, calculate `hash(quorumType, quorumHash, requestId)`
2. For each LLMQ of the active set, calculate `SHA256(quorumType, quorumHash, requestId)`
3. Sort the list of LLMQs based on the result of step 2 in ascending order.
4. Use the first entry of the sorted list as the LLMQ to perform the signing request
@ -77,7 +77,7 @@ After the responsible LLMQ is determined, the masternode should check if it is p
## Validating recovered threshold signatures
Each node (including regular nodes) must verify the recovered signatures for each signing session before accepting and relaying them. This can be done by validating the recovered signature and `hash(quorumHash, requestId, messageHash)` against the LLMQ’s quorum public key.
Each node (including regular nodes) must verify the recovered signatures for each signing session before accepting and relaying them. This can be done by validating the recovered signature and `SHA256(quorumHash, requestId, messageHash)` against the LLMQ’s quorum public key.
If this succeeds, the signing request is considered successful. In the InstantSend example, this would mean that a single input of the transaction has been locked.
@ -110,7 +110,7 @@ The internal Dash message name is `qbsigshares` and the format of the message is
|--|--|--|--|
| quorumHash | uint256 | 32 | The quorum identifier |
| id | uint256 | 32 | The signing request id |
| messageHash | uint256 | 32 | The message hash |
| messageHash | uint256 | 32 | The SHA256 hash of the message |
| shareCount | compactSize uint | 1-9 | The number of signature shares in this batch |
| shareMembers | uint32[] | 4 * shareCount | Member indexes of the shares in this batch |
| shareSigs | BLSSig[] | 96 * shareCount | The signature shares |
@ -124,7 +124,7 @@ If a valid recovered threshold signature was already received before enough shar
On receipt of a recovered signature, all nodes should perform the following verification:
1. The `quorumHash` should belong to an active LLMQ
2. The `thresholdSig` should validate against the LLMQ’s quorum public key and `hash(quorumHash, id, messageHash)`.
2. The `thresholdSig` should validate against the LLMQ’s quorum public key and `SHA256(quorumHash, id, messageHash)`.
Propagation of recovered signature shares utilizes the inventory system.
@ -134,7 +134,7 @@ The internal Dash message name is `qsigrec` and the format of the message is:
|--|--|--|--|
| quorumHash | uint256 | 32 | The quorum identifier |
| id | uint256 | 32 | The signing request id |
| messageHash | uint256 | 32 | The message hash |
| messageHash | uint256 | 32 | The SHA256 hash of the message |
| thresholdSig | BLSSig | 96 | The final recovered threshold signature |
## Internal high-level API

6
dip-0008.md
View file

@ -136,7 +136,7 @@ ChainLock is deeper than 6 blocks.
When these checks pass, each masternode must invoke the [DIP0007
`SignIfMember` operation](https://github.com/dashpay/dips/blob/master/dip-0007.md#void-signifmemberuint256-id-uint256-msghash-int-activellmqs).
The request id for the operation is `hash("clsig-attempt", blockHeight, attemptNum)` and the
The request id for the operation is `SHA256("clsig-attempt", blockHeight, attemptNum)` and the
message hash is the hash of the new block (`newBlockHash`). The first time this
is attempted, `attemptNum` must be set to `0`. "clsig-attempt" is a static string that
must be prepended by its length (13, as a compactSize uint).
@ -169,7 +169,7 @@ After a signing attempt has succeeded, another LLMQ must sign the successful
attempt. This is only performed once for each `blockHeight` and thus either
succeeds or fails without performing additional attempts.
The request id is `hash("clsig", blockHeight)` and the message hash is the block hash of the
The request id is `SHA256("clsig", blockHeight)` and the message hash is the block hash of the
previously successful attempt.
After a LLMQ member has successfully recovered the final ChainLocks
@ -190,7 +190,7 @@ announcing it to other nodes:
1. Based on the deterministic masternode list at the given height, a quorum must be
selected that was active at the time this block was mined
2. The signature must verify against the quorum public key and
`hash(llmqType, quorumHash, hash(height), blockHash)`. `llmqType` and `quorumHash`
`SHA256(llmqType, quorumHash, SHA256(height), blockHash)`. `llmqType` and `quorumHash`
must be taken from the quorum selected in 2.

4
dip-0010.md
View file

@ -85,7 +85,7 @@ initiate a signing request for each of the transaction’s inputs. The request
id is:
```
hash("inlock", prevTxHash, prevTxOut)
SHA256("inlock", prevTxHash, prevTxOut)
```
`"inlock"` is a static string, prepended with the length (6, as a compact int,
@ -113,7 +113,7 @@ Finalization is simply another signing request, performed on a (potentially)
different LLMQ than used before. The request id of the new signing request is:
```
hash("islock", inputCount, prevTxHash1, prevTxOut1, prevTxHash2, prevTxOut2, ...)
SHA256("islock", inputCount, prevTxHash1, prevTxOut1, prevTxHash2, prevTxOut2, ...)
```
`"islock"` is a static string, prepended with the length (6, as a compact int,