Author: Pieter Wuille
Source: https://bitcoinmagazine.com/print/the-v2-transport-bitcoin-p2p-traffic-goes-dark
For nearly 15 years, all communication between nodes on the Bitcoin network was transmitted completely transparently, without any encryption. This changed in 2024 with the adoption of BIP 324, which introduced the "V2" transport protocol for communication between nodes. This new protocol implements opportunistic encryption, making it impossible for adversaries without the ability to monitor inter-node messages to read their traffic. Since Bitcoin Core 26.0 added support for it and enabled it by default in version 27.0, it has been used in the majority of peer-to-peer traffic across the Bitcoin network.
However, even assuming a primary function of a Bitcoin node is to exchange essentially public information: blocks on the blockchain, transactions in the transaction pool, and the IP addresses of other Bitcoin nodes. Since this isn't secret information, the benefit of encrypting the traffic might not seem apparent. But closer inspection reveals that the vast amount of metadata associated with Bitcoin traffic is worth protecting. If a broad adversary could see when a transaction was forwarded and through which IP address, they could deduce which node might be the source of the propagation—and therefore, the initiator of the transaction. Furthermore, seeing the connections between nodes could expose which node belongs to which individual, allowing attackers to target a particular company or miner's node. For users living under authoritarian regimes, revealing that they are running a Bitcoin node might be inherently disadvantageous.
In Satoshi Nakamoto's P2P protocol, nodes connect to each other, sending messages over these connections such as " inv " ("I have a new block/transaction you don't know about"), " addr " ("This is another node's IP address"), and so on. These messages, and the set of features supported by each node, have changed significantly, such as support for early SPV clients (BIP 37), dense block forwarding (BIP 152), Tor v3 addresses (BIP 155), and so on. But the way these messages are encoded as bytes and transmitted over these connections—what we call the "transport protocol"—has essentially remained unchanged since 2009. The only exception was the introduction of checksums to the protocol in May 2010. BIP 324 was the first such change since then.
Note that while this can be considered a fundamental change to the "Bitcoin protocol," it is entirely optional. It is not a consensus change and does not require any coordination or activation mechanisms. It is only used between two nodes that both support this feature, but when a node supporting BIP 324 communicates with a node that does not, they revert to the old transport protocol (i.e., "v1"). This is why, for two years after clients supporting it and having it enabled by default were released, the vast majority of traffic between Bitcoin nodes quietly used this encrypted v2 transport protocol.
The idea of encrypting Bitcoin node traffic isn't new. Back in 2016, Bitcoin Core developer Jonas Schnelli proposed BIP 151, which allowed upgraded inter-node connections to switch to an encrypted mode. This proposal didn't go very far, and because this method couldn't hide the initial handshake between two nodes, BIP 324, released in 2019, aimed to completely overhaul the transport protocol. This more novel approach introduced a completely new set of connections, encrypted from the start. Progress continued until 2021 when Dhruv Mehta picked it up and, along with Tim Ruffing and myself, transformed it into a full proposal, adding a few new features such as a fully pseudo-random byte stream, affordances for traffic shaping, and optional plugins. In 2022, we announced it in the bitcoin-dev mailing list, and after receiving several comments, implemented it between 2022 and 2023. The full feature was merged into Bitcoin Core in 2023. After further testing, it was enabled by default for all connections in 2024 (provided the peer node supports it).
The fully pseudo-random byte stream characteristic provided by the new protocol means that bytes sent through this transport protocol have no recognizable pattern. For example, the TLS protocol, used in communication with secure websites ("https://" web pages), encrypts the website's content but doesn't hide the fact that TLS is used, nor the request for the site's hostname (at least before the use of Encrypted Client Greeting (ECH) in 2020). Before the implementation of BIP 324, the v1 transport protocol sent a fixed 16 bytes at the beginning of each connection, which was extremely easy to identify, so firewalls attempting to censor it could easily block any connection using this pattern. In contrast, the v2 transport protocol has no such pattern at all; each byte, from a third-party perspective, is uniformly random and therefore completely unpredictable. Any entity attempting to block Bitcoin traffic based on traffic patterns would need to intercept all seemingly random traffic, which could be politically more difficult (compared to simply blocking traffic from software like Bitcoin). The most difficult part of making the entire protocol pseudo-randomized comes from the handshake—before encryption is established, nodes need to exchange public keys, which are not random bytes. Thanks to a very new cryptographic technique called "Elligator" (2013) and a variant of it called "ElligatorSwift" (2022), which can encode elliptic curve public keys into seemingly random bytes, it is possible for recognizable patterns to emerge during the handshake.
It's worth noting that due to the public nature of the Bitcoin network, the privacy protection provided by the cryptographic transport layer between nodes faces significant limitations. Bitcoin nodes don't trust their peers and therefore don't particularly care who those peers are. Bitcoin nodes also don't have publicly available public keys, which is why the encryption provided by the v2 transport protocol is opportunistic and unverified; both parties use a new temporary key for each connection. This means that an active adversary (such as your internet service provider) can perform a "man-in-the-middle attack": using the v2 transport protocol with both nodes attempting to establish a connection, then decrypting a message from one party, re-encrypting it, and sending it to the other; in other words, espionage is still possible, and it's possible to simultaneously tamper with or censor information. However, the key point is that launching such a large-scale man-in-the-middle attack is much more expensive than being able to directly inspect an unencrypted single message (as allowed by the v1 transport protocol). And, of course, because the vast majority of Bitcoin node connections are arbitrarily initiated to random, untrusted nodes, an adversary wanting to probe other nodes on a large scale can always launch a large number of nodes and then have a large number of other nodes connect to these nodes. Just like a man-in-the-middle attack, it's more expensive to do than directly inspecting the v1 package.
Therefore, it's best not to view BIP 324 itself as a privacy enhancement, but rather as part of a larger effort: increasing the cost of mass surveillance of the Bitcoin network while avoiding reliance on alternative networks (such as Tor and I2P, which have their own sacrifices, such as increased latency or the risk of denial-of-service attacks, risks that cannot be accepted by all nodes in the network). Some features of BIP 324 are not yet implemented, such as traffic shaping, which could prevent others from discovering information about forwarded transactions by observing the size of encrypted packets. Hopefully, these features will be utilized in the coming years.
(over)
