From 035ac76dbd3c1536cd99fd89abaab5c538d100ce Mon Sep 17 00:00:00 2001 From: thephez Date: Wed, 3 Dec 2025 11:26:25 -0500 Subject: [PATCH 1/7] chore: lint fixes --- dip-0017.md | 79 ++++++++++++++++++++++++++--------------------------- dip-0018.md | 51 ++++++++++++++++++---------------- 2 files changed, 66 insertions(+), 64 deletions(-) diff --git a/dip-0017.md b/dip-0017.md index 073cc615..0a0581a1 100644 --- a/dip-0017.md +++ b/dip-0017.md @@ -47,63 +47,62 @@ Platform payment keys identify recipients of value on Dash Platform. This value The Platform payment feature is assigned DIP-9 feature index `17'`. The canonical derivation path is: -``` +```text m / 9' / coin_type' / 17' / account' / key_class' / index ``` Normative requirements: -- `purpose'` MUST be `9'`. -- `coin_type'` MUST be `5'` on mainnet (Dash SLIP-44 coin type) and MUST be `1'` on testnet/devnet/regtest (SLIP-44 test coin type), consistent with BIP-44 conventions. -- `account'` MUST be hardened. `0'` is the default account. Additional accounts MAY be used following BIP-44-style multi-account semantics. -- `feature'` MUST be `17'` (Platform payment feature). -- `key_class'` MUST be hardened. The default class for Platform payment receive keys is `0'`. Additional hardened classes MAY be defined by future DIPs; `1'` is reserved for wallet-internal or change-like segregation if a wallet chooses to implement it. -- `index` MUST be non-hardened (`0 ≤ index ≤ 2³¹−1`). -- No BIP-44 change level is used; privacy is obtained by incrementing `index` and optionally segregating with `key_class'`. +* `purpose'` MUST be `9'`. +* `coin_type'` MUST be `5'` on mainnet (Dash SLIP-44 coin type) and MUST be `1'` on testnet/devnet/regtest (SLIP-44 test coin type), consistent with BIP-44 conventions. +* `account'` MUST be hardened. `0'` is the default account. Additional accounts MAY be used following BIP-44-style multi-account semantics. +* `feature'` MUST be `17'` (Platform payment feature). +* `key_class'` MUST be hardened. The default class for Platform payment receive keys is `0'`. Additional hardened classes MAY be defined by future DIPs; `1'` is reserved for wallet-internal or change-like segregation if a wallet chooses to implement it. +* `index` MUST be non-hardened (`0 ≤ index ≤ 2³¹−1`). +* No BIP-44 change level is used; privacy is obtained by incrementing `index` and optionally segregating with `key_class'`. Default account paths: -- Mainnet: `m/9'/5'/17'/0'/0'/index` -- Testnet/Devnet/Regtest: `m/9'/1'/17'/0'/0'/index` (coin type `1'` for test networks). +* Mainnet: `m/9'/5'/17'/0'/0'/index` +* Testnet/Devnet/Regtest: `m/9'/1'/17'/0'/0'/index` (coin type `1'` for test networks). Wallets MAY derive and expose an extended public key at `m/9'/5'/17'/account'/key_class'` (mainnet) or `m/9'/1'/17'/account'/key_class'` (test networks) for watch-only or monitoring. They MUST NOT expose hardened parent levels. Accounts follow BIP-44 semantics: `account'` partitions user-controlled sets of Platform payment keys, enabling multiple profiles or organizational separations while preserving hardened isolation between accounts. - ## Wallet and Hardware Wallet Behavior -- Wallets MUST derive Platform payment keys only from `m/9'/5'/17'/account'/key_class'/index` (mainnet) or `m/9'/1'/17'/account'/key_class'/index` (test networks). Address encoding of the resulting public keys is specified in DIP-0018. -- Wallets SHOULD clearly separate Platform chain balances from Core chain balances in UI and storage. -- Wallets SHOULD rotate addresses by incrementing `index` to avoid reuse; a default gap limit of 20 is RECOMMENDED for discovery. -- Wallets MAY support watch-only by exporting the xpub at `m/9'/5'/17'/account'/key_class'` (mainnet) or `m/9'/1'/17'/account'/key_class'` (test networks). -- Wallets MAY present multiple accounts following BIP-44 semantics (distinct `account'` values), and SHOULD clearly label the active account in UI. -- Hardware wallets MUST whitelist the above derivation path and display a label such as “Dash Platform address” when showing or signing. -- Hardware wallets MUST apply the address encodings defined in DIP-0018 and MUST NOT reinterpret these as Core chain P2PKH/P2SH. -- If a wallet does not implement Platform, it simply never derives the `17'` feature path. +* Wallets MUST derive Platform payment keys only from `m/9'/5'/17'/account'/key_class'/index` (mainnet) or `m/9'/1'/17'/account'/key_class'/index` (test networks). Address encoding of the resulting public keys is specified in DIP-0018. +* Wallets SHOULD clearly separate Platform chain balances from Core chain balances in UI and storage. +* Wallets SHOULD rotate addresses by incrementing `index` to avoid reuse; a default gap limit of 20 is RECOMMENDED for discovery. +* Wallets MAY support watch-only by exporting the xpub at `m/9'/5'/17'/account'/key_class'` (mainnet) or `m/9'/1'/17'/account'/key_class'` (test networks). +* Wallets MAY present multiple accounts following BIP-44 semantics (distinct `account'` values), and SHOULD clearly label the active account in UI. +* Hardware wallets MUST whitelist the above derivation path and display a label such as “Dash Platform address” when showing or signing. +* Hardware wallets MUST apply the address encodings defined in DIP-0018 and MUST NOT reinterpret these as Core chain P2PKH/P2SH. +* If a wallet does not implement Platform, it simply never derives the `17'` feature path. # Rationale -- **Coin type 5' on mainnet, 1' on test networks:** Mainnet keeps Dash SLIP-44 coin type 5', while testnet/devnet/regtest follow SLIP-44 convention with coin type 1'. This avoids new registry allocations and keeps all Dash features under the established namespaces. -- **DIP-9 vs BIP-44:** DIP-9’s feature level cleanly separates Platform addresses from Core chain funds and from identities/masternodes without overloading BIP-44’s change level or accounts. -- **Feature index 17':** The next available DIP-9 feature after 16' (DashPay) is reserved for Platform payments, avoiding collisions with existing features. -- **Hardened upper levels:** `9'/coin_type'/17'/account'/key_class'` isolate Platform keys from other features and from each other. An xpub leak below `key_class'` cannot compromise hardened parents. -- **Non-hardened leaf index:** Enables watch-only, auditing, and future multisig/shared-custody schemes that rely on unhardened derivation of child public keys. Fully hardened leaves were rejected to preserve these capabilities. -- **Accounts retained:** A hardened `account'` level maintains BIP-44-style multi-account semantics while still isolating Platform keys under the DIP-9 feature branch. -- **No BIP-44 change level:** Platform addresses are not UTXO change outputs; a linear `index` (optionally partitioned by `key_class'`) keeps the model simple for hardware wallets and avoids misuse of the 0/1 change bit. +* **Coin type 5' on mainnet, 1' on test networks:** Mainnet keeps Dash SLIP-44 coin type 5', while testnet/devnet/regtest follow SLIP-44 convention with coin type 1'. This avoids new registry allocations and keeps all Dash features under the established namespaces. +* **DIP-9 vs BIP-44:** DIP-9’s feature level cleanly separates Platform addresses from Core chain funds and from identities/masternodes without overloading BIP-44’s change level or accounts. +* **Feature index 17':** The next available DIP-9 feature after 16' (DashPay) is reserved for Platform payments, avoiding collisions with existing features. +* **Hardened upper levels:** `9'/coin_type'/17'/account'/key_class'` isolate Platform keys from other features and from each other. An xpub leak below `key_class'` cannot compromise hardened parents. +* **Non-hardened leaf index:** Enables watch-only, auditing, and future multisig/shared-custody schemes that rely on unhardened derivation of child public keys. Fully hardened leaves were rejected to preserve these capabilities. +* **Accounts retained:** A hardened `account'` level maintains BIP-44-style multi-account semantics while still isolating Platform keys under the DIP-9 feature branch. +* **No BIP-44 change level:** Platform addresses are not UTXO change outputs; a linear `index` (optionally partitioned by `key_class'`) keeps the model simple for hardware wallets and avoids misuse of the 0/1 change bit. # Backwards Compatibility -- Classic Dash addresses (`X...`, `7...`, `y...`, `8...`) are unaffected. Nodes do not accept D-addresses in Core chain scripts. -- DIP-3/8 masternode derivations and DIP-13 identity derivations remain unchanged. -- Existing seeds stay valid; wallets can add Platform support without migration. -- Wallets unaware of Platform will not derive `m/9'/5'/17'/...` and therefore will not interfere with Platform balances. +* Classic Dash addresses (`X...`, `7...`, `y...`, `8...`) are unaffected. Nodes do not accept D-addresses in Core chain scripts. +* DIP-3/8 masternode derivations and DIP-13 identity derivations remain unchanged. +* Existing seeds stay valid; wallets can add Platform support without migration. +* Wallets unaware of Platform will not derive `m/9'/5'/17'/...` and therefore will not interfere with Platform balances. # Reference Implementation The following pseudo-code is normative for deriving a Platform payment address: -``` +```text function platform_payment_key(seed, account, key_class, index, network): # seed: BIP-39/BIP-32 seed bytes # account: hardened int (default 0) @@ -131,18 +130,18 @@ Encoding and decoding of these payloads into addresses is specified in DIP-0018. # Security Considerations -- Derivation uses hardened separation at `feature'` and `key_class'`; compromise of a Platform xpub does not expose other features or other key classes. -- Leakage of the xpub at `m/9'/coin_type'/17'/account'/key_class'` allows derivation of all Platform public keys for that key class but does not leak private keys or other features. -- Wallets MUST reject attempts to use D-addresses in Core chain transactions to prevent misdirected funds. -- Hardware wallets MUST show the full derivation path and “Dash Platform address” to reduce key-path confusion attacks. -- The checksum and distinct prefixes mitigate accidental prefix confusion with `X`/`7`/`y`/`8` addresses. +* Derivation uses hardened separation at `feature'` and `key_class'`; compromise of a Platform xpub does not expose other features or other key classes. +* Leakage of the xpub at `m/9'/coin_type'/17'/account'/key_class'` allows derivation of all Platform public keys for that key class but does not leak private keys or other features. +* Wallets MUST reject attempts to use D-addresses in Core chain transactions to prevent misdirected funds. +* Hardware wallets MUST show the full derivation path and “Dash Platform address” to reduce key-path confusion attacks. +* The checksum and distinct prefixes mitigate accidental prefix confusion with `X`/`7`/`y`/`8` addresses. # Privacy Considerations -- Platform addresses are unshielded; no zk-SNARK privacy is implied by this DIP. -- Wallets SHOULD avoid address reuse by incrementing `index` and MAY use separate `key_class'` values to segregate user profiles or accounts. -- Wallets SHOULD avoid correlating Platform `index` progression with Core chain BIP-44 indices to reduce cross-layer linkability. -- Sharing xpubs at `m/9'/coin_type'/17'/account'/key_class'` enables watch-only but also enables address graph reconstruction for that class; applications should only share when necessary. +* Platform addresses are unshielded; no zk-SNARK privacy is implied by this DIP. +* Wallets SHOULD avoid address reuse by incrementing `index` and MAY use separate `key_class'` values to segregate user profiles or accounts. +* Wallets SHOULD avoid correlating Platform `index` progression with Core chain BIP-44 indices to reduce cross-layer linkability. +* Sharing xpubs at `m/9'/coin_type'/17'/account'/key_class'` enables watch-only but also enables address graph reconstruction for that class; applications should only share when necessary. # Test Vectors diff --git a/dip-0018.md b/dip-0018.md index fdf2a13d..93745d59 100644 --- a/dip-0018.md +++ b/dip-0018.md @@ -42,18 +42,20 @@ Platform payment keys are derived under DIP-0017. To interoperate between wallet ## Address Types -- **Platform P2PKH (D-address):** HASH160 of a compressed secp256k1 public key derived per DIP-0017. -- **Platform P2SH:** HASH160 of a Platform script (e.g., multisig or policy script) for receiving Platform payments to scripts. +* **Platform P2PKH (D-address):** HASH160 of a compressed secp256k1 public key derived per DIP-0017. +* **Platform P2SH:** HASH160 of a Platform script (e.g., multisig or policy script) for receiving Platform payments to scripts. ## Encoding Base58Check is used for all Platform address types. Payloads: -- P2PKH payload: `HASH160(pubkey)` where `pubkey` is compressed secp256k1 (33 bytes). -- P2SH payload: `HASH160(script)` where `script` is the raw byte serialization of the Platform script being paid to. + +* P2PKH payload: `HASH160(pubkey)` where `pubkey` is compressed secp256k1 (33 bytes). +* P2SH payload: `HASH160(script)` where `script` is the raw byte serialization of the Platform script being paid to. Encoding algorithm (for either address type): + 1. Prepend the network-specific version byte for the address type. 2. Compute checksum = first 4 bytes of `SHA256(SHA256(version || payload))`. 3. Concatenate `version || payload || checksum`. @@ -73,6 +75,7 @@ These prefixes are distinct from Dash Core chain (`X`/`7`/`y`/`8`) and from each ## Validation An address is valid for a network if: + 1. Base58 decoding yields 25 bytes. 2. The checksum matches the first 4 bytes of `SHA256(SHA256(version || payload))`. 3. The version byte equals the network’s P2PKH or P2SH Platform prefix. @@ -80,17 +83,17 @@ An address is valid for a network if: ## Wallet and Hardware Wallet Behavior -- Wallets MUST use the P2PKH encoding above for public keys derived per DIP-0017. -- Wallets MUST use the P2SH encoding for Platform scripts intended to receive Platform funds. -- Hardware wallets MUST whitelist the version bytes above and display “Dash Platform address” or “Dash Platform script address” as appropriate. -- Software wallets SHOULD label Platform balances separately from Core chain balances and SHOULD avoid auto-pasting Platform addresses into Core chain contexts. -- Wallets SHOULD derive payloads via DIP-0017 and then encode using these rules; no alternative prefixes are allowed. +* Wallets MUST use the P2PKH encoding above for public keys derived per DIP-0017. +* Wallets MUST use the P2SH encoding for Platform scripts intended to receive Platform funds. +* Hardware wallets MUST whitelist the version bytes above and display “Dash Platform address” or “Dash Platform script address” as appropriate. +* Software wallets SHOULD label Platform balances separately from Core chain balances and SHOULD avoid auto-pasting Platform addresses into Core chain contexts. +* Wallets SHOULD derive payloads via DIP-0017 and then encode using these rules; no alternative prefixes are allowed. # Rationale -- **Base58Check:** Aligns with existing Dash address UX and reduces user confusion compared to introducing a new encoding. -- **Distinct prefixes:** `D/d` for P2PKH and `P/p` for P2SH avoid collisions with Core chain addresses and with each other. -- **Script support:** P2SH enables multisig and policy scripts on Platform without overloading the P2PKH prefix. +* **Base58Check:** Aligns with existing Dash address UX and reduces user confusion compared to introducing a new encoding. +* **Distinct prefixes:** `D/d` for P2PKH and `P/p` for P2SH avoid collisions with Core chain addresses and with each other. +* **Script support:** P2SH enables multisig and policy scripts on Platform without overloading the P2PKH prefix. # Backwards Compatibility @@ -98,7 +101,7 @@ No impact on Core chain addresses. Platform P2PKH/P2SH prefixes are new and cann # Reference Implementation -``` +```text function encode_platform_address(payload, type, network): # payload: 20-byte HASH160 # type: "p2pkh" or "p2sh" @@ -133,21 +136,21 @@ function decode_platform_address(addr, network): # Security Considerations -- Checksums detect mistyped addresses; distinct prefixes reduce layer-mixing mistakes. -- Hardware wallet whitelisting of prefixes mitigates key-path confusion. -- P2SH scripts must be fully validated by wallets before signing or displaying to prevent malicious script substitution. +* Checksums detect mistyped addresses; distinct prefixes reduce layer-mixing mistakes. +* Hardware wallet whitelisting of prefixes mitigates key-path confusion. +* P2SH scripts must be fully validated by wallets before signing or displaying to prevent malicious script substitution. # Privacy Considerations -- Base58Check addresses are unshielded; privacy relies on HD key rotation per DIP-0017 and script hygiene. -- P2SH script hashes reveal neither full script nor participant keys but can still be correlated if reused; wallets SHOULD discourage P2SH reuse. +* Base58Check addresses are unshielded; privacy relies on HD key rotation per DIP-0017 and script hygiene. +* P2SH script hashes reveal neither full script nor participant keys but can still be correlated if reused; wallets SHOULD discourage P2SH reuse. # Test Vectors Mnemonic (shared with DIP-0017): `abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about` Passphrase: `""` -### P2PKH examples (payloads from DIP-0017) +## P2PKH examples (payloads from DIP-0017) | Vector | Path (mainnet / testnet) | account' | key_class' | index | HASH160(pubkey) | Mainnet P2PKH | Testnet P2PKH | | ------ | ----------------------- | -------- | ---------- | ----- | --------------- | ------------- | -------------- | @@ -155,13 +158,13 @@ Passphrase: `""` | 2 | m/9'/5'/17'/0'/0'/1 / m/9'/1'/17'/0'/0'/1 | 0' | 0' | 1 | a5ff0046217fd1c7d238e3e146cc5bfd90832a7e | DLGoWhHfAyFcJafRgt2fFN7fxgLqNrfCXm | dZoepEc46ivSfm3VYr8mJeA4hZXYytgkKZ | | 3 | m/9'/5'/17'/0'/1'/0 / m/9'/1'/17'/0'/1'/0 | 0' | 1' | 0 | 6d92674fd64472a3dfcfc3ebcfed7382bf699d7b | DF8TaTy7YrLdGYqq6cwapSUqdM3qJxLQbo | dFQSkGujaeDNwWTQDDVfbrurQ9ChXXYDov | -### P2SH example +## P2SH example -- Script (hex): `76a914000102030405060708090a0b0c0d0e0f101112131488ac` +* Script (hex): `76a914000102030405060708090a0b0c0d0e0f101112131488ac` (standard HASH160-to-pubkey script for illustration) -- HASH160(script): `43fa183cf3fb6e9e7dc62b692aeb4fc8d8045636` -- Mainnet P2SH: `Pe8D1pMrEnWsmuj5zCEBhHTcsFE51Asp8k` -- Testnet P2SH: `pBk15SYRYnnKfMENUnYdGw4cG1wcRmSdoh` +* HASH160(script): `43fa183cf3fb6e9e7dc62b692aeb4fc8d8045636` +* Mainnet P2SH: `Pe8D1pMrEnWsmuj5zCEBhHTcsFE51Asp8k` +* Testnet P2SH: `pBk15SYRYnnKfMENUnYdGw4cG1wcRmSdoh` # Copyright From d35a37049e583c98a90d0ec057cf512d5d3a8fae Mon Sep 17 00:00:00 2001 From: thephez Date: Wed, 3 Dec 2025 15:28:16 -0500 Subject: [PATCH 2/7] fix: correct order of feature and account --- dip-0017.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dip-0017.md b/dip-0017.md index 0a0581a1..2fa00822 100644 --- a/dip-0017.md +++ b/dip-0017.md @@ -55,8 +55,8 @@ Normative requirements: * `purpose'` MUST be `9'`. * `coin_type'` MUST be `5'` on mainnet (Dash SLIP-44 coin type) and MUST be `1'` on testnet/devnet/regtest (SLIP-44 test coin type), consistent with BIP-44 conventions. -* `account'` MUST be hardened. `0'` is the default account. Additional accounts MAY be used following BIP-44-style multi-account semantics. * `feature'` MUST be `17'` (Platform payment feature). +* `account'` MUST be hardened. `0'` is the default account. Additional accounts MAY be used following BIP-44-style multi-account semantics. * `key_class'` MUST be hardened. The default class for Platform payment receive keys is `0'`. Additional hardened classes MAY be defined by future DIPs; `1'` is reserved for wallet-internal or change-like segregation if a wallet chooses to implement it. * `index` MUST be non-hardened (`0 ≤ index ≤ 2³¹−1`). * No BIP-44 change level is used; privacy is obtained by incrementing `index` and optionally segregating with `key_class'`. From 2a069c2670673899ebcfc8b27cb21f91a19c1cca Mon Sep 17 00:00:00 2001 From: thephez Date: Wed, 3 Dec 2025 15:28:43 -0500 Subject: [PATCH 3/7] chore: update copyright --- dip-0017.md | 2 +- dip-0018.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/dip-0017.md b/dip-0017.md index 2fa00822..f3052fca 100644 --- a/dip-0017.md +++ b/dip-0017.md @@ -166,4 +166,4 @@ Reserve DIP-9 feature index `17'` for “Platform Payment Addresses”: # Copyright -This document is licensed under the MIT License. +Copyright (c) 2025 Dash Core Group, Inc. [Licensed under the MIT License](https://opensource.org/licenses/MIT) diff --git a/dip-0018.md b/dip-0018.md index 93745d59..edfa805d 100644 --- a/dip-0018.md +++ b/dip-0018.md @@ -168,4 +168,4 @@ Passphrase: `""` # Copyright -This document is licensed under the MIT License. +Copyright (c) 2025 Dash Core Group, Inc. [Licensed under the MIT License](https://opensource.org/licenses/MIT) From e4da274a9b09ecb8d069511fd8894df872e1cf05 Mon Sep 17 00:00:00 2001 From: thephez Date: Wed, 3 Dec 2025 15:32:43 -0500 Subject: [PATCH 4/7] docs: add prior work sections and improve formatting in DIP-17/18 Add Prior Work sections referencing DIP-0009, BIP-0032, and BIP-0044 in DIP-17 and DIP-0017 in DIP-18. Convert path examples to table format, add key_class forward compatibility note, and fix minor formatting. --- dip-0017.md | 15 ++++++++++++--- dip-0018.md | 8 ++++++-- 2 files changed, 18 insertions(+), 5 deletions(-) diff --git a/dip-0017.md b/dip-0017.md index f3052fca..b0fc68ea 100644 --- a/dip-0017.md +++ b/dip-0017.md @@ -16,6 +16,7 @@ 1. [Abstract](#abstract) 1. [Motivation](#motivation) +1. [Prior Work](#prior-work) 1. [Specification](#specification) 1. [Overview](#overview) 1. [Derivation Path Definition](#derivation-path-definition) @@ -37,6 +38,12 @@ This DIP defines Dash Platform payment addresses (“D-addresses”) and their h Dash Platform enables value transfers distinct from Dash Core chain UTXO transactions. Wallets require an unambiguous address type, network-specific encodings, and deterministic derivation paths that coexist with BIP-44 Core chain funds and existing DIP-9 features (masternodes, identities, DashPay). This DIP provides a single standard so wallets, hardware wallets, and services can implement Platform payments. +# Prior Work + +* [DIP-0009: Feature Derivation Paths](https://github.com/dashpay/dips/blob/master/dip-0009.md) +* [BIP-0032: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) +* [BIP-0044: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) + # Specification ## Overview @@ -57,14 +64,16 @@ Normative requirements: * `coin_type'` MUST be `5'` on mainnet (Dash SLIP-44 coin type) and MUST be `1'` on testnet/devnet/regtest (SLIP-44 test coin type), consistent with BIP-44 conventions. * `feature'` MUST be `17'` (Platform payment feature). * `account'` MUST be hardened. `0'` is the default account. Additional accounts MAY be used following BIP-44-style multi-account semantics. -* `key_class'` MUST be hardened. The default class for Platform payment receive keys is `0'`. Additional hardened classes MAY be defined by future DIPs; `1'` is reserved for wallet-internal or change-like segregation if a wallet chooses to implement it. +* `key_class'` MUST be hardened. The default class for Platform payment receive keys is `0'`. Additional hardened classes MAY be defined by future DIPs; `1'` is reserved for wallet-internal or change-like segregation if a wallet chooses to implement it. Wallets MUST ignore unknown key_class values rather than rejecting the entire account. * `index` MUST be non-hardened (`0 ≤ index ≤ 2³¹−1`). * No BIP-44 change level is used; privacy is obtained by incrementing `index` and optionally segregating with `key_class'`. Default account paths: -* Mainnet: `m/9'/5'/17'/0'/0'/index` -* Testnet/Devnet/Regtest: `m/9'/1'/17'/0'/0'/index` (coin type `1'` for test networks). +| Network(s) | Default account path | +|-|-| +| Mainnet | `m/9'/5'/17'/0'/0'/index` | +| Testnet / Devnet / Regtest | `m/9'/1'/17'/0'/0'/index` (coin type `1'` for test networks) | Wallets MAY derive and expose an extended public key at `m/9'/5'/17'/account'/key_class'` (mainnet) or `m/9'/1'/17'/account'/key_class'` (test networks) for watch-only or monitoring. They MUST NOT expose hardened parent levels. diff --git a/dip-0018.md b/dip-0018.md index edfa805d..e3c369ab 100644 --- a/dip-0018.md +++ b/dip-0018.md @@ -16,6 +16,7 @@ 1. [Abstract](#abstract) 1. [Motivation](#motivation) +1. [Prior Work](#prior-work) 1. [Specification](#specification) 1. [Address Types](#address-types) 1. [Encoding](#encoding) @@ -38,6 +39,10 @@ This DIP specifies the address encoding formats for Dash Platform payments. It d Platform payment keys are derived under DIP-0017. To interoperate between wallets, hardware wallets, and services, a standard encoding with explicit network prefixes and checksum rules is required. Script-hash addresses are also needed for multisig and other script-based Platform payments. +# Prior Work + +* [DIP-0017: Dash Platform Payment Addresses and HD Derivation](https://github.com/dashpay/dips/blob/master/dip-0017.md) + # Specification ## Address Types @@ -160,8 +165,7 @@ Passphrase: `""` ## P2SH example -* Script (hex): `76a914000102030405060708090a0b0c0d0e0f101112131488ac` - (standard HASH160-to-pubkey script for illustration) +* Script (hex): `76a914000102030405060708090a0b0c0d0e0f101112131488ac` (standard HASH160-to-pubkey script for illustration) * HASH160(script): `43fa183cf3fb6e9e7dc62b692aeb4fc8d8045636` * Mainnet P2SH: `Pe8D1pMrEnWsmuj5zCEBhHTcsFE51Asp8k` * Testnet P2SH: `pBk15SYRYnnKfMENUnYdGw4cG1wcRmSdoh` From 29eba8c796b6242a444b1815562398ab8facaaf6 Mon Sep 17 00:00:00 2001 From: thephez Date: Wed, 3 Dec 2025 15:43:09 -0500 Subject: [PATCH 5/7] docs: add new dips to readme and update create date --- README.md | 2 ++ dip-0017.md | 2 +- dip-0018.md | 2 +- 3 files changed, 4 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 3f565747..83f8a054 100644 --- a/README.md +++ b/README.md @@ -33,6 +33,8 @@ Number | Layer | Title | Owner | Type | Status [14](dip-0014.md) | Applications | Extended Key Derivation using 256-Bit Unsigned Integers | Samuel Westrich | Informational | Proposed [15](dip-0015.md) | Applications | DashPay | Samuel Westrich, Eric Britten | Standard | Proposed [16](dip-0016.md) | Applications | Headers First Synchronization on Simple Payment Verification Wallets | Samuel Westrich | Informational | Proposed +[17](dip-0017.md) | Consensus | Dash Platform Payment Addresses and HD Derivation | Samuel Westrich | Standard | Proposed +[18](dip-0018.md) | Consensus | Dash Platform Payment Address Encodings | Samuel Westrich | Standard | Proposed [20](dip-0020.md) | Consensus | Dash Opcode Updates | Mart Mangus | Standard | Final [21](dip-0021.md) | Consensus | LLMQ DKG Data Sharing | dustinface | Standard | Final [22](dip-0022.md) | Consensus | Making InstantSend Deterministic using Quorum Cycles | Samuel Westrich, UdjinM6 | Standard | Final diff --git a/dip-0017.md b/dip-0017.md index b0fc68ea..c5eb51f3 100644 --- a/dip-0017.md +++ b/dip-0017.md @@ -6,7 +6,7 @@ Comments-Summary: No comments yet. Status: Draft Type: Standard - Created: 2024-05-23 + Created: 2025-11-28 License: MIT License Replaces: - Superseded-By: - diff --git a/dip-0018.md b/dip-0018.md index e3c369ab..30cb99ac 100644 --- a/dip-0018.md +++ b/dip-0018.md @@ -6,7 +6,7 @@ Comments-Summary: No comments yet. Status: Draft Type: Standard - Created: 2024-05-23 + Created: 2025-11-28 License: MIT License Replaces: - Superseded-By: - From f3c51bc326ef68e4f8b22c648fe2abd95d47a37a Mon Sep 17 00:00:00 2001 From: thephez Date: Wed, 3 Dec 2025 16:07:28 -0500 Subject: [PATCH 6/7] docs: standardize dip number representation and add links --- dip-0017.md | 26 +++++++++++++------------- dip-0018.md | 18 +++++++++--------- 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/dip-0017.md b/dip-0017.md index c5eb51f3..28facce9 100644 --- a/dip-0017.md +++ b/dip-0017.md @@ -32,11 +32,11 @@ # Abstract -This DIP defines Dash Platform payment addresses (“D-addresses”) and their hierarchical deterministic (HD) derivation under DIP-9. It uses Dash coin type 5' on mainnet and coin type 1' on test networks, and introduces a new DIP-9 feature index for Platform payments. The specification standardizes derivation paths (including account separation) and wallet/hardware wallet guidance for Platform payment keys. Address encoding (version bytes and formats) and script-hash address formats are defined in DIP-0018. +This DIP defines Dash Platform payment addresses (“D-addresses”) and their hierarchical deterministic (HD) derivation under [DIP-9](dip-0009.md). It uses Dash coin type 5' on mainnet and coin type 1' on test networks, and introduces a new [DIP-9](dip-0009.md) feature index for Platform payments. The specification standardizes derivation paths (including account separation) and wallet/hardware wallet guidance for Platform payment keys. Address encoding (version bytes and formats) and script-hash address formats are defined in [DIP-18](dip-0018.md). # Motivation -Dash Platform enables value transfers distinct from Dash Core chain UTXO transactions. Wallets require an unambiguous address type, network-specific encodings, and deterministic derivation paths that coexist with BIP-44 Core chain funds and existing DIP-9 features (masternodes, identities, DashPay). This DIP provides a single standard so wallets, hardware wallets, and services can implement Platform payments. +Dash Platform enables value transfers distinct from Dash Core chain UTXO transactions. Wallets require an unambiguous address type, network-specific encodings, and deterministic derivation paths that coexist with BIP-44 Core chain funds and existing [DIP-9](dip-0009.md) features (masternodes, identities, DashPay). This DIP provides a single standard so wallets, hardware wallets, and services can implement Platform payments. # Prior Work @@ -48,11 +48,11 @@ Dash Platform enables value transfers distinct from Dash Core chain UTXO transac ## Overview -Platform payment keys identify recipients of value on Dash Platform. This value includes Dash Credits, which represent DASH held on Platform, as well as other Platform-based payments. These keys are independent of Dash Platform identities and do not belong to an identity’s key set. Instead, they function as standalone payment keys that hold value outside of any identity. They use a single secp256k1 key pair and are not script-based. They are not valid Dash Core chain addresses and MUST NOT be used for Core chain transactions. Their encoding format is specified in DIP-0018. +Platform payment keys identify recipients of value on Dash Platform. This value includes Dash Credits, which represent DASH held on Platform, as well as other Platform-based payments. These keys are independent of Dash Platform identities and do not belong to an identity’s key set. Instead, they function as standalone payment keys that hold value outside of any identity. They use a single secp256k1 key pair and are not script-based. They are not valid Dash Core chain addresses and MUST NOT be used for Core chain transactions. Their encoding format is specified in [DIP-18](dip-0018.md). ## Derivation Path Definition -The Platform payment feature is assigned DIP-9 feature index `17'`. The canonical derivation path is: +The Platform payment feature is assigned [DIP-9](dip-0009.md) feature index `17'`. The canonical derivation path is: ```text m / 9' / coin_type' / 17' / account' / key_class' / index @@ -81,29 +81,29 @@ Accounts follow BIP-44 semantics: `account'` partitions user-controlled sets of ## Wallet and Hardware Wallet Behavior -* Wallets MUST derive Platform payment keys only from `m/9'/5'/17'/account'/key_class'/index` (mainnet) or `m/9'/1'/17'/account'/key_class'/index` (test networks). Address encoding of the resulting public keys is specified in DIP-0018. +* Wallets MUST derive Platform payment keys only from `m/9'/5'/17'/account'/key_class'/index` (mainnet) or `m/9'/1'/17'/account'/key_class'/index` (test networks). Address encoding of the resulting public keys is specified in [DIP-18](dip-0018.md). * Wallets SHOULD clearly separate Platform chain balances from Core chain balances in UI and storage. * Wallets SHOULD rotate addresses by incrementing `index` to avoid reuse; a default gap limit of 20 is RECOMMENDED for discovery. * Wallets MAY support watch-only by exporting the xpub at `m/9'/5'/17'/account'/key_class'` (mainnet) or `m/9'/1'/17'/account'/key_class'` (test networks). * Wallets MAY present multiple accounts following BIP-44 semantics (distinct `account'` values), and SHOULD clearly label the active account in UI. * Hardware wallets MUST whitelist the above derivation path and display a label such as “Dash Platform address” when showing or signing. -* Hardware wallets MUST apply the address encodings defined in DIP-0018 and MUST NOT reinterpret these as Core chain P2PKH/P2SH. +* Hardware wallets MUST apply the address encodings defined in [DIP-18](dip-0018.md) and MUST NOT reinterpret these as Core chain P2PKH/P2SH. * If a wallet does not implement Platform, it simply never derives the `17'` feature path. # Rationale * **Coin type 5' on mainnet, 1' on test networks:** Mainnet keeps Dash SLIP-44 coin type 5', while testnet/devnet/regtest follow SLIP-44 convention with coin type 1'. This avoids new registry allocations and keeps all Dash features under the established namespaces. * **DIP-9 vs BIP-44:** DIP-9’s feature level cleanly separates Platform addresses from Core chain funds and from identities/masternodes without overloading BIP-44’s change level or accounts. -* **Feature index 17':** The next available DIP-9 feature after 16' (DashPay) is reserved for Platform payments, avoiding collisions with existing features. +* **Feature index 17':** The next available [DIP-9](dip-0009.md) feature after 16' (DashPay) is reserved for Platform payments, avoiding collisions with existing features. * **Hardened upper levels:** `9'/coin_type'/17'/account'/key_class'` isolate Platform keys from other features and from each other. An xpub leak below `key_class'` cannot compromise hardened parents. * **Non-hardened leaf index:** Enables watch-only, auditing, and future multisig/shared-custody schemes that rely on unhardened derivation of child public keys. Fully hardened leaves were rejected to preserve these capabilities. -* **Accounts retained:** A hardened `account'` level maintains BIP-44-style multi-account semantics while still isolating Platform keys under the DIP-9 feature branch. +* **Accounts retained:** A hardened `account'` level maintains BIP-44-style multi-account semantics while still isolating Platform keys under the [DIP-9](dip-0009.md) feature branch. * **No BIP-44 change level:** Platform addresses are not UTXO change outputs; a linear `index` (optionally partitioned by `key_class'`) keeps the model simple for hardware wallets and avoids misuse of the 0/1 change bit. # Backwards Compatibility * Classic Dash addresses (`X...`, `7...`, `y...`, `8...`) are unaffected. Nodes do not accept D-addresses in Core chain scripts. -* DIP-3/8 masternode derivations and DIP-13 identity derivations remain unchanged. +* DIP-[3](dip-0003.md)/[8](dip-0008.md) masternode derivations and [DIP-13](dip-0013.md) identity derivations remain unchanged. * Existing seeds stay valid; wallets can add Platform support without migration. * Wallets unaware of Platform will not derive `m/9'/5'/17'/...` and therefore will not interfere with Platform balances. @@ -135,7 +135,7 @@ function platform_payment_key(seed, account, key_class, index, network): } ``` -Encoding and decoding of these payloads into addresses is specified in DIP-0018. +Encoding and decoding of these payloads into addresses is specified in [DIP-18](dip-0018.md). # Security Considerations @@ -157,7 +157,7 @@ Encoding and decoding of these payloads into addresses is specified in DIP-0018. Mnemonic (test-only): `abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about` Passphrase: `""` (empty) -All hex strings are lowercase, big-endian. Address encodings for the HASH160 values are specified in DIP-0018. +All hex strings are lowercase, big-endian. Address encodings for the HASH160 values are specified in [DIP-18](dip-0018.md). | Vector | Path (mainnet / testnet) | account' | key_class' | index | Private Key (hex) | Compressed Pubkey (hex) | HASH160(pubkey) | | ------ | ----------------------- | -------- | ---------- | ----- | ----------------- | ----------------------- | --------------- | @@ -167,11 +167,11 @@ All hex strings are lowercase, big-endian. Address encodings for the HASH160 val # DIP-9 Registry Update -Reserve DIP-9 feature index `17'` for “Platform Payment Addresses”: +Reserve [DIP-9](dip-0009.md) feature index `17'` for “Platform Payment Addresses”: | Feature Index | Feature | DIP | Note | | ------------- | ------- | --- | ---- | -| `17'` | Platform Payment Addresses | DIP-0017 | Sub-path: `17'/account'/key_class'/index` (default account' = `0'`, key_class' = `0'`) | +| `17'` | Platform Payment Addresses | DIP-17 | Sub-path: `17'/account'/key_class'/index` (default account' = `0'`, key_class' = `0'`) | # Copyright diff --git a/dip-0018.md b/dip-0018.md index 30cb99ac..0c1d2d4a 100644 --- a/dip-0018.md +++ b/dip-0018.md @@ -33,11 +33,11 @@ # Abstract -This DIP specifies the address encoding formats for Dash Platform payments. It defines Base58Check parameters for Platform pay-to-public-key-hash (P2PKH) addresses derived via DIP-0017 and introduces Platform pay-to-script-hash (P2SH) addresses. Distinct mainnet and testnet prefixes prevent confusion with Dash Core chain addresses. +This DIP specifies the address encoding formats for Dash Platform payments. It defines Base58Check parameters for Platform pay-to-public-key-hash (P2PKH) addresses derived via [DIP-17](dip-0017.md) and introduces Platform pay-to-script-hash (P2SH) addresses. Distinct mainnet and testnet prefixes prevent confusion with Dash Core chain addresses. # Motivation -Platform payment keys are derived under DIP-0017. To interoperate between wallets, hardware wallets, and services, a standard encoding with explicit network prefixes and checksum rules is required. Script-hash addresses are also needed for multisig and other script-based Platform payments. +Platform payment keys are derived under [DIP-17](dip-0017.md). To interoperate between wallets, hardware wallets, and services, a standard encoding with explicit network prefixes and checksum rules is required. Script-hash addresses are also needed for multisig and other script-based Platform payments. # Prior Work @@ -47,7 +47,7 @@ Platform payment keys are derived under DIP-0017. To interoperate between wallet ## Address Types -* **Platform P2PKH (D-address):** HASH160 of a compressed secp256k1 public key derived per DIP-0017. +* **Platform P2PKH (D-address):** HASH160 of a compressed secp256k1 public key derived per [DIP-17](dip-0017.md). * **Platform P2SH:** HASH160 of a Platform script (e.g., multisig or policy script) for receiving Platform payments to scripts. ## Encoding @@ -88,11 +88,11 @@ An address is valid for a network if: ## Wallet and Hardware Wallet Behavior -* Wallets MUST use the P2PKH encoding above for public keys derived per DIP-0017. +* Wallets MUST use the P2PKH encoding above for public keys derived per [DIP-17](dip-0017.md). * Wallets MUST use the P2SH encoding for Platform scripts intended to receive Platform funds. * Hardware wallets MUST whitelist the version bytes above and display “Dash Platform address” or “Dash Platform script address” as appropriate. * Software wallets SHOULD label Platform balances separately from Core chain balances and SHOULD avoid auto-pasting Platform addresses into Core chain contexts. -* Wallets SHOULD derive payloads via DIP-0017 and then encode using these rules; no alternative prefixes are allowed. +* Wallets SHOULD derive payloads via [DIP-17](dip-0017.md) and then encode using these rules; no alternative prefixes are allowed. # Rationale @@ -102,7 +102,7 @@ An address is valid for a network if: # Backwards Compatibility -No impact on Core chain addresses. Platform P2PKH/P2SH prefixes are new and cannot be misinterpreted as existing Dash formats. Seeds and derivation (DIP-0017) are unchanged. +No impact on Core chain addresses. Platform P2PKH/P2SH prefixes are new and cannot be misinterpreted as existing Dash formats. Seeds and derivation ([DIP-17](dip-0017.md)) are unchanged. # Reference Implementation @@ -147,15 +147,15 @@ function decode_platform_address(addr, network): # Privacy Considerations -* Base58Check addresses are unshielded; privacy relies on HD key rotation per DIP-0017 and script hygiene. +* Base58Check addresses are unshielded; privacy relies on HD key rotation per [DIP-17](dip-0017.md) and script hygiene. * P2SH script hashes reveal neither full script nor participant keys but can still be correlated if reused; wallets SHOULD discourage P2SH reuse. # Test Vectors -Mnemonic (shared with DIP-0017): `abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about` +Mnemonic (shared with [DIP-17](dip-0017.md)): `abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about` Passphrase: `""` -## P2PKH examples (payloads from DIP-0017) +## P2PKH examples (payloads from DIP-17) | Vector | Path (mainnet / testnet) | account' | key_class' | index | HASH160(pubkey) | Mainnet P2PKH | Testnet P2PKH | | ------ | ----------------------- | -------- | ---------- | ----- | --------------- | ------------- | -------------- | From 77c077fc141b893c74c8870fe31d524e6d25d0fd Mon Sep 17 00:00:00 2001 From: thephez Date: Wed, 3 Dec 2025 16:29:52 -0500 Subject: [PATCH 7/7] docs: add more prior work references --- dip-0017.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/dip-0017.md b/dip-0017.md index 28facce9..619b85d9 100644 --- a/dip-0017.md +++ b/dip-0017.md @@ -41,6 +41,8 @@ Dash Platform enables value transfers distinct from Dash Core chain UTXO transac # Prior Work * [DIP-0009: Feature Derivation Paths](https://github.com/dashpay/dips/blob/master/dip-0009.md) +* [DIP-0013: Identities in Hierarchical Deterministic Wallets](https://github.com/dashpay/dips/blob/master/dip-0013.md) +* [DIP-0015: DashPay](https://github.com/dashpay/dips/blob/master/dip-0015.md) * [BIP-0032: Hierarchical Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) * [BIP-0044: Multi-Account Hierarchy for Deterministic Wallets](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)