BIP-324 encrypted transport

Two nodes that both support BIP-324 run an ephemeral key exchange before any Bitcoin message is sent, then wrap every message in ChaCha20Poly1305. The specification was marked final on July 10, 2024, and a node advertises support with the NODE_P2P_V2 service flag, bit 11. Nothing about your coins changes: what changes is that a passive observer can no longer read the transactions your node passes around.

How it works

BIP-324 replaces the fixed magic bytes that used to open a bitcoin connection with a stream that has no recognizable shape at all.

The side that dials out generates a throwaway secp256k1 key and sends the 64-byte ElligatorSwift encoding of its public key. That encoding is the trick: an ordinary public key is identifiable as a curve point, while every 512-bit string is a valid ElligatorSwift encoding, so the opening bytes are statistically just noise. Either side may then append up to 4095 bytes of arbitrary padding, called garbage, so a connection does not have to begin with exactly 64 bytes. Both ends run X-only ECDH and push the result through HKDF-SHA256 to derive four encryption keys, two 16-byte garbage terminators, and a session ID.

Those opening bytes are the one part of the exchange sent in the clear. After the terminators, everything on the wire is packets. A packet is a 3-byte encrypted length field followed by a ChaCha20Poly1305 ciphertext covering a 1-byte header and the contents, costing 20 bytes plus the payload. The top bit of that header is the ignore bit, and a packet carrying it is a decoy: the receiver confirms it decrypts and then discards it, which is how a node can pad its traffic to disguise the moment a real message went out. Keys ratchet forward every 224 packets, an interval picked so that a near-idle link sending nothing but 20-minute pings rekeys roughly every 3.11 days, and that ratchet is what gives a session forward secrecy.

The design stops deliberately short of proving who is on the other end. There are no certificates and no identities, so a determined man in the middle can still sit between two nodes. What it cannot do is sit there cheaply or invisibly: the session ID falls out of the key exchange, and two operators who read theirs out to each other will see different values whenever someone is sitting in between.

Where you see it

BIP-324 leaves nothing on the blockchain, so the only place it shows up is between two running nodes.

Support is announced in address gossip through the NODE_P2P_V2 flag that peers learn from addr and addrv2 messages. Those flags pass through untrusted relays and get OR'ed together, so a false advertisement is possible, and the BIP encourages a v2 client that gets disconnected immediately to retry the same peer over v1. In the other direction, a v2 node goes on accepting inbound v1 connections on purpose, to keep the network from splitting into two halves that cannot reach each other.

The second visible effect is shorter messages. Version 1 spent 12 ASCII bytes on every command name; version 2 hands one-byte IDs to the 28 message types defined so far, so inv is the single byte 14 and getblocktxn is 10, and any message using a short ID costs 3 bytes less than its v1 form. Anything without an assigned ID falls back to a 13-byte encoding, a zero byte followed by the old ASCII name, so nothing is lost.

The specification carries the status Deployed, ships test vectors and a naive Python reference implementation meant only for demonstration, and is still being edited: revision 1.0.2 of January 30, 2026 added a message type ID table in an auxiliary file so other BIPs can claim IDs without editing the main document. The header also records that BIP-324 replaces BIP-151.