Decentralized Lightweight Detection of Eclipse Attacks on Bitcoin Clients

BY KEYHUNTER 06.03.2025
Decentralized Lightweight Detection of Eclipse Attacks on Bitcoin Clients

Clients of permissionless blockchain systems, like Bitcoin, rely on an underlying peer-to-peer network to send and receive transactions. It is critical that a client is connected to at least one honest peer, as otherwise the client can be convinced to accept a maliciously forked view of the blockchain. In such an eclipse attack, the client is unable to reliably distinguish the canonical view of the blockchain from the view provided by the attacker. The consequences of this can be catastrophic if the client makes business decisions based on a distorted view of the blockchain transactions.

In this paper, we investigate the design space and propose two approaches for Bitcoin clients to detect whether an eclipse attack against them is ongoing. Each approach chooses a different trade-off between average attack detection time and network load. The first scheme is based on the detection of suspicious block timestamps. The second scheme allows blockchain clients to utilize their natural connections to the Internet (i.e., standard web activity) to gossip about their blockchain views with contacted servers and their other clients. Our proposals improve upon previously proposed eclipse attack countermeasures without introducing any dedicated infrastructure or changes to the Bitcoin protocol and network, and we discuss an implementation. We demonstrate the effectiveness of the gossip-based schemes through rigorous analysis using original Internet traffic traces and real-world deployment. The results indicate that our protocol incurs a negligible overhead and detects eclipse attacks rapidly with high probability, and is well-suited for practical deployment.

Index Terms—Eclipse attacks, Bitcoin client, gossip protocol.

  1. Introduction

The invention of blockchains as a means of providing an immutable, trustless, and de-centralized ledger promises to revolutionize monetary transfers alongside other applications. It has enabled cryptocurrencies such as Bitcoin [34] to grow without the need for a central authority, and due to its transparency has applicability in a broad range of fields including secure logging infrastructures [39], distributed timestamping [3], and micropayment channels [21]. Any user can join the Bitcoin network and view or add transactions to the distributed ledger. Since the Bitcoin network is an overlay network [42] on top of a public infrastructure (the Internet), a number of attacks on the underlying network are inherited by the Bitcoin network. For example, attacks on DNS servers arise from a lack of proper authentication, or misaligned trust between entities in the delegated DNS hierarchy. Most Bitcoin clients, including the popular bitcoinj, depend on DNS seeders [1] to resolve the symbolic names of peers to their respective IP addresses. A recent survey reveals that 95% of cryptocurrencies employ DNS seeding or IP hard-coding which are censorship prone techniques [31]. If the DNS server used for name resolution by the client is compromised or malicious, then the DNS cache can be poisoned [37] to resolve the domain name to an attacker-controlled IP address. Similar attacks can be launched via insecure Internet core protocols like BGP. As discussed in the literature [28], [15], [33], [24], [26], [40], such network-level vulnerabilities make Bitcoin clients vulnerable to eclipse attacks, where an attacked client is connected only to attacker-controlled peers.

In this paper, we propose two new protocols to help Bitcoin clients detect whether they are being eclipsed. The first protocol detects eclipse attacks by using suspicious block timestamps – i.e., if the time between newly created blocks is too high, then this indicates that the network has been partitioned.

This protocol can be executed by any client in isolation, however, our analysis shows that it takes around 2-3 hours for a client to be relatively sure that it is under attack. To reduce the average attack detection times, we also propose a ubiquitous gossip protocol in which the client piggybacks gossip messages onto its connections to protocol-running servers. This protocol does not require any changes to Bitcoin or its peer-to-peer network. It also requires minimal support from web servers to communicate a small number of Bitcoin block headers. A server can be any host on the Internet that participates in the gossip protocol as a service to the public, and which contributes a small amount of data storage (in the order of few kilobytes) to store the gossip messages. A gossip message consists of a set of Bitcoin block headers. The server receives these gossip messages as different clients connect to it, and the server maintains the strongest view of the blockchain it has seen yet. This view is then passed to the connecting clients in exchange. The gossip protocol can function in a passive or active mode. In the passive mode, block headers are gossiped via inclusion in the HTTP(S) traffic when a client makes a standard web connection with the server. In the active mode, the client initiates connections with known protocol-running servers for the sole purpose of gossiping (to update its view of the blockchain) before it conducts a wallet balance check. We demonstrate the efficiency of our passive mode attack detection via a thorough analysis of real-world Internet traffic traces and show that, on average, the attack detection happens in less than an hour, depending on how many commonly-visited servers participate in the protocol. This time duration is typically sufficient since a block confirmation takes approximately one hour (due to the 6 block confirmation rule [11], while in reality…

more confirmations may be required due to mining pool centralization).

However, in active mode the detection is almost instantaneous, although additional connections with protocol-running servers are necessary. These servers are identified through passive-mode gossiping. The requirements and attack detection time for the proposed protocols are summarized in Table 1.

Various countermeasures have been proposed in the literature to detect eclipse attacks – these are discussed in Section 3. Our goal is to improve on those approaches by providing a practical solution for Bitcoin clients to detect eclipse attacks. The main contributions of this paper are to (i) propose the first (up to our best knowledge) lightweight and ubiquitous gossip protocol that can detect eclipse attacks on Bitcoin clients, (ii) present a fully passive eclipse attack detection protocol based on “suspicious” block timestamps which does not incur additional overhead or server participation, (iii) propose an implementation of the gossip protocols, and (iv) thoroughly analyze the effectiveness of our protocols using real-world network traffic traces and blockchain data.

The rest of the paper is organized as follows. Section 2 provides background information on Bitcoin and eclipse attacks. Section 3 reviews the related work. Section 4 provides an overview of the requirements and system model for the proposed the eclipse detection protocols. Section 5 presents the timestamp-based protocol. Section 6 presents our gossip-based protocol and analyzes the real Internet traffic trace to demonstrate its efficiency. Section 7 discusses real-world deployment and privacy concerns and Section 8 details the implementation and evaluation. Section 9 concludes the paper.

  1. Bitcoin and Eclipse Attacks

2.1. Bitcoin

Bitcoin is a distributed, peer-to-peer electronic payment system that enables Internet-based payments without going through a centralized and trusted entity like a financial institution [34]. A distributed copy of the electronic transaction ledger is stored by multiple peers of the Bitcoin network. Transactions are grouped into blocks, and the blocks are cryptographically linked forming a chain (called a blockchain). Bitcoin uses proof-of-work (PoW) for its consensus mechanism. A number of peers simultaneously attempt to solve a puzzle by finding a pre-image of a cryptographic hash that satisfies the condition of the puzzle. This process is called mining. A peer that solves the puzzle broadcasts its block to other peers in the network. Peers are incentivized to create blocks as they receive a block reward and transaction fees (in Bitcoin’s native cryptocurrency called bitcoin). Two concurrent blocks can be mined and announced simultaneously, and in such a case peers accept the block they receive first. This process of disagreement between peers is called forking. Forking in Bitcoin is resolved by all honest peers agreeing to follow the strongest chain rule, where a chain with the most PoW aggregated is considered to be the current one. Bitcoin requires that a majority of computational power (to mine blocks) belongs to honest parties, so that they can resolve forks in their favor and hence prevent double-spending attacks [41].

In Bitcoin, a block consists of two parts: the header [8] and the list of transactions [7]. The Bitcoin header aggregates the transactions and contains metadata – in particular, the following fields: timestamp, which is the (approximate) time at which the block was created, prevHash, which is the hash pointing to the block preceding the current block (this effectively creates a chain and provides an ordering to the blocks), and nBits, which encodes the block’s difficulty requirement (i.e., the amount of PoW effort required to find a solution hash to the mining puzzle). The difficulty is dynamically set every 2016 blocks in a way to adjust the average block creation time to 10 minutes. At this rate, 2016 blocks would be created in exactly 2 weeks. If it took more than 2 weeks to generate the 2016 blocks, the difficulty is reduced by adjusting the value of nBits. A time shorter than 2 weeks results in a difficulty increase, and a longer time in a decrease.

Peers in the Bitcoin network can, depending on their resource constraints, be categorized as mining nodes, full nodes, or simplified payment verification (SPV) nodes. Throughout the discussion, SPV nodes are also referred to as lightweight clients, light clients or clients. A mining node stores and verifies every block in the blockchain and competes to mine new blocks. A full node is similar to a mining node except that it does not work to mine blocks. An SPV client is a node that stores the block headers alone and verifies that a) each block header points to the previous block header b) and each block header was generated with the PoW required. Bitcoin aggregates transactions within blocks in a way that allows SPV clients (who only store block headers) to verify that any included transaction is part of the blockchain. To check whether a transaction has made it onto the blockchain, an SPV client makes an API call to a full node to request a proof.

2.2. Eclipse Attacks on Bitcoin

To handle the communication, Bitcoin introduces a peer-to-peer Internet overlay network. When a peer attempts to connect to the Bitcoin network, it first finds initial (seed) peers via a DNS lookup to pre-defined domain names. A successful DNS lookup allows the peer to contact seed peers, which in turn return lists of their known peers. The peer connects to these peers and can hence start using the protocol. The security of a Bitcoin client relies on its ability to connect to honest peers in the Bitcoin network. Being connected to an attacker-controlled Bitcoin network undermines the ability of the client to view or transact on the honest ledger, which can result in financial losses. The client may assume that it received payment in exchange for goods and services, only to realize later that the transaction was registered only on the attacker-controlled blockchain and not the canonical blockchain. Detecting such attacks is hence critical for the security of Bitcoin clients.

Unfortunately, as the Bitcoin network relies on the Internet, it inherits all its security drawbacks. Most prominently, in eclipse attacks [28], [27] an adversary manages to hijack all connections from an attacked client to other peers in the network. The client’s view of the network and information dissemination is fully under the control of the attacker. The attacker can provide a malicious view of the Bitcoin blockchain to the client, which may include transactions of bitcoins that have already been spent on the unseen part of the blockchain’s canonical branch (this is called a double-spend attack). A Bitcoin lightweight client may be vulnerable to an eclipse attack through DNS cache poisoning [37] involving the name resolution of Bitcoin seeders [22], [9], or routing attacks where the Bitcoin network is partitioned [15] and the peer eclipsed.

3. Related work

In this section, we investigate network-level attacks on blockchain systems and their countermeasures from the existing literature. Heilman et al. [28] studied and presented the feasibility of an eclipse attack on the Bitcoin network. They showed that it is viable for a powerful adversary who controls a large number of public IPs to monopolize all peer connections to a victim Bitcoin client and consequently present a malicious Bitcoin blockchain view. The ability of an adversary to use this vulnerability to conduct selfish mining and double-spend attacks was further discussed by Gervais et al. [25] and Nayak et al. [35]. Another class of serious attacks is connected to the BGP protocol which is one of the core Internet protocols. Apostolaki et al. [15] demonstrated that the Bitcoin protocol is vulnerable to BGP routing attacks where an attacker controlling a small number of BGP prefixes can partition the Bitcoin network by announcing malicious BGP messages. To prevent such an attack, the SABRE framework was proposed [14]. It is a secure relay network which helps to protect against BGP routing attacks by enabling the Bitcoin clients to connect to relay nodes hosted at safe autonomous systems. To prevent (D)DoS attacks on relay nodes this architecture requires high-performant programmable network switches. Tran et al. demonstrated that Bitcoin clients are vulnerable to the Erebus attack [40], which is a data plane attack (in contrast to the BGP routing attack, which is a control plane attack) and hence requires no routing manipulation. This makes it much more stealthy than previous attacks. Here, an attacker who is able to control ASes that can intercept traffic to a specific set of public IPs which need not be Bitcoin client addresses can execute Erebus attacks. However, in this study (as in all studies above) a successful attacker needs to be powerful (controlling a large number of public IPs or having access to BGP routers). In contrast, Wüst and Gervais [43] as well as Marcus et al. [33] showed the feasibility of an eclipse attack on the Ethereum blockchain by exploiting vulnerabilities in its peer-to-peer protocol where an attacker needs only a small number of machines with public IPs to compromise a victim. Recently, Loe and Quaglia [31] presented a survey which shows that 95% of existing cryptocurrencies are using censorship prone technique to bootstrapping i.e to identify peers in the network. The reason for this is attributed to code reuse of the five major cryptocurrencies. Also, the survey highlight the fact that 32% of cryptocurrencies rely on a single DNS provider for their DNS seeds leading to single point of failure. Finally, they analyze censorship resilient techniques which was found to be very inefficient with high latency overhead and none of the cryptocurrencies were able connect using this technique.

Although we are not aware of any work similar to ours, the detection and prevention of attacks on blockchain light clients is an active research topic. The popular Bitcoin light clients add hard-coded checkpoint block headers [5], [6] into their code bases. This helps to prevent malicious miners from reorganizing large parts of blockchain to produce a weaker view and present it to the light client. The bitcoinj light client developers have mentioned a proposal to detect eclipse attacks by analyzing the block arrival rate [1], but there is no known implementation of such a feature yet. In Section 5, we provide a detailed study on the effectiveness of such a feature in protecting light clients against eclipse attacks.

The fraud proofs by Mustafa et al. [13] help light clients to identify invalid blocks and reject them. The proposed data availability proofs support the light clients to gossip small chunks of information about the block for which it received a fraud proof. Therefore, the network which consists of light clients and full nodes can rebuild the complete block information to validate the proof. However, this approach requires significant modifications to the existing protocols and needs the support of a threshold number of honest light clients. The protocol is able to detect incorrect blockchain blocks, however, in contrast to our scheme fraud proofs do not detect eclipse attacks if the blocks have a valid content.

One research direction is to make light clients even lighter such that they do not have to process entire chains. Non-Interactive Proofs of Proof-of-Work (NIPoPoW) [29] and FlyClient [32] help encode blockchains such that their total PoW is expressed in a concise manner. For every chain, light clients only need to download a small proof from full nodes to make sure that their view is stronger than all known alternatives. Unfortunately, these schemes involve significant modifications to the Bitcoin protocol, e.g., Bitcoin header modification. Also, the security of NIPoPoWs is guaranteed only under certain parameter settings and in some cases it involves multiple round-trip communications between the light clients and full nodes, which increases the overhead at the light client. Although many of these issues were addressed in FlyClient, their protocol modifications form an obstacle to adaptability. Similar to the previous work, neither NIPoPoWs nor FlyClient can detect eclipse attacks by themselves – however, if deployed they could minimize the overheads introduced by our system.

TimestampInfrastructure Support RequiredNetwork LoadAttack Detection TimeRefer to
Gossippassive modeServersNatural browsing traffic3 hours
active modeServersAdditional connectionsImmediate

Table 1: Comparison of the proposed eclipse attack detection protocols.

Conceptually, the most related work to ours is in the context of monitoring the consistency of append-only centralized log servers as presented by Chuat et al. [19]. They propose a protocol for monitoring the consistency of certificate logs [30], where web clients exchange signed log statements via their HTTP(S) connections. This process helps to find potential inconsistencies in log statements, hence proving malice. An alternative approach for the same problem was proposed by Nordberg et al. [36], where web clients implement a feedback mechanism to inform a domain about observed log statements for the domain certificates. Due to the different setting, these schemes are not applicable in our scenario.

  1. Solution Overview

The objective of this work is to provide lightweight methods for a Bitcoin light client to detect that it is being subjected to an eclipse attack.

Our first observation is that if a Bitcoin light client is under an eclipse attack, it is then impossible for it to detect the attack via the Bitcoin network itself (as its view is controlled by the adversary). Therefore, to facilitate detection of the attack, an external infrastructure is necessary. However, deploying a new dedicated infrastructure is a challenging task in practice. Therefore, the protocol would ideally be implemented on top of a currently existing infrastructure.

The second observation is that although the attacked light client cannot itself learn that its blockchain view is malicious, the attack is trivially detectable if any stronger concurrent view of the blockchain is available to the affected client. Permissionless blockchains, like Bitcoin, do not introduce any trusted entities that could assert which blockchain view is canonical. Instead they follow the strongest chain rule, so given two conflicting views of different strengths it is trivial to decide which is the canonical one. Therefore, the deployed detection infrastructure can be implemented as a medium for exchanging blockchain views between protocol participants. Every participant can simply compare its local view with the obtained one, detect any potential attack, and save the strongest view as the current one.

The main idea behind our gossip-based protocols is based on the observation that users of Bitcoin light clients conduct standard network connections, like web browsing, messaging, email, etc, even when their client is under an eclipse attack. Therefore, if they were to be able to exchange their blockchain views with contacted Internet servers who would store only the strongest seen view, then that could be the base for a detection system. The passive gossip scheme only uses natural traffic for attack detection. By contrast, the active gossip scheme uses natural traffic to learn of protocol-following nodes, and purposely initiates connections with a subset of them during periods of interest, i.e., when the user checks her wallet balance via the client. The timestamp-based approach uses its own principles, which will be discussed in Section 5. In the remainder of this section we present our system model and the requirements of our detection systems.

4.1. System Model

The main agents in our system are as follows:

  • Server (S) is an Internet server that provides services accessible to the public and supports our protocol. Each server builds and stores its view of the blockchain from the block headers supplied to it by the clients when they establish a connection with the server. Each client sends a partial consecutive view of its block headers to the server when it connects to use its service.
  • Lightweight Client (LC) (or just a client) is an SPV node of the Bitcoin network. Each LC obtains its view of the blockchain from the Bitcoin network that it is connected to. An LC may be under an eclipse attack, in which case it receives a malicious view of the blockchain controlled by an attacker. We assume that LCs beside Bitcoin software run other programs (e.g., a web browser) and conduct user-driven Internet connections (e.g., browsing or messaging). In this work we focus on light clients as they are the most popular and convenient way for regular users to interact with the Bitcoin network. However, our protocol can be also run by other Bitcoin clients, e.g., full nodes.
  • Attacker is a malicious entity able to launch an eclipse attack on Bitcoin clients. The adversary may control (either directly or indirectly) enough mining power to construct an inferior branch prefixed with the canonical view of the blockchain in an attempt to masquerade as the canonical Bitcoin blockchain. The objective of the attacker is to partition the view of the Bitcoin network and provide a malicious view of the blockchain to the LC unnoticed. We assume that the adversary is not able to generate a stronger blockchain than the honest participants (or else the attacker could perform a so-called 51% attack without the need to eclipse clients).

4.2. Requirements

In order to realize a successful detection framework, we define the following requirements:

Effectiveness: participants of the detection framework should be able to detect ongoing eclipse attacks with high probability and speed. As in Bitcoin, the suggested transaction confirmation time is about one hour (i.e., six new-coming blocks after the transaction was appended), we aim for a similar time frame for attack detection.

Low overheads: protocol-introduced overheads should be negligible. In particular, the scheme should not require high CPU, memory, and storage utilization, and it should not introduce high bandwidth overheads or latency inflation into the existing client-server communications. The protocol should support a variety of light clients, including resource-constrained nodes like IoT devices.

Deployability: the protocol should be deployable without any dedicated network infrastructure. Thus, the protocol should not incur any significant investments.

or setup efforts. It should use the existing infrastructure with minimal or no changes to the applications deployed on it.

Backward compatibility: the scheme should not require any changes to the Bitcoin protocol or its network. As witnessed from past developments and deployments, the Bitcoin community is reluctant to introduce changes to the protocol, so if such a change is required then it could undermine the deployment of the attack detection framework.

5. The Timestamp-Based Protocol

The first eclipse attack detection protocol that we present is fully passive and requires only the block timestamps, which are part of the block headers and therefore known to the light clients by default. Of the three presented approaches, this one has the slowest average detection time, but it is the easiest to implement as it does not depend on protocol-running servers.

During an eclipse attack, an attacker can convince a lightweight client to accept an inferior branch of the blockchain. However, to build such a branch the attacker will still need to control, either directly or indirectly, a considerable amount of mining power. Since Bitcoin’s mining difficulty changes infrequently, the difficulty can be assumed to remain constant for the duration of the attack. Since the attacker cannot create blocks at the same frequency as the whole network, a sudden increase in the block creation times is likely. The lightweight client bitcoinj has indicated that in the future, it may implement a “red alert” mode based on the block creation times [1].

To the best of our knowledge, none of the lightweight clients have implemented such a feature yet, so we present our timestamp-based protocol in this section.

5.1. Block Timestamp Model

Alerts in the timestamp-based approach are triggered by abnormally long block creation times. Since block creation times are random by nature, we need a probabilistic model. The time between block creations follows an exponential distribution [20], so the time needed to create ( k ) blocks in a row follows the Erlang distribution with shape parameter ( k ) and a mean of ( k \cdot 10 ) minutes. However, day-to-day changes in the total network hash rate mean that these assumptions are not always valid. We investigate this using historical block timestamp observations and hash rate estimates that were obtained via the data API of [blockchain.com][1]. In particular, we collected timestamps for the blocks between height 506000 and 560013, which were mined on Jan. 25, 2018 and Jan. 25, 2019 respectively, and which have the following hashes:

0000000000000000000d69a840ca2ad3560d596ccc4d2c26e7e56f4b5d18ec4e 0000000000000000003cd1f6db7b2e2009e975e3baac7fc8d1c1e53f8025b8d8

For the hash rates we collected the data underlying the hash rate estimate chart[2] from the 2-year period starting from 23 Jan. 2017.

As we can see in Figure 2, the hash rate has changed considerably over time — it tripled between Jan. 2018 and its peak around 18 Sept. 2018, and fell by roughly 1% per day in the 32 days from 6 Nov. to 7 Dec. The observed average block creation time between 25 Jan. 2018 and 25 Jan. 2019 was not 600 seconds, but 581, which reflects the fact for most of this one-year period, the hash rate was increasing and the difficulty therefore often too low. However, higher block creation times were observed when the hash rate was dropping. In Figure 2, the observed timestamp differences are compared to an exponential distribution with a mean of 581 seconds: the fit is generally good, but more low and high extremes appear than one would expect from an exponential distribution. The assumptions underlying our calculations will be loosened to reflect this.

Since the largest observed drop in the hash rate trend since early 2017 has been 1% per day, and the Bitcoin difficulty resets every two weeks (or 16 days if we account for the dropping hash rate), we will assume that at any time the total network hash rate is at most 14-16% lower than during the last difficulty rescale. Hence, we will assume in the following that the time needed to create ( k ) blocks can be conservatively assumed to be Erlang-distributed with shape ( k ) and a mean of ( k \cdot 12 ) minutes (instead of ( k \cdot 10 ) minutes).

5.2. Alert Types

Using the probabilistic model described above, we introduce alerts that are triggered whenever the probability of a given sequence of block creation times is below a threshold. Different Bitcoin users require different levels of reliability, and therefore different thresholds user’s typical transactions (see also [1]). A user who cares more about fast confirmation times than security, e.g., an automated online store for video game downloads, might accept a transaction if it appears on any main chain block, with no confirmations needed. However, users with high security expectations, e.g., financial service providers, are more likely to use the six-confirmations rule, which means that they will only accept a transaction if it appears in a

Useful information for enthusiasts:

Contact me via Telegram: @ExploitDarlenePRO