docs: add DIP-17 (derivation for Platform payments) and DIP-18 (platform address encodings) #171
Conversation
…H/P2SH) with Core vs Platform terminology
WalkthroughAdds two new DIPs: DIP-0017 (Dash Platform payment addresses and HD derivation) and DIP-0018 (Dash Platform address encodings using bech32m). Updates DIP-0009 registry to reserve feature index Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes
Possibly related PRs
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
dip-0009/assignments.md(1 hunks)dip-0017.md(1 hunks)dip-0018.md(1 hunks)
🧰 Additional context used
🪛 GitHub Actions: .github/workflows/markdownlint.yml
dip-0017.md
[error] 50-50: MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"]
🪛 GitHub Check: lint
dip-0017.md
[failure] 67-67: Unordered list style
dip-0017.md:67:1 MD004/ul-style Unordered list style [Expected: asterisk; Actual: dash] https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md004.md
[failure] 66-66: Unordered list style
dip-0017.md:66:1 MD004/ul-style Unordered list style [Expected: asterisk; Actual: dash] https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md004.md
[failure] 62-62: Unordered list style
dip-0017.md:62:1 MD004/ul-style Unordered list style [Expected: asterisk; Actual: dash] https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md004.md
[failure] 61-61: Unordered list style
dip-0017.md:61:1 MD004/ul-style Unordered list style [Expected: asterisk; Actual: dash] https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md004.md
[failure] 60-60: Unordered list style
dip-0017.md:60:1 MD004/ul-style Unordered list style [Expected: asterisk; Actual: dash] https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md004.md
[failure] 59-59: Unordered list style
dip-0017.md:59:1 MD004/ul-style Unordered list style [Expected: asterisk; Actual: dash] https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md004.md
[failure] 58-58: Unordered list style
dip-0017.md:58:1 MD004/ul-style Unordered list style [Expected: asterisk; Actual: dash] https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md004.md
[failure] 57-57: Unordered list style
dip-0017.md:57:1 MD004/ul-style Unordered list style [Expected: asterisk; Actual: dash] https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md004.md
[failure] 56-56: Unordered list style
dip-0017.md:56:1 MD004/ul-style Unordered list style [Expected: asterisk; Actual: dash] https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md004.md
[failure] 50-50: Fenced code blocks should have a language specified
dip-0017.md:50 MD040/fenced-code-language Fenced code blocks should have a language specified [Context: "```"] https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md040.md
🪛 LanguageTool
dip-0017.md
[style] ~58-~58: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...t with BIP-44 conventions. - account' MUST be hardened. 0' is the default accoun...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~79-~79: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...t of 20 is RECOMMENDED for discovery. - Wallets MAY support watch-only by exporting the...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~80-~80: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...account'/key_class'` (test networks). - Wallets MAY present multiple accounts following...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🔇 Additional comments (4)
dip-0017.md (2)
154-157: Comprehensive test vectors present.The test vectors cover mainnet/testnet derivations, multiple key classes, and include private keys, compressed pubkeys, and HASH160 payloads—providing good coverage for implementation validation.
107-128: Reference implementation is clear and correct.The pseudo-code correctly demonstrates the derivation path construction, hardened level handling, and HASH160 payload calculation. The comments clarify parameter semantics (hardened vs. non-hardened).
dip-0018.md (2)
152-156: P2PKH test vectors align with DIP-0017.Test vectors correctly reference the HASH160 payloads from DIP-0017's test vectors and show both mainnet (D-prefix) and testnet (d-prefix) encodings, providing good cross-validation between the two DIPs.
118-131: Reference implementation validation logic is correct.The implementation properly validates checksums, checks for 25-byte payload length, and validates version bytes for both network and address type. The testnet validation (line 127–128) correctly handles testnet/devnet/regtest as equivalent networks.
thephez
changed the title
* chore: lint fixes * fix: correct order of feature and account * chore: update copyright * 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. * docs: add new dips to readme and update create date * docs: standardize dip number representation and add links * docs: add more prior work references
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
dip-0017.md (1)
51-54: Minor wording polish: simplify "outside of any identity".Line 53 contains the phrase "hold value outside of any identity." The construction "outside of" is mildly redundant; consider simplifying to "hold value outside any identity" or "hold value independent of any identity" for tighter prose.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
README.md(1 hunks)dip-0017.md(1 hunks)dip-0018.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
dip-0017.md
[style] ~53-~53: This phrase is redundant. Consider using “outside”.
Context: ...standalone payment keys that hold value outside of any identity. They use a single secp256...
(OUTSIDE_OF)
[style] ~67-~67: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...t with BIP-44 conventions. * feature' MUST be 17' (Platform payment feature). * ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~68-~68: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...Platform payment feature). * account' MUST be hardened. 0' is the default accoun...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~89-~89: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...t of 20 is RECOMMENDED for discovery. * Wallets MAY support watch-only by exporting the...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~90-~90: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...account'/key_class'` (test networks). * Wallets MAY present multiple accounts following...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🔇 Additional comments (6)
README.md (1)
36-37: New DIP entries are correctly formatted and placed.Both DIP-17 and DIP-18 entries follow the existing table format, include correct metadata (Samuel Westrich as author, Consensus layer, Standard type, Proposed status), and reference the corresponding markdown files. The sequential numbering after DIP-16 and before DIP-20 is appropriate.
dip-0017.md (4)
55-82: Derivation path specification is clear, well-structured, and properly formatted.The path definition (m/9'/coin_type'/17'/account'/key_class'/index) is presented in logical order with normative requirements clearly delineated. Mainnet/testnet coin_type distinction (5'/1') is correct, default account paths are properly documented, and wallet guidance on xpub export and multi-account support is appropriate. Previous formatting issues (code block language specifier, list markers) are resolved.
84-94: Wallet and hardware wallet behavior is comprehensively specified.Requirements for path derivation, address encoding, UI separation, multi-account support, and hardware wallet labeling are clear and distinct (using MUST/SHOULD/MAY appropriately). References to DIP-18 for address encoding are properly integrated. Previous list formatting issues are resolved.
95-169: Rationale, backwards compatibility, reference implementation, and test vectors are thorough and well-documented.Rationale clearly justifies design choices (hardened separation, non-hardened leaves, feature-based path structure, no change level). Backwards compatibility confirms zero impact on Core chain addresses. Reference implementation is appropriately marked as normative and uses pseudocode. Security and privacy considerations address key isolation, xpub exposure, and cross-layer confusion risks. Test vectors are consistent across DIP-17 and DIP-18 and cover default/alternate key classes.
170-177: DIP-9 registry reservation is properly documented.Feature index 17' is correctly reserved with sub-path notation and default account/key_class values clearly specified. Registry entry aligns with the derivation path specification and references DIP-17 appropriately.
dip-0018.md (1)
1-175: DIP-0018 is complete, well-structured, and properly integrates with DIP-0017.The specification clearly defines Base58Check encoding for Platform P2PKH (D-address) and P2SH addresses with distinct mainnet/testnet prefixes (0x1e/D vs 0x5a/d for P2PKH; 0x38/P vs 0x75/p for P2SH). Validation criteria properly check structure, checksum, and version bytes. Wallet and hardware wallet behavior guidance is comprehensive and addresses labeling and prefix whitelisting. Reference implementation uses appropriate pseudocode syntax (```text). Test vectors are consistent with DIP-17 and include both P2PKH and P2SH examples. Security and privacy considerations appropriately address checksum validation, prefix distinction, script validation, and address reuse risks. The document properly references DIP-17 and establishes clear interoperability between the derivation (DIP-17) and encoding (DIP-0018) specifications.
thephez
requested review from
HashEngineering,
PastaPastaPasta,
UdjinM6 and
pauldelucia
and removed request for
pauldelucia
Co-authored-by: PastaPastaPasta <6443210+PastaPastaPasta@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
dip-0017.md (1)
53-53: Minor style improvement: Remove redundant preposition.The phrase "outside of" can be simplified to "outside" for conciseness without loss of clarity.
-...standalone payment keys that hold value outside of any identity... +...standalone payment keys that hold value outside any identity...
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
dip-0017.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
dip-0017.md
[style] ~53-~53: This phrase is redundant. Consider using “outside”.
Context: ...standalone payment keys that hold value outside of any identity. They use a single secp256...
(OUTSIDE_OF)
[style] ~67-~67: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...t with BIP-44 conventions. * feature' MUST be 17' (Platform payment feature). * ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~68-~68: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...Platform payment feature). * account' MUST be hardened. 0' is the default accoun...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~89-~89: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...t of 20 is RECOMMENDED for discovery. * Wallets MAY support watch-only by exporting the...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~90-~90: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...account'/key_class'` (test networks). * Wallets MAY present multiple accounts following...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🔇 Additional comments (5)
dip-0017.md (5)
33-47: Clear motivation and comprehensive prior work.The abstract effectively summarizes the DIP's purpose, and the motivation section clearly articulates why Platform payment addresses are necessary alongside Platform identities. Prior work properly credits related specifications (DIP-9, DIP-13, DIP-15, BIP-32, BIP-44).
55-82: Comprehensive and well-specified derivation path definition.The normative requirements are clearly articulated with proper hardening distinctions, and the table of default account paths provides quick reference. The guidance on watch-only xpub export and account semantics is helpful for implementers.
84-110: Well-structured wallet requirements and thorough rationale.The wallet behavior section provides clear requirements for both software and hardware wallets, with proper emphasis on preventing Core/Platform address confusion. The rationale section effectively justifies each design decision (coin type selection, hardening levels, feature index, account retention). Backwards compatibility properly addresses impact on existing Dash features and migration paths.
112-167: Solid reference implementation, comprehensive security/privacy guidance, and good test coverage.The pseudo-code reference implementation clearly documents the derivation process with proper parameter handling and output structure. Security considerations address key separation, xpub leakage implications, and hardware wallet safeguards. Privacy section provides practical guidance on address rotation and cross-layer linkability. Test vectors cover both default and non-default key_class configurations with complete derivation details.
169-178: Proper DIP-9 registry entry and licensing.The registry update clearly reserves feature index 17' with appropriate sub-path notation and default values. Copyright and licensing are properly documented.
#173) * feat(dip-18): switch to bech32m encoding with reference implementation Replace Base58Check encoding with bech32m (BIP-350) for Platform addresses. Add Python reference implementation with full DIP-17 test vector validation. * chore: update authors list for dip-18 * chore(dip18): update bech2 hrp to (t)dashevo * docs(dip18): formatting and minor updates * fix(dip18): add BIP-39 NFKD normalization to mnemonic_to_seed Normalize mnemonic and passphrase with NFKD before UTF-8 encoding per BIP-39 spec. * refactor(dip18): use verbatim BIP-350 reference implementation Replace custom Bech32m implementation with exact code from sipa's reference at github.com/sipa/bech32. Adds MIT license header and proper attribution. * docs(dip18): reference Python implementation in spec
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
dip-0018/bech32.py (1)
421-428: Consider adding explicit assertion messages for debugging.The assertions on lines 424-425 lack messages. While the surrounding print statements provide context, explicit assertion messages would aid debugging if these fail.
- assert dec_net_m == "mainnet" and dec_type_m == "p2pkh" and dec_hash_m.hex() == expected_hash - assert dec_net_t == "testnet" and dec_type_t == "p2pkh" and dec_hash_t.hex() == expected_hash + assert dec_net_m == "mainnet" and dec_type_m == "p2pkh" and dec_hash_m.hex() == expected_hash, \ + f"Mainnet round-trip failed for vector {i}" + assert dec_net_t == "testnet" and dec_type_t == "p2pkh" and dec_hash_t.hex() == expected_hash, \ + f"Testnet round-trip failed for vector {i}"
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
README.md(1 hunks)dip-0018.md(1 hunks)dip-0018/bech32.py(1 hunks)
🧰 Additional context used
🪛 GitHub Actions: .github/workflows/markdownlint.yml
README.md
[error] 5-5: markdownlint: MD059 - Link text should be descriptive. Context: ["here"]
🪛 LanguageTool
dip-0018.md
[style] ~144-~144: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...s intended to receive Platform funds. * Wallets MUST treat HRP as the network selector....
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🪛 Ruff (0.14.8)
dip-0018/bech32.py
92-92: Consider [*values, 0, 0, 0, 0, 0, 0] instead of concatenation
Replace with [*values, 0, 0, 0, 0, 0, 0]
(RUF005)
177-177: Avoid specifying long messages outside the exception class
(TRY003)
180-180: Avoid specifying long messages outside the exception class
(TRY003)
183-183: Avoid specifying long messages outside the exception class
(TRY003)
204-204: Avoid specifying long messages outside the exception class
(TRY003)
207-207: Avoid specifying long messages outside the exception class
(TRY003)
210-210: Avoid specifying long messages outside the exception class
(TRY003)
217-217: Avoid specifying long messages outside the exception class
(TRY003)
221-221: Avoid specifying long messages outside the exception class
(TRY003)
227-227: Avoid specifying long messages outside the exception class
(TRY003)
254-254: Ambiguous variable name: I
(E741)
267-267: Ambiguous variable name: I
(E741)
🔇 Additional comments (14)
dip-0018/bech32.py (7)
1-48: LGTM - License and module structure are appropriate.The MIT license header correctly attributes Pieter Wuille's BIP-350 work, and the module docstring clearly documents purpose, dependencies, and usage.
49-140: LGTM - BIP-350 reference code is correctly preserved.The verbatim copy from the official BIP-350 reference ensures correctness and auditability. The static analysis hint (RUF005) about list concatenation style is not applicable here since this is intentionally preserved reference code.
165-192: LGTM - Platform address encoding is well-implemented.The
encode_platform_addressfunction properly validates inputs, constructs the 21-byte payload per DIP-18 specification, and uses Bech32m encoding. The explicit error messages aid debugging in reference implementation context.
194-232: LGTM - Platform address decoding correctly validates all components.The
decode_platform_addressfunction properly verifies Bech32m encoding, validates HRP against known networks, ensures correct payload length (21 bytes), and validates the type byte. The error handling is comprehensive.
252-270: VariableIfollows BIP-32 specification notation.The static analysis warning (E741) about ambiguous variable name
Ican be safely ignored here. The BIP-32 specification usesIto denote the HMAC-SHA512 output, and maintaining this naming aids cross-referencing with the specification document.
272-289: LGTM - Derivation utilities are correctly implemented.The
derive_path,hash160, andpriv_to_compressed_pubfunctions correctly implement their respective cryptographic operations per BIP-32/BIP-39 specifications.
302-341: LGTM - Test vectors are comprehensive.The test vectors cover all address types (P2PKH, P2SH) and networks (mainnet, testnet), aligning with the specification in dip-0018.md. The inclusion of intermediate values (private key, public key, HASH160) enables step-by-step validation.
README.md (1)
36-37: LGTM - DIP entries correctly added to summary table.The new entries for DIP-17 and DIP-18 follow the existing table format with appropriate metadata (Layer: Consensus, Type: Standard, Status: Proposed). The entries are correctly positioned after DIP-16.
dip-0018.md (6)
1-47: LGTM - DIP header and introductory sections are well-structured.The abstract clearly defines scope (bech32m encoding for Platform addresses), motivation explains the need for standardization, and prior work correctly references DIP-17, BIP-173, and BIP-350.
48-103: LGTM - Encoding specification is comprehensive and accurate.The encoding algorithm correctly describes the bech32m flow: payload construction, 8-to-5-bit conversion, checksum computation, and final string assembly. Decoder requirements are clearly specified.
112-127: LGTM - Network parameters are clearly defined.The HRP assignments (
dashevo/tdashevo) and type byte values (0x00/0x01) are unambiguous and correctly differentiate Platform addresses from Core chain addresses.
140-148: LGTM - Wallet behavior requirements are appropriately specified.The MUST/SHOULD requirements provide clear guidance for implementers while allowing flexibility where appropriate. Hardware wallet display requirements ensure users can distinguish Platform addresses.
167-220: LGTM - Reference implementation pseudocode is clear and accurate.The pseudocode correctly demonstrates the encoding and decoding algorithms, matching both the specification text and the Python implementation. Using
textas the code block language is appropriate for pseudocode.
242-256: Test vectors are consistent with the reference implementation.All P2PKH vectors (3 sets) and the P2SH vector match exactly between dip-0018.md and the
bech32.pyimplementation, enabling reliable cross-validation.
|
Updated now with the change to bech32m for DIP 18 @PastaPastaPasta @pauldelucia |
thephez
changed the title
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
dip-0017.md (1)
59-59: Minor: Simplify "outside of" to "outside".Line 59 uses "hold value outside of any identity"; the phrase could be condensed to "hold value outside any identity" for brevity.
-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). 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). +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). 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).Actually, apply this instead:
-Instead, they function as standalone payment keys that hold value outside of any identity. +Instead, they function as standalone payment keys that hold value outside any identity.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
dip-0017.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
dip-0017.md
[style] ~59-~59: This phrase is redundant. Consider using “outside”.
Context: ...standalone payment keys that hold value outside of any identity. They use a single secp256...
(OUTSIDE_OF)
[style] ~73-~73: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...t with BIP-44 conventions. * feature' MUST be 17' (Platform payment feature). * ...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~74-~74: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...Platform payment feature). * account' MUST be hardened. 0' is the default accoun...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~95-~95: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...t of 20 is RECOMMENDED for discovery. * Wallets MAY support watch-only by exporting the...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~96-~96: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...account'/key_class'` (test networks). * Wallets MAY present multiple accounts following...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🔇 Additional comments (1)
dip-0017.md (1)
1-184: Document structure and content are solid. ✅The DIP comprehensively defines Platform payment address derivation, wallet/hardware wallet guidance, security and privacy considerations, and test vectors. Previous markdown linting issues (code block language specifier, bullet style) have been resolved. References properly delegate address encoding to DIP-18 and registry updates to DIP-9. Normative requirements are clearly stated, and the motivation section adequately explains why Platform payment addresses complement identity-based transfers.
|
Note: we should make a pull request to update https://github.com/satoshilabs/slips/blob/master/slip-0173.md once this patch is merged. |
Summary
Clarifies Core chain vs Platform chain semantics and references DIP-0018 for encoding.
Details
mix-ups.
Testing
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.