v2 P2P transport
Also called: BIP 324, BIP324, encrypted transport, P2P encryption, v2transport.
v2 P2P transport (BIP 324) encrypts connections between Bitcoin nodes, so eavesdroppers can't read the traffic or easily recognize it as Bitcoin.
v2 transport is the encrypted peer-to-peer protocol that Bitcoin nodes can use instead of the original plaintext protocol (v1). It is specified in BIP 324 by Dhruv Mehta, Tim Ruffing, Jonas Schnelli and Pieter Wuille, and replaces an earlier encryption proposal, BIP 151. Bitcoin Core supports it and has enabled it by default since version 27.0.
Why encrypt Bitcoin traffic?
Blocks and transactions are public, but who sends what, and when, is not. With v1, anyone watching a connection, such as an internet provider, can see which transactions a node relays first, which can reveal where a transaction came from. Plaintext connections are also cheap to tamper with and easy to spot, since every message starts with fixed magic bytes. With v2 a passive observer sees only bytes that look random, and an attacker has to actively intercept connections, which costs more and can be detected.
How BIP 324 works
- Each side sends a 64-byte ElligatorSwift-encoded ephemeral public key, then up to 4,095 bytes of random "garbage" so the handshake has no fixed shape.
- Both compute a shared secret by ECDH on secp256k1 and derive encryption keys, a session ID and 16-byte garbage terminators.
- Every later packet is encrypted with ChaCha20-Poly1305, its length is encrypted separately with ChaCha20, and keys are replaced every 224 messages for forward security.
Common messages get 1-byte IDs instead of 12-byte names, slightly reducing bandwidth. Nodes advertise support with the NODE_P2P_V2 service bit (1 << 11) and fall back to v1 if a peer doesn't support v2.
The encryption is unauthenticated by design: it doesn't prove who a peer is, but operators can compare session IDs to detect a man-in-the-middle.