3
Security Analysis of Bitcoin’s V2 Transport Protocol: Exploiting Design Implications for Sustained Eclipse and Downgrade Attacks
1
2
4
Charmaine Ndolo #
5
Dresden University of Technology
6
Florian Tschorsch #
7
Dresden University of Technology
arXiv:2605.19715v1 [cs.CR] 19 May 2026
Abstract Bitcoin recently introduced a new protocol for the encryption of peer-to-peer (P2P) communication. The protocol, known as V2 P2P transport, represents a big step towards securing the overlay network against various previously-known attack vectors. Based on an analysis of V2 P2P transport, this work examines the current viability of said attacks and concludes that while they are now remediated, alternative attacks and paths to similar objectives exist. The identified shortcomings are conceptual (and not implementation bugs) and even applicable to other P2P networks. We show how a network-level attacker can identify application messages using the length of TCP payloads, can eclipse a target node by taking advantage of how encrypted communication channels work and can downgrade all of a node’s connections to the unencrypted protocol by using the mechanisms designed for compatibility. We validate our contributions using a combination of network measurements, emulations and simulations. Finally, we propose a series of short-term and long-term countermeasures towards securing Bitcoin’s P2P network. To the best of our knowledge, we are the first to study Bitcoin’s security under V2 P2P transport. 2012 ACM Subject Classification Networks → Network privacy and anonymity; Security and privacy → Software and application security; Security and privacy → Distributed systems security Keywords and phrases Bitcoin, V2 P2P transport, P2P layer Digital Object Identifier 10.4230/LIPIcs...1 Supplementary Material Source code used in this work is available as detailed in Sec. 9.
1
Introduction
Despite its emphasis on decentralisation and security, Bitcoin [32] has long relied on unencrypted peer-to-peer (P2P) communication. Until recently, all network traffic between nodes was exchanged over regular TCP connections. This proved to be a significant shortcoming of the Bitcoin protocol as multiple attacks that were built on inspecting the plaintext communication were uncovered. Among others, there has been research on attacks on the anonymity of users [8, 24], the privacy of nodes in the overlay network [35] and on the security of P2P communication in the presence of a malicious autonomous system (AS) [2, 3]. As a result, Bitcoin Improvement Proposal (BIP) 324 defines a new P2P transport protocol, commonly referred to as V2 P2P transport, which allows nodes to communicate over encrypted but unauthenticated channels. As of the release of Bitcoin Core 27.0 in April 2024, V2 P2P transport is the default mode of communication. Although it is reasonable to expect that V2 P2P transport advances the security of the P2P network, the degree and consequences of these improvements are less clear. To the best of our knowledge, neither the V2 P2P transport protocol itself nor its impact on the overlay’s security have been studied. In this paper, we present an analysis of Bitcoin’s V2 P2P transport protocol, with a focus on known attacks by an AS-level adversary. We find that while encryption renders © Charmaine Ndolo and Florian Tschorsch; licensed under Creative Commons License CC-BY 4.0 Leibniz International Proceedings in Informatics Schloss Dagstuhl – Leibniz-Zentrum für Informatik, Dagstuhl Publishing, Germany
1:2
Security Analysis of Bitcoin’s V2 Transport Protocol
these attacks impractical in their original form, an alternative path to them exists. We first present an eclipse attack that exploits how V2 P2P transport handles decryption errors to close legitimate connections. This replaces the component of prior attacks that has been disrupted by V2 P2P transport. The issues are conceptual in nature and, to some extent, can be applied to other major P2P networks. We also show that design choices made in the interest of backwards compatibility, i.e., silent retry and fallback on failure, give an adversary a reliable way of downgrading connections to the unencrypted protocol. Based on the insights from our analysis, we propose countermeasures to address the identified weaknesses. The main contributions of our work are summarised in the following. Analysis and Understanding of the V2 Protocol: We contribute to the understanding and further documentation of the V2 P2P transport protocol. The latter is currently limited to the specification document, the reference client’s code base and a handful of informal resources. Our work consolidates this information with the intention of providing an additional source of reference. For instance, we dissect the structure of a protocol message and show how message types can be classified at the network layer. We derive a threat model from BIP 324, which we use for the rest of this work, and discuss the current state of relevant, past attacks. To the best of our knowledge, this is the first work to study the security of Bitcoin’s P2P overlay network under V2 P2P transport. Sustained Eclipse Attack by Exploiting Encryption: We present an effective network-level eclipse attack that does not require any protocol state and replaces the components of previous attacks [3, 16, 43] that were broken by V2 P2P transport. The attack exploits how the protocol handles duplicate ciphertexts, i.e., a node closes the TCP connection if it encounters decryption errors. We performed a review of how other major P2P networks handle decryption errors and found that they all close the TCP connections immediately. This suggests that, although immediate disconnection upon decryption failures is common practice, its use in P2P environments (as opposed to client–server architectures) introduces a conceptual vulnerability that may be exploitable in other networks. As a result of this design choice, an active network-level adversary can cause all connections to a victim node to be closed by replaying payloads. They then gradually occupy all connection slots until the victim node is eclipsed. Furthermore, the attack exploits the fact that network-level classification of message types in TCP payloads is possible despite encryption. Consequently, the adversary can replay payloads transporting the same message type in order to maintain some discretion. We implemented the attack in our testbed and successfully eclipsed a victim node in less than a day. Our approach yields a more effective attack than the (now impractical) EREBUS attack with a significantly shorter execution period as the adversary actively provokes the closing of connections. Although eclipse attacks in Bitcoin have been studied extensively [3, 16, 20, 43], prior work neglects how to keep up the attack. We therefore place emphasis on sustaining an eclipse attack and describe the associated challenges and how they can each be overcome. Downgrade Attack by Exploiting Protocol Compatibility: We question the means with which compatibility with the original transport protocol, which we refer to as V1 P2P transport, is achieved. BIP 324 specifies that clients using V2 P2P transport should accept unencrypted incoming connections in order to minimise the risk of network partitions. Compatibility is achieved by reconnecting using the V1 P2P transport protocol if a connection is terminated by the remote side immediately after the TCP handshake. The issue therein is that BIP 324 relies on the transport layer for protocol negotiation with older clients instead of making the necessary provisions at the application layer. We show how a network-level adversary can downgrade all of a node’s connections even
C. Ndolo and F. Tschorsch
when both nodes support V2 P2P transport as a result of this design choice. While the possibility of downgrade attacks is mentioned briefly in BIP 324, we are, to the best of our knowledge, the first to present such an attack and demonstrate its feasibility. Our analysis of V2 P2P transport reveals a generous window of opportunity such that a network attacker has sufficient time to trigger connection termination. We implemented and confirmed that the attack is viable and succeeds without fail. This reopens the door to attacks that should no longer be possible due to encryption such as delay [3] and spoofing [16, 48] attacks. Addressing Causes and Countermeasures: As our final contribution, we narrow down the causes of the various issues identified in this work and suggest countermeasures Bitcoin can implement to address them. For example, certain features of the Bitcoin protocol, regardless of BIP 324, are conducive for eclipse attacks. Some of the proposed countermeasures are short-term and not ample on their own, while others address fundamental challenges in securing the P2P network and require further research.
2
Bitcoin’s V2 P2P transport protocol
Prior to December 2023, P2P communication in the Bitcoin network was not encrypted, which proved to have a significant impact on the privacy [8, 24] and security [3, 43] of the P2P network. The first notable attempts to address the lack of encryption were made in BIP 151 [41] in 2016 which was later withdrawn in 2021. The specification of a new P2P transport protocol in BIP 324 [30] and subsequent implementation in Bitcoin Core 26.0 introduced encrypted P2P communication to Bitcoin. This protocol, referred to as V2 P2P transport, specifies a scheme for the encryption of communication between peers and is enabled by default as of Bitcoin Core 27.0. Therefore, all P2P communication subsequent to connection establishment and key exchange will be encrypted if both peers support V2 P2P transport. In the following, we provide some background on peer and address management followed by a description of the V2 P2P transport protocol based on BIP 324 and the Bitcoin Core 28.0 code base. We then define a threat model based on our review of V2 P2P transport and discuss the current practicality of past attacks.
2.1
Background: peer and address management
The Bitcoin network is a permissionless P2P network. It primarily serves the purpose of propagating new transactions, blocks and node addresses to the network via a gossip protocol. Each node maintains up to 125 connections by default. Ten of these connection slots are reserved for outgoing connections and are selected meticulously in order to ensure that a node is connected to at least one honest node. All but one of the remaining slots are reserved for incoming connections. If a node already has the maximum number of open incoming connections when it receives a further connection request, an eviction policy will determine whether an existing connection should be closed in favour of the new one [19, 47]. Addresses discovered during bootstrapping and thereafter are managed in a local database that is is divided into two tables. The new table stores addresses that are relayed via ADDR messages, while the tried table stores addresses of nodes that have been successfully connected to. Addresses are organised into buckets primarily based on the /16 or /32 prefix of an IPv4 or IPv6 address respectively and the relaying node’s prefix group. Each address in the new table can occur in up to 8 different buckets. The final connection slot is reserved for a short-lived outgoing connection, a feeler connection, which is initiated every two minutes to a random address from the new table. The point of the feeler connection is to establish if a given address in the new table is
1:3
Security Analysis of Bitcoin’s V2 Transport Protocol
Responder
Initiator kI−
kI+
− kR
garbage + kR
garbage
Time
1:4
Key exchange
Length descriptor Ciphertext 3 bytes n bytes
garbage terminator garbage terminator VERSION VERSION
Version negotiation
VERSION VERACK VERSION VERACK
.. .
Application (same in V1 P2P transport but w/o encryption)
Figure 1 V2 P2P transport connection establishment after the TCP handshake.
Flags Contents Auth. tag 1 byte n − 17 bytes 16 bytes Type Message 1 or 3 bytes n − 18 or n − 20 bytes
Figure 2 Structure of a V2 P2P transport message during the application phase.
reachable. If that is the case, the address is moved to the tried table. When initiating a new outbound connection, a node first chooses either the new or tried table with equal probability. It then selects a random address from the chosen table and attempts to connect to it. If the connection is established, the address is moved to the tried table in case it was selected from the new table. Any existing copies of the address in the new table are also deleted.
2.2
V2 P2P transport protocol
BIP 324 defines three components of the V2 P2P transport protocol: the transport layer, the application layer and the signalling components. These subprotocols collectively contribute to a total of eight objectives defined in BIP 324. We provide an overview of the V2 P2P transport protocol and highlight its objectives in what follows. We concentrate on the establishment of encrypted communication channels. All of the objectives are named and highlighted in bold italics below, and a summary is provided in Table 3 in the appendix. V2 Transport layer The transport layer defines three phases (cf. Fig. 1) and is responsible for setting up an encrypted channel over a TCP/IP connection between two nodes and encrypting protocol messages. The channel is then used to transport application messages. In the key exchange phase, the initiator and responder each generate an ephemeral − secp256k1 private key, kI− and kR respectively, and exchange the corresponding 64-byte + + public keys (kI and kR ). Both parties use X-only ECDH [5] to compute a shared secret from the various keys and derive four encryption keys. They each derive one key for the encryption of packet lengths and one each for content encryption. They also derive a common session ID and a 16-byte garbage terminator each using HKDF-SHA256 [25]. The session ID provides observability of active attacks as peers can detect an active man-in-the-middle (MITM) attacker by comparing them manually. The garbage terminators are then exchanged and all further communication takes place in the form of encrypted packets leading to confidentiality against passive attacks. The protocol’s main shapability mechanism is provided by decoy packets that may be sent at any point henceforth. However, BIP 324 does not specify how decoy packets are to be used. The version negotiation phase serves the purpose of peers agreeing on a transport protocol version to use. Support for the current V2 P2P transport protocol is signalled by each node sending an empty VERSION packet. This is distinguishable from the original handshake because empty VERSION messages are never sent. Protocol upgradability is achieved in this way as future versions will be advertised via the content of this VERSION message.
C. Ndolo and F. Tschorsch
During the application phase, data transmitted between nodes in network packets is interpreted as application data. These packets contain application messages (commonly referred to as contents). The application phase is the same in the case of either transport protocols and always starts with a mandatory exchange of the VERSION and VERACK messages. These messages are used to communicate the features a node supports. V2 P2P transport maintains low overhead compared to the V1 P2P transport protocol and even a slight bandwidth reduction due to, e.g., smaller application messages. V2 Application layer The application layer is responsible for encoding application messages for transport by the transport layer. Each transmitted packet is authenticated and encrypted. Authentication in the scope of BIP 324 refers to the guarantee that a message obtained via successful decryption was encrypted using the legitimate encryption key. As depicted in Fig. 2, every V2 P2P transport packet contains an encrypted 3-byte length descriptor and a variable-length ciphertext consisting of the following fields: a 1-byte header for protocol flags. Currently, only the highest bit is defined as the ignore bit for decoy packets; a 16-byte Poly1305 authentication tag of the encrypted plaintext; and a variable-length array of the application message which is commonly referred to as the contents. The length is defined to be in the interval [0, 224 − 1] and is encoded in the aforementioned 3-byte length descriptor. The contents field consists of: a 1-byte field encoding the message type; and a variable-length byte array of the actual message. The plaintext is encrypted using ChaCha20-Poly1305 [36], while the length descriptor is encrypted using the ChaCha20 block function [36] with a different key. Consequently, each V2 P2P transport TCP payload will have a minimum size of 20 bytes and a maximum size of 224 + 19 bytes. Encrypting the fixed-size length field guarantees a stream that is pseudorandom to a passive attacker, i.e., they should not be able to distinguish a V2 P2P transport bytestream from a uniformly random bytestream. Both encryption keys are rotated every 224 packets in order to provide forward secrecy in case either is compromised. V2 Signalling The signalling component defines how nodes announce support for the V2 P2P transport protocol to other nodes in the network. They do so by advertising the NODE_P2P_V2 service flag when announcing their address to the network. For the sake of compatibility, client implementations are encouraged to attempt connecting with the V1 protocol if they are met with immediate disconnection during the handshake phase.
2.3
Threat model
BIP 324 does not explicitly define a threat model. Yet, it is evident that V2 P2P transport is designed to protect nodes from network-level attackers. Such attackers can vary both in terms of their capabilities, e.g., an eavesdropper within a network or an AS, as well as in their methodology, i.e., active or passive. We therefore describe our threat model in what follows based on related work and conclusions we draw from BIP 324. This work assumes a network-level adversary, e.g., an AS, that has control of key network infrastructure between a victim node and the rest of the Bitcoin network. This is a common threat model in the context of blockchain-based P2P networks. Especially in the case of Bitcoin, multiple works have studied the network’s security in the presence of such an adversary [2, 3, 16, 43]. This threat model has also been applied to the Lightning
1:5
1:6
Security Analysis of Bitcoin’s V2 Transport Protocol
network [33, 44] and related networks [40]. Depending on the specific attack, the adversary is either passive or active. In the latter case, they are in-path [29] and are thus capable of tampering with TCP streams arbitrarily, e.g., by dropping packets to/from the victim or by injecting forged packets into the stream. Even if the adversary is not initially in-path, techniques such as BGP hijacking and interception attacks provide a viable route to that position [3, 7, 6]. Furthermore, our eclipse attack requires that the adversary is able to identify the type of application message in an encrypted TCP payload. While the message format did not change in V2 P2P transport, message types can no longer be identified by reading the payload. We assume that message types can still be inferred from side-channel information, in particular message length, which we explain in Sec. 2.5. We require that potential victim nodes are running Bitcoin Core 27.0 or higher and that all of their connections are using the V2 P2P transport protocol. As in previous work, the adversary is only interested in nodes connecting to the network directly via TCP/IP, and not via Tor. Moreover, as V2 P2P transport is not self-revealing, unlike V1, we assume that potential victim nodes are using the default port (TCP/8333) for P2P communication.
2.4
Network attacks under V1 P2P transport
The first class of attacks of interest is eclipse and partitioning attacks as they have been of continued interest in Bitcoin. The first eclipse attack in Bitcoin was presented in 2015 [20] at a time when the Bitcoin protocol had several shortcomings in its address management. The adversary model later shifted to consider powerful network attackers who have access to and are capable of manipulating routing infrastructure [3, 16, 19, 43]. These attacks exploit the properties of the communication protocols used in the Internet as well as Bitcoin’s pre-V2 P2P transport lack of encryption and/or authentication to eclipse a victim node. BIP 324 successfully renders these attacks infeasible: encryption prevents an adversary from reading or modifying TCP payloads as well as from spoofing. BIP 324 hinders any interference with existing connections but it does not change address management in Bitcoin. The second class of attacks comprises the remaining network-level attacks identified in the literature. Their goals vary considerably and range from delaying block propagation [3] to off-path spoofing [27]. The attacks all exploit the absence of encryption and are therefore no longer practical threats as an adversary cannot read or modify the content of the payloads. While they could attempt traffic fingerprinting as described in Sec. 2.5, it is potentially less reliable and requires more resources.
2.5
Network-level message classification
Our threat model assumes that it is possible to determine the type of Bitcoin messages in a TCP payload using the payload’s length. V2 P2P transport does not specify any shapability mechanism despite it being one of the protocol’s objectives. The ability to identify message types despite encryption introduces a side channel for other attacks. Given a TCP payload with x bytes, we can infer that it contains an application message of type t if subtracting 20 (mandatory fields) and either 1 or 3 (type field) from x returns a multiple of t’s minimum length, i.e., if (x − 21 − {1, 3}) mod min(|t|) = 0. We validated this methodology using a 6-week measurement study of the public network and evaluated its merit. While certain messages types, e.g., VERSION, can be identified reliably, other message types, e.g., BLOCK, cannot be identified using an equally straightforward approach due to several variable-length fields. Furthermore, as application messages are transmitted
C. Ndolo and F. Tschorsch
as continuous streams of data over TCP, a payload may carry more than one application message. We expound on this approach in Appendix B and discuss the study in Appendix A.
3
Eclipse attack
Partitioning attacks isolate a set of nodes from the rest of a network by splitting the network. Eclipse attacks isolate a single node from the rest of the network, and are considered to be a subclass of partitioning attacks [17]. The main motivation for such attacks is to control the flow of legitimate information to victim nodes. In doing so, they become vulnerable to further attacks that are usually mitigated by the consensus rules in the network, e.g., double-spending [22] or 51% attacks [32]. Eclipse attacks under V2 P2P transport require a new mechanism for connection manipulation that does not depend on payload inspection or spoofing. A naive attack by means of dropping specific timeout-relevant messages results in immediate disconnection as decryption of any subsequent payload fails. Based on this observation, we present a new approach to closing the victim’s existing connections in order to free up connection slots. As the general approach to occupying connection slots described in [16, 43] still applies, we place greater emphasis on how to sustain an eclipse attack. We provide new insights into challenges an adversary will face and how each can be overcome. To the best of our knowledge, we are the first to provide an elaborate description of this component of eclipse attacks.
3.1
Closing existing connections
Our attack leverages that V2 P2P transport connections are terminated as a consequence of malleability. Specifically, the in-path adversary triggers disconnection by duplicating specific TCP payloads from the victim to its peers, i.e., a replay attack. As V2 P2P transport ciphertexts can only be decrypted exactly once, recipients of such ciphertexts will not be able to decrypt them and assume a transport layer error. As a result, they close the TCP connection using a regular FIN packet, which opens up a connection slot for the adversary. The adversary performs the following steps in order to eclipse a victim node successfully: 1. The adversary monitors all traffic to/from the victim on TCP port 8333 and makes decisions on how packets should traverse the network stack. All packets are sent to their destination without any form of modification by default. 2. The adversary selects an application message type m that they will use for the attack. As the P2P traffic is encrypted, the adversary does not know what message types are being transmitted. They use the size of TCP payloads to determine the type (cf. Sec. 2.5). 3. The adversary waits for the first packet carrying a message of type m from the victim node to a given peer. They store a copy of the payload and dispatch the packet as it is. 4. When the victim node sends a second packet with a message of type m, the adversary replaces the packet’s payload with the previously stored copy of m. They recompute the necessary fields of the TCP header before letting it traverse the rest of the network stack regularly. In order to reduce the risk of detection and minimise their workload, they only modify packets with messages of the same size and type. 5. When the altered packet arrives at its destination, the application will decrypt the 3-byte length descriptor which will return a wrong length. This is because the ChaCha20 block counter will have advanced and the keystream’s bytes used for decryption cannot produce the correct length. A ‘packet too large’ error message will be written to the recipients logs before closing the connection to the victim using a regular four-way handshake of
1:7
1:8
Security Analysis of Bitcoin’s V2 Transport Protocol
TCP FINs. This leaves no indications of an attack. Unlike a classic transport layer attack, e.g., RST injection, failed decryption is far less indicative of in-path manipulation. 6. Incoming peers will try to reconnect to the victim node which the attacker must prevent by dropping the TCP SYN packets. The attacker occupies every newly-available incoming connection slot with a malicious connection. In the case of outbound connections from the victim node, the adversary must block any subsequent reconnection attempts. They, however, have no other choice but to wait for the victim to open connections to them. The adversary follows these steps for every honest peer that the victim has until no more persist. The strategy does not entail preventing connections from new peers as they will simply be compromised later. We remark that the applicability of the attack is not exclusive to Bitcoin. A review of related P2P networks such as IPFS, the Lightning network and Ethereum showed that it is common practice to close TCP connections when decryption fails. This creates a broader conceptual vulnerability that could be exploited in other networks.
3.2
Choice of message to duplicate
Technically, any application message type that is sent more than once to each peer can be used for the attack. However, certain properties reinforce the attack from an adversarial point of view. The more often the victim sends a certain message type of the same size, the more suitable it is for the attack for two main reasons. On the one hand, connections can be closed faster and on the other, the attacker only needs to store payloads for a short time. We therefore recommend using either the PING or PONG message types. PINGs are sent approximately every two minutes [10] and are the smallest non-empty messages. However, both messages are transported in 29-byte payloads which makes them indistinguishable based on just the payload size. As the adversary does not maintain any protocol state, they will inevitably be wrong sometimes, i.e., PINGs may be replaced with PONGs or vice versa.
3.3
Occupying the target’s connection slots
A single honest connection to the network is sufficient for a node to remain in consensus with the rest of the network. A successful eclipse attack therefore requires that each of the victim’s peers is controlled by the adversary. Inbound connection slots can be filled easily by the adversary as there are no requirements for them. Hence, it suffices to connect to the target from one host with one IP address on different ports until all slots are occupied. Filling the outgoing connection slots is significantly more challenging as there is not much the adversary can actively do besides making sure that their addresses are inserted into the new table. The approach described in [43] still works even though a series of measures was deployed in response to previous eclipse attacks [3, 20, 43]. We therefore provide a pertinent overview of the steps an adversary must take in order to receive connections from the victim; a detailed description is available in Appendix D. 1. The adversarial addresses must be inserted into the victim node’s address database. The adversary inserts its addresses by participating in the P2P network and relaying its addresses via regular ADDR to the victim node; 2. the adversary must have at least ten IP addresses from distinct /16 IPv4 or /32 IPv6 subnets. As our threat model assumes a network-level adversary such as an AS, we assume that they are able to meet this requirement; 3. the size of the address table means that the probability of selection is low. The adversary improves their chances by ensuring that each address occurs multiple times in the new table and that they are all from different prefix groups; and
C. Ndolo and F. Tschorsch
4. after an address has been selected, Bitcoin Core performs various checks to verify that the address is suitable as an outgoing connection. Among others, they check that the selected node supports a series of application-level features. Adversarial nodes must announce each of these features, however, they do not need to actually support any of them.
3.4
Maintaining connections
The eclipse attack is successful once the adversary has managed to occupy all of the victim node’s connection slots. Depending on the adversary’s ultimate objective, the adversary needs to sustain the connections for follow-up attacks. Bitcoin core implements various mechanisms to make sure that connections are active and useful to a node. Connections that do not fulfil these requirements are replaced. We identified the minimum functionality a client must implement in order to maintain the P2P connections. In the following, we provide an overview of the relevant mechanisms and how each can be overcome. basic-btc-client is our implementation of such a client and is described in Appendix C.2. It implements the necessary functionality to bypass the challenges while maintaining no protocol state. Application layer handshake Subsequent to the TCP handshake, a node will wait for up to 60 seconds for the initiator to start the P2P handshake (cf. Fig. 1). If that does not happen, the newly-established connection will be closed. Hence, the bare minimum an adversarial node must do to avoid immediate disconnection is to perform the handshake with the victim. Timeout Several timeouts lead to disconnection. However, with respect to a minimal P2P peer that does not relay data, the most relevant is a 20-minute inactivity timeout [11]. It expires if either a PONG in response to a PING does not arrive in time or, more generally, if a node has not received any communication from a peer within the timeout. Adversarial nodes can avoid disconnection simply by responding to PINGs from the victim node. Synchronisation of outbound peers A node may disconnect an outbound peer if they are determined to be out-of-sync with the node’s blockchain, i.e., if they have never sent a block header or have only sent one with old information [12]. A node verifies that an outbound peer is synchronised by sending them a GETHEADERS message requesting block headers from a particular point in the blockchain. The response, a HEADERS message, must be received within two minutes. Failure to respond within the timeout or responding with stale data leads to immediate disconnection. As the adversarial nodes do not propagate chain data, they will be inevitably asked to verify their chain state after 20 minutes. In order to pass the verification and keep the connection open, adversarial nodes can keep track of the chain state by issuing GETHEADERS messages periodically. An alternative is to send the exact same GETHEADERS message back to the victim, wait for their HEADERS reply, and then simply send the received data back to the victim node. The latter approach is preferable as it does not require protocol state but relies on the victim’s HEADERS message arriving before the two-minute timeout elapses. Eviction of inbound peers The victim may still receive incoming connection requests from other nodes in the network. This triggers the eviction mechanism that determines which peer to disconnect so as to free up a slot for the new connection. While the eviction policy is complex and out-of-scope of this work, the adversary is at a clear disadvantage for two reasons: they do not provide any useful data to the victim and each of the incoming
1:9
Security Analysis of Bitcoin’s V2 Transport Protocol
Initiator kI−
(TCP handshake) kI+
Responder − kR
garbage + kR
Time
1:10
garbage
Window of opportunity
garbage terminator garbage terminator VERSION VERSION
.. .
Figure 3 Overview of the V2 P2P transport protocol connection establishment scheme showing the window of opportunity for downgrade attacks. RST packets sent during this period will cause the initiator to retry using the V1 protocol.
connections were initiated from the same IP address. We refer to [19, 47] for descriptions of the eviction mechanism in Bitcoin. The adversary has two straightforward options of dealing with potential eviction. They can either block all incoming TCP SYNs after eclipsing the victim or allow such connections and risk temporary eviction before closing them as part of the attack.
4
Downgrade attack
In the following, we present a downgrade attack that reopens the door to the full range of legacy attacks. The objective of the downgrade attack is to force the victim into using the original unencrypted protocol for all P2P communication. The attack leverages the fact that V2 P2P transport lacks a version negotiation protocol and relies on the transport layer for signalling of compatibility. The adversary can therefore first perform an additional step of downgrading the victim’s connections before proceeding to their primary attack.
4.1
Downgrading V2 P2P transport connections
An active network-level adversary can take advantage of BIP 324’s compatibility considerations to ensure that a victim node only uses the V1 P2P transport protocol. In order to understand how they can do so, we revisit the different phases a new TCP/IP connection goes through. As illustrated in Fig. 3, nodes exchange keys and generate shared secrets after connection establishment. BIP 324 encourages implementations to retry using the V1 protocol if they are met with immediate disconnection when establishing a V2 P2P transport connection. While immediate is not specified, Bitcoin Core will retry if the responder terminates the connection before completion of the key exchange phase. Therefore, an adversary can downgrade the connection by injecting a TCP RST packet at any point during the key exchange phase. They can do so by either changing a legitimate packet to a RST packet (in-path [29]) or injecting a forged RST packet into the TCP stream (on-path [46]). However, it has been shown that on-path attack systems can generally be detected by observing anomalies in the traffic flows [29, 46]. In order to comply with the protocol specification, e.g., for the sake of discretion, the RST packet should be sent from the responder to the initiator. However, a Bitcoin Core initiator will retry the connection regardless of where the RST originated from as long as it is during the window of opportunity shown in Fig. 3. The initiator will then open a new TCP connection to the responder, skip the key exchange and version negotiation phases, and initiate the regular handshake of VERSION/VERACK messages. Evidently, no communication over this connection will be
C. Ndolo and F. Tschorsch
encrypted. The adversary ensures that all of a victim’s connections use the V1 transport protocol by consistently interfering with all connection attempts to/from the victim node.
4.2
Identifying V2 connection attempts
As described so far, the adversary interferes with all connection attempts regardless of the transport protocol version the connection would use. That would cause more damage than intended to the victim node because V1 transport connections will not be retried. Our measurements in the mainnet showed that less than 50% of the node’s outgoing connections are V2 P2P transport connections. Since the attack’s objective is to ensure that all of the connections are unencrypted, the adversary does not need to interfere with V1 connection attempts. The adversary, therefore, needs to be able to differentiate between connections that will use V1 P2P transport and V2 P2P transport. The protocol version a new connection will use can be determined based on the payload of the first packet after the TCP handshake. The adversary can use either the content or the size of the first payload to distinguish the protocol version that is being set up. The initiator will use V2 P2P transport if the NODE_P2P_V2 service flag was previously announced for the responder’s address. If a V1 connection is being established, the initiator’s first packet after the TCP handshake will contain 126 bytes of payload as it is a VERSION message (cf. Fig. 1). In contrast, V2 P2P transport’s first payload is larger and cannot be serialised to VERSION message. The adversary only needs to downgrade the connection in the latter case.
4.3
Window of opportunity
Fig. 3 shows the window of opportunity for this attack. It is the time period during which public keys, garbage and garbage terminators are exchanged. Bitcoin Core implements this phase in one and a half round trips as follows: 1. initiator sends their kI+ and garbage; + 2. responder sends their kR , garbage, garbage terminator and VERSION message; and
3. initiator sends their garbage terminator and VERSION. This makes the critical period shorter in practice and requires that the attack is implemented efficiently. Nonetheless, there remains ample time for a successful attack.
4.4
Attack duration
The downgrade attack depends on the adversary’s ability to interfere with connections while they are being established. If the victim node already has some peers, the attack will require a significant amount of time as connections tend to be kept alive for extended periods [3, 34]. The attack can be sped up significantly if the adversary waits for or is able to trigger a reboot of the victim node. Besides deliberate efforts to restart a node such as DDoS, memory exhaustion or power failures, there are more predictable reasons such as major software upgrades [20]. For instance, according to the Bitnodes crawler, 120 nodes had upgraded to Bitcoin Core 28.0 one day after its release on 4 October 2024. The number was up to 447 nodes a week later and 1562 nodes after 30 days. In other words, there were at least 1562 restarts in the first month after Bitcoin Core 28.0’s release. Furthermore, previous work [8] found that a node with a public IP address has a 10% probability of going offline after two hours. The probability increases to 25% after ten hours.
1:11
1:12
Security Analysis of Bitcoin’s V2 Transport Protocol
Virtual Mininet network Victim node Bitcoin Core 28.0
Seed nodes Bitcoin Core 28.0
x
193.168.1.i/24, i ∈ [3, 5]
basic-btc-client (connect mode)* iptables and netfilter-based attack code 193.168.1.2/24
Router Regular nodes
Attacker nodes*
Bitcoin Core 27.0 or Bitcoin Core 28.0
basic-btc-client (listen mode)
175.i.0.j/16, i ∈ [1, 200], j ∈ [1, 3]
11.i.0.1/16, i ∈ [1, 20]
* only for the eclipse attack x position simulates a network-level attacker
Figure 4 Network topology used for the evaluation of the eclipse and downgrade attacks.
5
Evaluation: Eclipse Attack
In the following, we describe our evaluation setup before presenting results concerning various aspects of the attack. Multiple results are omitted due to space constraints but are provided in Fig. 14 as part of the appendix. The impact of eclipse attacks on Bitcoin has been evaluated extensively in previous work (refer to [19] for an analysis of the impact of eclipse attacks). Our evaluation therefore places emphasis on the primary contributions of this work.
5.1
Methodology
We built our own testbed, btc-play-ground, for the purpose of evaluating the attack in a controlled environment (see Sec. 9 for ethical considerations). It is based on the Mininet project [26] and uses Docker containers as hosts to build a virtual network topology. We refer to Appendix C.1 for further information on btc-play-ground. We deployed the topology illustrated in Fig. 4 on an Ubuntu 24.04 LTS server with 16 cores and 94 GiB RAM. In addition to seed nodes, the network consisted of 621 hosts and was configured as follows: 3 hosts each in 200 subnets, running either Bitcoin Core 27.0 or Bitcoin Core 28.0; 1 Debian Linux container with our implementation of the attack attached to a netfilter queue as well as Bitcoin Core 28.0 (the victim node). The attack code, which we implemented using the netfilter framework and describe in greater detail in Appendix C.2, replays PING messages and uses basic-btc-client1 to occupy the victim’s inbound slots and announce adversarial addresses. An iptables rule set directs all packets on TCP port 8333 to the netfilter queue. The victim and the attacker were placed in the same container due to implementation simplicity. The setup is representative of an in-path attacker as traffic must flow through them, i.e., the adversary’s position is different, but the traffic they can intercept and their capabilities remain the same. Separating the two components in our testbed is not expected to have any impact on the attack’s evaluation; 20 subnets containing 1 host each running basic-btc-client and waiting for connections. The adversary uses these hosts to fill the victim’s outgoing connection slots; and a block generation time of ten minutes. All Bitcoin Core instances were configured with the default settings. The only exception was the victim as we set the maximum number of connections to 50 which only has an 1
basic-btc-client is our implementation of a minimal Bitcoin client (cf. Appendix C.2 for a description).
C. Ndolo and F. Tschorsch
Attacker
28.0.0
Network traffic (MB)
27.1.0
50
100
40
50 Duration (days)
Number of peers (max=50)
1:13
30 20 10 0 0
2
4
Attack period (hours)
1 peer/replay
3 peers/replay
20 IPs 30 IPs 50 IPs
20 IPs 30 IPs 50 IPs
5 peers/replay
10 peers/replay
20 IPs 30 IPs 50 IPs
20 IPs 30 IPs 50 IPs
5 4 3
0
20
0
5
10 Number of connections
5
2 1
10
0
0
2
4
0
2
4
Attack period (hours)
Figure 5 The victim node’s Figure 6 Time required for Figure 7 Data sent (left) and number of inbound and out- the attacker to occupy a 30-day received (right) by the victim’s bound peers by user agent before old node’s outgoing connection Bitcoin Core client before and and during the attack. slots. during the attack in megabytes.
impact on the number of incoming connections the victim will allow, i.e., 10 outgoing, 1 feeler and 39 incoming connection slots. As inbound slots are easier to monopolise, this setting has little to no impact on the validity of our experiments. The attack code was launched 24 hours after the network was deployed in order to allow the victim to arrive at a ‘stable’ state with respect to its peers and address tables. 100% of the victim node’s outgoing and ≈ 80% of its incoming connection slots were occupied when the attack started (see Fig. 14a in the appendix for the absolute number of connections). This is comparable to what we observed on our measurement node and confirms that the attack was evaluated under realistic conditions with respect to the victim’s connections. The presented results refer to data collected 30 minutes prior to the attack until the victim was eclipsed.
5.2
Feasibility
Message classification The attacker’s ability to identify application messages in the TCP payloads is of significant value to the attack’s success, especially with regard to terminating connections efficiently. In order to quantify how well the adversary is able to identify messages types in real time, we compared the ground-truth messages logged by the victim’s Bitcoin Core client and the attack code’s logs during the attack. We examine only outgoing PINGs because they are relevant for the attack. We calculated commonly used classification metrics for these messages which reveal a precision of 0.99 and recall of 0.52. The high precision means that payloads classified as PINGs were almost always PINGs. The lower recall means that the program failed to detect approximately half of the PINGs sent by the victim node. The main reason for that is that a TCP segment may carry more than one application message which inevitably leads to inaccuracies when only using payload size as an indicator. Attack success Fig. 5 shows the victim node’s number of connections differentiated by user agent, i.e., the client version advertised by a node. The onset of the attack is clearly visible in two ways. Firstly, there is a steep drop in the number of connections. This initial decline is expected because the node had multiple connections which were terminated by the attacker in quick succession. Secondly, the number of peers advertising their user agent as ‘Attacker’ starts to rise. However, the rise is not as steep as the decline of legitimate user agents. This is because some of the closed connections are outgoing, and the adversary has no control over when the victim will connect to them. This is why the number of legitimate user agents sometimes increases during the attack. The victim is eclipsed after approximately
1:14
Security Analysis of Bitcoin’s V2 Transport Protocol
five hours at the point when 49 of its connections are to the attacker. The 50th connection slot is only ever occupied temporarily when the victim node initiates a feeler connection. While these results demonstrate that the presented attack can be mounted successfully, they do not show that, in reality, the attack requires more time. This is because a target’s address database will contain more entries. In order to estimate how long it would take under more realistic conditions, we simulated a simplified version of the selection of outgoing connections (see Appendix C.3 for implementation details). Incoming connections are not decisive for the duration of the attack as the adversary initiates them. Bitcoin Core sends PINGs to peers every two minutes meaning that the adversary can replay a packet on a given connection after four minutes. The simulation assumes that the adversary replays a packet between the victim node and a given peer every four minutes, i.e., a new peer is chosen every four minutes. We performed the simulations using the address database of a 30-day old node, a varying number of addresses, and a varying number of concurrent disconnections per minute. The latter refers to the number of connections the adversary can close per minute, e.g., when set to one, the attacker closes a single connection per minute. The estimated time required to occupy all ten outgoing connection slots with adversarial addresses is shown in Fig. 6 for various combinations of these parameters. The worst case is if the adversary can only close a single connection at a time and uses only 20 different IP addresses. In this case, they require around 100 days to eclipse the victim node. Using the same number of addresses, the required time is reduced to less than 30 days if five connections are closed at the same time. In the best case, the adversary uses 50 addresses and is able to always close all ten connections at a go. The attack then takes just 10 days to succeed. Aside from the fact that comparable attacks are no longer practical, our attack is less expensive (w.r.t. the necessary network addresses) and faster, e.g., the EREBUS attack takes five to six weeks. This is because our attack relies more on exhausting entries in the victim’s address database instead of filling the entire database. The best results are obtained by closing multiple connections at the same time and having many addresses available. The duration is shortened further if they can close multiple connections in quick succession, which depends on how fast they can identify payloads containing PING messages and/or how offensive they are willing to be. The adversary can therefore assign higher precedence to stealth, lower resources or speed making the attack more versatile than similar ones.
5.3
Latency overhead
We measured the latency added to each packet by our implementation during the attack. We recorded the time from the program first accessing a packet in the netfilter queue to a decision being made and the packet being returned to the kernel. The data was collected from the onset of the attack until its completion. The results suggest that our implementation is quite efficient and issues a verdict on a packet within a median time of 32.6µs and mean time of 39µs (see Sec. D the appendix for a plot). That equates to a mean throughput of ≈ 25, 641pps regardless of packet size. in We conclude that the delays induced by the extra filtering layer are negligible and do not have a negative impact on the feasibility of the attack. We argue that delays in the range of tens of microseconds are likely to go unnoticed by operators. Besides, the attack is implemented in user-space code, and would likely be more efficient if it made use of lower-level functions.
C. Ndolo and F. Tschorsch
5.4
Attack footprint
The TCP connection is closed by the remote side regularly via the four-way handshake which does not suggest any malicious interference. The victim node’s Bitcoin Core client writes an ECONNRESET error [23] to the log file which does not indicate any malicious activity either. Among other reasons, such an error may be issued by the kernel when the client attempts to write to a connection the remote peer considers to be closed as is the case here. We therefore examine whether the attack leaves any evidence at the network layer. Fig. 7 shows the total network traffic recorded by the victim’s Bitcoin Core client prior to and during the attack. It shows an unmistakable peak in both sent and received traffic when the attack starts. This can be explained by the fact that many connections are closed and opened in quick succession at that point. As the number of connections to the attacker increases, the rate of traffic on average reduces. This is because basic-btc-client nodes do not initiate any unsolicited communication. However, the traffic pattern changes in that it is burstier compared to before the attack started. The reasons for the bursts are either the opening/closing of connections or the victim node transmitting application messages. The main indicator of the attack is likely to be the sudden onset of closed connections in quick succession which can be countered by staggering the attack, e.g., attack at most a certain number of connections per time interval. However, as evidenced by the simulation results in Fig. 6, the attack is significantly faster when connections are closed speedily. The adversary therefore needs to assign higher precedence to either speed or stealth. The change in traffic patterns might also make an attentive node operator suspicious leading them to dig deeper and discover that all of their incoming connections are from one IP address. This risk can be mitigated easily by imitating Bitcoin Core’s behaviour in basic-btc-client. However, none of this actually provides insight on to why connections are being closed.
6
Evaluation: Downgrade attack
In the following, we describe our evaluation setup and then present results concerning various aspects of the downgrade attack. Multiple results and graphs are omitted due to space constraints but are provided in Fig. 15 as part of the appendix.
6.1
Methodology
We used the network shown in Fig. 4 (without attacker nodes) and configured the victim container to run the user-space implementation of the attack attached to a netfilter queue as well as a Bitcoin Core 28.0 client. An iptables rule set is used to direct all TCP packets on port 8333 from the client to the netfilter queue. The attack code, detailed in Appendix C.4, monitors the victim’s network traffic and forges RST packets by modifying a legitimate packet when it detects a new V2 P2P transport connection attempt. Similar to the eclipse attack, the attack code was launched 24 hours after the network was deployed in order to allow the victim node to arrive at a ‘stable’ state. The entire network was then restarted at the onset of the attack so as to model basic churn as connections in the private network (and in the public network) are otherwise very long-lived. By doing so, we ensure that the victim node receives incoming connections while the attack code is attached. While this does not represent natural churn, the best time to perform the downgrade attack is after a reboot as all connections can be downgraded simultaneously, making legacy attacks possible sooner. The results presented in what follows refer to data collected 30 minutes prior to launching the attack and during the first two hours.
1:15
Security Analysis of Bitcoin’s V2 Transport Protocol Table 1 Excerpt of a packet trace between a node (175.6.0.2) and the victim node (193.168.1.2) in the testbed as captured and displayed by Wireshark. Plain ACK packets have been omitted for brevity. The attacker forges a RST packet (#9) from the responder during the key establishment phase. The initiator reacts by reconnecting to the victim using V1 P2P transport. No. Time
Src
Dst
Prot.
Len. Info
1 2 3 4 5 9 10 11 12 13 15
175.6.0.2 193.168.1.2 175.6.0.2 175.6.0.2 175.6.0.2 193.168.1.2 175.6.0.2 193.168.1.2 175.6.0.2 175.6.0.2 193.168.1.2
193.168.1.2 175.6.0.2 193.168.1.2 193.168.1.2 193.168.1.2 175.6.0.2 193.168.1.2 175.6.0.2 193.168.1.2 193.168.1.2 175.6.0.2
TCP TCP TCP TCP TCP TCP TCP TCP TCP Bitcoin Bitcoin
0 0 0 2896 625 0 0 0 0 126 126
09:37:56.858152 09:37:56.858284 09:37:56.864617 09:37:56.889652 09:37:56.889674 09:37:56.890003 09:37:56.979774 09:37:56.979889 09:37:56.985895 09:37:57.006229 09:37:57.006425
Incoming
Outgoing
44120>8333 [SYN] Seq=0 8333>44120 [SYN;ACK] Seq=0 Ack=1 44120>8333 [ACK] Seq=1 Ack=1 44120>8333 [PSH;ACK] Seq=1 Ack=1 44120>8333 [PSH;ACK] Seq=2897 Ack=1 8333>44120 [RST;ACK] Seq=1 Ack=3522 44126>8333 [SYN] Seq=0 8333>44126 [SYN;ACK] Seq=0 Ack=1 44126>8333 [ACK] Seq=1 Ack=1 version version
Total
50 Number of peers (max=50)
1:16
40 30 20 10 0 −0.5
0.0
0.5
1.0
1.5
2.0
Attack period (hours)
Figure 8 The victim node’s number of peers before and during the attack. The connections established after the restart were all using V1 P2P transport unlike before the attack.
6.2
Feasibility
We first demonstrate that the attack can indeed be carried out by a network-level adversary. We captured the network traffic at the victim node and show an excerpt of the packet trace in Table 1. It shows a connection establishment between a regular node (175.6.0.2) and the victim node (193.168.1.2) while the attack code was running. Packets #4 to #8 show the initial parts of the key exchange phase. The code does not tamper with these packets but we now know that the connection is being setup for V2 P2P transport. Therefore, the program changes packet #9 to a RST from the responder. In response, the initiator opens a new TCP connection (#10 to #12) and then starts the unencrypted handshake by sending a VERSION immediately afterwards. The connection has been successfully downgraded at this point.
6.3
Attack success
We now show that the attack was successful in that all of a victim’s connections were downgraded to the V1 P2P transport protocol. 100% of the victim node’s connection slots were occupied prior to the attack and were using V2 P2P transport as expected. Fig. 8 shows the number of peers the victim node maintained prior to and during the attack. The onset of the attack is clearly visible at the point when the node’s connection count drops to zero. The figure shows that the victim node quickly established all of its outgoing connections, while it took more time before its incoming connection slots were filled. This is consistent with previous work [43] and our measurements in the mainnet. However, 100% of the connections
C. Ndolo and F. Tschorsch
that were established during the attack used V1 P2P transport. In reality, the attack requires more time if the victim node is already participating in the P2P network. The adversary may need to wait for a reboot of the victim (cf. Sec. 4.4). However, depending on the adversary’s ultimate objective, a certain percentage of V1 peers may be sufficient. In that case, the attack duration is shorter and may not require a reboot. In fact, our measurements showed that at no point were more than 50% of the outgoing connections and 70% of the incoming connections using V2 P2P transport. This suggests that the attack is likely less time-consuming in practice.
6.4
Latency overhead
We measured the latency added by our implementation of the attack during the first two hours. Specifically, we recorded the duration from the program first reading a packet from the netfilter queue to a decision being made and it being returned to the kernel. The results are similar to the implementation of the eclipse attack in Sec. 5.3. The program issues a verdict on a packet within a median time of 41µs and mean time of 49µs. This leads to a mean throughput of ≈ 20, 408pps regardless of packet size. This implementation can also be made more efficient by making use of lower-level functions. We refer to Fig. 15a in the appendix for a plot of these results.
6.5
Attack footprint
Although the window of opportunity for this attack is long enough for an on-path adversary to inject a RST packet into the stream, we chose to implement it as an in-path attack. This is because on-path attack systems can generally be detected by observing anomalies in the traffic flows [29, 46]. One would simply notice the arrival of a RST packet despite already receiving the legitimate key exchange packets. The main reason for concern might be the fact that none of a node’s connections, including connections the victim node had prior to the attack, are using V2 P2P transport. However, the lack of derivations from the protocol specification would make it difficult to identify the attack without out-of-band communication.
7
Countermeasures
Our analysis of V2 P2P transport uncovered conceptual weaknesses that we exploit for the attacks this work. Completely mitigating the attacks may not be possible: closing connections on failed decryption appears to be standard practice and a full protocol negotiation mechanism requires updates to past releases. However, there are certain features of Bitcoin and V2 P2P transport that are conducive for attacks. In the following, we pinpoint these problems (P), propose possible countermeasures (C) for each and evaluate some short-term measures.
7.1
Primary countermeasures
This first set of measures relates directly to making network-level attacks less viable in general. We believe that these measures are effective on their own, but may require significant protocol changes and additional research to fully understand their expected impact on Bitcoin. P1 Network-level information leakage: Classification at the network level without the need for any state information is reasonably accurate. We can expect even higher accuracy if the adversary uses sophisticated fingerprinting techniques, e.g., leveraging that Bitcoin is mainly a request-response protocol.
1:17
1:18
Security Analysis of Bitcoin’s V2 Transport Protocol
C1 Bitcoin needs to obfuscate TCP payloads’ features by including a length-hiding scheme. Examining what an appropriate mechanism for Bitcoin would be exceeds the scope of this work, but we refer to a recent work [33] for a comprehensive discussion on padding strategies for the Lightning network. The main points apply to Bitcoin. P2 Default port: TCP port 8333 is the default for P2P communication and was used by over 95% of the reachable nodes according to the Bitnodes crawler at the time of writing. As V2 P2P transport is not self-revealing, a default port is somewhat self-defeating. C2 Using a non-default port forces the adversary to monitor all network traffic and not just on port 8333. Transitioning to non-default ports has been raised previously [3, 13] but we are not aware of any related changes. While we generally support this recommendation, we argue that it is only effective in combination with traffic shaping. The new port can otherwise possibly still be inferred from traffic patterns (cf. P1). We also acknowledge that random ports would complicate matters for network devices such as firewalls. P3 Network-level protocol negotiation: BIP 324 encourages clients to retry with the V1 protocol if the connection is closed immediately after the TCP handshake. This makes it possible for a network-level adversary to downgrade a connection. C3A Protocol version negotiation should be handled by the application layer as is commonly done. For instance, HTTP’s upgrade mechanism over TLS could be used to negotiate the protocol after connection establishment as is done in Ripple [1]. However, any such approach would only be meaningful in combination with authentication (cf. P4). C3B Currently, feeler connections are closed immediately after the application handshake. This means that a node not only discovers whether an address is reachable, but also which transport version the remote node supports. When the address is selected as an outgoing peer, the local node should attempt to only connect with the discovered protocol. C3C A further measure is to discontinue this behaviour when the adoption of V2 P2P transport is considered to be mature enough or after a certain number of releases past when V2 P2P transport was activated. Older clients would still be able to connect to the network as they, as the initiators, decide whether to perform the key exchange or not. P4 Lack of authentication: Our analysis shows that a P2P connection can be downgraded upon reconnection even though the peers had been previously using V2 P2P transport. C4 We suggest adding transport protocol information to the state maintained on peers and only reconnecting using the stored version or higher. This is especially relevant for connections whose main purpose is to protect a node from attacks. If C2 were to be adopted, authentication becomes indispensable in order to ensure the legitimacy of the remote peer. In the case of C3B, feeler connections should include authentication.
7.2
Secondary countermeasures
The next set of measures addresses additional issues we identified in the course of this work. They, however, cannot secure the P2P overlay from network attacks on their own. P5 Unrestricted incoming connections: The resources required for attacks are lowered significantly as all incoming connections can be from one IP address. In fact, measurement data shows that at least 75% of incoming connections were from distinct /16 prefix groups (cf. Fig. 11 in the appendix).
C. Ndolo and F. Tschorsch
C5 We recommend limiting the number of incoming connections per network prefix or at least per IP address to raise adversarial costs. As incoming slots are considered scarce [18], the constraints need not be as strict as for outbound connections and should only came into effect when most slots are occupied to mitigate partition risks. P6 Unverified service flags: Service flags are advertisements made by nodes to announce protocol features they support. They are part of ADDR messages and can be spoofed or falsified trivially. Nodes can therefore simply announce the favourable features without actually supporting them, much to the benefit of an adversary. C6A Service flags, at least those required for outbound connections, should be validated, e.g., using a challenge-response protocol. A node that advertises the NETWORK flag should be able to respond with a valid BLOCK when queried for a random block hash. An adversary can still fake their service flags, but they would be forced to maintain protocol state. C6B Although less preferable, service flags should not be taken into consideration when selecting outbound peers. As it stands, they do not do not provide any real protection. P7 Bypassable synchronisation check: Among others, a node checks that an outgoing peer is synchronised to the same blockchain height as they are. If not, the node sends a GETHEADERS message asking for recent block hashes and closes the connection if it does not receive a valid response within a timeout. The sustainability of eclipse attacks is enhanced by the fact that an adversary can simply send the exact same GETHEADERS message to the node, wait for their HEADERS reply and then send the response back. C7 Nodes should not respond to GETHEADERS from peers that are up for possible disconnection. This would force the adversary to maintain state via legitimate connections. P8 Lack of anomaly detection: Bitcoin Core does not include any monitoring or anomaly detection. This makes it very hard for node operators to detect attacks in time. C8 Anomaly detection mechanisms should be deployed to support node operators in securing their nodes. It should issue warnings and alerts about unusual events such as unusually frequent disconnections or extended periods without receiving any data. Monitoring would not mitigate the attacks but it would allow operators to react accordingly.
7.3
Evaluation of short-term countermeasures
Although the primary measures are the most effective, they are impractical in the near term as they require protocol changes and further research. The secondary measures, on the other hand, are insufficient on their own but several can already be deployed immediately. To assess their practical viability, we implemented C3C and C5 in Bitcoin Core 28.0 and ran two nodes with these changes on the public network. Alongside C3C, which prevents any connection attempt from being retried following a TCP reset, we implemented C5 such that requests from prefix groups the node already has connections from are only accepted when less than x% (x ∈ {90, 95}) of the incoming slots are full. We monitored both nodes’ connection statistics over 30 days. The percentage of occupied incoming slots and of outgoing V2 P2P transport peers is shown in Fig. 13 in the appendix. It reveals variations in how fast nodes fill their incoming connection slots. The 90% threshold was met after 8 days and the remaining slots were gradually filled up to full capacity despite the restrictions on the connections to accept.
1:19
1:20
Security Analysis of Bitcoin’s V2 Transport Protocol
One node received connection requests very slowly such that the 95% threshold had not yet been met at the time of writing. The data also shows that both nodes had outgoing V1 connections despite supporting V2 P2P transport and C3C. This is because Bitcoin Core uses the service flags propagated in ADDR messages to determine whether to attempt a V2 P2P transport connection. Manual inspection of the relayed service flags after connection revealed that several of our V1 peers did in fact support V2 P2P transport but this had not propagated to our nodes at the time of connection establishment. Overall, the data indicates that all incoming slots will eventually be filled despite C5 and the maximum number of outgoing connections is also maintained under C3C. We are therefore confident that these measures can be deployed immediately without adversely affecting the P2P network.
8
Related Work
Due to the magnitude of research on attacks in Bitcoin, we limit the following discussion to network-level attacks and refer to surveys [14, 17] for extensive overviews on various attacks. Eclipse attacks in Bitcoin were first discussed in 2015 [20] at a time when Bitcoin had several shortcomings in its management of nodes’ addresses. Despite the deployment of multiple countermeasures, multiple works later presented eclipse attacks [3, 16, 43]. These attacks are closely related to our work as they share a common attacker model and attack objective. However, our eclipse attack differs from all of these attacks in multiple aspects. It does not involve hijacking network traffic and is designed to work in the presence of encrypted communication. Additionally, none of the attacks are still viable under V2 P2P transport as originally described. Furthermore, our attack does not require a reboot of the target node unlike the attacks presented in [20, 43]. The attack in [20] differs from ours in more ways besides not operating at the network layer. Most notably, we do not exploit protocol vulnerabilities to initiate connections from the victim to the attacker. Unlike the earlier works, we also discusses sustaining the attack in detail. Eclipse attacks have also been studied in related P2P networks such as Ethereum [21, 28], Monero [42] and IPFS [38]. Some of these related works [3, 43] also performed measurements of the Bitcoin mainnet. However, they do not cover the V2 P2P transport protocol as they were conducted at a time when BIP 324 was not yet finalised. This work is, to the best of our knowledge, the first to study the P2P layer following the specification of V2 P2P transport. Existing work briefly describes V2 P2P transport as a countermeasure to the presented attack [48]. Bitcoin’s P2P network has long been subject to traffic analysis attacks targeting privacy [8, 9, 24] and topology inference [35]. BIP 324 aims to increase the cost of such attacks by encrypting messages. While recent works on traffic analysis focus on the Lightning Network [33, 44], the threat of traffic analysis is not specific to blockchain networks [15, 31, 39].
9
Conclusion
This paper presented the first study of Bitcoin’s new V2 P2P transport protocol. In doing so, we contribute to the further understanding of the protocol and offer an additional source of reference. We studied V2 P2P transport’s ability to secure the overlay from network-layer attacks. While we conclude that V2 P2P transport successfully hinders previously-known, network-layer attacks, we present an alternative path to eclipse attacks. By exploiting properties introduced by the usage of encrypted communication channels, we developed an eclipse attack that is based on closing connections by replaying TCP payloads. Our analysis of the attack showed that it is highly effective. We then presented a downgrade attack
C. Ndolo and F. Tschorsch
that takes advantage of how compatibility with the V1 protocol is achieved. It reopens the door to attacks that are no longer possible in the presence of encrypted communication. In conclusion, we proposed a series of countermeasures that can be taken in response to the findings in this work. Some of them, e.g., defining a length-hiding scheme, require additional research and present interesting avenues for future work. References 1 2
3
4 5
6
7
8
9 10 11 12 13 14
Overlay. URL: https://github.com/XRPLF/rippled/blob/master/src/xrpld/overlay. Maria Apostolaki, Cedric Maire, and Laurent Vanbever. Perimeter: A network-layer attack on the anonymity of cryptocurrencies. In Financial Cryptography and Data Security - 25th International Conference, FC 2021, Virtual Event, March 1-5, 2021, Revised Selected Papers, Part I, volume 12674 of Lecture Notes in Computer Science, pages 147–166. Springer, 2021. doi:10.1007/978-3-662-64322-8\_7. Maria Apostolaki, Aviv Zohar, and Laurent Vanbever. Hijacking bitcoin: Routing attacks on cryptocurrencies. In 2017 IEEE Symposium on Security and Privacy, SP 2017, San Jose, CA, USA, May 22-26, 2017, pages 375–392. IEEE Computer Society, 2017. doi: 10.1109/SP.2017.29. Michael D. Bailey, David Dittrich, Erin Kenneally, and Douglas Maughan. The menlo report. IEEE Secur. Priv., 10(2):71–75, 2012. doi:10.1109/MSP.2012.52. Daniel J. Bernstein. Curve25519: New diffie-hellman speed records. In Moti Yung, Yevgeniy Dodis, Aggelos Kiayias, and Tal Malkin, editors, Public Key Cryptography - PKC 2006, 9th International Conference on Theory and Practice of Public-Key Cryptography, New York, NY, USA, April 24-26, 2006, Proceedings, volume 3958 of Lecture Notes in Computer Science, pages 207–228. Springer, 2006. doi:10.1007/11745853\_14. Henry Birge-Lee, Maria Apostolaki, and Jennifer Rexford. Global bgp attacks that evade route monitoring. In Passive and Active Measurement: 26th International Conference, PAM 2025, Virtual Event, March 10–12, 2025, Proceedings, page 335–357, Berlin, Heidelberg, 2025. Springer-Verlag. doi:10.1007/978-3-031-85960-1_14. Henry Birge-Lee, Liang Wang, Jennifer Rexford, and Prateek Mittal. Sico: Surgical interception attacks by manipulating bgp communities. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, CCS ’19, page 431–448, New York, NY, USA, 2019. Association for Computing Machinery. doi:10.1145/3319535.3363197. Alex Biryukov, Dmitry Khovratovich, and Ivan Pustogarov. Deanonymisation of clients in bitcoin P2P network. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security, Scottsdale, AZ, USA, November 3-7, 2014, pages 15–29. ACM, 2014. doi:10.1145/2660267.2660379. Alex Biryukov and Ivan Pustogarov. Bitcoin over tor isn’t a good idea. In 2015 IEEE Symposium on Security and Privacy, pages 122–134, 2015. doi:10.1109/SP.2015.15. Bitcoin Core Developers. Bitcoin core 28.x, 2024. URL: https://github.com/bitcoin/ bitcoin/blob/28.x/src/net_processing.cpp#L84. Bitcoin Core Developers. Bitcoin core 28.x, 2024. URL: https://github.com/bitcoin/ bitcoin/blob/28.x/src/net.h#L57. Bitcoin Core Developers. Bitcoin core 28.x, 2024. URL: https://github.com/bitcoin/ bitcoin/blob/28.x/src/net_processing.cpp#L5460-L5516. Bitcoin Core Developers. Bitcoin core issue #31036, 2024. URL: https://github.com/ bitcoin/bitcoin/issues/31036. Joseph Bonneau, Andrew Miller, Jeremy Clark, Arvind Narayanan, Joshua A. Kroll, and Edward W. Felten. Sok: Research perspectives and challenges for bitcoin and cryptocurrencies. In 2015 IEEE Symposium on Security and Privacy, SP 2015, San Jose, CA, USA, May 17-21, 2015, pages 104–121. IEEE Computer Society, 2015. doi:10.1109/SP.2015.14.
1:21
1:22
Security Analysis of Bitcoin’s V2 Transport Protocol
15
Kevin P. Dyer, Scott E. Coull, Thomas Ristenpart, and Thomas Shrimpton. Peek-a-boo, I still see you: Why efficient traffic analysis countermeasures fail. In IEEE Symposium on Security and Privacy, SP 2012, 21-23 May 2012, San Francisco, California, USA, pages 332–346. IEEE Computer Society, 2012. doi:10.1109/SP.2012.28.
16
Wenjun Fan, Sang-Yoon Chang, Xiaobo Zhou, and Shouhuai Xu. Conman: A connection manipulation-based attack against bitcoin networking. In IEEE Conference on Communications and Network Security, CNS 2021, Tempe, AZ, USA, October 4-6, 2021, pages 101–109. IEEE, 2021. doi:10.1109/CNS53000.2021.9705018.
17
Federico Franzoni and Vanesa Daza. Sok: Network-level attacks on the bitcoin P2P network. IEEE Access, 10:94924–94962, 2022. doi:10.1109/ACCESS.2022.3204387.
18
Matthias Grundmann, Max Baumstark, and Hannes Hartenstein. On the peer degree distribution of the bitcoin p2p network. In 2022 IEEE International Conference on Blockchain and Cryptocurrency (ICBC), pages 1–5, 2022. doi:10.1109/ICBC54727.2022.9805511.
19
Jaehyun Ha, Seungjin Baek, Muoi Tran, and Min Suk Kang. On the sustainability of bitcoin partitioning attacks. In Financial Cryptography and Data Security - 27th International Conference, FC 2023, Bol, Brač, Croatia, May 1-5, 2023, Revised Selected Papers, Part II, volume 13951 of Lecture Notes in Computer Science, pages 166–181. Springer, 2023. doi:10.1007/978-3-031-47751-5\_10.
20
Ethan Heilman, Alison Kendler, Aviv Zohar, and Sharon Goldberg. Eclipse attacks on bitcoin’s peer-to-peer network. In Jaeyeon Jung and Thorsten Holz, editors, 24th USENIX Security Symposium, USENIX Security 15, Washington, D.C., USA, August 12-14, 2015, pages 129–144. USENIX Association, 2015. URL: https://www.usenix.org/conference/ usenixsecurity15/technical-sessions/presentation/heilman.
21
Sebastian A. Henningsen, Daniel Teunis, Martin Florian, and Björn Scheuermann. Eclipsing ethereum peers with false friends. In 2019 IEEE European Symposium on Security and Privacy Workshops, EuroS&P Workshops 2019, Stockholm, Sweden, June 17-19, 2019, pages 300–309. IEEE, 2019. doi:10.1109/EUROSPW.2019.00040.
22
Ghassan Karame, Elli Androulaki, and Srdjan Capkun. Double-spending fast payments in bitcoin. In Ting Yu, George Danezis, and Virgil D. Gligor, editors, the ACM Conference on Computer and Communications Security, CCS’12, Raleigh, NC, USA, October 16-18, 2012, pages 906–917. ACM, 2012. doi:10.1145/2382196.2382292.
23
Michael Kerrisk. Linux manual page. URL: https://man7.org/linux/man-pages/man3/ errno.3.html.
24
Philip Koshy, Diana Koshy, and Patrick D. McDaniel. An analysis of anonymity in bitcoin using P2P network traffic. In Financial Cryptography and Data Security - 18th International Conference, FC 2014, Christ Church, Barbados, March 3-7, 2014, Revised Selected Papers, volume 8437 of Lecture Notes in Computer Science, pages 469–485. Springer, 2014. doi: 10.1007/978-3-662-45472-5\_30.
25
Hugo Krawczyk. Cryptographic extraction and key derivation: The HKDF scheme. In Advances in Cryptology - CRYPTO 2010, 30th Annual Cryptology Conference, Santa Barbara, CA, USA, August 15-19, 2010. Proceedings, volume 6223 of Lecture Notes in Computer Science, pages 631–648. Springer, 2010. doi:10.1007/978-3-642-14623-7\_34.
26
Bob Lantz, Brandon Heller, and Nick McKeown. A network in a laptop: rapid prototyping for software-defined networks. In Proceedings of the 9th ACM Workshop on Hot Topics in Networks. HotNets 2010, Monterey, CA, USA - October 20 - 21, 2010, page 19. ACM, 2010. doi:10.1145/1868447.1868466.
27
Shaoyu Li, Shanghao Shi, Yang Xiao, Chaoyu Zhang, Y. Thomas Hou, and Wenjing Lou. Bijack: Breaking bitcoin network with TCP vulnerabilities. In Computer Security - ESORICS 2023 28th European Symposium on Research in Computer Security, The Hague, The Netherlands, September 25-29, 2023, Proceedings, Part III, Lecture Notes in Computer Science, pages 306–326. Springer, 2023. doi:10.1007/978-3-031-51479-1\_16.
C. Ndolo and F. Tschorsch
28
29
30
31
32 33
34 35
36 37
38
39
40
41
Yuval Marcus, Ethan Heilman, and Sharon Goldberg. Low-resource eclipse attacks on ethereum’s peer-to-peer network. Cryptology ePrint Archive, Paper 2018/236, 2018. URL: https://eprint.iacr.org/2018/236. Bill Marczak, Nicholas Weaver, Jakub Dalek, Roya Ensafi, David Fifield, Sarah McKune, Arn Rey, John Scott-Railton, Ron Deibert, and Vern Paxson. An analysis of china’s "great cannon". In 5th USENIX Workshop on Free and Open Communications on the Internet (FOCI 15), 2015. URL: https://www.usenix.org/conference/foci15/workshop-program/ presentation/marczak. Dhruv Mehta, Tim Ruffing, Jonas Schnelli, and Pieter Wuille. Version 2 p2p encrypted transport protocol, 2024. URL: https://github.com/bitcoin/bips/blob/master/bip-0324. mediawiki. Brad Miller, Ling Huang, Anthony D. Joseph, and J. D. Tygar. I know why you went to the clinic: Risks and realization of HTTPS traffic analysis. In Privacy Enhancing Technologies 14th International Symposium, PETS 2014, Amsterdam, The Netherlands, July 16-18, 2014. Proceedings, volume 8555 of Lecture Notes in Computer Science, pages 143–163. Springer, 2014. doi:10.1007/978-3-319-08506-7\_8. Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008. URL: https: //nakamotoinstitute.org/bitcoin/. Charmaine Ndolo and Florian Tschorsch. Payment censorship in the lightning network despite encrypted communication. In 6th Conference on Advances in Financial Technologies, AFT 2024, September 23-25, 2024, Vienna, Austria, volume 316 of LIPIcs, pages 12:1–12:24. Schloss Dagstuhl - Leibniz-Zentrum für Informatik, 2024. doi:10.4230/LIPICS.AFT.2024.12. Till Neudecker. Characterization of the bitcoin peer-to-peer network (2015-2018). Technical Report 1, Karlsruher Institut für Technologie (KIT), 2019. doi:10.5445/IR/1000091933. Till Neudecker, Philipp Andelfinger, and Hannes Hartenstein. Timing analysis for inferring the topology of the bitcoin peer-to-peer network. In 2016 Intl IEEE Conferences on Ubiquitous Intelligence & Computing, Advanced and Trusted Computing, Scalable Computing and Communications, Cloud and Big Data Computing, Internet of People, and Smart World Congress (UIC/ATC/ScalCom/CBDCom/IoP/SmartWorld), Toulouse, France, July 18-21, 2016, pages 358–367. IEEE Computer Society, 2016. doi:10.1109/ UIC-ATC-SCALCOM-CBDCOM-IOP-SMARTWORLD.2016.0070. Yoav Nir and Adam Langley. ChaCha20 and Poly1305 for IETF Protocols. RFC 8439, June 2018. doi:10.17487/RFC8439. M. Peuster, H. Karl, and S. van Rossem. Medicine: Rapid prototyping of productionready network services in multi-pop environments. In 2016 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN), pages 148–153, Nov 2016. doi:10.1109/NFV-SDN.2016.7919490. Bernd Prünster, Alexander Marsalek, and Thomas Zefferer. Total eclipse of the heart – disrupting the interplanetary file system. In 31st USENIX Security Symposium, pages 3735– 3752. USENIX Association, 2022. URL: https://graz.elsevierpure.com/en/publications/ total-eclipse-of-the-heart-disrupting-the-interplanetary-file-sys. Jean-François Raymond. Traffic analysis: Protocols, attacks, design issues, and open problems. In Designing Privacy Enhancing Technologies, International Workshop on Design Issues in Anonymity and Unobservability, Berkeley, CA, USA, July 25-26, 2000, Proceedings, volume 2009 of Lecture Notes in Computer Science, pages 10–29. Springer, 2000. doi:10.1007/ 3-540-44702-4\_2. Muhammad Saad and David Mohaisen. Three birds with one stone: Efficient partitioning attacks on interdependent cryptocurrency networks. In 44th IEEE Symposium on Security and Privacy, SP 2023, San Francisco, CA, USA, May 21-25, 2023, pages 111–125. IEEE, 2023. doi:10.1109/SP46215.2023.10179456. Jonas Schnelli. Peer-to-peer communication encryption, 2016. URL: https://github.com/ bitcoin/bips/blob/master/bip-0151.mediawiki.
1:23
1:24
Security Analysis of Bitcoin’s V2 Transport Protocol
42 43
44
45
46
47
48
Ruisheng Shi, Zhiyuan Peng, Lina Lan, Yulian Ge, Peng Liu, Qin Wang, and Juan Wang. Eclipse attacks on monero’s peer-to-peer network. 01 2025. doi:10.14722/ndss.2025.240095. Muoi Tran, Inho Choi, Gi Jun Moon, Anh V. Vu, and Min Suk Kang. A stealthier partitioning attack against bitcoin peer-to-peer network. In 2020 IEEE Symposium on Security and Privacy, SP 2020, San Francisco, CA, USA, May 18-21, 2020, pages 894–909. IEEE, 2020. doi:10.1109/SP40000.2020.00027. Theo von Arx, Muoi Tran, and Laurent Vanbever. Revelio: A network-level privacy attack in the lightning network. In 8th IEEE European Symposium on Security and Privacy, EuroS&P 2023, Delft, Netherlands, July 3-7, 2023, pages 942–957. IEEE, 2023. doi:10.1109/EUROSP57164. 2023.00060. Ziqiang Wang, Xuewei Feng, Qi Li, Kun Sun, Yuxiang Yang, Mengyuan Li, Ganqiu Du, Ke Xu, and Jianping Wu. Off-path tcp hijacking in wi-fi networks: A packet-size side channel attack. 01 2025. doi:10.14722/ndss.2025.230305. Nicholas Weaver, Robin Sommer, and Vern Paxson. Detecting forged TCP reset packets. In Proceedings of the Network and Distributed System Security Symposium, NDSS 2009, San Diego, California, USA, 8th February - 11th February 2009. The Internet Society, 2009. URL: https://www.ndss-symposium.org/ndss2009/detecting-forged-tcp-reset-packets/. Huashuang Yang, Jinqiao Shi, Yue Gao, Xuebin Wang, Yanwei Sun, Ruisheng Shi, and Dongbin Wang. Evicting and filling attack for linking multiple network addresses of bitcoin nodes. Cybersecur., 6(1):50, 2023. doi:10.1186/S42400-023-00182-9. Yuwen Zou, Wenjun Fan, and Zhen Ma. Unveiling vulnerabilities in bitcoin’s misbehaviorscore mechanism: Attack and defense. In Proceedings of the 19th International Conference on Availability, Reliability and Security, ARES 2024, Vienna, Austria, 30 July 2024 - 2 August 2024, pages 28:1–28:12. ACM, 2024. doi:10.1145/3664476.3664509.
Ethical Considerations The primary goal of this work is to contribute to further advancement of the security and resilience of the Bitcoin network for all involved users. Uncovering, presenting, and addressing potential concerns in the network is a central part of that process. Prior to submission, we shared a copy of the manuscript and informed Bitcoin Core’s security team about our intention to publish our results. We are yet to receive a response, but note that we are prepared to discuss the suggested countermeasures and to cooperate on implementing measures in response to this work. As far as the practical evaluation of the attacks is concerned, we followed the guidelines of the Menlo report [4] and general security research best practices. In particular, with the exception of conducting measurements using our own node, we did not interact with the public mainnet in any way. The measurements neither store nor reveal any information about other nodes in the network, and are based entirely on normal node operation. All adversarial experiments were conducted in our private testbed (in regtest mode) and only consists of nodes set up for the precise purpose. We will not publish our implementations of the attacks as we cannot control how they are used. We, however, made the code available to reviewers in entirety and will consider doing the same to researchers upon request.
Open Science In line with the principles of open science, we have uploaded all of our source code to an anonymised repository. We have made our best efforts to document it clearly enough for independent use. The following artefacts are available at the respective repository:
C. Ndolo and F. Tschorsch
1. our proof-of-concept implementation of both the eclipse and downgrade attacks is only available for reviewers; 2. basic-btc-client which is a minimal Bitcoin client2 ; 3. the implementation of our Mininet-based testbed.3 It was designed with generality in mind and is potentially useful for similar research projects. The documentation contains details on how to reproduce our experiments; and 4. our simulator for the selection of outgoing addresses.4 The repository includes our node’s dump of its address tables as obtained from Bitcoin Core using the getrawaddrman RPC. Subsequent to peer review, the artefacts will be published on GitHub for general access. The only exception is our implementation of the attacks which we withhold to mitigate potential misuse. We consider the paper detailed enough for readers to reproduce with their own implementation, if necessary. We will, however, provide the code for research purposes only upon request contingent on it not being distributed beyond the intended scope.
A
Measurement Study of V2 P2P transport in the Public Network
In an effort to understand the extent and impact of V2 P2P transport on the Bitcoin network, we conducted measurements in the mainnet. The results shown in this work refer to data collected between 24 May 2025 and 7 July 2025. The measurements are performed passively using our own freshly-deployed node running Bitcoin Core 28.0 in the mainnet. The node is reachable via a public IP address, accepts incoming connections via TCP/IP and is configured with the default settings. To the best of our knowledge, this is the first empirical study of V2 P2P transport in the public network. Number of peers The first set of results provides general data on the measurement node. Fig. 9 shows its number of connections based on snapshots taken every four hours. The figure shows that the node established the maximum of ten outgoing connections within a short period of time and steadily maintained that many connections. Spikes in the number of outgoing connections are due to feeler connections that test the reachability of stored addresses. On the other hand, the number of incoming connections gradually increases over time such that over 90% of its available connection slots were filled after 14 days. Both of these observations are consistent with reports in previous works [43]. Percentage of V2 P2P transport peers Fig. 10 shows the share of connections using the V2 P2P transport protocol. It shows that at most 50% of the node’s outgoing connections are V2 P2P transport connections. This is somewhat unexpected as roughly 60%5 of the reachable nodes in the mainnet were using Bitcoin Core 27.0 and above as of 24 May 2025. As the connections tend to be long-lived, the percentage of V2 P2P transport peers does not fluctuate much. This seems to suggest that potential outgoing peers should be selected with even more care if support for encrypted communication is of importance as such connections are likely there to stay. In the case of incoming connections, the number slowly increases as more nodes initiate connections to the measurement node. 2
https://github.com/tud-dud/btc-v2-attack-tools https://github.com/tud-dud/btc-play-ground 4 https://github.com/tud-dud/btc-addr-sim 5 According to data gathered by the Bitnodes crawler: https://bitnodes.io. 3
1:25
Security Analysis of Bitcoin’s V2 Transport Protocol
Incoming
Outgoing
Total
Incoming
Percentage of V2 connections
Number of peers (max=125)
Outgoing
70
120 100 80 60 40 20 0
60 50 40 30 20 10 0
0
10
20 30 Node uptime (days)
40
0
10
20 30 Node uptime (days)
40
Figure 9 Number of inbound and outbound Figure 10 Percentage of V2 connections mainpeers. tained by the measurement node distinguished by connection type. Incoming
New table(≤ 216 )
Outgoing
100
104 103
95
Number of addresses
Percentage of unique prefix groups
90 85 80
102 Tried table(≤ 214 ) 3000 2000 1000
75 0
10
20 30 Node uptime (days)
0
40
0
10
20 30 Node uptime (days)
40
Figure 11 Percentage of peers from distinct /16 Figure 12 Number of entries in the measureprefix groups. ment node’s address database.
Occupied incoming slots
90%
95%
Outgoing V2 peers
100 80 Percentage
1:26
60 40 20 0 0
10
20
30 0 Node uptime (days)
10
20
30
Figure 13 Percentage of occupied incoming slots and of outbound V2 P2P transport peers after activating C5 with {90%, 95%} and C3C. The sudden drop on days 24 and 25 is due to an unexpected shutdown of the host running the affected measurement node.
C. Ndolo and F. Tschorsch
Percentage of unique prefix groups Fig. 11 shows the share of distinct /16 prefix groups connected to the measurement node. It shows that 100% of its outgoing connections were to different prefix groups. This is expected as Bitcoin Core only initiates connections to prefix groups that are not already part of the node’s outgoing connections to increase the cost of eclipse attacks. Although no such restrictions exist on incoming connections, over 75% of them consistently originated from distinct prefix groups. Address tables Fig. 12 shows the progression of the number of entries in the respective address management tables during the measurement period. We recorded the size of the measurement node’s new and tried tables whenever an entry was added to either table. The figure shows that new table was already almost at full capacity after approximately five days in the network. On the other hand, the tried table was at roughly 20% of its capacity at the end of the measurement period.
B
V2 P2P transport message classification
As described in Sec. 2.5, the information available in the TCP header suffices to weaken confidentiality against passive attacks. For illustration, we show how to identify message types using the INV message. It is used to advertise objects, e.g., transactions or blocks, and features the INV_VEC data structure. Like every packet, it contains 20 bytes of mandatory fields, an additional byte for the flags and the application message in the contents. The message contains a vector of inventory objects and a variable-length field encoding the number of objects in the vector (cf. Sec. D for a visual description). The number of objects in the vector is limited to 50k entries which means that the length field is always encoded in either one or three bytes. Each inventory object is 36 bytes big and, therefore, the smallest non-empty INV message is 37 bytes big. Therefore, a TCP payload containing a non-empty encrypted INV message has a minimum length of 58 bytes. Similarly, the maximum length of such an unfragmented TCP payload is just slightly larger than 1.8 megabytes. To that end, we can use the number of bytes in the TCP payload to determine if a payload contains an INV message. Given a TCP payload with x bytes, the payload can be determined to be an INV message if x, after subtracting 21 bytes for the mandatory fields and either 1 byte or 3 bytes for the length field, is a multiple of 36, i.e., if (x − 21 − {1, 3}) mod 36 = 0. This formula also gives us the number of INV_VEC objects in the payload. We remark that the classification accuracy of this approach is limited in cases where message formats are identical. Such message types, e.g., GETDATA and INV, only differ in the value of the type field and are therefore indistinguishable based on just the payload size. We therefore recorded the type and size of all V2 P2P transport messages that were either sent or received by the node to examine if and to what extent V2 P2P transport protects against such attacks. We recorded a total of 99.51 M incoming and 98.97 M outgoing V2 messages during the measurement period. Table 2 shows the three most common sizes and their respective occurrence rates as a percentage of all messages of the specific type for select message types. Note that the sizes refer to the entire TCP payload, i.e., the size includes the length descriptor, flags, type and tag fields. A general observation we make is that messages of the same size tend to occur frequently, which is not necessarily a given since a majority of application messages contain variable-length fields. The BLOCK message type appears to be an exception, with a maximum occurrence rate of 2.09% at a payload size of 237 bytes. As a follow up to the hypothesis in Sec. 2.5, we examine the recorded lengths of INV
1:27
1:28
Security Analysis of Bitcoin’s V2 Transport Protocol Table 2 The three most frequent sizes of common Bitcoin V2 P2P transport messages. The length of a TCP payload containing such a message is equal to the listed length. Type
Size (B)
%
37 65 52 237 236 287 230 568 530 23216
34.06 9.99 8.2 2.09 0.82 0.07 11.48 1.9 1.57 0.08
ADDRV2 ADDRV2 ADDRV2 BLOCK BLOCK BLOCK BLOCKTXN BLOCKTXN BLOCKTXN CMPCTBLOCK
Type GETBLOCKTXN GETBLOCKTXN GETBLOCKTXN GETDATA GETDATA GETDATA HEADERS HEADERS HEADERS INV
Size (B)
% Type
55 57 56 58 94 130 103 162024 184 58
19.52 INV 12.13 INV 11.28 PING 43.77 PONG 18.85 TX 10.83 TX 95.55 TX 2.11 VERSION 0.77 VERSION 14.48 VERSION
Size (B)
%
94 130 29 29 375 243 244 135 150 136
11.61 9.95 100.0 100.0 9.52 8.4 6.61 90.58 7.39 1.34
messages. Notably, 14.48% of the INV messages were transported in 58-byte payloads. These messages contain one INV_VEC and are the smallest possible INV messages. The second-most frequent payload size for INV messages was 94 bytes. As described in Sec. 2.5, we can deduce that such a payload contains two INV_VEC objects. We can apply similar logic to the other payload sizes and try to find out what type of message is being transmitted. For example, a 103-byte TCP payload could be a HEADERS message containing exactly one block header which, as evident in Table 2, is transmitted very frequently. We refer the reader to Fig. 16 for an overview of how exactly these messages are defined. While we cannot decipher the exact contents of the payload, previous works have shown that such side channels can be exploited for effective attacks, e.g., [33, 44, 45]. We believe that knowledge of the message type alone is sufficient for censorship or delay attacks. In practice, classification at the network level is not always as straightforward and accurate for the following reasons: 1. application messages naturally add some randomness to the bytestream because of the presence of variable-length fields in most message types. As related works have shown, message types with distinct but invariable lengths can be classified extremely accurately despite encryption [33, 44]; and 2. application messages are transmitted as continuous streams of data that are separated by magic bytes, and therefore, a TCP payload may carry more than one application message. Unlike V1 streams, packet boundaries cannot be determined by examining the payload. However, we contend that the frequencies are sufficient for network-level classification attacks using just the length of TCP payload.
C
Implementation: Testbed, attacks & simulator
In the following, we describe the testbed that we used for our analysis of the attacks (Appendix C.1). We also provide further details on our implementation of the eclipse attack (Appendix C.2), address table simulator used to evaluate the duration of the eclipse attack (Appendix C.3) and downgrade attack (Appendix C.4).
C.1
Testbed
Accurately testing network-layer attacks at scale is challenging for several reasons. It requires that node behaviour resembles real implementations as well as a realistic representation of the
C. Ndolo and F. Tschorsch
networking layer. Furthermore, and especially in the case of partitioning attacks, the size of the network must be taken into account. This requires resources that are not always available. Related attacks have in the past been evaluated by either simulating certain aspects of the Bitcoin protocol [43], attacking nodes deployed in the public network [16, 20] or setting up a testbed of real Bitcoin Core clients running in a dedicated network [3]. We decided to perform our evaluations in a private network as it provides the most authentic client behaviour without the risk of interfering with third-party nodes in any way. Unfortunately, some of the components of the testbed used in [3] are not publicly available. While warnet,6 a software tool to generate private Bitcoin networks, is promising, it does not provide access to key networking functionality, e.g., defining different IP networks. We therefore built our own testbed, named btc-play-ground, out of necessity, and make it publicly available.7 It uses Containernet [37], a fork of the Mininet project [26], to build a virtual network topology that runs on a Linux machine. Containernet extends Mininet with support for Docker containers as hosts. The testbed has the potential to support a wide range of network-layer research on Bitcoin as well as related networks and is highly configurable. Like warnet, Docker containers running configurable versions of Bitcoin Core in ‘regtest’ mode are used as hosts and are connected to form a private Bitcoin network. It handles bootstrapping automatically using three Bitcoin Core 28.0 nodes serving as seed nodes. It includes a Prometheus server and Grafana dashboard monitoring various application-specific metrics, e.g., peer count, as well as relevant system metrics of the Linux server. It supports building a network topology of multiple ASs that are connected via switches and routers. Currently, different networks are reserved for various types of hosts: 175.0.0.0/8 for regular Bitcoin core clients, 193.168.1.0/24 for a victim node as well as seeds and 11.0.0.0/8 for adversarial clients. Parameters such as the number of subnets, nodes per subnet and block generation rate are all configurable at runtime. This ensure scalability and general accessibility to users with different computation resources to their disposal. We plan on extending btc-play-ground and adding support for more features in the future. We intend on modelling the network topology to resemble the public Bitcoin network more, e.g., the distribution of AS and latencies between peers. We also plan on generalising btc-play-ground such that it can be used for various P2P networks aside from Bitcoin.
C.2
Eclipse attack
Our implementation of the eclipse attack consists of two components: the network-level attack logic and the application-level logic that handles the adversary’s connections with the victim.
C.2.1
Attack
We implemented a prototype of the attack using the netfilter8 framework which has been used in the past by related works [3, 33]. The attack code was implemented in user space using the nfq-rs9 library in Rust. The source code is available for reviewers in an online repository.
6
https://github.com/bitcoin-dev-project/warnet https://github.com/tud-dud/btc-play-ground 8 https://www.netfilter.org 9 https://github.com/nbdd0121/nfq-rs
7
1:29
1:30
Security Analysis of Bitcoin’s V2 Transport Protocol
The program begins by attaching itself to a queue; traffic to/from the victim node should be directed to this queue. The program monitors all the traffic and issues an ACCEPT verdict in almost all cases. The only exception is for TCP SYNs subsequent to a replayed payload. It stores the first payload that is suspected to be a PING from the victim in a map in which the destination is the key. When a second packet transporting a PING is identified, its payload is replaced with the stored payload, the TCP checksum is recalculated and an ACCEPT verdict is issued. The payload is deleted afterwards such that it only holds a maximum of one 29-byte payload per connection at any given point.
C.2.2
Bitcoin P2P client
The adversary requires a lightweight Bitcoin client that is able to establish and maintain P2P connections with the victim node. As we did not find any such client, we implemented our own client in Rust using the rust-bitcoin10 library. The result is a minimal Bitcoin client, named basic-btc-client that implements the aspects of the P2P transport protocol described in Sec. 3.4. The code is publicly available in an online repository.11 basic-btc-client can be used in client mode, i.e., initiates a connection to a node, or in server mode, i.e., a TCP server listens for and accepts connections. Due to the backwards compatibility specified in BIP 324, the client does not need to support V2 P2P transport.
C.3
Simulation of address selection
In order to evaluate how long the eclipse attack would require in practice, we implemented a simulator for the selection of outgoing addresses. It was implemented in Rust and is available in a repository.12 The simulator expects a dump of a Bitcoin Core node’s address table, the number of attacker addresses, the number of connections to close per time interval and a seed for the random number generator as input. It generates the specified number of attacker addresses in the 0.0.0.0/8 address space which we chose in order to not produce addresses that may collide with addresses in the provided database. The simulation begins by selecting ten addresses at random as the initial peers and continues to keep track of current peers throughout the simulation. The address database is then populated with the attacker addresses in random buckets of the new table. Following the Bitcoin protocol, the simulator makes a feeler connection every two minutes to a random address and moves the address to the tried table. In case the address was present multiple times, all references are also deleted from the new table. Every four minutes, the specified number of random, non-adversarial connections are closed. This means that the simulator fills the freed slots with equally many new connections. It does so by first selecting either the new or tried table at random, and then selecting a random address from the chosen table. The address, and all of its references, are removed from the table. The simulation runs until all ten connections belong to the generated addresses.
C.4
Downgrade attack
We implemented a prototype of the downgrade attack using the netfilter framework as a user-space program in Rust. The source code is available for reviewers in an online 10
https://github.com/rust-bitcoin/rust-bitcoin https://github.com/tud-dud/btc-v2-attack-tools 12 https://github.com/tud-dud/btc-addr-sim 11
C. Ndolo and F. Tschorsch
repository.The basics of the implementation are very similar to the implementation of the eclipse attack described in Appendix C.2. The program begins by attaching itself to a queue; traffic to/from the victim node are directed to this queue. It monitors all the traffic it receives and issues an ACCEPT verdict for all packets. When a TCP SYN in either direction is taken from the queue, the program starts to keep track of the particular connection. Specifically, it waits for the TCP handshake to be completed and then monitors the payloads being transmitted over the connection. If the first packet’s payload contains more than 126 bytes, the program alters the second packet to a TCP RST packet. It sets the RST flag and recalculates the TCP checksum before returning the packet to the kernel.
D
Supplementary material
The following is a follow-up of Sec. 3.3; we expound on what the attacker needs to do in order to occupy the victim node’s outgoing connection slots. Entering the tables The most fundamental step the adversary must perform is to insert their addresses into the victim’s new table. Whether or not or when such an address moves to the tried table is beyond the adversary’s control. Our adversary inserts its malicious addresses by participating in the P2P network and relaying its addresses via regular ADDR to the victim node. The most effective strategy is to propagate these addresses to the victim directly as well as to other nodes in the network. In the latter case, the addresses will eventually reach the victim via gossip. Prefix groups The Bitcoin protocol stipulates that each of a node’s outgoing connections must be from a different prefix group. The adversary must therefore control at least ten IP addresses from distinct subnets that are waiting for connections. Feeler connections do not partake in information relay in any way, but trigger the migration of addresses to the smaller tried table. Therefore, it is in the adversary’s best interest to provide more than the bare minimum number of addresses in case they are moved to the tried table. Hence, the more unique prefix groups the adversary controls, the faster they will be able to eclipse a node. As our threat model assumes a network-level adversary such as an AS, we do not consider this requirement to be inherently deterring. Table size As the new table can hold up to 216 entries, the odds of an adversarial address being selected are not high. Our adversary improves their chances by ensuring that each address occurs multiple times in the new table and, most importantly, that each of their addresses is from a different prefix group. While our attack relies more on the target depleting the entries rather than filling the entire table, we refer to [43] for a related discussion. Desirable services Once an address has been selected as a potential outgoing connection, Bitcoin Core performs some tests13 on the address before initiating a connection request. Among others, it verifies that the address is valid, publicly routable and belongs to a network group that is distinct from the current outbound network groups. The logic also verifies that the potential peer provides all of the required application-level services. Services are features
13
https://github.com/bitcoin/bitcoin/blob/28.x/src/net.cpp#L2452-L2791
1:31
Security Analysis of Bitcoin’s V2 Transport Protocol
that a node supports, e.g., NODE_P2P_V2 for V2 P2P transport, and are advertised in ADDR messages. All the adversary needs to do is to advertise the relevant flags in the ADDR messages they use to relay addresses. They do not have to actually offer any of the announced services as there is no verification or validation mechanism. They should announce the NODE_NETWORK, NODE_NETWORK_LIMITED and NODE_WITNESS flags to cover all relevant cases. Incoming
Outgoing
Total
100 Processing time (µs)
Number of peers (max=50)
50 40 30 20 10 0
80 60 40 20
0
2
4 n = 53, 049
Attack period (hours)
(a) The number of peers the victim node had before and during the attack. All but one of its incoming connection slots were occupied at the start of the attack. The initial decline in incoming connections is expected because the node already had multiple connections that the attacker tampered with. The results show that the attack progresses quite fast initially, but needs more time to fill the last slots. The victim node was eclipsed after five hours in this experiment.
(b) The packet processing times for the prototype implementation of the eclipse attack. The data was collected during the first five hours of the attack, and is depicted as a violin plot. This is the duration from the program accessing a packet from the queue to it returning the (altered) packet to the kernel. The implementation is quite efficient and issues a verdict on a packet in a median time of ≈ 32µs and mean time of 39µs.
Figure 14 Additional results from the evaluation of the eclipse attack.
Network traffic (KB)
Received
125 100
200
0
75
400
50
Sent
Processing time (µs)
1:32
25
n = 29, 465
(a) The packet processing times for the prototype implementation of the downgrade attack based on packets received during the first two hours of the attack. The figure shows the time from the program accessing a packet from the queue to it returning the (altered) packet to the kernel. The implementation is relatively efficient and issues a verdict on a packet within a median time of ≈ 41µs and mean time of 49µs.
200 0 −0.5
0.0
0.5
1.0
1.5
2.0
Attack period (hours)
(b) The amount of data sent and received by the victim’s Bitcoin Core client before and during the attack in kilobytes. The figure shows an unmistakable peak in both sent and received traffic when the attack starts. This is because many connections are closed and opened in quick succession at that point due to the restart.
Figure 15 Additional results from the evaluation of the downgrade attack.
C. Ndolo and F. Tschorsch
1:33
Table 3 Summary of BIP 324’s objectives and how they are achieved. Traffic shaping is considered to be out-of-scope of BIP 324 and is not implemented. Upgradability is not yet relevant as there is currently only one version of V2 P2P transport. Objective
What
How
#1
Confidentiality against passive attacks
Unauthenticated ChaCha20Poly1305 encryption of the plaintext communication between nodes.
#2
Observability of active attacks
#3
Pseudorandom bytestream
#4
Shapable bytestream
An attacker must not be able to determine the plaintext being exchanged from a recorded V2 P2P transport bytestream without additional information. An active man-in-the-middle attacker runs the risk of being detected as a session ID uniquely identifies an encrypted channel. A passive attacker must not be able to distinguish a bytestream without timing and fragmentation information from a uniformly random bytestream. It should be possible to shape V2 P2P transport bytestreams to increase resistance to traffic analysis.
#5
Forward secrecy
#6
Upgradability
#7
Compatibility
V2 P2P transport clients accept inbound V1 connections to minimise risk of network partitions.
#8
Low overhead
The computational cost or bandwidth for nodes that implement V2 P2P transport should not increase substantially compared to the original protocol
An eavesdropper who compromises a node’s sessions secrets should not be able to decrypt historical session traffic. The protocol should provide an upgrade path using transport versioning which can be used to add features in the future.
Manual comparison of session IDs by operators.
ChaCha20 encryption of the length field with a different (from plaintext encryption) key. The ignore bit in encrypted packets is used to indicate decoy packets. BIP 324 does not specify how and when decoy packets should be used. A hash step is performed every 224 messages (≤ 3.11 days) to rekey the encryption ciphers. The VERSION message sent during the version negotiation phase is used to encode support for a specific protocol version. BIP 324 does not specify how exactly version support should be announced. Connection attempts are to be retried in case of immediate disconnection when establishing a V2 P2P transport connection. The protocol provides a slight bandwidth reduction compared to the original protocol. Among other measures, the format of V2 P2P transport messages leads to smaller messages.
1:34
Security Analysis of Bitcoin’s V2 Transport Protocol
Size (B)
Description
1 3 5 9
[0, 253) [254, 216 − 1] [216 , 232 − 1] ≥ 232
(a) Size of the variable length integer encoding used for the length of application messages.
20B + 1B + INV
Size (B)
Desc.
Size (B)
Desc.
1+ 36×0+
count inventory
4 32
type hash
(b) Structure and size of a V2 P2P transport TCP payload transporting an INV message. It contains the mandatory fields (length descriptor, authentication tag and flags), one byte encoding the message type and the INV message. The INV message contains a variable number of inventory vectors which is encoded using the scheme in Fig. 16a.
20B + 1B + ADDR
Size (B)
Desc.
1+ 30×0+
count address list
Size (B)
Desc.
4 8 16 2
timestamp services IP address port number
(c) Structure and size of a V2 P2P transport TCP payload transporting an ADDR message. It contains the mandatory fields (length descriptor, authentication tag and flags), one byte encoding the message type and the ADDR message. The ADDR message contains a variable number of address lists which is encoded using the scheme in Fig. 16a.
20B + 1B + HEADERS
Size (B)
Desc.
1+ 81×0+
count headers
Size (B)
Desc.
4 32 32 4 4 4 1
version prev. block merkle root timestamp difficulty nonce 0
(d) Structure and size of a V2 P2P transport TCP payload transporting a HEADERS message. It contains the mandatory fields (length descriptor, authentication tag and flags), one byte encoding the message type and the HEADERS message. The HEADERS message contains a variable number of headers which is encoded using the scheme in Fig. 16a.
Figure 16 The format and size (in bytes) of select application messages as defined in the protocol.