diff --git a/dip-0003.md b/dip-0003.md index 67bce9f..38b711a 100644 --- a/dip-0003.md +++ b/dip-0003.md @@ -69,10 +69,11 @@ Only the valid subset is used in calculations to determine the recipient of the To join the masternode list, masternode owners must submit a special transaction (DIP2) to the network. This transaction is called a Provider Registration Transaction and is abbreviated to ProRegTx. The ProRegTx must include an output with the 1000 DASH or refer to an already existing unspent output which holds 1000 DASH. -The ProRegTx contains 3 public key IDs, which represent 3 different roles in the masternode and define update and voting rights. A "public key ID" refers to the hash160 of an ECDSA public key. These are: +The ProRegTx contains 2 public key IDs and one BLS public key, which represent 3 different roles in the masternode and define update and voting rights. +A "public key ID" refers to the hash160 of an ECDSA public key. The keys are: 1. KeyIdOwner: This is the public key ID of the masternode or collateral owner. It is different than the key used in the collateral output. Only the owner is allowed to issue ProUpRegTx transactions. - 2. KeyIdOperator: This is the public key ID of the masternode operator. Only the operator is allowed to issue ProUpServTx transactions. The operator key is also used while operating the masternode to sign masternode related P2P messages, quorum related messages and governance trigger votes. Messages signed with this key are only valid while the masternode is in the valid set. + 2. PubKeyOperator: This is the BLS public key of the masternode operator. Only the operator is allowed to issue ProUpServTx transactions. The operator key is also used while operating the masternode to sign masternode related P2P messages, quorum related messages and governance trigger votes. Messages signed with this key are only valid while the masternode is in the valid set. 3. KeyIdVoting: This is the public key ID used for proposal voting. Votes signed with this key are valid while the masternode is in the registered set. A single key can be used for multiple roles so the owner can also operate the masternode and/or issue proposal votes. Alternately, different keys can be used to delegate duties to other people. For example, owners might decide to use a masternode hosting service instead of self-hosting the masternode. To do so, they would use the operator key provided by the hosting service. The same applies to the voting key, which allows them to assign voting rights to someone else. @@ -98,7 +99,7 @@ The transaction consists of the following data in the payload area: | ipAddress | byte[] | 16 | IPv6 address in network byte order. Only IPv4 mapped addresses are allowed (to be extended in the future) | | port | uint_16 | 2 | Port (network byte order) | | KeyIdOwner | CKeyID | 20 | The public key hash used for owner related signing (ProTx updates, governance voting) | -| KeyIdOperator | CKeyID | 20 | The public key hash used for operational related signing (network messages, ProTx updates) | +| PubKeyOperator | BLSPubKey | 48 | The public key used for operational related signing (network messages, ProTx updates) | | KeyIdVoting | CKeyID | 20 | The public key hash used for voting. | | operatorReward | uint_16 | 2 | A value from 0 to 10000. | | scriptPayoutSize | compactSize uint | 1-9 | Size of the Payee Script. | @@ -138,8 +139,7 @@ The transaction consists of the following data in the payload area: | 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 | -| payloadSigSize | compactSize uint | 1-9 | Size of the Signature | -| payloadSig | vector | Variable | Signature of the hash of the ProUpServTx fields. Signed by the Operator. | +| payloadSig | BLSSig | 96 | Signature of the hash of the ProUpServTx fields. Signed by the Operator. | ### Updating Registrar of Masternode (ProUpRegTx) @@ -156,7 +156,7 @@ The transaction consists of the following data in the payload area: | version | uint_16 | 2 | Upgrade Provider Transaction version number. Currently set to 1. | | proTXHash | uint256 | 32 | The hash of the provider transaction | | mode | uint_16 | 2 | Masternode mode | -| KeyIdOperator | CKeyID | 20 | The public key hash used for operational related signing (network messages, ProTx updates) | +| PubKeyOperator | BLSPubKey | 48 | The public key used for operational related signing (network messages, ProTx updates) | | 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) | @@ -182,8 +182,7 @@ The transaction consists of the following data in the payload area: | 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 | -| payloadSigSize | compactSize uint | 1-9 | Size of the Signature | -| payloadSig | vector | Variable | Signature of the hash of the ProTx fields. Signed by the Operator. | +| payloadSig | BLSSig | 96 | Signature of the hash of the ProTx fields. Signed by the Operator. | ## Rules for Updating the Masternode List @@ -215,9 +214,9 @@ A ProRegTx is invalid if any of these conditions are true: 1. collateralOutpoint `hash` is null but an output with 1000 DASH is not present at position `n` of the ProRegTx outputs 2. collateralOutpoint `hash` is not null but an output with 1000 DASH can't be found in the UTXO specified by the `hash` and `n` 3. Any KeyId* field is null (KeyIdOwner, KeyIdOperator or KeyIdVoting) - 4. KeyIdOwner or KeyIdOperator was already used by any entry in the registered masternodes set + 4. KeyIdOwner or PubKeyOperator was already used by any entry in the registered masternodes set 5. scriptPayout is not a P2PKH or P2SH script - 6. When scriptPayout is P2PKH script and the public key hash equals any of KeyIdOwner, KeyIdOperator or KeyIdVoting + 6. When scriptPayout is P2PKH script and the public key hash equals any of KeyIdOwner or KeyIdVoting 7. ipAddress is set and port is not set to the default mainnet port 8. ipAddress is set and not routable or not an IPv4 mapped address 9. ipAddress is set and already used in the registered masternodes set diff --git a/dip-0004.md b/dip-0004.md index 805f5c1..52c88fa 100644 --- a/dip-0004.md +++ b/dip-0004.md @@ -83,7 +83,7 @@ A SML entry consists of the following fields: | proRegTxHash | uint256 | 32 | The hash of the ProRegTx that identifies the masternode | | ipAddress | byte[] | 16 | IPv6 address in network byte order. Only IPv4 mapped addresses are allowed (to be extended in the future) | | port | uint_16 | 2 | Port (network byte order) | -| keyIDOperator | CKeyID | 20 | The operators public key hash | +| pubKeyOperator | BLSPubKey | 48 | The operators public key | | keyIDVoting | CKeyID | 20 | The public key hash used for voting. | | isValid | bool | 1 | True if a masternode is not PoSe-banned | diff --git a/dip-0005.md b/dip-0005.md index 04faf0d..242b30e 100644 --- a/dip-0005.md +++ b/dip-0005.md @@ -68,15 +68,13 @@ The special transaction type used for Register Subscription Transactions is 8. The transaction consists of the following data in the payload area: -| Name | Data Type | Description | -| - | - | - | -| version | uint16_t | Register transaction version number | -| userNameSize | compactSize uint | Length of the username | -| userName | string | Username for the account
* Cannot be changed by subsequent SubTxs | -| pubkeySize | compactSize uint | Length of the public key | -| pubkey | byte[] | Owner’s public key for the account
* For authentication only - should not be used to hold funds | -| payloadSigSize| compactSize uint | Length of the signature | -| payloadSig | byte[] | Signature of the hash of the preceding fields signed by the blockchain user with the private key for the specified PubKey (65 bytes) | +| Name | Type | Size | Description | +| - | - | - | - | +| version | uint16_t | 2 | Register transaction version number | +| userNameSize | compactSize uint | 1-9 | Length of the username | +| userName | string | Variable | Username for the account
* Cannot be changed by subsequent SubTxs | +| pubKey | BLSPubKey | 48 | Owner’s public key for the account
* For authentication only - should not be used to hold funds | +| payloadSig | BLSSig | 96 | Signature of the hash of the preceding fields signed by the blockchain user with the private key for the specified PubKey | ### Topup Blockchain User Credit (SubTxTopup) @@ -88,10 +86,10 @@ The special transaction type used for Topup Subscription Transactions is 9. The transaction consists of the following data in the payload area: -| Name | Data Type | Description | -| - | - | - | -| version | uint16_t | Topup transaction version number | -| regTxHash | uint256 | Registration Transaction-ID of the first Register Subscription Transaction | +| Name | Type | Size | Description | +| - | - | - | - | +| version | uint16_t | 2 | Topup transaction version number | +| regTxHash | uint256 | 32 | Registration Transaction-ID of the first Register Subscription Transaction | ### Reset Blockchain User Key (SubTxResetKey) @@ -107,16 +105,14 @@ The special transaction type used for ResetKey Subscription Transactions is 10. The transaction consists of the following data in the payload area: -| Name | Data Type | Description | -| - | - | - | -| version | uint16_t | Reset key transaction version number | -| regTxHash | uint256 | Registration Transaction-ID of the first Register Subscription Transaction | -| hashPrevSubTx | uint256 | Hash of the user’s previous subscription transaction | -| creditFee | int64_t | Fee (denominated in duffs) to pay for transaction | -| newPubKeySize | compactSize uint | Length of the new public key | -| newPubKey | byte[] | New public key for a change/reset action | -| payloadSigSize| compactSize uint | Length of the signature | -| payloadSig | byte[] | Signature of most recent pubkey prior to this transaction, signing a change/reset action | +| Name | Type | Size | Description | +| - | - | - | - | +| version | uint16_t | 2 | Reset key transaction version number | +| regTxHash | uint256 | 32 | Registration Transaction-ID of the first Register Subscription Transaction | +| hashPrevSubTx | uint256 | 32 | Hash of the user’s previous subscription transaction | +| creditFee | int64_t | 8 | Fee (denominated in duffs) to pay for transaction | +| newPubKey | BLSPubKey | 48 | New public key for a change/reset action | +| payloadSig | BLSSig | 96 | Signature of most recent pubkey prior to this transaction, signing a change/reset action | ### Close Blockchain User Account (SubTxCloseAccount) @@ -126,14 +122,13 @@ The special transaction type used for CloseAccount Subscription Transactions is The transaction consists of the following data in the payload area: -| Name | Data Type | Description | +| Name | Type | Size | Description | | - | - | - | -| version | uint16_t | Close account transaction version number | -| regTxHash | uint256 | Registration Transaction-ID of the first Register Subscription Transaction | -| hashPrevSubTx | uint256 | Hash of the user’s previous subscription transaction. This is necessary to ensure proper order of operations is followed (e.g. make sure the proper key has signed the Close message if a ResetKey message is also present) | -| creditFee | int64_t | Fee (denominated in duffs) to pay for transaction | -| payloadSigSize| compactSize uint | Length of the signature | -| payloadSig | byte[] | Signature from either the current key or a previous key
Version 1 - Previous keys are constrained to ones <= ~90 days old (51840 blocks) +| version | uint16_t | 2 | Close account transaction version number | +| regTxHash | uint256 | 32 | Registration Transaction-ID of the first Register Subscription Transaction | +| hashPrevSubTx | uint256 | 32 | Hash of the user’s previous subscription transaction. This is necessary to ensure proper order of operations is followed (e.g. make sure the proper key has signed the Close message if a ResetKey message is also present) | +| creditFee | int64_t | 8 | Fee (denominated in duffs) to pay for transaction | +| payloadSig | BLSSig | 96 | Signature from either the current key or a previous key
Version 1 - Previous keys are constrained to ones <= ~90 days old (51840 blocks) #### Important notes regarding closed accounts diff --git a/dip-0006.md b/dip-0006.md index d2b129b..80aaff2 100644 --- a/dip-0006.md +++ b/dip-0006.md @@ -187,11 +187,11 @@ The internal Dash message name is `qcontrib` and the format of the message is: | 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 -| vvec | BLSPubKey[] | 64 * vvecSize | The verification vector -| ephemeralPubKey | BLSPubKey | 64 | Ephemeral BLS public key used to encrypt secret key contributions +| vvec | BLSPubKey[] | 48 * vvecSize | The verification vector +| ephemeralPubKey | BLSPubKey | 48 | Ephemeral BLS public key used to encrypt secret key contributions | skCount | compactSize uint | 1-9 | Number of encrypted secret key contributions | skContributions | byte[] | 32 * skCount | Secret key contributions encrypted to recipient masternodes’ BLS public operator key -| sig | BLSSig | 32 | BLS signature, signed with the operator key of the contributing masternode +| sig | BLSSig | 96 | BLS signature, signed with the operator key of the contributing masternode ### 3. Complaining phase @@ -231,7 +231,7 @@ The internal Dash message name is `qcomplaint` and the format of the message is: | badMembers | byte[] | (bitSize + 7) / 8 | The bad members bitvector | complaintsBitSize | compactSize uint | 1-9 | Number of bits in the complaints bitvector | complaints | byte[] | (bitSize + 7) / 8 | The complaints bitvector -| sig | BLSSig | 32 | BLS signature, signed with the operator key of the contributing masternode +| sig | BLSSig | 96 | BLS signature, signed with the operator key of the contributing masternode ### 4. Justification phase @@ -265,7 +265,7 @@ The internal Dash message name is `qjustify` and the format of the message is: | skContributionsCount | compactSize uint | 1-9 | Number of unencrypted secret key contributions | skContributionMembers | uint32[] | 4 * count | Indexes of the members for which justifications are provided | skContributions | BLSSecKey[] | 32 * count | Unencrypted secret key contributions for the members contained in skContributionMembers -| sig | BLSSig | 32 | BLS signature, signed with the operator key of the contributing masternode +| sig | BLSSig | 96 | BLS signature, signed with the operator key of the contributing masternode ### 5. Commitment phase @@ -309,10 +309,10 @@ The internal Dash message name is `qpcommit` and the format of the message is: | proTxHash | uint256 | 32 | The proTxHash of the committing member | 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 | 64 | The quorum public key +| quorumPublicKey | BLSPubKey | 48 | The quorum public key | quorumVvecHash | uint256 | 32 | The hash of the quorum verification vector -| quorumSig | BLSSig | 32 | Threshold signature, signed with the threshold signature share of the committing member -| sig | BLSSig | 32 | BLS signature, signed with the operator key of the contributing masternode +| 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 ### 6. Finalization phase @@ -356,10 +356,10 @@ The internal Dash message name is `qfcommit` and the format of the message is: | signers | byte[] | (bitSize + 7) / 8 | Bitset representing the aggregated signers of this final commitment | 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 | 64 | The quorum public key +| quorumPublicKey | BLSPubKey | 48 | The quorum public key | quorumVvecHash | uint256 | 32 | The hash of the quorum verification vector -| quorumSig | BLSSig | 32 | Recovered threshold signature -| sig | BLSSig | 32 | Aggregated BLS signatures from all included commitments +| quorumSig | BLSSig | 96 | Recovered threshold signature +| sig | BLSSig | 96 | Aggregated BLS signatures from all included commitments ### 7. Mining phase diff --git a/dip-0006/bls_signature_scheme.md b/dip-0006/bls_signature_scheme.md index a88151c..c130418 100644 --- a/dip-0006/bls_signature_scheme.md +++ b/dip-0006/bls_signature_scheme.md @@ -110,23 +110,26 @@ We chose to enforce distinct messages when signing with a secret key. Dash’s i ## BLS Curves used -The BLS signature scheme requires pairing-friendly curves to be used. Multiple curves with different security, performance and space characteristics have been proposed by different parties. At the time this document was written, no decision had been made as to which curve would be used. - -However, the choice of the specific curve should have no influence on the scheme itself, how BLS is used or what is possible. - -This document will be updated when a decision has been made on which curve to use. +The BLS signature scheme requires pairing-friendly curves to be used, of which only a few suitable exist. Dash is +using the BLS12-381 with reversed G1 and G2 groups. A specification can be found in the Chia [bls-signatures](https://github.com/Chia-Network/bls-signatures/blob/master/SPEC.md) +repository. ## Serialization format of BLS primitives -It is necessary to serialize BLS primitives into a byte representation so that they can be used inside other serialized data structures. How this is performed depends on the curves and libraries used. This has not been defined yet and this document will be updated later. +It is necessary to serialize BLS primitives into a byte representation so that they can be used inside other serialized data structures. +The serialization format is described in the Chia [bls-signatures](https://github.com/Chia-Network/bls-signatures/blob/master/SPEC.md) +repository. -Until then, all DIPs will use placeholders types for the BLS primitives and assume a fixed size. These placeholder type are: +The size of individual BLS primitives is fixed: | Type | Size | Description | | -- | -- | -- | | BLSSecKey | 32 | BLS secret key -| BLSPubKey |64 | BLS public key -| BLSSig |32 | BLS signature +| BLSPubKey | 48 | BLS public key +| BLSSig | 96 | BLS signature + +Please note that there is no length field before the primitives serialized data. This is different from ECDSA signatures +where a compact size integer is prepended. ## Copyright diff --git a/dip-0007.md b/dip-0007.md index 37cbf7e..a697d73 100644 --- a/dip-0007.md +++ b/dip-0007.md @@ -110,7 +110,7 @@ The internal Dash message name is `qbsigshares` and the format of the message is | messageHash | uint256 | 32 | The message hash | | 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[] | 32 * shareCount | The signature shares | +| shareSigs | BLSSig[] | 96 * shareCount | The signature shares | ### Recovered threshold signatures @@ -132,7 +132,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 | -| thresholdSig | BLSSig | 32 | The final recovered threshold signature | +| thresholdSig | BLSSig | 96 | The final recovered threshold signature | ## Internal high-level API