nostr_quantum_preparation/laans_explanation.md

Laan's explanation

⚠️ Research prototype. This is a short summary of an experimental pre-quantum key-commitment system. It does not, by itself, make a Nostr identity post-quantum secure.

A short summary of how the post-quantum Nostr migration works, matching the implementation.

1. Create a new seed phrase. This is your post-quantum (PQ) Nostr backup. It's a BIP39 mnemonic (24 words by default; 12 words available for testing) — pure entropy, not tied to any algorithm.

2. Derive 5 PQ keypairs from the seed. Using BIP32 hierarchical deterministic derivation (the same standard as NIP-06), each PQ algorithm gets its own child key under the path m/44'/1237'/0'/0/:

   • child 1 → ML-DSA-44
   • child 2 → ML-DSA-65
   • children 3+4 → SLH-DSA-128s
   • children 5+6 → Falcon-512
   • children 7+8 → ML-KEM-768

   The same seed always produces the same PQ keys, so they're recoverable from the seed phrase.

3. Construct the attestation statement. A human-readable text statement is created that names your current npub and the Bitcoin block height, and lists the 5 PQ algorithms. This is the content of a kind 1 Nostr event.

4. Each PQ key signs the attestation. Each PQ signature scheme (ML-DSA-44, ML-DSA-65, SLH-DSA-128s, Falcon-512) signs the attestation text. ML-KEM-768 does NOT sign — it's a KEM (Key Encapsulation Mechanism), not a signature scheme. Its public key is included in a tag without a signature.

5. Your existing identity signs the events. The kind 1 announcement (with PQ signatures in its tags) and a kind 9999 proof carrier (which embeds the kind 1 event as JSON and carries the OpenTimestamps proof) are both signed by your existing Nostr identity via window.nostr.signEvent(). This authorizes the migration.

6. Timestamp the kind 1 event. The SHA-256 of the full signed kind 1 event JSON is submitted to OpenTimestamps, anchoring it to the Bitcoin blockchain. This proves the event existed at this point in time, pre-quantum.

7. Publish both events to relays. The kind 1 announcement and the kind 9999 proof carrier are published. The client then polls for Bitcoin confirmation and republishes the kind 9999 proof carrier with the confirmed OTS proof.

Note: The seed-derived secp256k1 key (at m/44'/1237'/0'/0/0) is derived but not used to sign. There is no "successor signature." The security model relies on OTS precedence — the real event is anchored pre-quantum, and a forged event cannot be backdated to before that anchor.