BIP-324 (Encrypted P2P Transport)

What Is BIP-324?

BIP-324, also known as the v2 P2P transport protocol, is a Bitcoin Improvement Proposal that adds encrypted communication between Bitcoin nodes. Authored by Dhruv Mehta, Tim Ruffing, Jonas Schnelli, and Pieter Wuille, it replaces the original v1 protocol that transmitted all peer-to-peer messages in plaintext since Bitcoin's launch in 2009.

Under the v1 protocol, every transaction relay, block propagation, and gossip message traveled across the internet as readable text. Any observer positioned on the network path (an ISP, a state-level actor, or a compromised router) could inspect these messages, identify Bitcoin traffic by its fixed 4-byte magic bytes, and correlate transactions to IP addresses. BIP-324 eliminates this passive surveillance vector by wrapping all communication in authenticated encryption.

The proposal was merged into Bitcoin Core in October 2023 (PR #28331), shipped as an experimental opt-in feature in Bitcoin Core 26.0 (December 2023), and enabled by default in Bitcoin Core 27.0 (April 2024). By early 2026, the majority of reachable Bitcoin nodes had adopted v2 transport.

How It Works

BIP-324 establishes an encrypted channel through a three-phase process: key exchange, version negotiation, and encrypted application data. The design prioritizes two goals: preventing passive eavesdropping and making Bitcoin traffic unidentifiable on the wire.

Key Exchange

When two v2-capable nodes connect, they perform an Elliptic Curve Diffie-Hellman (ECDH) key exchange on the secp256k1 curve. The critical innovation is how the public keys are transmitted: instead of sending raw key bytes (which would be identifiable), each peer encodes its ephemeral public key using ElligatorSwift, a technique that produces a 64-byte string indistinguishable from random data.

1. The initiator generates an ephemeral secp256k1 keypair, encodes the public key as a 64-byte ElligatorSwift string, and sends it along with 0 to 4,095 bytes of random garbage data
2. The responder checks whether the incoming bytes match the v1 protocol's magic prefix: if not, it treats the connection as v2
3. The responder sends its own ElligatorSwift-encoded public key, garbage data, and a 16-byte garbage terminator derived from the shared secret
4. Both peers compute the shared secret via X-only ECDH and derive session keys using HKDF-SHA256

The variable-length garbage data prevents fingerprinting by packet size. Combined with the pseudorandom public key encoding, the entire handshake bytestream contains no recognizable patterns for a network observer to detect.

Encryption Layer

Once the handshake completes, all subsequent communication uses authenticated encryption:

• Payload encryption: ChaCha20-Poly1305 (per RFC 8439) provides both confidentiality and integrity, with a 16-byte authentication tag on every packet
• Length encryption: a separate ChaCha20 stream encrypts the 3-byte packet length field, preventing observers from inferring message types by size
• Forward secrecy within sessions: the FSChaCha20Poly1305 wrapper rekeys every 2^24 (roughly 16.7 million) messages using a hash-based key derivation, so compromising a later key does not expose earlier traffic

HKDF-SHA256 derives four encryption keys from the shared secret (two per direction: one for length, one for payload), a 32-byte session ID for future authentication, and two 16-byte garbage terminators.

Message Format

The v2 protocol introduces a compact message format that replaces the v1 protocol's 24-byte header:

┌─────────────┬────────┬──────────────┬─────────┬──────────┐
│ Length (3 B) │ Header │ Message Type │ Payload │ Tag (16) │
│  encrypted   │ (1 B)  │  (1-13 B)    │  (var)  │  MAC     │
└─────────────┴────────┴──────────────┴─────────┴──────────┘

Header byte:
  Bit 7 = ignore flag (1 = decoy packet, discard after auth)
  Bits 0-6 = reserved

Message type:
  0x01-0xFF = 1-byte short ID (e.g., 0x15 = TX, 0x0E = INV)
  0x00 + 12 ASCII bytes = full command name (fallback)

The 1-byte short message IDs save 11 bytes per message compared to the v1 protocol's 12-byte ASCII command names. Common messages like TX, INV, PING, HEADERS, and CMPCTBLOCK all have single-byte assignments.

Decoy Packets

Setting bit 7 of the header byte marks a packet as a "decoy." The recipient must authenticate the packet (verifying the Poly1305 tag) but then discard the contents. Decoy packets serve as the primary traffic shaping mechanism: nodes can pad traffic volume and timing to resist analysis of transaction propagation patterns.

Why It Matters

Bitcoin's privacy model has long relied on pseudonymity: addresses are not directly tied to identities. But the plaintext P2P protocol undermined this model at the network layer. Even with techniques like Tor or VPNs, the majority of nodes communicated in the clear, creating a rich dataset for surveillance.

BIP-324 shifts the threat model from passive to active. Before v2 transport, an observer could silently collect data at scale. After v2, intercepting traffic requires a persistent man-in-the-middle position: a fundamentally costlier and more detectable operation. This has several practical implications:

• Transaction origin privacy: ISPs can no longer trivially identify which node first broadcast a transaction, making it harder to link transactions to IP addresses
• Censorship resistance: because v2 traffic is indistinguishable from random data, network operators cannot selectively block Bitcoin connections without blocking all unidentified traffic
• Protection against eclipse attacks: encrypted transport makes it harder for attackers to selectively target and manipulate a node's peer connections, since they cannot passively identify which connections carry Bitcoin traffic
• Defense against BGP hijacking: even if an attacker reroutes traffic through their infrastructure, they see only encrypted streams rather than readable Bitcoin messages

For a broader view of how BIP-324 fits into Bitcoin's evolving privacy toolkit alongside CoinJoin, silent payments, and Tor integration, see the Bitcoin Privacy Landscape 2026 research article.

Opportunistic Encryption and Authentication

BIP-324 is intentionally "opportunistic": it encrypts traffic without verifying peer identity. When both sides of a connection support v2, encryption activates automatically. If one side only supports v1, the connection falls back to plaintext. No configuration is required.

This design choice was deliberate. Requiring authentication would demand some form of identity infrastructure (certificate authorities, key registries, or pre-shared keys) that Bitcoin's permissionless network does not have. Opportunistic encryption provides immediate value against the most common threat: passive mass surveillance.

However, the protocol exports a deterministic 32-byte session ID from the key exchange. Node operators can compare session IDs through an out-of-band channel to detect man-in-the-middle attacks today. A future protocol called Countersign (under development by Pieter Wuille, building on work by Greg Maxwell) aims to add mutual authentication on top of BIP-324's encrypted channel, enabling whitelisted connections between trusted nodes without revealing identities to third parties.

Use Cases

Node Operator Privacy

Individuals and businesses running full nodes benefit from encrypted P2P traffic because their ISPs can no longer build profiles of their Bitcoin activity. This is particularly relevant in jurisdictions where Bitcoin usage may attract unwanted attention or where ISPs sell traffic metadata.

Mining Pool Security

Mining pools and large miners relay blocks and block templates between infrastructure nodes. Encrypted transport prevents competitors or adversaries from observing block propagation timing, which could be exploited for selfish mining strategies or fee sniping.

Censorship-Resistant Regions

In countries that actively filter internet traffic, Bitcoin's v1 protocol was trivially blockable. BIP-324's traffic looks identical to any other encrypted stream, requiring deep packet inspection capabilities and willingness to block all unidentified traffic to interfere with it.

Layer 2 Infrastructure

Layer 2 protocols like Lightning and Spark rely on the underlying Bitcoin P2P network for settlement and dispute resolution. Encrypted base-layer transport strengthens the security assumptions of these protocols by reducing the surface area for network-level attacks against the nodes they depend on.

Risks and Considerations

No Protection Against Active Attackers

Without authentication, BIP-324 does not prevent a man-in-the-middle attacker who can intercept the initial handshake. An attacker in this position could establish separate encrypted sessions with both peers, relaying and potentially modifying messages. The session ID mechanism enables detection but requires manual out-of-band verification.

Backward Compatibility and Downgrade

When a v2 node connects to a v1-only node, it falls back to plaintext. An active attacker could force this downgrade by interfering with the initial handshake bytes, stripping encryption from connections that would otherwise be protected. As v2 adoption increases and more nodes run Bitcoin Core 27.0+, the option to disable v1 fallback entirely becomes more viable.

Computational Overhead

The ElligatorSwift key encoding and ChaCha20-Poly1305 encryption add computational cost compared to plaintext v1 connections. In practice, this overhead is negligible for modern hardware: ChaCha20 was specifically designed for high performance on general-purpose CPUs, and the handshake cost is amortized over long-lived connections. Benchmarks from the Bitcoin Core implementation showed no measurable impact on block relay or transaction propagation latency.

Traffic Analysis Limitations

While BIP-324 encrypts message contents, it does not fully hide traffic patterns. Connection timing, volume, and the number of peers remain visible to network observers. Combining BIP-324 with Tor or I2P provides stronger metadata protection. Decoy packets offer some traffic shaping capability, but Bitcoin Core does not yet generate them by default: future releases may add configurable traffic padding.

How to Enable BIP-324

For nodes running Bitcoin Core 27.0 or later, v2 transport is enabled by default. You can verify and configure it through the following:

# Check if v2 transport is active (Bitcoin Core 27.0+)
bitcoin-cli getnetworkinfo | grep v2transport

# Explicitly enable (if disabled)
# Add to bitcoin.conf:
v2transport=1

# Check peer connection types
bitcoin-cli getpeerinfo | grep transport_protocol_type

# Nodes advertise v2 support via service flag
# NODE_P2P_V2 = (1 << 11) = 0x0800

The getpeerinfo RPC includes transport_protocol_type and session_id fields for each connection, allowing operators to verify which peers are using encrypted transport and to compare session IDs for MITM detection.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.