BIP324

V2 P2P

BIP324 introduced version 2 of the peer to peer communication protocol between bitcoin nodes. Version 1 of the protocol is entirely in the open, no encryption. Blockchain data is technically public information so what is the big deal? It makes it way to easy to censor bitcoin activity. Ideally, all parts of the bitcoin ecosystem use encryption and remain dark.

old v1 remotes

The BIP324 spec mentions how if a V2 client tries to connect to a V1 only node, the remote node will probably close the connection immediately. Modern versions of the bitcoin core implementation validate the first few bytes they receive from a new peer connecting to them. Before the V2 protocol, they check if the first four bytes match the network magic for the network the node is running on. V2 adds another validation branch, but I am curious about how a V2 client handles really old remotes.

If you go back to some pretty old versions of core, talking before 0.9.0i (released around 2014), the client connecting code was much more forgiving. Instead of having a disconnect immediately policy, it tried to push the client back to the protocol. Core changed its overall policy though around 0.7.0 to try and be less forgiving since this opens windows for attacks to toss anything at a node.

At the end of 2024, less than 0.1% of bitcoin nodes were running a version older than 0.9.0. I don’t think the BIP324 library needs to have the “V1 only node keeps connection alive and keeps sending V1 messages” as a first class support path. It can safely assume a remote will close the connection if it doesn’t understand V2. The worst case scenario, for implementations with a more forgiving policy, the connection fails hard as the client chokes on the handshake. The V1 version packet which starts the V1 protoocl is larger than the 64 byte key to start the V2 protocol, so at least the client won’t hang.

Tasks

• Clients
• Push V2 message serialization logic into rust-bitcoin.
  • This is logic which should be shared in the ecosystem, but it currently hard to refactor due to how the V1 NetworkMessage type is currently structured in rust-bitcoin.
  • rust-bitcoin discussion on V2 message handling.
  • RawNetworkMessage, V1, and V2 type naming.