P2P Encryption (BIP 324)

What Is P2P Encryption?

P2P encryption is the practice of encrypting communication between peers in a decentralized network so that no third party can read or tamper with the data in transit. In Bitcoin, this concept is realized through BIP 324, the v2 P2P transport protocol authored by Dhruv Mehta, Tim Ruffing, Jonas Schnelli, and Pieter Wuille. It replaced the original v1 protocol, which had transmitted every transaction relay, block propagation, and gossip message as plaintext since Bitcoin's launch in 2009.

Under the v1 protocol, any observer on the network path could identify Bitcoin connections by their fixed 4-byte magic prefix, read every message, and correlate transactions to IP addresses. Internet service providers, government agencies, and compromised routers all had full visibility into node communication. BIP 324 eliminates this surveillance vector by wrapping every message in authenticated encryption, making the bytestream opaque to anyone who is not a direct participant in the connection.

The proposal was merged into Bitcoin Core in October 2023 (PR #28331), shipped as an 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 three phases: a key exchange that produces a shared secret, version negotiation, and encrypted application data. The design achieves two goals simultaneously: encrypting message contents and making Bitcoin traffic unidentifiable on the network.

The ElligatorSwift Handshake

The handshake is the most innovative aspect of BIP 324. When two v2-capable nodes connect, they perform an Elliptic Curve Diffie-Hellman (ECDH) key exchange on the secp256k1 curve. The critical difference from standard ECDH is how public keys are transmitted: instead of sending raw key bytes (which would be identifiable as elliptic curve points), each peer encodes its ephemeral public key using a technique called ElligatorSwift.

ElligatorSwift maps each public key to a 64-byte string that is computationally indistinguishable from random data. This means the very first bytes of a v2 connection look like noise, not like a cryptographic handshake. The process works as follows:

1. The initiator generates an ephemeral secp256k1 keypair, encodes the public key as a 64-byte ElligatorSwift string, and appends 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 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 key encoding, the entire handshake contains no recognizable patterns for a network observer.

Encryption and Authentication

Once the handshake completes, all subsequent communication uses ChaCha20-Poly1305 authenticated encryption (per RFC 8439). This provides both confidentiality (no one can read the messages) and integrity (no one can modify them without detection). Each encrypted packet carries a 16-byte Poly1305 authentication tag.

The protocol also encrypts the 3-byte length field of each packet using a separate ChaCha20 stream. This prevents observers from inferring message types by examining packet sizes, a technique known as traffic analysis.

HKDF-SHA256 derives four encryption keys from the shared secret: one length key and one payload key for each direction. It also produces a 32-byte session ID (useful for out-of-band authentication) and two garbage terminators used during the handshake.

Message Format

BIP 324 introduces a compact binary message format that replaces the v1 protocol's 24-byte header with a more efficient structure:

┌─────────────┬────────┬──────────────┬─────────┬──────────┐
│ 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)
  Bits 0-6 = reserved

Message type:
  0x01-0xFF = 1-byte short ID (common messages)
  0x00 + 12 bytes = full command name (fallback)

Common messages like TX, INV, PING, and HEADERS use single-byte type identifiers, saving 11 bytes per message compared to the v1 format's 12-byte ASCII command names.

Decoy Packets

Setting bit 7 of the header byte marks a packet as a decoy. The recipient authenticates the packet (verifying the Poly1305 tag) but discards the contents. Decoy packets allow nodes to pad traffic volume and timing, making it harder for observers to infer activity patterns from encrypted traffic. BIP 324 defines the mechanism but does not prescribe when or how often decoy packets should be sent, leaving this to future implementations.

What P2P Encryption Protects Against

Before BIP 324, Bitcoin's privacy model was undermined at the network layer. Encrypted transport shifts the threat model from passive observation to active interception, a fundamentally costlier and more detectable operation.

ISP-Level Surveillance

Internet service providers sit on the network path between nodes. Under the v1 protocol, ISPs could trivially identify Bitcoin connections by their magic bytes, read every transaction relay, and build profiles of which addresses a node was interested in. With v2 transport, ISPs see only encrypted streams that are indistinguishable from other traffic.

Man-in-the-Middle Injection

The v1 protocol had no integrity protection. An attacker positioned on the network path could modify messages without detection: altering transaction data, injecting fake peer addresses, or selectively dropping messages. BIP 324's Poly1305 authentication tags ensure that any tampering causes the recipient to reject the modified packet.

Network-Level Censorship

In jurisdictions that actively filter internet traffic, Bitcoin's v1 protocol was trivially blockable because it had a recognizable fingerprint. BIP 324 traffic has no identifiable signature. Censors would need to block all unidentified encrypted traffic to interfere with Bitcoin, which would disrupt large amounts of legitimate internet activity.

BGP Hijacking

BGP hijacking allows attackers to reroute internet traffic through their infrastructure. Even if an attacker successfully redirects Bitcoin traffic, encrypted transport ensures they see only ciphertext. Without the session keys, they cannot read messages or selectively interfere with specific transaction types.

Comparison with Other Encryption Approaches

BIP 324 is not the only encryption protocol used in the Bitcoin ecosystem. The Noise Protocol Framework secures Lightning Network connections via Noise_XK, providing both encryption and mutual authentication. The two protocols solve different problems:

Lightning can require authentication because nodes have persistent identities published through the gossip protocol. Bitcoin's base layer P2P network is permissionless: any node can join without registering an identity, so authentication cannot be mandatory. BIP 324 chose opportunistic encryption as the pragmatic path to immediate privacy gains. For more on how these approaches fit together, see the research article on Bitcoin's privacy landscape in 2026.

Use Cases

Node Operator Privacy

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

Mining Infrastructure

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

Layer 2 Security

Layer 2 protocols rely on the Bitcoin P2P network for settlement and dispute resolution. Encrypted base-layer transport reduces the attack surface for network-level attacks against the nodes that these protocols depend on. Platforms like Spark inherit stronger security guarantees when the underlying Bitcoin nodes communicate over encrypted channels rather than plaintext.

Censorship-Resistant Regions

In countries that actively filter internet traffic, the combination of encrypted content and traffic camouflage makes v2 connections significantly harder to block. Because the bytestream has no identifiable patterns, filtering Bitcoin traffic requires blocking all unrecognized encrypted connections, which would disrupt a wide range of internet services.

Risks and Considerations

No Peer Authentication

P2P encryption in Bitcoin does not verify who you are communicating with. An attacker who can intercept the initial handshake (a position requiring active network-level access) could establish separate encrypted sessions with both peers, relaying and potentially modifying messages. The protocol exports a 32-byte session ID that operators can compare out-of-band to detect this, but manual verification does not scale. A future protocol called Countersign (under development by Pieter Wuille) aims to add optional mutual authentication on top of BIP 324.

Downgrade Attacks

When a v2 node connects to a v1-only node, it falls back to unencrypted plaintext. An active attacker could force this downgrade by interfering with the handshake bytes, stripping encryption from connections that would otherwise be protected. As v2 adoption increases, operators gain the option to disable v1 fallback entirely (-v2transport=1 in Bitcoin Core), eliminating this attack vector at the cost of refusing connections from older nodes.

Traffic Analysis Limitations

While BIP 324 encrypts message contents, it does not fully conceal traffic patterns. Connection timing, volume, and the number of peers remain visible to network observers. For stronger metadata protection, operators can combine P2P encryption with Tor or I2P. Decoy packets offer some traffic padding capability, but Bitcoin Core does not generate them by default as of version 27.0.

Computational Cost

The ElligatorSwift key encoding and ChaCha20-Poly1305 encryption introduce computational overhead compared to plaintext. In practice, this cost is negligible: ChaCha20 was 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 propagation or transaction relay latency.

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.