joshua/dips
1
0
Fork 0
mirror of https://github.com/seigler/dips synced 2025-07-27 09:46:12 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Add description of collateralOutpoint and signing of ProRegTx (#28)

Browse source 
* Add description of collateralOutpoint and signing of ProRegTx

* Add note about magicString being handled by "signmessage"
This commit is contained in:
Alexander Block 2018-11-13 20:20:30 +01:00 • committed by thephez
parent c5b35976ee
commit 432c4a977e
1 changed files with 21 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

21
dip-0003.md
View file

@ -78,6 +78,27 @@ A "public key ID" refers to the hash160 of an ECDSA public key. The keys are:
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. 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.
The collateralOutpoint of the ProRegTx might refer to an external collateral or to an output which is part of the ProRegTx itself. If the hash of collateralOutpoint is null, it refers to
an output of the ProRegTx. If it refers to an external collateral (hash of collateralOutpoint is not null), the collateral must exist and not be spent. The ProRegTx must also prove ownership
of external collaterals by setting payloadSigSize and payloadSig to a valid signature which signs the following message:
`<magicString><payoutStr>|<operatorReward>|<ownerKeyAddress>|<votingKeyAddress>|<payloadHash>`
The individual parts of the message are:
1. `<magicString>`: A fixed string which is always "DarkCoin Signed Message:" with a newline character appended.
Please note that existing tools (e.g. the RPC command `signmessage`) usually add the magicString internally, making it
unnecessary to manually add it.
2. `<payoutStr>`: The Dash address corresponding to the scriptPayout field of the ProRegTx. In case scriptPayout is not a
P2PK/P2PKH/P2SH script, `<payoutStr>` must be set to the hex representation of the full script.
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.
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
payloadSig must be empty.
The ProRegTx might have the IP address and port fields set to zero. This will result in the masternode being added to the masternode list in the PoSe-banned state and require the operator to issue a ProUpServTx. This is needed in case the owner wants to delegate the operator role to a hosting service without knowing the IP Address and port in advance. The ProRegTx might have the IP address and port fields set to zero. This will result in the masternode being added to the masternode list in the PoSe-banned state and require the operator to issue a ProUpServTx. This is needed in case the owner wants to delegate the operator role to a hosting service without knowing the IP Address and port in advance.
The ProRegTx also defines the masternode's type and mode. Default masternodes are of type 0, and future types will be defined in an [annex document](dip-0003-masternode-types.md). Different types would introduce additional or different consensus rules towards the masternodes based on future Dash improvement proposals. Masternode types are not updatable, however each type can have multiple operation modes. The operation modes are updatable. The ProRegTx also defines the masternode's type and mode. Default masternodes are of type 0, and future types will be defined in an [annex document](dip-0003-masternode-types.md). Different types would introduce additional or different consensus rules towards the masternodes based on future Dash improvement proposals. Masternode types are not updatable, however each type can have multiple operation modes. The operation modes are updatable.