Skip to content

Update DIPs regarding use of BLS12-381-reversed #25

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
thephez merged 7 commits into from
Nov 9, 2018
Merged

Update DIPs regarding use of BLS12-381-reversed #25

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
4e1a594
Update bls_signature_scheme.md with BLS12-381-reversed
codablock Oct 26, 2018
4d4b6a1
Update DIP3/DIP4 to use BLS operator keys
codablock Oct 26, 2018
236a650
Update DIP5 to use BLS keys for user keys
codablock Oct 26, 2018
8636fd3
Update BLS primitives serialization size in DIP6/7
codablock Oct 26, 2018
0a2a688
DIP3 - Correct PubKeyOperator type
thephez Oct 26, 2018
70e5de3
DIP4 - Correct PubKeyOperator type
thephez Oct 26, 2018
ba96b79
Remove trailing e from integere
codablock Oct 29, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 9 additions & 10 deletions dip-0003.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Copy link
Copy Markdown
Contributor

@nmarley nmarley Oct 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question about line breaks as below


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.
Expand All @@ -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. |
Expand Down Expand Up @@ -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<unsigned char> | 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)

Expand All @@ -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) |
Expand All @@ -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<unsigned char> | 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

Expand Down Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion dip-0004.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 |
Comment thread
thephez marked this conversation as resolved.
| keyIDVoting | CKeyID | 20 | The public key hash used for voting. |
| isValid | bool | 1 | True if a masternode is not PoSe-banned |

Expand Down
55 changes: 25 additions & 30 deletions dip-0005.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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<br> * Cannot be changed by subsequent SubTxs |
| pubkeySize | compactSize uint | Length of the public key |
| pubkey | byte[] | Owner’s public key for the account<br> * 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<br> * Cannot be changed by subsequent SubTxs |
| pubKey | BLSPubKey | 48 | Owner’s public key for the account<br> * 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)

Expand All @@ -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)

Expand All @@ -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)

Expand All @@ -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<br>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<br>Version 1 - Previous keys are constrained to ones <= ~90 days old (51840 blocks)

#### Important notes regarding closed accounts

Expand Down
22 changes: 11 additions & 11 deletions dip-0006.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down Expand Up @@ -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

Expand Down Expand Up @@ -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

Expand Down Expand Up @@ -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

Expand Down Expand Up @@ -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

Expand Down
21 changes: 12 additions & 9 deletions dip-0006/bls_signature_scheme.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Copy Markdown
Contributor

@nmarley nmarley Oct 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for the line breaks here?

Copy link
Copy Markdown
Contributor Author

@codablock codablock Oct 29, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's very hard to read/edit otherwise in my editor. In Markdown, single-newlines are ignored when rendered, so it's the same as if there was no newline.

I'd suggest to limit line width in the future when we create DIPs to make editing/reading the plain Markdown easier.

Copy link
Copy Markdown
Contributor Author

@codablock codablock Oct 29, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have this problem in all DIPs and nearly all paragraphs are in a single line...

Copy link
Copy Markdown
Contributor

@nmarley nmarley Nov 9, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see it as a "problem" since editors can be made to soft fold, but, I also understand and think if we do this then let's set at something standard like 72 or 80 and hard-wrap at that then.


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

Expand Down
4 changes: 2 additions & 2 deletions dip-0007.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand All @@ -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

Expand Down