bip bip-324 bitcoin-core cryptography privacy

Bitcoin Core 28.0's Transport V2 Encryption Goes Live: Why P2P Privacy Finally Matters

bitcoinindex.net · · 6 min read
Bitcoin Core 28.0's Transport V2 Encryption Goes Live: Why P2P Privacy Finally Matters

Bitcoin got a massive privacy upgrade nearly two years ago, and almost nobody noticed.

In April 2024, Bitcoin Core 27.0 quietly enabled BIP 324 by default. This protocol encrypts peer-to-peer connections between nodes, turning Bitcoin traffic from easily identifiable plaintext into pseudorandom data that looks like random noise. Your ISP can’t see what transactions you’re relaying. Governments can’t use deep packet inspection to identify and block Bitcoin traffic. Passive eavesdroppers are out of luck.

It’s one of the most significant privacy improvements to Bitcoin’s base layer in years. And most people running full nodes have no idea it’s even turned on.

What BIP 324 actually does

Before BIP 324, every Bitcoin node connection started with a fixed “magic bytes” sequence that screamed “I’m Bitcoin traffic!” to anyone watching. Every transaction relay, every block announcement, every peer handshake was transmitted in plaintext. If you wanted to know which node first broadcast a transaction, you just needed packet capture access to their network. ISPs could do it. State actors could do it. Anyone positioned on the network path could do it.

BIP 324 changes this by encrypting the connection between nodes using elliptic curve cryptography (the same secp256k1 curve Bitcoin uses for signatures). Here’s what it gives you:

Pseudorandom traffic. Bitcoin connections now look indistinguishable from random data. Deep packet inspection can’t identify it as Bitcoin without also flagging every other encrypted protocol.

Forward secrecy. Even if session keys are compromised later, past traffic can’t be decrypted.

Tamper resistance. Before, attackers could flip individual bits in Bitcoin messages without maintaining full protocol state. Now they need to decrypt, modify, and re-encrypt, which means performing an active man-in-the-middle attack instead of passive observation.

Backward compatibility. Nodes running v2 transport still accept v1 connections, so the network doesn’t split. Old nodes keep working, but miss out on the privacy benefits.

The protocol is opportunistic, meaning it doesn’t require certificates or a public key infrastructure. Two nodes that both support v2 transport will automatically negotiate an encrypted connection. If one side doesn’t support it, they fall back to the old plaintext protocol.

The threat model: what this stops (and what it doesn’t)

Let’s be clear about what BIP 324 protects against.

Before: Your ISP could watch Bitcoin traffic and see which transactions your node relayed first. Even though Bitcoin transactions are public once confirmed, knowing that your node was the origin point for a specific transaction can link it to your IP address and potentially your real-world identity. State actors could build maps of the entire Bitcoin network topology just by watching traffic patterns.

After: Passive surveillance stops working. To spy on Bitcoin traffic now, attackers need to become active participants. They have to either:

  • Run a full man-in-the-middle attack (expensive, detectable)
  • Trick your node into connecting to theirs instead of honest peers
  • Force a downgrade to v1 connections (also detectable if you check)

What it doesn’t do: authenticate connections. BIP 324 encrypts traffic, but it doesn’t prove you’re talking to the node you think you’re talking to. A sophisticated attacker positioned on your network path could still intercept the initial handshake and establish two separate encrypted channels, one with you and one with the real peer.

For most users, this tradeoff makes sense. Passive surveillance is cheap and scales to millions of users. Active attacks are expensive and require targeting specific individuals. By forcing attackers to switch from passive to active mode, BIP 324 raises the cost of mass surveillance dramatically.

For high-stakes scenarios where you need to be absolutely certain you’re talking to a specific node (say, your own remote node), BIP 324 includes a session ID mechanism. You can manually compare session IDs over a separate secure channel to verify no man-in-the-middle attack occurred during the handshake.

Why nobody knows this exists

Bitcoin Core 27.0 landed on April 16, 2024. The release notes mentioned BIP 324 in passing: “v2 transport is now enabled by default. It remains possible to disable v2 by running with -v2transport=0.”

That’s it. No fanfare. No explanation of what this means for privacy. No celebration of a years-long engineering effort finally shipping.

Compare that to the media attention given to BIP 324 when it was being designed back in 2019–2023. Plenty of technical deep dives, plenty of speculation about when it might ship. But when it actually became the default? Silence.

Part of the problem is visibility. If you’re running Bitcoin Core, nothing in the GUI tells you your connections are encrypted. You have to open a terminal and run bitcoin-cli getpeerinfo to see a session_id field that confirms you’re using v2 transport. Most users never look.

Another issue: Bitcoin Core has roughly 95% market share among full nodes, but it’s the only major implementation with BIP 324 support. Connections to btcd, libbitcoin, and other clients fall back to unencrypted v1. So even though your node supports v2, not every connection will use it.

The result is a privacy win that happened almost entirely in the background. Good for user experience (no breaking changes, no manual configuration), bad for awareness.

How to check if you’re actually using v2 transport

If you’re running Bitcoin Core 27.0 or later, v2 transport is enabled by default. To verify which of your connections are encrypted:

bitcoin-cli getpeerinfo | grep -A 5 "session_id"

A v2 connection will show a session_id field with a 64-character hex string:

{
  "id": 42,
  "addr": "203.0.113.45:8333",
  "transport_protocol_type": "v2",
  "session_id": "a1b2c3d4e5f6..."
}

A v1 connection (unencrypted fallback) will have an empty session_id field:

{
  "id": 43,
  "addr": "198.51.100.23:8333",
  "transport_protocol_type": "v1",
  "session_id": ""
}

If you’re still running Bitcoin Core 26.0 or earlier, v2 transport is either experimental (26.0, opt-in only) or not supported at all (25.0 and earlier). Upgrading to the latest version is the easiest way to take advantage of encrypted connections.

For paranoid users who want to manually verify no man-in-the-middle attack occurred on a specific connection, you can compare session IDs out-of-band. If you’re connecting to your own remote node, check the session_id on both ends and compare them over a separate secure channel (Signal, encrypted email, etc.). If they match, the handshake was clean.

What comes next

BIP 324 is foundational work. It gets encryption turned on, but authentication is still missing. Future protocol versions could add optional authentication, letting nodes prove their identity if they choose to. The session ID mechanism was designed with this in mind.

There’s also the question of adoption beyond Bitcoin Core. A “BIP324 Proxy” proof-of-concept exists to help alternative implementations integrate v2 transport without rewriting their entire networking stack, but it’s still early stage. Until btcd, libbitcoin, and others ship native support, a chunk of the network will keep using unencrypted v1 connections.

And honestly, the biggest challenge might just be awareness. A privacy feature only works if people know it exists and understand why it matters. Right now, BIP 324 is the best-kept secret in Bitcoin infrastructure.

If you run a full node, check your connections. If you’re still on an old version, upgrade. If you know someone who runs a node and hasn’t heard of BIP 324, tell them.

Privacy doesn’t announce itself. Sometimes you have to go looking for it.

Sources

Last updated: February 27, 2026