Elliptic Curve Diffie-Hellman (ECDH)

Elliptic Curve Diffie-Hellman (ECDH) is a key-agreement protocol that lets two parties, each holding an elliptic-curve key pair, compute an identical shared secret over an insecure channel without ever transmitting that secret. It is the elliptic-curve form of the Diffie-Hellman exchange that underpins much of modern encrypted communication. Because Bitcoin and Nostr both use the secp256k1 curve, the same class of keys that controls coins can also bootstrap private communication — a quiet but powerful overlap for anyone building a sovereign stack.

How the shared secret is formed

If Alice has private key a and public key A = aG, and Bob has private key b and public key B = bG (where G is the curve's generator point), then Alice computes aB and Bob computes bA. Both arrive at the same point, abG, and conventionally its x-coordinate becomes the raw shared secret. An eavesdropper sees only the public keys A and B; recovering the secret from them would require solving the Elliptic Curve Discrete Logarithm Problem, which is computationally infeasible at these key sizes. The raw shared point is never used directly as an encryption key — it is first run through a hash or key-derivation function to produce a clean symmetric key, and implementations must validate incoming public keys, rejecting invalid or malformed points that could leak information about the private key. These subtleties are handled at the library level, which is exactly why hand-rolling ECDH is a classic mistake.

Where sovereign Bitcoiners meet it

The most visible example is Nostr: encrypted direct messages derive a shared key via ECDH over secp256k1 between the sender's and recipient's keys, then encrypt the payload with a symmetric cipher before it ever touches a relay. That means a Nostr identity — structurally a Bitcoin-style keypair — doubles as an end-to-end encryption identity, with no account, server, or certificate authority involved. On the Bitcoin side, ECDH-style shared secrets appear in privacy techniques where a sender and recipient derive addresses only the two of them can compute, letting someone receive to a static identifier without creating visible address reuse on-chain. Hardware wallets and communication tools in the self-custody world lean on the same primitive whenever two devices need a private channel without pre-shared secrets.

ECDH versus signing

It is worth keeping the two uses of a keypair distinct. Signing — whether ECDSA or a Schnorr signature — proves you authorized something; ECDH agreement produces a secret two parties share for encryption. Same curve, same key material mathematics, different jobs. Best practice is to use separate keys for signing and encryption where protocols allow it, so that compromise or exposure in one role does not bleed into the other.

Ephemeral versus static keys

One design choice matters enormously in practice: whether the keypairs used for ECDH are long-lived or generated fresh per session. Static-static ECDH — both parties using their permanent keys — is convenient and deterministic, but if either private key is ever compromised, every past conversation encrypted under that shared secret falls with it. Ephemeral ECDH generates throwaway keypairs per session, so a future key compromise cannot decrypt recorded traffic — the property called forward secrecy, standard in modern TLS. Protocols built on static identity keys, including simple encrypted-DM schemes, trade some of that protection for the simplicity of one identity that is always reachable. The practical takeaway for a sovereign operator: know which model your tools use, protect long-lived keys accordingly, and prefer protocols that layer ephemeral exchanges on top of static identities when the conversation history is worth protecting.

ECDH reuses the very curve mathematics behind your private key and public key, so understanding it connects on-chain custody with off-chain private messaging. For related signing and aggregation topics, see MuSig2 (BIP327) and Taproot (BIP341).