BIP85: add Nostr application #2126

pull ethicnology wants to merge 8 commits into bitcoin:master from ethicnology:bip85-nostr-application-86 changing 2 files +56 −5
  1. ethicnology commented at 1:18 PM on March 20, 2026: contributor

    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: 9000

    9000 is the zip code of Funchal in Madeira, Portugal. The place where I wrote this pull request during the Sovereign Engineering event. 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'/9000'/{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:

  2. feat(BIP-85): add Nostr application 86' d3512bdcef
  3. fix: exclude nsec from typos 371277d2e0
  4. ethicnology renamed this:
    feat(BIP85): add Nostr application
    BIP85: add Nostr application
    on Mar 20, 2026
  5. murchandamus commented at 3:58 PM on March 20, 2026: member

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

  6. murchandamus closed this on Mar 20, 2026
  7. ethicnology commented at 4:31 PM on March 20, 2026: contributor

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

  8. murchandamus commented at 11:49 PM on March 20, 2026: member

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

  9. murchandamus reopened this on Mar 20, 2026
  10. murchandamus added the label Proposed BIP modification on Mar 20, 2026
  11. murchandamus added the label Pending acceptance on Mar 20, 2026
  12. akarve commented at 12:32 AM on March 21, 2026: contributor

    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
  13. ethicnology commented at 3:04 PM on March 26, 2026: contributor

    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: https://github.com/nostr-protocol/nips/issues/1691#issuecomment-4098191665

  14. jodobear commented at 3:22 PM on March 26, 2026: none

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

  15. in bip-0085.mediawiki:442 in 371277d2e0 outdated 
     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====
    SatsAndSports commented at 3:49 PM on March 26, 2026:

    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" />

    ethicnology commented at 7:53 PM on March 26, 2026:

    resolved in cdf115e6c2ea8fd21c25084e3fdcf0f489358f0b

  16. BullishNode commented at 4:02 PM on March 26, 2026: none

    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.

  17. Merge branch 'bitcoin:master' into bip85-nostr-application-86 1ce5ca8ab6
  18. BIP-85: use bold text for Nostr test vector labels to reduce TOC entries cdf115e6c2
  19. akarve commented at 7:49 PM on April 4, 2026: contributor

    @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

  20. murchandamus commented at 7:08 PM on April 6, 2026: member

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

  21. akarve commented at 7:10 PM on April 6, 2026: contributor

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

  22. in bip-0085.mediawiki:432 in cdf115e6c2 
     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>
    akarve commented at 9:49 PM on May 3, 2026:

    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.

    ethicnology commented at 2:26 PM on May 4, 2026:

    done in 7cb636fe65670383af523cc9a69748eea8d11ce3

    jonatack commented at 7:42 PM on May 5, 2026:

    Should {account} in the path format spec be {index} or {account_index}?

    ethicnology commented at 11:43 AM on May 6, 2026:

    819db6a31aa715d7992560057f4bba9c4df3de6c

  23. in bip-0085.mediawiki:494 in cdf115e6c2 outdated 
     486 | @@ -441,6 +487,12 @@ BIP32, BIP39
 487 |  
 488 |  ==Changelog==
 489 |  
 490 | +===2.1.0===
 491 | +
 492 | +====Added====
 493 | +
 494 | +* Nostr application 86'
    akarve commented at 9:55 PM on May 3, 2026:

    How about 7879838482 per earlier discussion?

    ethicnology commented at 2:30 PM on May 4, 2026:

    Isn't it a too big number ?

    jonatack commented at 5:43 PM on May 6, 2026:

    Looks like this is the remaining point to resolve?

    ethicnology commented at 6:50 PM on May 6, 2026:

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

    akarve commented at 7:05 PM on May 6, 2026:

    Isn't it a too big number ?

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

    ethicnology commented at 5:47 AM on May 10, 2026:

    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

  24. refactor: according to @jonatack review 819db6a31a
  25. Merge branch 'master' into bip85-nostr-application-86 c1ba10eb37
  26. in .typos.toml:20 in cdf115e6c2 outdated 
      16 | @@ -17,6 +17,7 @@ extend-ignore-re = [
  17 |      "value: .*",
  18 |      "pqNTRUsign",
  19 |      "Strnad",
  20 | +    "nsec1.*",
    jonatack commented at 7:44 PM on May 5, 2026:

    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"
    ethicnology commented at 11:43 AM on May 6, 2026:

    819db6a31aa715d7992560057f4bba9c4df3de6c

  27. jonatack requested review from akarve on May 6, 2026
  28. akarve commented at 6:31 PM on May 10, 2026: contributor

    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: @.***>

  29. ethicnology commented at 9:08 AM on May 11, 2026: contributor

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

  30. akarve commented at 4:44 PM on May 13, 2026: contributor

    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: @.***>

  31. jonatack added the label PR Author action required on May 13, 2026
  32. Merge branch 'bitcoin:master' into bip85-nostr-application-86 1e8baf08ac
  33. ethicnology commented at 11:11 AM on May 14, 2026: contributor

    c0aa336f1c164315d9c2ddef2b7706a0108da93d

    • 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
  34. in bip-0085.mediawiki:488 in c0aa336f1c 
     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]
 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]
    murchandamus commented at 12:32 PM on May 14, 2026:

    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.

    ethicnology commented at 3:08 PM on May 14, 2026:

    My bad, I've amended my commit and let only the bipsea reference implementation

    6f4756633628637bbb26349790867801d0152239

    murchandamus commented at 6:51 PM on May 14, 2026:

    Thanks!

  35. ethicnology force-pushed on May 14, 2026
  36. jonatack removed the label PR Author action required on May 14, 2026
  37. in bip-0085.mediawiki:488 in 6f47566336 
     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===
    jonatack commented at 8:42 PM on May 14, 2026:

    nit, the other changelog entries in this BIP have a date. Perhaps insert (2026-05) or (2026-05-15) here.

    ethicnology commented at 5:36 AM on May 15, 2026:

    done

  38. jonatack commented at 8:44 PM on May 14, 2026: member

    @ethicnology Can you update the PR description for the application number (86 -> 9000)? @akarve any further feedback here?

  39. BIP-86: rename Nostr application 86' to 9000', bump to 2.1.0, list rust-bip85 + dart-bip85-entropy reference implementations 13f307b55e
  40. ethicnology force-pushed on May 15, 2026
Contributors
ethicnologymurchandamusakarvejodobearSatsAndSportsBullishNodejonatack


akarve

Labels
Proposed BIP modificationPending acceptance
github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-05-19 06:50 UTC