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.
This doesn’t strike me as related to Bitcoin. Perhaps this would be better directed at the NIPs repository.
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...)
Maybe I reacted too quickly. @akarve, please let us know whether you are interested in accepting this PR.
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'.
m/44'/1237'/<account>'/0/0 derivation?For later (if we get there):
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/0derivation?
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: https://github.com/nostr-protocol/nips/issues/1691#issuecomment-4098191665
It makes sense for Nostr to have a defined number in BIP 85
437 | +Account index <code>0'</code> is reserved across all identities for key management operations. 438 | +Usable keys start at <code>identity >= 1'</code> and <code>account >= 1'</code>. 439 | + 440 | +The resulting 32-byte private key is Bech32 encoded as an <code>nsec</code> per NIP19. 441 | + 442 | +====identity=1, account=1====
Can you use something other than this header thing here (===)?
I ask because I think it's nice to just have a minimal 'Nostr' entry in the table-of-contents, so we don't take up too much space there this list of applications get longer
<img width="342" height="470" alt="Image" src="https://github.com/user-attachments/assets/1e1da2e3-1de7-4ad7-9591-bd9f0b95fedb" />
resolved in cdf115e6c2ea8fd21c25084e3fdcf0f489358f0b
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.
@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
@akarve: Could you clarify, whether this is ready to be merged?
@murchandamus not yet; will review in more detail and circle back
427 | + 428 | +Application number: 86' 429 | + 430 | +The application number is the sum of the alphabetical positions of the letters in Nostr (n=14 + o=15 + s=19 + t=20 + r=18) to avoid the confusion with NIP06. 431 | + 432 | +The derivation path format is: <code>m/83696968'/86'/{identity}'/{account}'</code>
It's pretty standard for all BIP applications to take an index. Is there a reason we wouldn't map account to index? This would also simplify your bipsea implementation a bit.
It can be called account_index or so in the path spec but the point is to show that "this is how you get fresh secrets for a fixed identity. Lmk if that makes sense or if there are numbering or collision issues.
Should {account} in the path format spec be {index} or {account_index}?
819db6a31aa715d7992560057f4bba9c4df3de6c
486 | @@ -441,6 +487,12 @@ BIP32, BIP39 487 | 488 | ==Changelog== 489 | 490 | +===2.1.0=== 491 | + 492 | +====Added==== 493 | + 494 | +* Nostr application 86'
How about 7879838482 per earlier discussion?
Isn't it a too big number ?
Looks like this is the remaining point to resolve?
Yes, it is. 86 is too small, but 7879838482 exceeds 2³¹. I want to make sure that won't cause issues.
Isn't it a too big number ?
Good catch. No reason to break integer bounds. Can we try the Hebrew “NSTR”?
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
16 | @@ -17,6 +17,7 @@ extend-ignore-re = [ 17 | "value: .*", 18 | "pqNTRUsign", 19 | "Strnad", 20 | + "nsec1.*",
Thanks for updating here. Completely optional, but while touching this file can also do the following pico-cleanup in the same commit, if you wish:
@@ -16,7 +16,6 @@ extend-ignore-re = [
"prefix.*",
"value: .*",
"pqNTRUsign",
- "Strnad",
"nsec1.*",
]
@@ -30,6 +29,7 @@ Atack = "Atack"
Falke = "Falke"
Meni = "Meni"
Ono = "Ono"
+Strnad = "Strnad"
819db6a31aa715d7992560057f4bba9c4df3de6c
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 https://github.com/bitcoin/bips/pull/2126#discussion_r3214386728:
@@ -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 https://github.com/bitcoin/bips/pull/2126#discussion_r3214386728, 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: @.***>
@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.
Go for it.
On Mon, May 11, 2026 at 2:08 AM Azad @.***> wrote:
ethicnology left a comment (bitcoin/bips#2126) https://github.com/bitcoin/bips/pull/2126#issuecomment-4419103606
@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 https://github.com/bitcoin/bips/pull/2126#issuecomment-4419103606, 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: @.***>
c0aa336f1c164315d9c2ddef2b7706a0108da93d
86' → 9000'Version bumped 2.0.0 → 2.1.0 to match the changelog entry.rust-bip85 (1.2.0) and dart-bip85-entropy (1.1.0) to Reference Implementations484 | 485 | * 1.3.0 Python 3.x library implementation: [https://github.com/akarve/bipsea] 486 | * 1.1.0 Python 2.x library implementation: [https://github.com/ethankosakovsky/bip85] 487 | * 1.0.0 JavaScript library implementation: [https://github.com/hoganri/bip85-js] 488 | +* 1.2.0 Rust library implementation: [https://github.com/ethicnology/rust-bip85] 489 | +* 1.1.0 Dart library implementation: [https://github.com/ethicnology/dart-bip85-entropy]
Please don’t collect long lists of implementations in BIPs. This later creates work for BIP authors and editors, as more people open pull requests to add their own implementations. Such lists then tend to outdate quickly and contain implementations that have not gotten much review in the first place. BIPs are explicitly not meant to be sign-posts to adopting projects.
Please remove any outdated implementations from this list and preferably link to a single reference implementation. If some projects represent the reference for different aspects of this BIP, and you decide to keep more than one, please indicate clearly why more than one is being retained and what they are the reference for.
My bad, I've amended my commit and let only the bipsea reference implementation
6f4756633628637bbb26349790867801d0152239
Thanks!
486 | -* 1.1.0 Python 2.x library implementation: [https://github.com/ethankosakovsky/bip85] 487 | -* 1.0.0 JavaScript library implementation: [https://github.com/hoganri/bip85-js] 488 | 489 | ==Changelog== 490 | 491 | +===2.1.0===
nit, the other changelog entries in this BIP have a date. Perhaps insert (2026-05) or (2026-05-15) here.
done
@ethicnology Can you update the PR description for the application number (86 -> 9000)? @akarve any further feedback here?
422 | @@ -423,6 +423,52 @@ OUTPUT 423 | * DERIVED ENTROPY=5e41f8f5d5d9ac09a20b8a5797a3172b28c806aead00d27e36609e2dd116a59176a738804236586f668da8a51b90c708a4226d7f92259c69f64c51124b6f6cd2 424 | * DERIVED ROLLS=1,0,0,2,0,1,5,5,2,4 425 | 426 | +===Nostr=== 427 | + 428 | +Application number: 9000' 429 | + 430 | +9000 is the zip code of Funchal in Madeira, Portugal, where this specification was written during the Sovereign Engineering event.
It is customary to leave the origin of the number a mystery, even if the number is semantic :)
As the app author this number is really up to you. I would still suggest NSEC or NIP or CHAT or something more likely to be semantic. Think of this as a tiny puzzle or fairy door that readers can solve for themselves and smile later.
The mention of a ZIP Code for Vegas was just because gambling happens in Vegas not because we invented the app there ;)
433 | + 434 | +Uses the entropy as a Nostr private key. 435 | + 436 | +Identity index <code>0'</code> is reserved for future protocol use. 437 | +Account index <code>0'</code> is reserved across all identities for key management operations. 438 | +Usable keys start at <code>identity >= 1'</code> and <code>account_index >= 1'</code>.
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.
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?
This mostly looks good to me and I anticipate approving after next round of answers/edits. @ethicnology
429 | + 430 | +9000 is the zip code of Funchal in Madeira, Portugal, where this specification was written during the Sovereign Engineering event. 431 | + 432 | +The derivation path format is: <code>m/83696968'/9000'/{identity}'/{account_index}'</code> 433 | + 434 | +Uses the entropy as a Nostr private key.
Please consolidate this section with the 32-byte comment (push it below), it doesn't make sense here.
435 | + 436 | +Identity index <code>0'</code> is reserved for future protocol use. 437 | +Account index <code>0'</code> is reserved across all identities for key management operations. 438 | +Usable keys start at <code>identity >= 1'</code> and <code>account_index >= 1'</code>. 439 | + 440 | +The resulting 32-byte private key is Bech32 encoded as an <code>nsec</code> per NIP19.
Can you be more explicit about truncation and which 32 bytes to use? The user gets 64 bytes by standard application of BIP-85 so this is a leap.
60498282aa6c68ad2c5dba64bec8ce89a4e63e10
444 | +INPUT: 445 | +* MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb 446 | +* PATH: m/83696968'/9000'/1'/1' 447 | + 448 | +OUTPUT 449 | +* DERIVED ENTROPY=552ad1d578fe1bc927cec9612651652b07c52dde4017911bc23bc953568075ff
This is not consistent with the rest of the spec. Even if you only use 32-bytes you should show all 64 for test consistency.
60498282aa6c68ad2c5dba64bec8ce89a4e63e10
482 | 483 | ==Reference Implementations== 484 | 485 | * 1.3.0 Python 3.x library implementation: [https://github.com/akarve/bipsea] 486 | -* 1.1.0 Python 2.x library implementation: [https://github.com/ethankosakovsky/bip85] 487 | -* 1.0.0 JavaScript library implementation: [https://github.com/hoganri/bip85-js]
No need to change this section. It's showing up as a net delete; we should leave it as is.
I think this was in reaction to my comment. See: #2126 (review)
Sure but it drops two lines too many, not just the two new ones (which would show up as no diff) but two existing ones.
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?
That is true. If you are OK with deleting them in this PR's scope then I am too. The answer to your question is when we added me as a champion we kept the past-revision-specific implementations but tbh they are bit rotten so getting rid of them is the move. I can do this in a separate PR if you prefer.
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 https://github.com/bitcoin/bips/pull/2126#discussion_r3307784747:
-* 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 https://github.com/bitcoin/bips/pull/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: @.***>
422 | @@ -423,6 +423,48 @@ OUTPUT 423 | * DERIVED ENTROPY=5e41f8f5d5d9ac09a20b8a5797a3172b28c806aead00d27e36609e2dd116a59176a738804236586f668da8a51b90c708a4226d7f92259c69f64c51124b6f6cd2 424 | * DERIVED ROLLS=1,0,0,2,0,1,5,5,2,4 425 | 426 | +===Nostr=== 427 | + 428 | +Application number: 128002'
for all of the prose lines try to get to about 80-100 chars wide, it is much easier to read in a terminal and even on gh that way.
Done in 1e0bf69
431 | + 432 | +Each <code>identity</code> is an independent, unlinkable Nostr key namespace, and each <code>account_index</code> is a distinct key within that identity. 433 | + 434 | +Identity index <code>0'</code> and account index <code>0'</code> are reserved for future key-management use, such as proof-of-linkage between an identity's keys, key rotation, and revocation. Their semantics are out of scope for this BIP and may be specified by a future NIP. Usable signing keys therefore start at <code>identity >= 1'</code> and <code>account_index >= 1'</code>. 435 | + 436 | +The standard application of BIP-85 produces 64 bytes of entropy. Take the first 32 bytes (the 256 most significant bits) as the Nostr private key and discard the trailing 32 bytes, as in the HEX application. This 32-byte private key is then Bech32 encoded as an <code>nsec</code> per NIP19.
Maybe HEX is not the right analogy. Isn't nsec a secp256k1 scalar? if so it makes more sense to use WIF or XPRV as an example and reuse the existing footnote on curve order and bounds, right?
What is Nostr convention, shouldn't we say NIP-19, and then NIP-01 and NIP-06 below?
Updated in 1e0bf69
The body now says NIP-19 in 1e0bf69
493 | -* 1.1.0 Python 2.x library implementation: [https://github.com/ethankosakovsky/bip85] 494 | -* 1.0.0 JavaScript library implementation: [https://github.com/hoganri/bip85-js] 495 | 496 | ==Changelog== 497 | 498 | +===2.1.0 (2026-05-15)===
===2.1.0 (2026-08-02)===
This PR adds the BIP-85 derivation specification for Nostr keys (NIP-19 nsec).
identity and account_index.identity = 0' and account_index = 0' for future key management semantics. Signing keys start from identity >= 1' and account_index >= 1.nsec per NIP-19), discarding the remaining 32 bytes.441 | +The standard application of BIP-85 produces 64 bytes of entropy. Take the first 32 bytes 442 | +(the 256 most significant bits)<ref name="curve-order" /> as the secp256k1 secret key, 443 | +as in the HD-Seed WIF application, and discard the trailing 32 bytes. Encode the secret 444 | +key in Bech32 with the <code>nsec</code> human-readable part as specified by NIP-19. 445 | + 446 | +'''identity=1, account=1'''
let's be consistent about account_index everywhere so it all hangs together with the path above
@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.
@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.
@murchandamus howdy this is approved by me to merge
ACK @akarve To be complete ISTM that https://github.com/akarve/bipsea/pull/70 needs to be merged.