BIP85: add Nostr application

[ethicnology]

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

[murchandamus]

This doesn’t strike me as related to Bitcoin. Perhaps this would be better directed at the NIPs repository.

[ethicnology]

Hello @murchandamus

I'm surprised by this reaction since most of the applications specified in this BIP are not directly Bitcoin related either (RSA, Dice, Passwords...)

[murchandamus]

Maybe I reacted too quickly. @akarve, please let us know whether you are interested in accepting this PR.

[akarve]

Maybe I reacted too quickly. @akarve, please let us know whether you are interested in accepting this PR.

Thanks for caring, @murchandamus.

@ethicnology nostr could be a reasonable BIP85 app. I'm probably missing something about nostr since I don't know it deeply, so I will ask a few basic questions to make sure we aren't reinventing any wheels. Looking at NIP-06 there are BIP32 and BIP39 derivations for nostr keys. BIP85 already has apps for 32' and 39'.

• What is missing if one just assigns an integer key index for either app as their nostr index and then derives the nsec and npub?
• How does your proposed derivation relate to the recommended BIP32 m/44'/1237'/<account>'/0/0 derivation?

For later (if we get there):

• Higher app numbers are better (less collisions, higher = later, saves room for BIPs) so I'd recommend one number per letter of nostr
• I am updating the linked reference implementation to have an app protocol soon and would request if we move forward that you extend the same https://github.com/akarve/bipsea