Bitcoin Magazine
The v2 Transport: Bitcoin P2P Traffic Goes Dark
For nearly 15 years, all communication between nodes on the Bitcoin network was transmitted completely in the clear, without any encryption. That changed in 2024 with the adoption of BIP 324, which introduced the “v2” transport protocol for communication between nodes. This new protocol features opportunistic encryption, making the traffic unreadable to passive adversaries capable of monitoring messages between nodes. Since adding support for it in Bitcoin Core 26.0, and enabling it by default in 27.0, it is now used for the majority of global Bitcoin P2P traffic.
Taking a step back, a Bitcoin node’s primary function is exchanging pieces of information that are fundamentally public: blocks in the blockchain, transactions in the mempool, and IP addresses of other Bitcoin nodes. Because this is not secret information, it is not immediately obvious why encrypting it along the way would be beneficial. But on closer inspection, there is plenty of metadata associated with Bitcoin traffic that is worth protecting. If a large-scale adversary can see which transaction is relayed when and by which IP address, they can infer which node was the likely originator – and thus creator – of a transaction. In addition to that, seeing the connections between nodes themselves may reveal who certain nodes belong to, allowing nodes of specific companies or miners to be targeted for attacks. And for some users running nodes in oppressive regimes, it may be undesirable to reveal they are running a Bitcoin node at all.
In the P2P protocol as designed by Satoshi, nodes connect to each other, and over those connections send messages like inv (“I have new blocks/transactions for you”), getdata (“give me that block/transaction”), addr (“here is an IP address of another node”), and many others. The set of messages and features they support has changed significantly over time, including support for early SPV clients with BIP 37, compact block relay with BIP 152, support for Tor v3 addresses with BIP 155, and dozens of others. But the way those messages are encoded into bytes that are sent over the wire – what we call the transport protocol – had essentially never changed since 2009. The only exception to this was the introduction of checksums to the protocol in May 2010. BIP 324 was the first change of this nature since then.
Note that despite being a rather fundamental change to what can be described as part of the “Bitcoin protocol”, it is entirely optional. It is not a consensus change, and did not need any coordination or activation mechanism. It is simply used between individual nodes that support it, but when a BIP 324 supporting node talks to another one that does not, they fall back to speaking the old (“v1”) transport protocol. This is how, without much fanfare not two years after the release of client software that enables it by default, the majority of commu