BIP85: add Nostr application#2126
Conversation
ethicnology
changed the title
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
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. |
murchandamus
added
Proposed BIP modification
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'.
For later (if we get there):
|
|
Hi @akarve, thanks for taking the time
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
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.
Ok, I'm open to your suggestion.
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) |
|
It makes sense for Nostr to have a defined number in BIP 85 |
|
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 |
|
|
||
| ====Added==== | ||
|
|
||
| * Nostr application 86' |
There was a problem hiding this comment.
How about 7879838482 per earlier discussion?
There was a problem hiding this comment.
Isn't it a too big number ?
There was a problem hiding this comment.
Looks like this is the remaining point to resolve?
There was a problem hiding this comment.
Yes, it is.
86 is too small, but 7879838482 exceeds 2³¹. I want to make sure that won't cause issues.
There was a problem hiding this comment.
Isn't it a too big number ?
Good catch. No reason to break integer bounds. Can we try the Hebrew “NSTR”?
There was a problem hiding this comment.
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
|
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:
***@***.***>
|
|
@akarve let's use 9000 ? |
|
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:
***@***.***>
|
jonatack
added
the
PR Author action required
|
| * 1.3.0 Python 3.x library implementation: [https://github.com/akarve/bipsea] | ||
| * 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] | ||
| * 1.2.0 Rust library implementation: [https://github.com/ethicnology/rust-bip85] | ||
| * 1.1.0 Dart library implementation: [https://github.com/ethicnology/dart-bip85-entropy] |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
My bad, I've amended my commit and let only the bipsea reference implementation
ethicnology
force-pushed
the
bip85-nostr-application-86
branch
from
c0aa336 to
6f47566
Compare
jonatack
removed
the
PR Author action required
jonatack
left a comment
jonatack
left a comment
There was a problem hiding this comment.
@ethicnology Can you update the PR description for the application number (86 -> 9000)?
@akarve any further feedback here?
…st-bip85 + dart-bip85-entropy reference implementations
ethicnology
force-pushed
the
bip85-nostr-application-86
branch
from
6f47566 to
13f307b
Compare
|
|
||
| Application number: 9000' | ||
|
|
||
| 9000 is the zip code of Funchal in Madeira, Portugal, where this specification was written during the Sovereign Engineering event. |
There was a problem hiding this comment.
It is customary to leave the origin of the number a mystery, even if the number is semantic :)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
The mention of a ZIP Code for Vegas was just because gambling happens in Vegas not because we invented the app there ;)
| Identity index <code>0'</code> is reserved for future protocol use. | ||
| Account index <code>0'</code> is reserved across all identities for key management operations. | ||
| Usable keys start at <code>identity >= 1'</code> and <code>account_index >= 1'</code>. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
left a comment
akarve
left a comment
There was a problem hiding this comment.
This mostly looks good to me and I anticipate approving after next round of answers/edits. @ethicnology
|
|
||
| The derivation path format is: <code>m/83696968'/9000'/{identity}'/{account_index}'</code> | ||
|
|
||
| Uses the entropy as a Nostr private key. |
There was a problem hiding this comment.
Please consolidate this section with the 32-byte comment (push it below), it doesn't make sense here.
| Account index <code>0'</code> is reserved across all identities for key management operations. | ||
| Usable keys start at <code>identity >= 1'</code> and <code>account_index >= 1'</code>. | ||
|
|
||
| The resulting 32-byte private key is Bech32 encoded as an <code>nsec</code> per NIP19. |
There was a problem hiding this comment.
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.
| * PATH: m/83696968'/9000'/1'/1' | ||
|
|
||
| OUTPUT | ||
| * DERIVED ENTROPY=552ad1d578fe1bc927cec9612651652b07c52dde4017911bc23bc953568075ff |
There was a problem hiding this comment.
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.
| * 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] |
There was a problem hiding this comment.
No need to change this section. It's showing up as a net delete; we should leave it as is.
There was a problem hiding this comment.
I think this was in reaction to my comment. See: #2126 (comment)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
|
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:
***@***.***>
|
7 participants
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:
m/83696968'/128169'/32'/index'm/44'/1237'/0'/0/0m/44'/1237'/account'/0/0A 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 akanpubfor 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'sm/44'/1237'/...) to clearly distinguish BIP-85 derivation from NIP-06 derivation.Identity index
0'and account index0'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: