Dependability Analysis of Bitcoin subject to Eclipse Attacks

The immense potential of the blockchain technology in diverse and critical applications (e.g., financial services, cryptocurrencies, supply chains, smart contracts, and automotive industry) has led to a new challenge: the dependability modeling and analysis of the blockchain-based systems. In this paper, we model the Bitcoin, a peer-to-peer cryptocurrency system built on the blockchain technology that allows individuals to trade freely without involving banks or other intermediate agents. We analyze the dependability of the Bitcoin system subject to the Eclipse attack. A continuous-time Markov chain-based method is suggested to model the system behavior under the Eclipse attack and further quantify the dependability of the Bitcoin system. The effects of several model parameters (related to the miner’s habits in system protection, restart, and mining frequency) on the system dependability are demonstrated through numerical examples. Findings from this work may provide effective guidelines in designing a resilient and robust Bitcoin system.


Introduction
As one of the most revolutionary invention in the computer science world, the block chain technology has received extensive attention from academia, industries and governments in the past decade (Atzei et al., 2017;Dai et al., 2019;Ferrag et al., 2018;Kang et al., 2018). It has great potential in various critical applications (e.g., financial services, smart contracts, supply chains, voting and the Internet of Things), contributing to the transformation of human society towards smart, efficient, and resilient (Akbari et al., 2017;Frizzo-Barker et al., 2020;Garay et al., 2017;Xing, 2020Xing, , 2021. Bitcoin is known as the peer-to-peer cryptocurrency system built on the block chain technology (Satoshi, 2008). Compared with the fiat currency, the Bitcoin is featured with a decentralized property, which allows individuals to trade freely without involving banks. Bitcoin has been widely used in different areas and has a market cap of 185 billion. However, the whole Bitcoin network is vulnerable to a variety of threats or attacks.
For example, an attacker can control the availability of the block chain data by creating incorrect or illegal access to the data. To do so, the attacker only needs to track the correspondence of different addresses including the IP address and the Bitcoin address (Koshy et al., 2014). An attacker can easily track the relationship between addresses from transactions by taking advantage of the open network of the Bitcoin system. Thus, the users' privacy may be exposed and their personal information is in danger (Reid and Harrigan, 2013). An attacker can also temper the block chain data by attacking the block chain consensus mechanism (Bag et al., 2016). The vulnerability of a smart contract can cause serious damages to the network if the attacker takes over the control of the block chain data from the user. In addition to the above examples, the Bitcoin system is facing many other security problems, such as Sybil attacks (Zhang and Lee, 2019), Selfish mining (Eyal and Sirer, 2014), mining pool attacks (Bahack, 2013), re-identification attacks (Meiklejohn et al., 2013), miner attacks (Rosenfeld, 2011) and Crypto Locker based attacks (Liao et al., 2016) (a family of ransomware that encrypts a victim's files until a ransom is paid). Considerable research efforts have been expended in studying the Bitcoin security against those attacks.
For example, in Eyal and Sirer (2014) a mitigation strategy based on a practical modification to the Bitcoin protocol was suggested to defend the Bitcoin system against the concluding selfish mining attack. In Gervais et al. (2015), it was shown that an attacker can delay the propagation of Bitcoin transactions in multiple ways to a specific node. Different countermeasures were explored to improve the security of the network, including dynamic timeouts, updating block advertisements and penalizing non-responding nodes. In Pustogarov (2015a, 2015b), it was examined and proved that the Bitcoin over Tor system is not promising in solving the security problem. In Bamert et al. (2014), a hardware token was proposed to secure the sign Bitcoin transaction. In Ben-Sasson et al. (2014) and Monaco (2015), the Bitcoin's weakness in privacy protection was examined and a decentralized anonymous payment scheme was proposed for providing privacy protection. In Kroll et al. (2013), it was shown that there are infinitely many Nash equilibria for mining strategies and argued requirements of the governance structures. In Joux (2004), it was shown that the difficulty of finding simultaneous collisions are not higher than finding individual ones in multiple hash functions. In Bastiaan (2015), the threat to the Bitcoin network from the pool mining was discussed and the Markov Chain was applied for the stochastic analysis of the two phase proof-of-work (2P-POW) including an average reward for pools under different difficulties. In Göbel et al. (2016), the Markov Chain model was applied to demonstrate the possible detection of block-hiding attacks (selfish mining) by monitoring the production rate of orphan blocks. Existing research works mostly focus on the detection of possible threats and estimation of effects from the malicious behavior (protocol or encryption-wise). To the best of our knowledge, no systematic efforts have been dedicated to quantitative dependability analysis of the Bitcoin system and investigating impacts from parameters related to miner's habits.
In this paper we make contributions by modeling and analyzing the dependability of the Bitcoin system subject to Eclipse attacks. The process and mechanism of the Eclipse attack are examined. A continuous-time Markov Chain (CTMC)-based method is applied to model the behavior of the Bitcoin system under the Eclipse attack and quantify the dependability of the Bitcoin system. Numerical examples are provided to demonstrate the effects of different parameters reflecting the miner's habits in system protection, restart, and mining frequency on the Bitcoin dependability.
The rest of the paper is arranged as follows: Section 2 examines the working mechanism of the Eclipse attack. Section 3 identifies key states of the Bitcoin system under the Eclipse attack and presents the CTMC-based method for the dependability modeling and analysis of the Bitcoin system. Section 4 presents example analysis results and examines the effects of several model parameters on the Bitcoin dependability. Section 5 draws the conclusion of our study and discusses future research directions.

The Eclipse Attack
During the Eclipse attack, an attacker aims to control the information flow of a victim node including reception and transmission so that the victim node loses its connection to other legitimate nodes. To do so, the attacker node maliciously fills the victim node's routing table before the victim node of the block chain restarts. The victim node can be forced to restart, or the attacker can simply wait for the victim node to restart. After the restart, the victim node establishes an outgoing connection with the attack address in the routing table. At the same time, the attacker node continuously establishes an incoming connection with the victim node. Finally, the information flow channel of the victim node is monopolized or controlled so that the victim node can only receive fake or even malicious information sent by the attacker node (Heilman et al., 2015). Figure  1 gives the flowchart of a successful Eclipse attack.
If the attacker node can successfully implement Eclipse attacks on more nodes, it can control the block chain channels and information flows of more nearby nodes, and gradually control most of the block chain network. Thus, a successful Eclipse attack can result in other attacks like doublespending, selfish mining, and block withholding (Heilman et al., 2015).

Dependability Modeling and Analysis
In this section, we apply the CTMC to model and analyze the dependability of the Bitcoin system under the Eclipse attack. Figure 2 illustrates the state transition diagram in the CTMC-based solution. Based on the working mechanism of the Eclipse attack presented in Section 2, five key states are identified: 0 (original), 1 (table hacked), 2 (restart), 3 (connected), and 4 (monopolized).
Specifically, in the original state 0, the Bitcoin system functions normally without being impacted by the attack. Under state 0, an attack node can send an ADDR message containing a lot of "trash" IP addresses that will gradually overwrite all legal addresses of the node table, causing the system to transit from state 0 to state 1. The transition rate is λ01 (i.e., the table hackling rate). Under state 1, the victim node performs the restart causing the system to transit to state 2 with transition rate λ12. Under state 1, if the user detects and deletes the suspicious message, which contains forged addresses, then the system can go back to state 0 with µ10. Under state 2 (the victim node has been restarted), the victim node can be connected to the attack addresses with rate λ23, causing the system to transit to state 3. Under state 2, if the user cleans his/her node table with tools, the system can transit back to state 1 with µ21. Under state 3, the victim node is forced to select an address from the hacked table to establish an outgoing connection, causing the system to transit to state 4 with rate λ34. Under state 3, if the user successfully restores the healthy connection through some maintenance operation, the system can transit back to state 0 with µ30. Under state 4, the attacker controls all incoming connections to the victim node, truly monopolizing the victim node; the Eclipse attack succeeds. In state 4, if the user detects the adversary connection and rebuilds partial connections with honest nodes, the system is able to transit back to state 3 with rate µ43. Note that transition rates µ10, µ21, µ30, µ43 are generally considered as recovery rates and their values are mostly associated with the miner/user's habits. In Section 4, the effects of some of these transition rates on the dependability of the Bitcoin system are investigated through numerical results. Based on the state transition diagram in Figure 2, the state equations in the matrix form are given in Eq. (1), where the left-most matrix is the transition rate matrix of the CTMC, ( ) represents the probability of the Bitcoin system being in state j (j=0,1,2,3,4), and ̇( ) represents the derivative of the state j probability. Eq. (1) can also be detailed using separate differential equations as shown in Eqs. (2)-(6).
The system state probabilities can be obtained by aapplying the Laplace transform-based method to solve Eqs.
We apply the inverse Laplace transform of * ( ) obtained in Eqs. (7)-(11) to derive the system state probabilities in the time domain Pj(t) (j=0,1,2,3,4). This conversion is completed by Matlab in our study.
With the system state probabilities evaluated, the dependability of the Bitcoin system can be obtained as D(t) = P0(t) + P1(t) + P2(t), which is the probability that the Bitcoin system can function normally. Under states 3 and 4, the Eclipse attack is considered successful; the Bitcoin system is infected and not dependable. Thus, we define ̅ ( ) = P3(t) + P4(t).

Example Analysis Results
This section illustrates the CTMC-based method and impacts of several model parameters on the Bitcoin dependability, gaining insights into the Eclipse attack and defense behaviors of the Bitcoin system.
Specifically, we examine the impacts of parameters ( 21 , 30 , 43 ), λ12, and λ34 on the system dependability using the parameter set as shown in Table 1. Parameters ( 21 , 30 , 43 ) stand for the user's sense of system protection, and their effects are examined through parameter sets a, b, and c in Table 1. Parameter λ12 models the user's habits of turning off the system after using it, and its effects are estimated through parameter sets d, b and e. Parameter λ34 models the user's mining habits, and its effects are investigated using sets f, b, and g in Table 1.

Effects of Protection Parameters ( , , )
Parameter sets a, b and c of Table 1 model different levels of the user's sense of system protection, from low to high. Specially, set a represents a user who has the least sense of system protection and rarely checks the status of the system health. Set b represents a normal user who checks the system status with a common frequency. Set c represents a user with a strong sense of system security and experiences in system protection. Table 2 shows the dependability of the Bitcoin system under parameter sets a, b, and c for several values of mission time. Figure 3 shows the graphical representation of the dependability results.  3. Effects of parameters μ 21 , μ 30 , μ 43 on the system dependability.
From Figure 3, we can observe that the system dependability decreases with time. The system dependability D under set a (user with the least sense of system protection) is the lowest and decreases quickly with time; D under set c (experienced user with a strong sense of system protection) appears the highest and decreases slightly with time; D under set b appears in between the former two cases. The above results support the intuition that the system is more likely to stay in the dependable state when its user has a higher sense of system protection.

Effects of User Restart Habits Parameter
Effects of user's restart habits parameter 12 are investigated through parameter sets d, b, and e in Table 1. Set d models a user who almost never turns off his/her computer after finish using it. Set b models a user who turns off the system with a certain frequency. Set e models a user who always shuts down the system (due to, e.g., strong security sense, economic concern, or obsessivecompulsive disorder). The system dependability results under set d, b, and e are presented in Table  3. Figure 4 gives the graphical representation of the dependability results.  Figure 4 shows that the system dependability D under set d is the highest and has the lowest decreasing speed as time proceeds; D under set e appears the lowest and decreases with the highest speed as time proceeds; D under set b appears in between the former two cases. The numerical results support the intuition that the system is more likely to stay in the dependable state when its user has a habit of not turning off the system after each use. In other words, the system is more likely to get compromised if its user shuts down and restarts the system more frequently. This is due to the special mechanism of the Eclipse attack, which requires the system to reboot to complete the malicious attack.

Effects of Mining Frequency Parameter
Effects of the mining frequency parameter 34 are investigated through parameter sets f, b, and g in Table 1. Set f corresponds to an amateur miner or a beginner level miner who rarely does mining. Set b corresponds to a normal miner who does average mining. Set g corresponds to a frequent miner who would do mining almost all the time. Table 4 shows the system dependability results under sets f, b and g. Figure 5 gives the graphical representation of the dependability results.  5. Effects of parameters 34 on the system dependability. Figure 5 shows that the system dependability D under set f is the highest and has the slowest decreasing speed as time proceeds among the three cases studied; D under set g appears the lowest and decreases more quickly with time than the other two cases; D under set b appears in between the former two cases. From these results we can draw a conclusion that a miner with a higher frequency of mining has a relatively higher chance of being exposed to the attack/risk, leading to lower system dependability.

Conclusion and Future Work
An Eclipse attack to a Bitcoin system is a network-level attack, where an attacker essentially takes control of the peer-to-peer network blocking a node's view of the block chain. The existing works on the Bitcoin security risk are mostly based on protocol and encryption with a focus on threat detection or evaluation of impacts from the malicious behaviour. This paper advances the state of the art by performing the quantitative dependability analysis of the Bitcoin system undergoing the eclipse attack using the CTMC-based method. We further investigate the impacts of several parameters related to the miner's habits in system protection, restart, and mining frequency on the system dependability through numerical studies.
The CTMC-based method is limited to constant transition rates (or exponentially distributed state transition time). In the future we plan to explore semi-Markov models to relax this limitation for the Bitcoin dependability analysis. We also plan to extend the proposed method to investigate other types of attacks on the Bitcoin network such as selfish mining (Yang et al., 2020) and block withholding mining (Qin et al., 2020). Another direction is to design resilience algorithms and methods that can improve the robustness of the current Bitcoin network model and strengthen its immunity to various threats.

Conflict of Interest
The authors confirm that there is no conflict of interest to declare for this publication.