Repository navigation
feat(key-wallet)!: add the DIP-13 rotation level to application encryption paths - #1250
Conversation
…ption paths The application encryption path is about to become permanent on mainnet. DIP-13 (dashpay/dips#191, used by App Connect in dashpay/dips#181) ends it with a hardened 31-bit rotation level so an identity can replace the encryption key for a contract: m/9'/coin'/5'/7'/0'/identityId'/contractId'/purpose'/rotation', serialised as ser32(rotation + 2^31), with rotation 0' first. `DerivationPath::application_encryption_path` now takes `rotation: u32` and returns `Result`, failing with `Error::InvalidChildNumber` if the rotation does not fit in 31 bits. Migration: callers pass the rotation (0 for a first key) and handle the `Result`. The old 8-level layout moved to `application_encryption_path_without_rotation`, which wallets derive only to recognise keys that pre-DIP wallets registered on testnet and devnet. The pinned vectors now cover the rotation keys and keep the legacy pins against the renamed function. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Waiting for bot review — coderabbitai not yet. Wait for the missing reviews, or a writer can post |
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Add validated rotation paths key-wallet/src/dip9.rs |
application_encryption_path now accepts a rotation and returns Result<Self, Error>. It rejects values at or above 2^31. application_encryption_path_without_rotation retains the prior path layout. |
Test rotation and legacy paths key-wallet/src/bip32.rs |
Tests cover rotation bounds, public-key vectors for rotation-specific and pre-DIP paths, and matching a parsed decryption path with rotation 1. |
Priority:
Estimated code review effort: 2 (Simple) | ~12 minutes
Change: Feature
Suggested reviewers: kwvg, xdustinface
Merge Risk: 
Minimal · up to 9aa9f
-
Rotation paths are added while the legacy layout remains available. No merge-blocking issue was identified.
Pre-merge checks: 
4 · 
1
-
Failed checks: 1 warning Passed checks: 4 passedFull details: Docstring Coverage
-
Explanation
Docstring coverage is 66.67% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 3 functions across 2 files.
Resolution
Write docstrings for the functions missing them to satisfy the coverage threshold.
-
Finishing Touches: 💡 1
-
📝 Generate docstrings: 💡
-
- Commit to this branch
- Create a new PR
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
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 help to get the list of available commands.
|
Bots are done — your move: post |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #1250 +/- ##
==========================================
+ Coverage 78.94% 78.96% +0.01%
==========================================
Files 298 298
Lines 79165 79260 +95
==========================================
+ Hits 62497 62584 +87
- Misses 16668 16676 +8
|
Problem
The DIP-13 application encryption key path is about to become permanent on mainnet, and as built in #1049 it cannot express a replacement key.
m/9'/coin'/5'/7'/0'/identityId'/contractId'/purpose'gives an identity exactly one encryption key per contract and purpose, so rotating a compromised or retired key would mean abandoning the contract. DIP-13 (dashpay/dips#191, used by App Connect in dashpay/dips#181) fixes this by ending the path with a hardened 31-bitrotation'level, serialised asser32(rotation + 2^31), with0'as the first key.Fix
DerivationPath::application_encryption_pathnow takesrotation: u32and appendsChildNumber::Hardened { index: rotation }, givingm/9'/coin'/5'/7'/0'/identityId'/contractId'/purpose'/rotation'.Result<Self, Error>. A rotation of2^31or more fails withError::InvalidChildNumber, the same errorChildNumber::from_hardened_idxuses elsewhere in the crate.application_encryption_path_without_rotation. Wallets derive it only to recognise encryption keys that pre-DIP wallets registered on testnet and devnet; new keys must use the rotation path. It is documented rather than#[deprecated]because the pinned legacy vectors in the tests call it and the workspace builds with-D warnings.No other in-repo code calls the function, and
key-wallet-ffidoes not expose it.Migration for callers
rotation(use0for a first key) and handle theResult.application_encryption_path_without_rotationwith the old arguments.dashpay/platform will carry a temporary local append of the rotation level until it bumps to a rev that includes this change, then drop it.
Testing
test_application_key_vectorspins the new rotation keys and keeps the existing legacy pins, now run against the without-rotation function. Mnemonic isabandon ... about, empty passphrase, mainnet coin type5'.0x35..and0x6b..are 32 bytes of that value;ascis00 01 .. 1fanddescisff fe .. e0..../0x35..'/0x6b..'/1'/0'031a882c119e2b1f8e0349b444d877afa2599efeef49a26930fd25518cb6e9d57a.../0x35..'/0x6b..'/1'/1'03d0f6f0f48d968b9554d8e7fe467d7135bacf29d5c4994ca593bd10ebeed696f6.../asc'/desc'/1'/0'02dfed57ddaaea8c0758e8da44513520038eb8d6b0b92109953c14d6ab1087259b.../asc'/desc'/2'/0'020bcde800f41ad1f924477a9502f111445224cc9ab70114ae4e5099ba02bdd034.../asc'/desc'/2'/1'021b97869c21933673076a938337c28848c8bf8094bbe6883e3a4acbf33c639072Path-string tests cover both builders, the largest valid rotation (
2^31 - 1), and rejection of2^31andu32::MAX.Run locally:
cargo fmt --all --check,cargo clippy -p key-wallet --all-features --all-targets -- -D warnings,cargo check --workspace --all-targets, andcargo test -p key-wallet application_(4 passed).🤖 Generated with Claude Code
PR Hygiene ·
9aa9fde/self-reviewedkey-wallet(key-wallet/src/bip32.rs,key-wallet/src/dip9.rs) — approved by xdustinfaceWhen every merge requirement is met, the
PR Hygienecheck passes. Reviewer limits do not block merging; other required GitHub checks and protections still apply.Summary by CodeRabbit