BIP324 describes how to encrypt messages exchanged by Bitcoin nodes. A node is software that checks transactions and blocks and communicates with other participants in the network. These direct connections between network participants are called P2P connections; the encrypted variant is known as v2 transport. Someone merely listening to a connection should not be able to read its contents easily. Encryption alone, however, does not confirm which node you are actually talking to. The public blockchain and transaction validity rules remain unchanged.
A block is a batch of transactions added to Bitcoin’s shared history. Blocks are public, but watching them propagate is different from reading the finished chain. Someone monitoring an unencrypted connection also sees message order, requests and when a node relayed a transaction. This can help associate network activity with people. BIP324 limits a passive observer’s ability to read that content easily. [1] [2] [7]
Two supporting nodes agree on keys when connecting and then communicate through encryption. They need not know each other’s identity beforehand or have a certificate from a central authority. That is precisely why encrypted does not mean trustworthy. The other node can of course read the messages and may still belong to an attacker. [1]
When a connection starts, a process called the handshake, both nodes generate temporary keys. A private key is a secret numerical value; its corresponding public key can be shared with others. Using ECDH, each calculates the same shared secret without exchanging private keys. Keys that protect the traffic are then derived from that secret. ElligatorSwift is a way of encoding public keys so that this part of the exchange resembles random data and is harder to recognize by a fixed pattern. These are strictly network connection keys. They are not private keys that control bitcoin or a seed, the secret starting value used to derive wallet keys. Enabling encrypted transport never requires sharing a wallet backup. [1] [8]
Imagine someone intercepts a message and changes its contents along the way. BIP324 uses ChaCha20Poly1305: encryption with a check that the message matches the connection’s key and has not been altered. An attacker without that key cannot simply rewrite the data and produce a valid message. This check does not establish that you share the key with the intended node, however. An active intermediary can pose as the other endpoint to each side while connections are being established. It then has two separate encrypted connections and reads and forwards messages between them. Protecting messages and verifying the other endpoint are therefore different tasks. [1]
Keys change throughout the connection. Provided old secrets are properly erased, obtaining current keys later does not automatically unlock the entire earlier recording. This property is called forward secrecy. It cannot protect messages the other node has already read or saved. Nor does it help against an attacker who retains control of the computer; the most recent group of messages may also remain exposed. [1]
The older v1 transport remains supported for compatibility. If a v2 connection fails, software may try v1. An active attacker can therefore block encrypted connections and attempt to force an unencrypted fallback. BIP324 raises the cost of passive surveillance, but promises neither general downgrade resistance nor connection availability. [1] [4]
BIP324 hides neither IP addresses nor all traffic timing and volume patterns. An IP address is the network address a device uses to communicate over the internet. Tor can address another part of the problem, but combining them does not automatically provide anonymity. However a message arrives, a Full Node must verify transactions, signatures and blocks. Encryption alone does not solve an Eclipse Attack in which attackers surround a node. [1] [6]
Bitcoin Core 26.0 added v2 support in 2023, initially disabled by default. Version 27.0 enabled it by default. This entry’s year therefore marks the first Bitcoin Core support, not the proposal’s origin. Negotiation happens separately for each connection; software support does not mean every connected peer uses v2. [3] [4]
A Bitcoin Core operator can read the connection state with bitcoin-cli getpeerinfo. This is a query through RPC, an interface for controlling a node and retrieving information; this command does not broadcast transactions to the Bitcoin network or change settings. Its output lists each connection separately. In transport_protocol_type, v2 means encrypted transport, v1 means the older unencrypted transport, and detecting means the choice is still unresolved. The session_id field contains an identifier for a v2 connection; otherwise it is empty. Its presence alone does not verify the other endpoint. Two operators can compare the identifier for their mutual connection through another trusted channel to detect an intermediary; ordinary connections do not perform that check automatically. The result describes this link, not the transaction’s entire journey through the network. The output also contains network details that need not be made public. [5] [1]
BIP324 lists Dhruv Mehta, Tim Ruffing, Jonas Schnelli and Pieter Wuille as authors. Its number was assigned in 2019; on review on 17 October 2026 its status is Deployed. Adoption requires neither a Soft Fork nor a change to bitcoin supply. It gradually improves node communication, with benefits depending on correct implementation and the connections actually used. [1]
For the clearest picture, read this entry together with Full Node, Eclipse Attack, Bitcoin Privacy, Bitcoin Core. The reverse links also lead from Mix Network.