Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion .typos.toml
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ extend-ignore-re = [
"prefix.*",
"value: .*",
"pqNTRUsign",
"Strnad",
"nsec1.*",
Comment thread
ethicnology marked this conversation as resolved.
]

[default.extend-words]
Expand All @@ -29,6 +29,7 @@ Atack = "Atack"
Falke = "Falke"
Meni = "Meni"
Ono = "Ono"
Strnad = "Strnad"
Toom = "Toom"

[files]
Expand Down
58 changes: 54 additions & 4 deletions bip-0085.mediawiki
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@
Type: Informational
Assigned: 2020-03-20
License: BSD-2-Clause OR OPUBL-1.0
Version: 2.0.0
Version: 2.1.0
</pre>

==Abstract==
Expand Down Expand Up @@ -423,6 +423,52 @@ OUTPUT
* DERIVED ENTROPY=5e41f8f5d5d9ac09a20b8a5797a3172b28c806aead00d27e36609e2dd116a59176a738804236586f668da8a51b90c708a4226d7f92259c69f64c51124b6f6cd2
* DERIVED ROLLS=1,0,0,2,0,1,5,5,2,4

===Nostr===

Application number: 9000'

9000 is the zip code of Funchal in Madeira, Portugal, where this specification was written during the Sovereign Engineering event.

@akarve akarve May 24, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is customary to leave the origin of the number a mystery, even if the number is semantic :)

@akarve akarve May 24, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The mention of a ZIP Code for Vegas was just because gambling happens in Vegas not because we invented the app there ;)


The derivation path format is: <code>m/83696968'/9000'/{identity}'/{account_index}'</code>

Uses the entropy as a Nostr private key.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please consolidate this section with the 32-byte comment (push it below), it doesn't make sense here.


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>.
Comment on lines +436 to +438

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?


The resulting 32-byte private key is Bech32 encoded as an <code>nsec</code> per NIP19.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


'''identity=1, account=1'''

INPUT:
* MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb
* PATH: m/83696968'/9000'/1'/1'

OUTPUT
* DERIVED ENTROPY=552ad1d578fe1bc927cec9612651652b07c52dde4017911bc23bc953568075ff

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

* DERIVED NSEC=nsec1254dr4tclcdujf7we9sjv5t99vru2tw7gqtezx7z80y4x45qwhlsmxapst

'''identity=1, account=2'''

INPUT:
* MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb
* PATH: m/83696968'/9000'/1'/2'

OUTPUT
* DERIVED ENTROPY=4fd36c0061a65db375b4350f44bb62a6d7f716ee93bd0f59887ac50b35fa8b96
* DERIVED NSEC=nsec1flfkcqrp5ewmxad5x585fwmz5mtlw9hwjw7s7kvg0tzskd063wtq34wlgr

'''identity=2, account=1'''

INPUT:
* MASTER BIP32 ROOT KEY: xprv9s21ZrQH143K2LBWUUQRFXhucrQqBpKdRRxNVq2zBqsx8HVqFk2uYo8kmbaLLHRdqtQpUm98uKfu3vca1LqdGhUtyoFnCNkfmXRyPXLjbKb
* PATH: m/83696968'/9000'/2'/1'

OUTPUT
* DERIVED ENTROPY=b2d3b48992d46f98beac0196c4e258417087e467dbec1503342785368f4402c2
* DERIVED NSEC=nsec1ktfmfzvj63he304vqxtvfcjcg9cg0er8m0kp2qe5y7zndr6yqtpq7q5y44

==Backwards Compatibility==

This specification is not backwards compatible with any other existing specification.
Expand All @@ -431,16 +477,20 @@ This specification relies on BIP32 but is agnostic to how the BIP32 root key is

==References==

BIP32, BIP39
BIP32, BIP39, [https://github.com/nostr-protocol/nips/blob/master/01.md NIP01], [https://github.com/nostr-protocol/nips/blob/master/06.md NIP06], [https://github.com/nostr-protocol/nips/blob/master/19.md NIP19]

==Reference Implementations==

* 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]
Comment on lines -439 to -440

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to change this section. It's showing up as a net delete; we should leave it as is.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this was in reaction to my comment. See: #2126 (comment)

@akarve akarve May 26, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?


==Changelog==

===2.1.0 (2026-05-15)===

====Added====

* Nostr application 9000'

===2.0.0 (2025-09-19)===

====Fixed====
Expand Down