BIP85: add Nostr application

[ethicnology]

BIP-85: the Nostr path

Adds BIP-85 application number 128002' for deterministic Nostr private-key derivation.

Derivation path:

m/83696968'/128002'/{identity}'/{account_index}'

identity selects an independent, unlinkable Nostr key namespace; account_index selects a key within that identity. Indices 0' are reserved for future key-management semantics.

The first 32 bytes of BIP-85 entropy are used as the secp256k1 secret key and encoded as an nsec according to NIP-19.

[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.

[akarve]

@ethicnology Your app proposal makes sense. The reference implementation has a new protocol that you can use when PR'ing that repo (and as an implicit test of the protocol and your app): https://github.com/akarve/bipsea/blob/main/src/bipsea/apps/README.md

[murchandamus]

@akarve: Could you clarify, whether this is ready to be merged?

[akarve]

@murchandamus not yet; will review in more detail and circle back

[akarve]

How about 7879838482 per earlier discussion?

[ethicnology]

Isn't it a too big number ?

[jonatack]

Looks like this is the remaining point to resolve?

[ethicnology]

Yes, it is.
86 is too small, but 7879838482 exceeds 2³¹. I want to make sure that won't cause issues.

[akarve]

Isn't it a too big number ?

Good catch. No reason to break integer bounds. Can we try the Hebrew “NSTR”?

[ethicnology]

To avoid removing a char, we could try, the ASCII sum of "nostr" (110+111+115+116+114) –> 566

But then I don't know if it is still too small

If so I could try a date

[akarve]

Up to you to pick something meaningful. I would prefer numbers larger than 1024, as we are already up to BIP-446 and we should give all BIPs a chance to use their own numbers for app codes. Most four letter (haha) semantic words can work, or a zip code from a city meaningful to Nostr, etc. Other apps use COLD or the Vegas zip for dice, etc.

…

On Sat, May 9, 2026 at 10:47 PM Azad ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In bip-0085.mediawiki <#2126 (comment)>: > @@ -441,6 +487,12 @@ BIP32, BIP39 ==Changelog== +===2.1.0=== + +====Added==== + +* Nostr application 86' To avoid removing a char, we could try, the ASCII sum of "nostr" (110+111+115+116+114) –> 566 But then I don't know if it is still too small If so I could try a date — Reply to this email directly, view it on GitHub <#2126 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKC5W6YVOZNLAQRQQ7TZ6L42AJX3AVCNFSM6AAAAACWZDWMMCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHM2DENJYHE2TONZSGU> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ethicnology]

@akarve let's use 9000 ?
It's the zip code of Funchal in Madeira, Portugal. The place where I wrote this pull request during the Sovereign Engineering event.

[akarve]

Go for it.

…

On Mon, May 11, 2026 at 2:08 AM Azad ***@***.***> wrote: *ethicnology* left a comment (bitcoin/bips#2126) <#2126 (comment)> @akarve <https://github.com/akarve> let's use 9000 ? It's the zip code of Funchal in Madeira, Portugal. The place where I wrote this pull request during the Sovereign Engineering <https://sovereignengineering.io/> event. — Reply to this email directly, view it on GitHub <#2126 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKC5WYLBU2G66OL56MVXRL42GKBBAVCNFSM6AAAAACWZDWMMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DIMJZGEYDGNRQGY> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ethicnology]

c0aa336

• 86' → 9000'
• Version bumped 2.0.0 → 2.1.0 to match the changelog entry.
• Added rust-bip85 (1.2.0) and dart-bip85-entropy (1.1.0) to Reference Implementations

[akarve]

I don't see a great reason to do this as written. If it's really about illegal values, fine, but update the description? Otherwise show me for example how you would use the derivation path m/83696968'/9000'/0'/0' in the future? Or do you mean nostr reserves account 0 for its own use, in which case we should link to that spec here. Pretty much every index in this spec starts with 0, it seems weird to do things different just for nostr.

[akarve]

If what you really want is a type segment (for future uses) is that something worth adding now or will it be forward compatible to add a segment for new "types"/sub-apps?

[akarve]

This mostly looks good to me and I anticipate approving after next round of answers/edits. @ethicnology

[akarve]

there’s one but, this is not a big deal so whatever, that’s outside the scope of this PR and in the PR we last touched these lines we decided to keep the historical reference implementations. again either resolution is fine with me.

…

On Tue, May 26, 2026 at 5:58 PM Murch ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In bip-0085.mediawiki <#2126 (comment)>: > -* 1.1.0 Python 2.x library implementation: [https://github.com/ethankosakovsky/bip85] -* 1.0.0 JavaScript library implementation: [https://github.com/hoganri/bip85-js] Right, but why are there three reference implementations in the first place? Unless they are references for different aspects of BIP85, shouldn’t there just be one? — Reply to this email directly, view it on GitHub <#2126?email_source=notifications&email_token=AAKC5W26YY2E3YX7IQRGIB344Y4TJA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIMZWHA3DGMBVGA2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#discussion_r3307784747>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKC5W4MDK3NOHV45ETIRS344Y4TJAVCNFSM6AAAAACWZDWMMCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHM2DGNRYGYZTANJQGQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[akarve]

@jonatack @murchandamus Pre-emptive APPROVE to keep PR moving (I can't approve on GH, only comment).

@ethicnology thanks for the contributions, please address the minor comments before merge.

[akarve]

@ethicnology also please tighten up PR description. I would remove anything that's already expressed in the PR or divergent from the PR decisions (i.e. 90% of PR description can be deleted). This makes history and audit easier.

[ethicnology]

@akarve @jonatack

• updated the changelog date
• renamed account to account_index in the test vectors
• squashed the branch into 3 commits and updated the PR description.