BIP-85: the Nostr path

Adds a dedicated BIP-85 application for deriving Nostr private keys a.k.a. nsec, with a structured /{identity}'/{account}' path supporting multiple unlinkable identities.

Motivation

Today there is no standardized BIP-85 path for Nostr key derivation:

| Method | Path | Problem | |--------|------|---------| | BIP-85 HEX | m/83696968'/128169'/32'/index' | Not Nostr-specific, no identity structure | | BIP-85 mnemonic + NIP-06 | BIP-85 → 12 words → m/44'/1237'/0'/0/0 | Two-step, wasteful intermediate mnemonic | | NIP-06 directly | m/44'/1237'/account'/0/0 | Unhardened, Not BIP-85 entropy isolation |

A dedicated application number eliminates this fragmentation.

Without an isolated derivation path, a mnemonic imported into a Nostr-aware wallet could collide with keys already in use by a Bitcoin wallet (or vice versa). A dedicated BIP-85 application isolates Nostr key derivation entirely, preventing any cross-protocol key reuse.

The structured {identity}'/{account}' path also enables account discovery: a wallet can derive pubkeys aka npub for the first N identities and accounts, then query Nostr relays for events signed by those keys to automatically recover all active accounts.

Application number: 86

The number is the sum of alphabetical positions of the letters in nostr (n=14 + o=15 + s=19 + t=20 + r=18). This deliberately avoids 1237 (the SLIP-0044 coin type used in NIP-06's m/44'/1237'/...) to clearly distinguish BIP-85 derivation from NIP-06 derivation.

m/83696968'/86'/{identity}'/{account}'

Identity index 0' and account index 0' across identities are reserved for future key management operations.

From this new application number, identity semantics (proof-of-linkage, key rotation, account discovery) can be specified in an external NIP that references this application.

Implementation commitment

I maintain two BIP-85 libraries and can port this application to both:

• Rust: bip85_extended
• Dart/Flutter: bip85_entropy