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

[ethicnology]

Hi @akarve, thanks for taking the time

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?

HEX can produce valid Nostr keys but carry no semantics. The integer index is just a counter there is no concept of identity / account, and we cannot perform any discovery.

The two-level {identity}'/{account}' structure allows: multiple unlinkable identities, key rotation within an identity, a dedicated proof key for linkage/revocation (account 0).

How does your proposed derivation relate to the recommended BIP32
m/44'/1237'/<account>'/0/0 derivation?

I want to distinguish my proposal from NIP-06 (or BIP85–> BIP39 + NIP06), because it derives directly from the wallet's master seed without BIP-85 isolation AND the last two path levels are unhardened, exposing sibling keys.

As a wallet (Bull) that offers BIP85 mnemonics to create sub/decoy-wallet, we would invent our own convention to integrate Nostr keys without conflicting with HEX and BIP39 derivations.

Higher app numbers are better

Ok, I'm open to your suggestion.

I would request that you extend bipsea

Ok, will do if we move forward.

PS: Full identity/account semantics allow Nostr enthusiasts to design mechanism for key rotation/migration like this one: nostr-protocol/nips#1691 (comment)

[jodobear]

It makes sense for Nostr to have a defined number in BIP 85

[BullishNode]

I find this useful as an application layer BIP enhancement in the context that a few wallets have expressed the intention of leveraging Nostr identities as payment contacts (already the case for LNURL, with work ongoing for silent payments). Another application being considered is PSBT sharing and multisig coordination over Nostr. It is useful for these wallets to be able to regenerate the Nostr identities in a standardized way from the same mnemonic used to recover Bitcoins. So there is relevance to Bitcoin wallets in addition to the more typical Nostr "social media" apps.