Post-quantum BIP 324: what a recorded Bitcoin connection would give away

Updated September 2026

Most of the quantum conversation on this site is about the box: whether your public key is already on the chain. This page is about something next to it, the encrypted connections Bitcoin nodes use to pass transactions around. On September 18, 2026, a BIP proposal on the bitcoin-dev mailing list put forward a way to add new features to that encryption, with a post-quantum key exchange as the first use. Here is what the risk actually is, what the fix looks like, and why it does not change what you should do with your coins.

What is BIP 324?

BIP 324 is the version 2 peer-to-peer transport. Before it, Bitcoin nodes talked to each other in the clear. Its authors, Dhruv Mehta, Tim Ruffing, Jonas Schnelli and Pieter Wuille, gave the reason plainly: without encryption, "a global passive attacker eavesdropping on all Bitcoin P2P connections can trivially identify the source and timing of a transaction."

The fix works in two steps. First the two nodes agree on a shared secret. Each one makes a fresh, throwaway secp256k1 key, sends the public half as a 64-byte ElligatorSwift encoding that looks like random bytes, and both derive the same secret through an x-only elliptic curve Diffie-Hellman exchange. Then everything else in the session is encrypted with ChaCha20-Poly1305 under keys derived from that secret.

Bitcoin Core turned it on by default in version 27.0, released on April 2, 2024: "BIP324 v2 transport is now enabled by default." Two v2 nodes that meet each other encrypt without anyone configuring anything.

Two design choices matter for what follows. BIP 324 is deliberately unauthenticated: it hides traffic from someone listening, but does not prove who is on the other end. And it makes the whole stream, handshake included, look like random bytes, so a network filter cannot spot Bitcoin traffic by a fixed pattern.

Why could a quantum computer read it later?

The weak step is the first one. The shared secret comes from an elliptic curve exchange on the same curve Bitcoin signatures use, and Shor's algorithm on a large enough quantum computer would recover the private half of an elliptic curve key from its public half. The public halves of both throwaway keys cross the wire at the start of every session.

So an observer who records a session today keeps everything needed for later: the two public keys and the encrypted stream. If a cryptographically relevant quantum computer ever runs, it could recover one throwaway private key, rebuild the shared secret, derive the session keys and read the recording. That is "harvest now, decrypt later", the pattern the EU's financial supervisors warned about this month and that we read through the box earlier this week.

The encryption itself is not the target. Shor's algorithm breaks the exchange that produced the key, not the ChaCha20 cipher that uses it. That is why every proposal below changes the handshake and leaves the cipher alone.

What would a decrypted session actually reveal?

This is where the box helps. Think about what flows through a Bitcoin node's connections: blocks, transactions, lists of peer addresses, and messages announcing that a node has something new.

• Transactions and blocks. These end up on the public chain anyway. Decrypting them years later reveals nothing about their contents that a block explorer does not already show.
• Public keys. A spend carries its public key in the transaction. That key becomes public the moment the transaction confirms, encrypted transport or not. Whether your box is open is decided by what is on the chain, not by what a recording holds.
• Private keys. Never sent. A node relays signed transactions, not the keys that signed them. A decrypted session cannot hand anyone your coins.
• Who said it first, and when. This is the real secret. Which node first passed on a given transaction, at what moment and over which connection is exactly the "source and timing" that BIP 324 was written to hide. Linked to an IP address, it can point to the person who made a payment.

A harvested Bitcoin connection is a privacy problem for later, not a theft problem. The keys that guard your coins are never in the envelope.

That is a real loss for some people. A journalist, an activist or anyone paying from a home connection in a hostile country could be linked to a transaction years after they made it. But it is a different risk from the one that decides whether coins can be stolen, which is covered on long and short exposure.

What changed in September 2026?

The design discussion started earlier. On May 5, 2026, Olaoluwa Osuntokun, who in June also sketched a layer-by-layer plan for post-quantum Lightning, posted "A Post-Quantum Path for BIP 324" to the bitcoin-dev list. Bitcoin Optech summarized it in its June 5 newsletter.

What was missing was a place in the protocol to switch the upgrade on. BIP 324 left one open on purpose: after the handshake, each side sends a version packet, empty today, and the spec says "Any other value for content is reserved for future versions." It even names the likely uses: "post-quantum cryptography upgrades to the handshake, and optional authentication."

On September 18, Liam Gilligan's Transport Feature Negotiation proposal filled that slot. It renames the version packet a negotiation packet: a length, a one-byte header naming a feature, and that feature's data, with header zero reserved. One peer advertises what it supports and the other picks. An empty packet, which every v2 node already sends, still means plain BIP 324, so today's nodes already comply. The proposal deliberately does not define a "version 3" transport, to avoid locking in a post-quantum algorithm before the field settles.

There is no merged BIP, pull request or code for it yet. It is a proposal with open questions attached, among them whether features should be limited to encryption and authentication.

Lightning's PQLN made the opposite call for its own transport. It runs its hybrid handshake on a separate port with no negotiation message at all, because, as its author put it, such a message could be rewritten by a quantum attacker "to force a downgrade." Which approach Bitcoin nodes take is still open.

What would the new handshake look like?

Every serious option uses ML-KEM, the lattice-based key encapsulation NIST standardized as FIPS 203 on August 13, 2024. It does not work like Diffie-Hellman. One side publishes an encapsulation key, the other uses it to wrap a fresh secret and sends back a ciphertext. At the ML-KEM-768 level most proposals pick, FIPS 203 lists the encapsulation key at 1,184 bytes and the ciphertext at 1,088 bytes, against 64 bytes for each ElligatorSwift key today.

Osuntokun laid out several routes:

• Pure ML-KEM. Replace the elliptic curve exchange entirely. Simple, but the session then rests on a scheme far younger than elliptic curves.
• Hybrid in one step. Send an ElligatorSwift key and an ML-KEM key together and hash both secrets into one. An attacker must break both. The catch is that raw ML-KEM keys do not look like random bytes, which undoes one of BIP 324's goals.
• Disguised ML-KEM. Encode the ML-KEM material with Kemeleon, an encoding that makes it look random, the way ElligatorSwift does for curve points. It works, at a cost in speed and complexity.
• Classical first, then upgrade. Run today's BIP 324 handshake unchanged, then do an ML-KEM exchange inside the encrypted channel, combine both secrets and switch to new keys. Outsiders only ever see random bytes, and the post-quantum material travels already encrypted.
• Nested in one step. An outer elliptic curve exchange encrypts an inner, disguised ML-KEM exchange, called an outer encrypts inner nested combiner (OEINC). Same security in fewer round trips, with more moving parts.

His own view: "At a glance, the route of classical-then-pq-upgrade seems to be the simplest. BIP 324 stays as is, then we run ML-KEM within that." Jonas Schnelli, one of BIP 324's authors, agreed in the thread, because it "keeps the byte-0 pseudorandomness property without needing Kemeleon or any new obfuscation primitive." A future attacker recording that session would have to break the outer elliptic curve exchange and the inner ML-KEM exchange to read it.

Why hybrid, and not just post-quantum?

Because nobody wants to bet everything on either side. Elliptic curves have decades of scrutiny and a known quantum weakness. ML-KEM is built to resist quantum attacks but is new, and new schemes sometimes turn out to have classical flaws. Combining the two means the session stays private as long as either one holds. This site's plain explainer on post-quantum cryptography covers why the lattice schemes are young.

The rest of the internet has already made this move. OpenSSH 10.0, released April 9, 2025, made the hybrid "mlkem768x25519-sha256" its default key agreement. Schnelli pointed to it as precedent for simply hashing the two shared secrets together.

Not everyone framed it the same way. Ethan Heilman asked whether Bitcoin should move to TLS 1.3 instead. Osuntokun answered that TLS 1.3 does not support secp256k1 and bundles authentication with certificates, which BIP 324 left out on purpose. conduition noted that isogeny schemes such as CSIDH allow a true Diffie-Hellman-style exchange with 64 to 128 byte keys, but are slow, and asked for clear paths to move to pure post-quantum or back to classical later.

What does it cost a node?

Mostly bytes and a new denial-of-service surface. Today a node that accepts a connection only needs the first 64 bytes before it can compute the shared secret. As Osuntokun put it, "ML-KEM-768 makes the responder do real work before it can decide if a connection is even legit." A flood of fake 1,184-byte keys costs the receiver more than a flood of fake 64-byte ones, so a one-step hybrid would likely need tighter handshake limits and timeouts.

The classical-then-upgrade route softens that. The receiving node still commits after 64 bytes, as now, and only does ML-KEM work for a peer that has already completed a normal BIP 324 handshake. The price is one extra round trip per connection, paid once when two nodes connect, not per transaction.

A few kilobytes per connection is small next to the blocks a node downloads. It is a very different trade from post-quantum signatures on the chain, where every extra byte is paid in every transaction forever.

Why can this ship before Bitcoin's quantum fork?

Because BIP 324 is a conversation between two nodes, not a rule every node enforces. Protecting coins needs a new output type and new signature rules, which is the consensus road BIP-360 is on. Protecting the transport only needs two upgraded nodes that agree to use the new exchange with each other and the old one with everyone else.

Osuntokun's opening post made the same point: "Compared to a consensus change, which requires widespread market agreement, and coordination to achieve, upgrading BIP 324 to be post quantum resistant is a much lower hanging fruit worthy of pursing immediately." Lightning is in the same position one layer up, which is why PQLN can switch on node by node.

Timing favors moving early here, unlike on the chain. A public key on the chain can be protected at any time before a quantum computer arrives, by moving the coins to a never-spent address. A recorded session cannot be protected after the fact. Anything relayed before the upgrade stays in whatever recordings exist.

What should you do now?

• As a holder, nothing. None of this touches your keys or coins. No quantum computer can break secp256k1 today, and that has not changed. Your quantum exposure is still decided by whether your public key is on the chain.
• If you run a node, keep v2 on. It is the default, and encrypted traffic protected by today's exchange is still far better than traffic anyone can read now.
• If transaction privacy matters to you, do not count on encryption alone. BIP 324 hides the stream from passive listeners, but it is unauthenticated and, today, not quantum resistant. Hiding where a transaction comes from at the network level is a separate job from encrypting the stream.
• Watch for a draft BIP and code. The negotiation proposal has no pull request yet, and the thread left open which ML-KEM implementation Bitcoin software would use. When those appear, this page will be updated.