Twenty-Four Words for an nsec

An nsec is a Nostr private key: thirty-two bytes of pure entropy, the cryptographic root of an online identity, structurally identical to a Bitcoin private key and yet stranded in a tooling vacuum. People paste their nsec into password managers, screenshot it into iCloud, email it to themselves, and occasionally print the hex on paper that fades in a year. Bitcoin solved this problem over a decade ago with mnemonic phrases stamped into titanium rated for fires and floods, yet that infrastructure remains formally inaccessible to Nostr because of a misunderstanding about what BIP39 does.

NIP-06 specifies that a Nostr key can be derived from a BIP39 mnemonic by feeding the phrase through PBKDF2 to produce a 512-bit seed and then walking BIP32 to path m/44'/1237'/0'/0/0 to emerge with a child key. This pipeline runs in one direction only. Given a mnemonic you can compute the nsec; given an nsec the mnemonic is permanently lost, because PBKDF2 and BIP32 derivation are one-way functions designed for irreversibility. The Stack Exchange answers warning "the seed phrase is unrecoverable from a private key" describe this pipeline accurately, and the warning has hardened into a folk belief that any word-based encoding of an existing private key remains out of reach.

The folk belief is wrong. A second, much simpler operation hides inside BIP39 that does exactly what we want.

When a fresh Bitcoin wallet generates a 24-word phrase, the procedure starts from 256 bits of random entropy, appends an 8-bit SHA256 checksum to make 264 bits, splits those bits into twenty-four groups of eleven, and looks up each group as an index into a 2048-word table. This is just base conversion: radix-2 to radix-2048, the same operation that turns binary into hexadecimal except with a much larger alphabet. Base conversion is bijective by construction. The same 256 bits always produce the same twenty-four words, and the same twenty-four words always recover the same 256 bits, deterministically, forever. BIP39 then continues onward into PBKDF2 and BIP32, but that continuation is a choice, not a requirement.

The proposal here is to stop after the bijective step.

Take any existing Nostr private key. Treat its 32 bytes as 256 bits of entropy, compute a single checksum byte, concatenate to get 264 bits, slice into twenty-four 11-bit indices, and look up each index in the BIP39 wordlist. The output is a 24-word phrase. Run the procedure in reverse and you recover the exact same nsec you started with, byte for byte, this year or in twenty years. The original key remains in place and the encoding is a pure mathematical function of bytes that already exist.

Here is where the design has to be careful, because a naive version steals money. If a Nostr 24-word phrase used the same SHA256 checksum as BIP39, then roughly one in every 256 such phrases would coincidentally pass the BIP39 validator when pasted into a Bitcoin wallet, silently deriving an unrelated private key via PBKDF2 and presenting the user with an empty wallet that has zero connection to their Nostr identity. That is a footgun: rare enough to escape testing, common enough to drain real funds in production. The fix is a keyed checksum. Compute HMAC-SHA256 over the 32 bytes with a fixed Nostr-specific key string, take the first byte, append it. The math preserves BIP39's one-in-256 error-detection rate against transcription errors but flips the cross-protocol failure mode from silent to loud. Any Bitcoin wallet that receives a Nostr phrase rejects it with overwhelming probability, and the same goes in reverse. The two formats share a wordlist and a word count yet remain fully disjoint at the bit level.

This unlocks an entire shadow layer of physical key storage already engineered and paid for, sitting in safes and bank vaults around the world. Titanium plates from Cryptotag, the SeedHammer machine that punches words onto stainless-steel washers, and the Trezor Keep stainless-steel card together cover most of the serious end of the market. The procedure for engraving 24 words onto metal is solved and tested against literal house fires. Someone who already stamped their Bitcoin seed onto a Trezor Keep can reuse the same plate format and engraving tool and fireproof safe for a separate Nostr identity. At the layer that matters to the physical tools, the two procedures are identical.

The deeper point is that Nostr should reuse cypherpunk infrastructure where it can rather build duplicate versions from scratch. Bitcoin spent more than a decade engineering the physical layer of cryptographic key storage, and that work transfers without modification when the encoding format meets the existing tooling halfway. The current state, where Nostr keys live as raw hex strings in password managers and iCloud screenshots, is a default that nobody questioned because the NIP-06 framing made the bijective operation look impossible. A bijective encoding skips NIP-06 entirely. The PBKDF2 and BIP32 derivation machinery sits unused. Base conversion plus a checksum byte does the whole job, primitives that every Bitcoin library has shipped for over a decade.

The serious objections are about coordination, not cryptography. Existing nsec users would need a tool to compute their twenty-four words, and that tool needs to ship in the wallets people use: Amber, nos2x, Coracle, Damus, Primal. The phrase format needs a name that makes its non-BIP39 nature visible at first glance, like "nsec24" or "nwords," so that a user holding a phrase knows immediately what tooling can interpret it. The keyed checksum needs standardization in a NIP so all implementations produce identical output. These are coordination problems, and Nostr coordinates faster than most protocols because the relay model removes the need for consensus on much of anything.

The objection worth dismissing is the suggestion that users should "just generate a fresh key from a BIP39 mnemonic" using NIP-06. That tells someone with years of accumulated identity to abandon it and start over for the privilege of engraving their key on metal. It treats the encoding format as more important than the identity itself, inverting the real stakes. An encoding that demands key rotation to adopt is a replacement for the key, masquerading as an encoding of it.

Twenty-four words for an nsec asks nothing of the key beyond a base conversion that any computer runs in microseconds. The identity you already have, written down on the same steel plate that holds your bitcoin, recoverable by the same procedure your hardware wallet already implements, distinct enough from a Bitcoin seed that no tool confuses the two. The procedure works on every nsec generated since the protocol launched and every nsec generated tomorrow, without permission from anyone. Write the NIP.