Skip to content

DIP: Dash Platform Application Key Exchange and State Transition Signing#181

Open
PastaPastaPasta wants to merge 2 commits intodashpay:masterfrom
PastaPastaPasta:dip-pasta-yappr
Open

DIP: Dash Platform Application Key Exchange and State Transition Signing#181
PastaPastaPasta wants to merge 2 commits intodashpay:masterfrom
PastaPastaPasta:dip-pasta-yappr

Conversation

@PastaPastaPasta
Copy link
Member

@PastaPastaPasta PastaPastaPasta commented Mar 11, 2026

Summary

  • Defines the dash-key: URI protocol for wallet-based QR code login to Dash Platform applications using ECDH key exchange and AES-256-GCM encryption
  • Defines the dash-st: URI protocol for requesting wallet signature and broadcast of unsigned state transitions
  • Specifies the full cryptographic flow: BIP32 derivation (m/9'/coin_type'/21'/account'), HKDF key derivation, ECDH shared secret, and per-contract/per-identity key isolation
  • Documents the loginKeyResponse Platform contract schema, indices, and polling mechanism
  • Covers first-time key registration via IdentityUpdateTransition with ECDSA_HASH160 keys

Test plan

  • Review spec for technical accuracy against existing implementations in dash-evo-tool and yappr
  • Verify all cryptographic parameters (HKDF salts, info fields, key sizes) match implementations
  • Review security considerations section for completeness

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Documentation
    • Added a comprehensive specification for two URI-based protocols for wallet‑app interaction: key exchange and state‑transition signing.
    • Defines URI formats, payload layouts, login key derivation/registration flow, encryption/signing workflows, polling lifecycle, validation rules, UX prompts for wallet approvals, governance notes, and security considerations (nonce handling, key cleanup, isolation, forward‑secrecy caveats).

…ansition Signing

Defines the dash-key: and dash-st: URI protocols for wallet-based QR code login to Dash Platform applications. Covers ECDH key exchange, AES-256-GCM encryption, BIP32+HKDF key derivation, the loginKeyResponse contract schema, and first-time key registration flow.
@coderabbitai
Copy link

coderabbitai bot commented Mar 11, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: dbfb7b47-d905-4941-9347-f4fda9f8b84c

📥 Commits

Reviewing files that changed from the base of the PR and between 9482c77 and 50756a7.

📒 Files selected for processing (1)
  • dip-pasta-yappr.md

📝 Walkthrough

Walkthrough

Adds a new DIP describing two URI-based protocols for wallet–app interaction: dash-key (Key Exchange Protocol) and dash-st (State Transition Signing Protocol), specifying URI formats, payload encodings, cryptographic key derivation/encryption flows, data contract schemas, validation rules, and security/UX considerations.

Changes

Cohort / File(s) Summary
DIP Specification Document
dip-pasta-yappr.md
New specification introducing dash-key and dash-st protocols: URI formats and query parameters, Base58/binary payload layouts, deterministic login key derivation (BIP32 path + HKDF), ECDH shared-secret and AES-256-GCM encryption, application key derivation, Dash data contract (loginKeyResponse) and lifecycle, dash-st unsigned state-transition signing workflow, first-time login registration (IdentityUpdateTransition), validation rules, nonce/nonce-management, UX wallet prompts, and security considerations (ephemeral key cleanup, per-identity isolation, forward-secrecy caveats).

Sequence Diagram(s)

mermaid
sequenceDiagram
participant App
participant Wallet
participant Node
App->>Wallet: Open dash-key: URI (includes login request)
Wallet->>Wallet: Derive deterministic login key (BIP32 + HKDF)
Wallet->>App: Provide public key / Base58 payload (encrypted loginKeyResponse request)
App->>Node: Query loginKeyResponse contract / poll
Node-->>App: Return loginKeyResponse (encrypted payload)
App->>Wallet: Forward encrypted loginKeyResponse
Wallet->>Wallet: ECDH -> derive shared-secret, decrypt (AES-256-GCM)
Wallet-->>App: Confirm login (signed response / auth keys)

mermaid
sequenceDiagram
participant App
participant Wallet
participant Node
participant IdentityStore
App->>Wallet: Open dash-st: URI with unsigned state transition
Wallet->>Wallet: Validate wallet identity/keys, fetch signing keys
Wallet->>IdentityStore: (optional) check identity/key metadata
Wallet->>Node: (optional) request additional state or fees
Wallet->>Wallet: Sign state transition per-identity/key selection
Wallet-->>App: Return signed state transition (encoded)
App->>Node: Submit signed state transition to network

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title directly and clearly summarizes the main change: a new DIP document defining two URI-based protocols (dash-key and dash-st) for Dash Platform application authentication and state transition signing.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
📝 Coding Plan
  • Generate coding plan for human review comments

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (2)
dip-pasta-yappr.md (2)

262-265: Consider clarifying concurrent request handling.

The keyIndex logic states that if no document exists, keyIndex is 0. If a wallet processes multiple key exchange requests for the same identity and contract concurrently (before the first document is created), both could use keyIndex 0, potentially creating a race condition. Consider adding guidance on how wallets should handle this scenario (e.g., serialize requests per identity+contract or retry on conflict).

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@dip-pasta-yappr.md` around lines 262 - 265, Clarify concurrent-request
behavior for keyIndex/loginKeyResponse: explain that when no loginKeyResponse
exists wallets must handle races by serializing requests per identity+contract
or using a create-if-not-exists atomic operation and retry-on-conflict;
reference the keyIndex and loginKeyResponse documents and state a recommended
strategy (e.g., queue/serialize per identity+contract, use optimistic
concurrency/version checks on loginKeyResponse, or retry on conflict) so two
concurrent requests cannot both assume keyIndex = 0 and create duplicate keys.

391-401: Consider exponential backoff for revision conflict retries.

The document lifecycle specifies retrying up to 3 times with a fixed 500ms delay on revision conflicts. Consider recommending exponential backoff (e.g., 500ms, 1000ms, 2000ms) to reduce contention under high load while maintaining the same maximum retry count.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@dip-pasta-yappr.md` around lines 391 - 401, The retry logic for handling
revision conflicts when updating a loginKeyResponse document should use
exponential backoff instead of a fixed 500ms delay: update the retry loop that
currently retries up to 3 times with a fixed 500ms pause to instead wait 500ms,
then 1000ms, then 2000ms between attempts (keeping the same max retry count),
and continue to re-query the loginKeyResponse document on each retry and
preserve the existing update/create flow and revision bump behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@dip-pasta-yappr.md`:
- Line 36: The Table of Contents link fragment "#supported-encodings" is broken
because the actual header is "## Encoding"; update either the TOC entry or the
heading so they match—e.g., change the TOC item "* [Supported
Encodings](`#supported-encodings`)" to "* [Encoding](`#encoding`)" or rename the
header "## Encoding" to "## Supported Encodings" so the fragment and header text
are consistent.

---

Nitpick comments:
In `@dip-pasta-yappr.md`:
- Around line 262-265: Clarify concurrent-request behavior for
keyIndex/loginKeyResponse: explain that when no loginKeyResponse exists wallets
must handle races by serializing requests per identity+contract or using a
create-if-not-exists atomic operation and retry-on-conflict; reference the
keyIndex and loginKeyResponse documents and state a recommended strategy (e.g.,
queue/serialize per identity+contract, use optimistic concurrency/version checks
on loginKeyResponse, or retry on conflict) so two concurrent requests cannot
both assume keyIndex = 0 and create duplicate keys.
- Around line 391-401: The retry logic for handling revision conflicts when
updating a loginKeyResponse document should use exponential backoff instead of a
fixed 500ms delay: update the retry loop that currently retries up to 3 times
with a fixed 500ms pause to instead wait 500ms, then 1000ms, then 2000ms between
attempts (keeping the same max retry count), and continue to re-query the
loginKeyResponse document on each retry and preserve the existing update/create
flow and revision bump behavior.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 6edfd7c4-83bf-45c9-b579-c785373b1631

📥 Commits

Reviewing files that changed from the base of the PR and between 40b74e9 and 9482c77.

📒 Files selected for processing (1)
  • dip-pasta-yappr.md

Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9482c77c3f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

| ---------- | ----- | ----------- |
| 9' | Feature purpose (per [DIP-0009](https://github.com/dashpay/dips/blob/master/dip-0009.md)) | |
| coin_type' | `5` (mainnet) or `1` (testnet/devnet/regtest) | Per [BIP-0044](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) |
| 21' | Key exchange feature index | |
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why 21?

| --------- | -------- | ----------- |
| `n` | Yes | Network identifier (`m`, `t`, `d`, or `r`) |
| `v` | Yes | Protocol version; must be `1` |
| `id` | No | Base58-encoded identity identifier hint (32 bytes); wallet should pre-select this identity |
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extraneous word?

Suggested change
| `id` | No | Base58-encoded identity identifier hint (32 bytes); wallet should pre-select this identity |
| `id` | No | Base58-encoded identity identifier (32 bytes); wallet should pre-select this identity |

- Fix broken ToC link: rename heading to 'Supported Encodings' to match ToC entry
- Make Binary Payload Layout a subsection of URI Format and reorder above Network Identifiers
- Simplify BIP32 path table by removing empty Description column
- Add hyperlink to Network Identifiers from dash-st component table
- Remove extraneous 'hint' from id parameter description
- Remove unnecessary 'Read Only' rows from key registration tables
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants