dashpay / dips

Dash Improvement Proposals

Dash Improvement Proposals (DIPs)

DIP stands for Dash Improvement Proposal. Similar to Bitcoin's BIPs, a DIP is a design document providing information to the Dash community, or describing a new feature for Dash or its processes or environment. The DIP should provide a concise technical specification of the feature and a rationale for the feature.

Because Dash is forked from the Bitcoin codebase, many of the BIPs can be applied to Dash as well (a list of the BIPs updated to include Dash-specific details can be found here). The purpose of the DIPs is not to duplicate those which exist as BIPs, but to introduce protocol upgrades or feature specifications which are unique to Dash.

Contributions

We use the same general guidelines for introducing a new DIP as specified in BIP 2, with a few differences. Specifically:

• Instead of the BIP editor, initiate contact with the Dash Core development team and your request should be routed to the DIP editor(s). The DIP workflow mimics the BIP workflow.
• Recommended licenses include the MIT license
• Markdown format is the preferred format for DIPs
• Following a discussion, the proposal should be submitted to the DIPs git repository as a pull request. This draft must be written in BIP/DIP style as described in BIP 2, and named with an alias such as "dip-johndoe-infinitedash" until the editor has assigned it a DIP number (authors MUST NOT self-assign DIP numbers).

Dash Improvement Proposal Summary

Number	Layer	Title	Owner	Type	Status
1	Consensus	Initial Scaling of the Network	Darren Tapp	Standard	Final
2	Consensus	Special Transactions	Samuel Westrich, Alexander Block, Andy Freer	Standard	Final
3	Consensus	Deterministic Masternode Lists	Samuel Westrich, Alexander Block, Andy Freer, Darren Tapp, Timothy Flynn, Udjinm6, Will Wray	Standard	Final
4	Consensus	Simplified Verification of Deterministic Masternode Lists	Alexander Block, Samuel Westrich, UdjinM6, Andy Freer	Standard	Final
5	Consensus	Blockchain Users	Alexander Block, Cofresi, Andy Freer, Nathan Marley, Anton Suprunchuk, Darren Tapp, Thephez, Udjinm6, Alex Werner, Samuel Westrich	Standard	Withdrawn
6	Consensus	Long-Living Masternode Quorums	Alexander Block	Standard	Final
7	Consensus	LLMQ Signing Requests / Sessions	Alexander Block	Standard	Final
8	Consensus	ChainLocks	Alexander Block	Standard	Final
9	Applications	Feature Derivation Paths	Samuel Westrich	Informational	Proposed
10	Consensus	LLMQ InstantSend	Alexander Block	Standard	Final
11	Consensus	Identities	Ivan Shumkov, Anton Suprunchuk, Samuel Westrich, Cofresi	Standard	Proposed
12	Consensus	Dash Platform Name Service	Ivan Shumkov, Anton Suprunchuk	Standard	Proposed
13	Applications	Identities in Hierarchical Deterministic Wallets	Samuel Westrich	Informational	Proposed
14	Applications	Extended Key Derivation using 256-Bit Unsigned Integers	Samuel Westrich	Informational	Proposed
15	Applications	DashPay	Samuel Westrich, Eric Britten	Standard	Proposed
16	Applications	Headers First Synchronization on Simple Payment Verification Wallets	Samuel Westrich	Informational	Proposed
20	Consensus	Dash Opcode Updates	Mart Mangus	Standard	Final
21	Consensus	LLMQ DKG Data Sharing	dustinface	Standard	Final
22	Consensus	Making InstantSend Deterministic using Quorum Cycles	Samuel Westrich, UdjinM6	Standard	Final
23	Consensus	Enhanced Hard Fork Mechanism	Pasta	Standard	Proposed
24	Consensus	Long-Living Masternode Quorum Distribution and Rotation	Samuel Westrich & Virgile Bartolo	Standard	Final
25	Peer Services	Compressed Block Headers	gabriel-bjg, Thephez, UdjinM6	Standard	Proposed
26	Consensus	Multi-Party Payout	Timothy Munsell, UdjinM6	Standard	Proposed
27					Reserved
28	Consensus	Evolution Masternodes	Paul DeLucia, Odysseas Gabrielides, Łukasz Klimek, Ivan Shumkov, Samuel Westrich	Standard	Final
29	Consensus	Randomness Beacon For LLMQ Selection	Virgile Bartolo	Standard	Proposed

License

Unless otherwise specified, Dash Improvement Proposals (DIPs) are released under the terms of the MIT license. See LICENSE for more information or see the MIT License.

dips's Issues

DIP11 (identities) key purposes don't match implementation

dashpay/platform#317 implements a "withdraw" public key purpose that isn't included in the DIP. It also uses a number (3) that was designated for a different purpose in https://github.com/dashpay/dips/blob/master/dip-0011.md#identity-public-key.

DIP14 threshold bits are already defined as BIP32 hardened derivation paths

The threshold bits for DIP14 should be >=2^32 instead of >=2^31 as 2^31 to 2^32-1 is defined for hardened BIP32 keys: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#extended-keys

DIP2/DIP4 Test vectors

Are there any test vectors for DIP2/DIP4 transactions that have been confirmed on-chain?

python-trezor has one, but it does not appear to be a "real" transaction.

some thoughts on onchain masternodes

first of all since I started with masternode code I was actually going to do this but after talking to UdjinM6 realized the plan was to go with onchain so its great we follow the same ideologies about how this will work.

A few questions.

1. since you split the keys can you not store the base58 address for collateral instead of pubkey so that you can support p2sh collateral contracts? Any thoughts on using schnorr here?

2. is the ip check that it is unique across the mn list a strict requirement? doing so removes plausible deniability of operation of a masternode through historical context. I would think only keys and sigs only need to be onchain to make deterministic masternode services work properly and a proof on chain can exist to make the rest of the data immutable.

3. you might want a notion or identity connected to masternodes to build these offchain anchor and aux services connected to your mn object. You can then prune based on identity liveness (expiry) like I did with Syscoin. This makes the architecture pretty flexible. Although most of that can be done offchain aswell through a merkle tree abstraction where root hash is stored on chain to enable enterprise grade DApps function offchain but store data through the dashdrive. To me data liveness matterd little as data is cheap and cloud uptime is good enough. IPFS is sufficient as a content addressable storage medium is all thats needed and not incentivised storage. You store what you care about and pay others if needed through cloud type services.

`llmqType` field missing from `qfcommit`

The qfcommit message has a 1 byte llmqType field that is not found in the table under Finalization Phase.

See https://github.com/dashpay/dash/blob/develop/src/llmq/quorums_commitment.h#L63-L71 and https://github.com/dashpay/dash/blob/develop/src/consensus/params.h#L42-L52 for details.

DIP14 version bytes do not match the human readable prefixes

For cases where the last child number of a derivation path is a 256 bit integer, the version bytes are given here (https://github.com/dashpay/dips/blob/master/dip-0014.md#serialization-format) are:

4 byte: version bytes (mainnet: 0X0EECEFC5 public, 0x0EECF02E private; testnet: 0x0EED270B public, 0x0EED2774 private)

Later in the document the human readable representations are given as:

Because of the choice of the version bytes, the Base58 representation will start with dpms (dashpay mainnet secret) or dpmp (dashpay mainnet public) on mainnet, dpts (dashpay testnet secret) or dptp (dashpay testnet public) on testnet or devnets.

However, to get the prefix to match dptp for instance, I had to use version byte values from this table.

On DashJ, these have not been used to do a round trip test from a deterministic key to serialized to deterministic key.

dpms - 0x0eecf02e
dpmp - 0x0eecefc6
dptp - 0x0eed270b
dpts - 0x0eed2774

What is strange though, is that long ago when Dash used dpub instead of xpub, then these version bytes do start with 0x02fd. Perhaps the length of the serialization has influence over the version bytes.

# mainnet - digit boundary after prefix
dpub8Du2vbh7JUQr  0x02fda923
dprv3hCznBesA6jB  0x02fda4e8

# mainnet - mostly uppers after prefix
dpubZ9169KDAEUny  0x02fda926
dprvLJcNFzfZn6yw  0x02fda4ea

Further info in a related PR: #84

Update DIP-2 special tx table

Upon activation of Dash Core v18's hard fork, the QcTx version will increment to 2. Update the version number in this table once that has happened: https://github.com/dashpay/dips/blob/master/dip-0002-special-transactions.md.

DIP-15 extendedPublicKey serialization format is not specified

In line 301: https://github.com/dashpay/dips/edit/master/dip-0015.md#L301

ASK = HMAC(senderSecretKey, extendedPublicKey)

The extendedPublicKey serialization Format is not specified, according to the implementation it is not the BIP32 serialization but the abbreviated DIP15 serialization defined in line 362: https://github.com/dashpay/dips/edit/master/dip-0015.md#L362
of BIP32

DIP-7 doc doesn't match implementation

DIP7 needs to be updated to match 0.14 implementation when finalized (reference dashpay/dash#2726 (comment)).

@codablock Adding this as an issue so we keep track of it

DIP-15 HMAC hashing algorithm is not specified

In line 301: https://github.com/dashpay/dips/edit/master/dip-0015.md#L301

ASK = HMAC(senderSecretKey, extendedPublicKey)

The hashing algorithm to be used is not specified, according to the implementation it is sha256.

versions in special transactions chart seem wrong

https://github.com/dashpay/dips/blob/master/dip-0002-special-transactions.md

In dip-0002, it is mentioned that the version field will be set to >=3 to identify special transactions and that right now for normal transactions, they are version 2? I think. The document is rather clear, until it isn't. If that is the case, the special transaction chart (see URL above) has all versions incorrectly set to 1. I don't grok this... or there is an error. Or both. :) -t0dd

DIP-3 Operator Key (BLS)

DIP-3 needs to be updated with details regarding the Operator key being changed to BLS.

• Update ProRegTx description with operator BLS key details
• Remove ProUpServTx payloadSigSize field for BLS signatures (BLS sigs are 96 bytes)
• Remove ProUpRevTx payloadSigSize field for BLS signatures (BLS sigs are 96 bytes)

This looks inconsistent with `<sub>`N`</sub>`C`<sub>`400`</sub>` notion described above. Shouldn't this be

This looks inconsistent with <sub>N</sub>C<sub>400</sub> notion described above. Shouldn't this be

<sub>`m`</sub>`C`<sub>`160`</sub> * <sub>`N - m`</sub>`C`<sub>240</sub>

instead?

(same for the gif below)

Originally posted by @UdjinM6 in https://github.com/dashpay/dips/pull/55/files/238cec047b5c45761710a6570de7e9fc7956a2bb

Copyright statements

DIPs written in 2017+ (all of them) should have "Dash Core Group, Inc." in the copyright field

DIP14 version bytes don't match the base58 characters expected

version bytes (mainnet: 0x02FD9CD5 public, 0x02FD9CEA private; testnet: 0x02FDA7E8 public, 0x02FDA7FD private)

don't macht the Base58 representation of

dpms (dashpay mainnet secret) or dpmp (dashpay mainnet public) on mainnet, dpts (dashpay testnet secret) or dptp (dashpay testnet public) on testnet or devnets.