the immutable and the exposed: bitcoin protects its past, nostr cannot

the shared weakness

bitcoin keys and nostr keys are the same kind of object: a secp256k1 keypair where the public key is derived from the private key by elliptic curve multiplication. that operation is one way today. Shor's algorithm makes it two way. given a public key, a large enough quantum machine recovers the private key by solving the discrete log problem in polynomial time

so far, identical exposure. the divergence is entirely in what each system does with that key, and what is sitting in the open waiting to be attacked

bitcoin: the past is permanent, the risk is forward

bitcoin's ledger is a hash chain secured by SHA-256 proof of work. hashing is not broken by Shor, and Grover's algorithm only weakens it quadratically, dropping 256 bit security to roughly 128 bit effective, which is still comfortably safe. that means no quantum computer rewrites bitcoin history. a confirmed transaction from 2011 stays confirmed. the record is immutable in the way it was always advertised to be

what quantum does threaten in bitcoin is ownership, not history. if your public key is exposed on chain, an attacker can derive your private key and move your coins. exposure happens for reused addresses, old pay to public key outputs, and any address that has already spent once and revealed its key. Satoshi era coins sitting in P2PK outputs are the textbook example

here is the part that matters: the threat is forward looking, and you can act on it. you can move your coins to a fresh address whose public key has never been revealed, and one day to a post quantum address scheme when the network adopts one. the danger is in front of you, which means there is something you can do before it arrives

nostr: the past is the liability, and you cannot act on it

nostr inverts this completely. in nostr your public key is your identity, the npub, and it is broadcast in plaintext inside every single event you ever publish. there is no hash wrapper hiding it, no spend-once reveal, no narrow window. it sits on relays permanently, fully exposed, from the first day you use it

now consider the direct messages. nostr DMs encrypt the body with a symmetric cipher, AES-256 in the older NIP-04, ChaCha20 in the newer NIP-44. the symmetric layer itself is quantum fine. but the symmetric key is not chosen at random and kept secret. it is derived from an ECDH key exchange over the same secp256k1 keys. the lock is strong, the key to the lock is hung on an elliptic curve hook that Shor snaps off

put the pieces together and you get the attack known as harvest now, decrypt later:

1. harvest: the encrypted message already lives on public relays, retrievable by anyone, stored indefinitely. the public keys of both sender and recipient are right there beside it. the attacker collects all of this today, at zero cost, and simply keeps it

2. wait: no quantum hardware is needed yet. the adversary is patient because the data never expires off the relays

3. decrypt: when a Shor-capable machine exists, the attacker recovers either party's private key from the public key, recomputes the ECDH shared secret, derives the symmetric key, and decrypts the stored message retroactively. nothing about the old ciphertext needs to change

and there is no forward secrecy to soften this. Signal rotates ephemeral keys with a double ratchet so that cracking one key exposes one sliver of conversation. nostr does not. one long lived identity key decrypts your entire message history. when that single key falls, everything you ever sent falls with it, all at once

the cruelty of the asymmetry is this: in bitcoin you can move your coins before the storm. in nostr there is no action that un-sends a message you already sent. the harvest has already happened. whatever you typed into a nostr DM is, from a cryptographic standpoint, a sealed envelope sitting on a public shelf with a lock that will eventually open by itself

the precise indictment, so no one can wave it away

it would be lazy to say nostr was built carelessly. secp256k1 was the strong, dominant, well tooled choice in its design window, and essentially no deployed messaging system had post quantum key exchange. the same EC weakness lives in TLS, SSH, PGP, and bitcoin itself. nostr is not uniquely soft

what is specific to nostr, and what makes the DM case genuinely worse than most, is the combination of three design facts:

1. permanent public storage: the ciphertext is openly retrievable and never deleted, so the harvest is guaranteed, not opportunistic

2. identity as a public key: the key needed to break the exchange is published in cleartext in every event, not hidden behind a hash or revealed only momentarily

3. no key rotation, no forward secrecy: a single long lived key unlocks the entire archive, so the eventual break is total rather than partial

that is a sharp architectural critique. it is far stronger than a vague charge of weakness, and it is the version that survives scrutiny

the practical warning

treat every nostr DM as eventually public. not certainly, not on a fixed date, large fault tolerant quantum hardware may be ten or fifteen years out or it may stall, the timeline is a probability and not a promise. but the asymmetry of consequences is brutal: if the hardware never arrives you lost nothing by being careful, and if it does arrive then everything you protected by staying quiet is the only thing that stays private

so the rule is simple. do not send secrets, passwords, keys, or anything you need to stay confidential for a decade through nostr DMs. anything sensitive should go through a channel with forward secrecy and, ideally, post quantum key exchange. nostr is excellent for public, signed, censorship resistant speech, which is what it was actually built for. it is the wrong place to whisper

the headline holds in one line: bitcoin's design makes the past safe and the future defensible, while nostr's design makes the past the very thing that is exposed, with nothing you can do now to take it back