Standardize a BIP85 Derivation Path for Nostr Keys

[ethicnology]

The title is explicit, bip85 is great, let's standardize a derivation path for Nostr Keys.

This would be very helpful to manage multiple identities over Nostr secured by the same mnemonic.

Derivation path should start after initial bip85 index (83696968') so m/83696968'/1984'/{index}' where index represent the identity of your key

first identity/keys would be 1984'/0', the second 1984'/1' and so on

What do you think?

[vitorpamplona]

Isn't that already on NIP-06? https://github.com/nostr-protocol/nips/blob/master/06.md

[ethicnology]

It seems to derive directly from BIP32 without BIP85 but I may be wrong

[vitorpamplona]

Frankly, I failed to understand the differences between all these BIPs.

[fiatjaf]

I don't get the use case for having multiple keys and a standard derivation method for them. NIP-06 was a mistake.

[ethicnology]

Creating multiple identities (depending on the context) secured and derivated from the same mnemonic

[matejcik]

It seems to derive directly from BIP32 without BIP85 but I may be wrong

You can use BIP-85 to generate a BIP-39 seed, then derive the Nostr keys on the NIP-06 path.
I don't see a good reason to abuse BIP-85 specifically to derive Nostr keys. But see also #1774

[ethicnology]

With BIP85 you can derive various format hex, base64…

The good reason for nostr keys using BIP85 is to standardize the derivation path across applications.

Let's say you use app A from which you derived X nostr accounts, now you are switching to app B with the same mnemonic. The app B should recover your nostr accounts using the standardize path.

[matejcik]

Let's say you use app A from which you derived X nostr accounts, now you are switching to app B with the same mnemonic. The app B should recover your nostr accounts using the standardize path.

That's what NIP-06 is literally for.

BIP-85 allows you to export entropy; i.e., it could be useful if you wanted to generate private keys from a seed and then export those keys to some other app that doesn't understand the seed.
This is possibly valuable, see #1774 (comment), but "standardize the derivation path" is a very small piece of that functionality.

[RandyMcMillan]

👀

[fiatjaf]

Please stop reviving threads for no reason, @RandyMcMillan. If you have something to say then say it.

[ethicnology]

Hello from SEC-06
cc: @jodobear @dergigi @gzuuus

@matejcik

BIP-85 allows you to export entropy; i.e., it could be useful if you wanted to generate private keys from a seed and then export those keys to some other app that doesn't understand the seed. This is possibly valuable, see #1774 (comment), but "standardize the derivation path" is a very small piece of that functionality.

BIP-85 Nostr Key Management

Defining an identity and account semantics for Nostr keys derived via BIP-85, enabling multiple unlinkable identities, account rotation, proof-of-linkage, and account discovery from a single mnemonic.

BIP-85 application 86' defines a derivation path for Nostr secret keys:

m/83696968'/86'/{identity}'/{account}'

Requirements

1. Multiple identities: unlinkable contexts (personal, professional, anonymous)
2. Accounts: multiple keys within an identity (per-app, key rotation)
3. Proof of linkage: prove two accounts belong to the same identity without revealing other identities
4. Account discovery: wallets can scan and recover all accounts from a seed

Specification

Reserved Indices

Index	Level	Purpose
0'	Identity	Reserved for future protocol use (e.g. global revocation across all identities)
0'	Account	Identity proof key (P) — used only for identity management, MUST NOT sign regular Nostr events

Identity Semantics

Identity	Purpose
0'	Reserved
1'	First identity
2'+	Additional identities

Identities are unlinkable by design thanks to hardened derivation guarantees that no observer can determine whether two identities share the same seed.

Account Semantics

Account	Purpose
0'	Identity proof key (P) — signs linkage, migration, and revocation events only
1'	Primary nsec — first Nostr signing key for this identity
2'+	Additional nsec — for rotation or per-application use

Identity Proof Key

The key at account = 0' for each identity is a dedicated identity proof key (P):

• Derived deterministically from the mnemonic (reproducible on recovery)
• MUST NOT sign regular Nostr events (kind 1, DMs, zaps, etc.)
• Signs attestations binding account pubkeys to the identity
• SHOULD never be exposed to a Nostr client, since BIP-85 derives from a Bitcoin mnemonic that is assumed to be securely stored (hardware wallet, secure element), P inherits that security posture. A hardware wallet could sign linkage events directly, or a small dedicated offline tool can handle P operations without leaking the key to any client.

Proof of Linkage

Problem

A user rotates from account 1 to account 2 within the same identity. How does the public verify these are the same person?

Linkage Event

The proof key P publishes a replaceable Nostr event listing all active accounts. Only the latest event matters, adding or revoking a account publishes a new event that supersedes the previous one.

{
  "kind": <replaceable>,
  "pubkey": "<proof_key_pubkey>",
  "content": "",
  "tags": [
    ["p", "<sub_account_1_pubkey>"],
    ["p", "<sub_account_2_pubkey>"],
    ["alt", "Identity linkage proof"]
  ]
}

Account Self-Declaration

To establish the reverse link, from account A back to proof key P, account A publishes a signed Nostr event referencing P's pubkey. This event SHOULD be OpenTimestamps anchored.

Since the event is signed by A and timestamped in Bitcoin, it constitutes a tamper-proof declaration that A claims P as its identity proof key.

OTS Anchoring

The initial linkage event SHOULD be timestamped using OpenTimestamps to anchor the proof key's first appearance in the Bitcoin blockchain.

What is anchored: The event ID (which is a SHA-256 hash committing to the pubkey, tags, and content).

Why: If an attacker compromises an account and tries to claim a different proof key, the OTS proof on A's original declaration demonstrates which proof key was established first. New followers can verify via the Bitcoin timestamp.

Verification

1. Fetch any OTS-anchored event from pubkey_A referencing P
2. Fetch any OTS-anchored event from pubkey_B referencing P
3. Fetch replaceable linkage event from P — verify Schnorr signature
4. Check that both pubkey_A and pubkey_B appear in p tags

All signatures valid and timestamps agree → A and B are the same identity.

Proof Key Operations

1. Account Rotation

When an account is compromised or the user wants to add/remove keys, P publishes an updated linkage event:

{
  "kind": <replaceable>,
  "pubkey": "P",
  "tags": [
    ["p", "<new_account_pubkey>"],
    ["revoked", "<compromised_account_pubkey>", "compromised"],
    ["alt", "Identity linkage proof"]
  ]
}

Clients see the updated event (replaceable) and adjust follows accordingly.

2. Identity Migration

When a user voluntarily moves to a new identity (e.g. from identity 1 to identity 3), P₁ signs a linkage event with a migration tag pointing to the new proof key:

{
  "kind": <replaceable>,
  "pubkey": "P₁",
  "tags": [
    ["p", "<account_A_pubkey>"],
    ["migration", "<P₃_pubkey>"]
  ]
}

Clients see the migration tag, fetch P₃'s linkage event, and discover the new identity's accounts. Identity migration is irreversible and permanently links the two identities.

3. Identity Revocation

If P's secret key is compromised, the owner burns the identity by publishing P's secret key:

Publish P's nsec (secret key) to any relay.

This signals to all clients that P is dead:

• Anyone can verify it's P's real secret key (derive pubkey, confirm match)
• No event from P should be trusted after this point
• All accounts under this identity should be considered untrusted

The owner starts fresh with a new identity index.

Account Discovery

1. Scanning identities starting at index 1' (index 0' is reserved)
2. For each identity, deriving the proof key at account 0' and querying relays for linkage events
3. Scanning accounts starting at index 1' (index 0' is the proof key)
4. For each account, deriving the pubkey and querying relays for any events signed by that key
5. Stopping at each level when consecutive empty slots exceed a gap limit

Examples

Single User, One Identity

m/83696968'/86'/1'/0'  → proof key P (identity management only)
m/83696968'/86'/1'/1'  → Alice's nsec (daily-use key)

Account Rotation

Alice's key is compromised:

m/83696968'/86'/1'/1'  → old nsec (compromised)
m/83696968'/86'/1'/2'  → new nsec (active)
m/83696968'/86'/1'/0'  → P signs updated linkage event: revokes old, adds new

Multiple Identities

Identity 1 (Main):
  m/83696968'/86'/1'/0'  → proof key P₁
  m/83696968'/86'/1'/1'  → Amethyst
  m/83696968'/86'/1'/2'  → Damus

Identity 2 (Anonymous):
  m/83696968'/86'/2'/0'  → proof key P₂
  m/83696968'/86'/2'/1'  → Amethyst
  m/83696968'/86'/2'/2'  → Primal

• Sub-keys within identity 1 can be publicly linked via P₁
• Sub-keys within identity 2 can be publicly linked via P₂
• Identity 1 and 2 cannot be linked (hardened derivation)

Identity Migration

User migrates from identity 1 to identity 3:

P₁ signs linkage event with: ["migration", "<P₃_pubkey>"]

Clients discover identity 3's accounts via P₃. Identities 1 and 3 are now permanently linked.

Security Considerations

1. Proof key security: Since BIP-85 derives from a Bitcoin mnemonic, the seed is assumed to be already securely stored (hardware wallet, metal backup, etc.). The proof key P inherits this security posture — it is derived from the same seed and never needs to leave that secure environment. P only signs during rare operations (initial setup, rotation, migration), so it never needs to be exposed to a Nostr client. A hardware wallet could sign linkage events directly without revealing P's secret key, or a small dedicated offline signing tool could handle P operations in isolation. Compromise of the proof key compromises the entire identity — the only recourse is revocation.

2. Hardened derivation everywhere: Unlike NIP-06 which uses non-hardened derivation for the last two levels, this scheme uses hardened derivation at every level. This prevents the "leaked child key + xpub = all sibling keys" attack at the cost of requiring the master seed for every derivation.

3. Identity unlinkability: Relies on BIP-32 hardened derivation. There is no known way to link hardened child keys without the parent private key. Identity migration intentionally breaks this — it is a one-way, irreversible action.

4. OTS anchoring: Eliminates TOFU assumptions. Even new followers who discover the identity after a compromise can verify which proof key was established first.

5. Mnemonic compromised: If the mnemonic is compromised, all coins, identities, proof keys, and accounts are compromised.

Compatibility

Relationship to NIP-06

This NIP supersedes NIP-06 for wallets that support BIP-85. NIP-06 (m/44'/1237'/account'/0/0) remains valid but lacks:

• BIP-85 entropy isolation
• account structure
• unhardened elements

Relationship to BIP-85 HEX

The existing BIP-85 HEX application (m/83696968'/128169'/32'/index') can produce valid Nostr keys but has no identity/account semantics. This NIP provides a dedicated, structured alternative.

Relationship to BIP-85 BIP39 + NIP-06

Some wallets derive a BIP-85 BIP39 mnemonic (m/83696968'/39'/...) and then feed it into NIP-06 (m/44'/1237'/account'/0/0). This two-step approach works but is wasteful — it generates an intermediate mnemonic that serves no purpose other than being re-derived into a key. Worse, if that derived mnemonic is imported into another wallet, it could produce conflicting keys used for both Nostr and Bitcoin, breaking the isolation that BIP-85 is designed to provide. Application 86' collapses this into a single derivation step with a richer identity/account structure and no ambiguous intermediate mnemonic.

My related work

• rust-bip85
• dart-bip85
• dart-nostr
• Nostr Names over Namecoin / Bitnames –> BIP300 / BIP301
• Nostr silent alarm for Bitcoin wallets
• ZeroStr: ZeroNet over Nostr

References

• BIP-85: The Nostr Path
• BIP-32: Hierarchical Deterministic Wallets
• NIP-06: Basic key derivation from mnemonic seed phrase
• NIP-01: Basic protocol flow
• NIP-19: Bech32-encoded entities
• OpenTimestamps