The v2 Transport: Bitcoin P2P Traffic Goes Dark

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 communication between Bitcoin nodes wound up using the encrypted v2 transport protocol.

The idea of encrypting Bitcoin traffic was not new. Back in 2016, Bitcoin Core developer Jonas Schnelli proposed BIP 151, which would allow upgrading connections to switch them to an encrypted mode. The proposal did not make it far, and since that approach couldn’t hide the initial handshake between two nodes from prying eyes, BIP 324 was proposed in 2019 to instead revamp the transport protocol entirely. This more modern approach instead introduced an entirely new class of connections that are encrypted from the start. Progress on it accelerated when it was picked up by Dhruv Mehta in 2021, and together with Tim Ruffing and myself, turned into a full proposal that included a few new features like a fully pseudorandom bytestream, affordances for traffic shaping, and optional extensions. We announced it on the bitcoin-dev mailing list in 2022, and after receiving several comments, implemented it over the course of 2022 and 2023. The full feature was merged in Bitcoin Core in 2023. After further testing, it was enabled by default for all connections (with supporting peers) in 2024.

The fully pseudorandom bytestream feature offered by the new protocol means it exhibits no recognizable patterns in the bytes sent over the wire. For example TLS, used for communication with secure websites (“https://” URLs), encrypts the contents of websites, but not the fact that TLS is being used, or (until 2020 with Encrypted Client Hello, “ECH”) which hostname the site was being requested from. The v1 transport used before BIP 324 sent a very recognizable fixed first 16 bytes over every connection, making it easy for censoring firewalls to block any connection with that pattern. In contrast, the v2 transport has no such pattern at all; every byte is uniformly random from the perspective of a third party, and thus completely unpredictable. Any entity that intends to block Bitcoin traffic using it would need to block anything that looks random, which might be politically more difficult than just narrowly blocking Bitcoin-like traffic. The hardest part of making the entire protocol pseudorandom was the fact that during the handshake – before encryption is set up – the nodes need to exchange public keys, and public keys are not just random bytes. Only thanks to a fairly modern cryptographic technique called Elligator (2013), and specifically a variant called ElligatorSwift (2022) that allows encoding elliptic curve public keys in random-looking bytes, was it possible to avoid even this pattern.

It is worth pointing out that due to the public nature of the Bitcoin network, there are significant limitations to the privacy protections that an encrypted transport layer between nodes can offer. Bitcoin nodes do not place trust in their peers, and thus do not really care who they are talking to. Bitcoin nodes do not have known public keys, which is why the encryption offered by the v2 transport is opportunistic and non-authenticated; both sides just make up a new temporary key for each connection. This means it is possible for active adversaries (e.g., your ISP) to perform a man-in-the-middle attack: talk v2 to both sides of the connection, but decrypt and re-encrypt all communication flowing between them, still allowing spying, and possibly tampering or censoring while doing so. However, the point is that this is significantly more expensive to do at scale, compared to simply inspecting unencrypted individual messages like is possible in the v1 transport. And of course, since most Bitcoin connections are arbitrarily made to random untrusted nodes, an adversary who wants to spy at scale on other nodes always has the option of just spinning up a large amount of nodes themselves, and getting a large portion of the network to connect to them. Like man-in-the-middle attacks, this is more expensive to do at scale than simply inspecting v1 packets.

BIP 324 is thus best seen not as a privacy improvement in and of itself, but as part of a larger effort of raising costs for large-scale surveillance of the Bitcoin network, without relying on alternate networks like Tor or I2P, which have their own trade-offs like increased latency and denial-of-service risk that would not be acceptable for all nodes on the network. BIP 324 also offers a number of features that are as of yet unimplemented, like traffic shaping to avoid revealing information about transactions being relayed just through observing the sizes of encrypted packets. Hopefully, those will be taken advantage of further in the coming years.

Don’t miss your chance to own The Core Issue — featuring articles written by many Core Developers explaining the projects they work on themselves!

This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Core Issue. We’re sharing it here as an early look at the ideas explored throughout the full issue.

This post The v2 Transport: Bitcoin P2P Traffic Goes Dark first appeared on Bitcoin Magazine and is written by Pieter Wuille.