<p>Maybe the most important thing you need is to come up with a good strategy, because various countermeasures have been implemented against the eclipse attack presented in the paper by Heilman et al.</p>
<p>See <a href="https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Addrman-and-eclipse-attacks#deployed-countermeasures-for-eclipse-attacks" rel="nofollow noreferrer">this article</a> for a detailed overview, but in short, it has become a lot harder to take control over the Tried tables of addrman, making successful eclipse attacks harder.</p>
<p>So just following the approach outlined in the paper (filling the New tables of the victim's addrman with junk IPs and the Tried tables with attacker-controlled IPs) is not going to work in today's network, you will need to be more creative.
Accordingly, the resources you are going to need depend a lot on what your actual approach is going to look like.</p>

CC BY-SA 4.0
2022-06-11T16:52:08.073Z
2022-06-11T16:52:08.073Z
Lightlike
<p>To increase the probability of successfully pulling off an eclipse attack an attacker would want access to as many resources as they can get. Significant network hash rate to feed your victim blocks with significant proof of work would mean you don't need to attempt a &quot;from genesis&quot; eclipse attack and instead operate on or around the current blockchain tip. Alternatively if you have access to a botnet or a denial of service (DoS) vulnerability you could try knocking your victim's existing peers offline and attempt to replace them. Without significant network hash rate though it will take an extremely long time to generate the blocks at the current difficulty level.</p>
<p>A &quot;from genesis&quot; eclipse attack could in theory be pulled off with just a few IP addresses and/or control of <a href="https://bitcoin.stackexchange.com/questions/110200/monitor-domains-used-by-dns-seeds-in-bitcoin-core-and-bitcoin-knots">multiple DNS seeds</a> if you could ensure that your victim doesn't connect to <strong>any</strong> honest peers. (A single honest peer should keep the victim aware of the network recognized blockchain.) This attack would be attempted through feeding your victim an entirely different blockchain from genesis though your victim may be alerted by checkpoints in Bitcoin Core's code that lets them know the network's recognized blockchain is different to the blockchain they have been validating up until now.</p>
<p>So in summary, the more resources and the more tools an attacker has the greater the probability of a successful attack. However, it is never certain that it will succeed as it does rely on the victim not doing cross checks and not having additional infrastructure to flag an attempted eclipse attack.</p>

CC BY-SA 4.0
2021-11-01T13:37:56.500Z
Eclipse attacks have nothing to do with hashrate. It's just about making a victim node only have attacker connections. Once a victim is eclipsed, the attacker can leverage it to mount other attacks, like censoring transactions/blocks, double spending, selfish mining, feeding a forked chain...; which may require hashrate, but those aren't part of the Eclipsing itself.
Pieter Wuille
CC BY-SA 4.0
2021-11-01T13:41:04.287Z
I think we disagree then on how we are defining eclipse attack. I would include what the attacker does (e.g. double spend, feed blocks that rest of network isn't aware of) after successfully eclipsing a victim as part of the eclipse attack. You seem to want to define an eclipse attack as just the eclipsing part and not the part that ends up hurting the victim. If the victim is eclipsed but the attacker continues to feed them the actual blockchain the victim doesn't get hurt!
Michael Folkson
CC BY-SA 4.0
2021-11-01T13:52:38.043Z
I'm just following the definition from the paper; "We presented an eclipse attack on bitcoin’s peer-to-peer network that undermines bitcoin’s core security guarantees, allowing attacks on the mining and consensus system, including N-confirmation double spending and adversarial forks in the blockchain.".
Pieter Wuille
CC BY-SA 4.0
2021-11-01T13:59:17.160Z
Hmm interesting. An eclipse attack on "the network" doesn't make much sense to me. Surely the whole point is to target a particular victim or subset of the network. The only thing you can do to the entire network is (as the paper says) undermine guarantees which doesn't sound to me like you are carrying out a specific attack.
Michael Folkson
CC BY-SA 4.0
2021-11-01T14:06:47.753Z
The fact that it is an attack on the network doesn't mean it isn't targetting a specific victim or victims.
Pieter Wuille
CC BY-SA 4.0
2021-11-01T14:12:53.167Z
I guess this is getting rather philosophical. But we already know an eclipse attack is possible and it would surprise me if one hasn't been carried out either on early Bitcoin or an altcoin. So the fact that it is possible doesn't materially "undermine" the network. A monstrous one would have to be carried out to undermine the entire network. Otherwise it is just hurts the victims and the network shrugs it off and goes on unaffected.
Michael Folkson
CC BY-SA 4.0
2021-11-01T15:08:28.993Z
Semantics discussions aside; I still disagree that hashrate is involved. Even if you see an eclipse attack as necessarily involving some other step to actually hurt the victim, that step may just be censoring transactions, or delaying blocks. Neither requires hashrate.
Pieter Wuille
CC BY-SA 4.0
2021-11-03T08:57:24.630Z
Yes, I just want to know the Eclipse attack itself. What resources are needed to launch a Eclipse attack?
A-qiu
CC BY-SA 4.0
2021-11-01T13:34:28.263Z
2021-11-01T13:34:28.263Z
Michael Folkson
<p>I have read this paper of Eclipse attack. And I want to konw that what resources are needed to implement an Eclipse attack? IP addresses and investing attack time are needed, and is there anything else you need? Thank you for your answer!</p>
<p><a href="https://eprint.iacr.org/2015/263.pdf" rel="nofollow noreferrer">Eclipse Attacks on Bitcoin’s Peer-to-Peer Network</a></p>

<p2p><eclipse-attack>
What resources are needed to implement an Eclipse attack?
A-qiu
# What resources are needed to implement an Eclipse attack?

(Asked by: username_0 on 2021-10-31)

I have read this paper of Eclipse attack. And I want to konw that what resources are needed to implement an Eclipse attack? IP addresses and investing attack time are needed, and is there anything else you need? Thank you for your answer!

[Eclipse Attacks on Bitcoin’s Peer-to-Peer Network](https://eprint.iacr.org/2015/263.pdf)

**Tags:** p2p, eclipse-attack


---

## 2 answers

### Answer by username_1 on 2022-06-11. Score: 2

Maybe the most important thing you need is to come up with a good strategy, because various countermeasures have been implemented against the eclipse attack presented in the paper by Heilman et al.

See [this article](https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Addrman-and-eclipse-attacks#deployed-countermeasures-for-eclipse-attacks) for a detailed overview, but in short, it has become a lot harder to take control over the Tried tables of addrman, making successful eclipse attacks harder.

So just following the approach outlined in the paper (filling the New tables of the victim's addrman with junk IPs and the Tried tables with attacker-controlled IPs) is not going to work in today's network, you will need to be more creative.
Accordingly, the resources you are going to need depend a lot on what your actual approach is going to look like.


---

### Answer by username_2 on 2021-11-01. Score: 0

To increase the probability of successfully pulling off an eclipse attack an attacker would want access to as many resources as they can get. Significant network hash rate to feed your victim blocks with significant proof of work would mean you don't need to attempt a "from genesis" eclipse attack and instead operate on or around the current blockchain tip. Alternatively if you have access to a botnet or a denial of service (DoS) vulnerability you could try knocking your victim's existing peers offline and attempt to replace them. Without significant network hash rate though it will take an extremely long time to generate the blocks at the current difficulty level.

A "from genesis" eclipse attack could in theory be pulled off with just a few IP addresses and/or control of [multiple DNS seeds](https://bitcoin.stackexchange.com/questions/110200/monitor-domains-used-by-dns-seeds-in-bitcoin-core-and-bitcoin-knots) if you could ensure that your victim doesn't connect to **any** honest peers. (A single honest peer should keep the victim aware of the network recognized blockchain.) This attack would be attempted through feeding your victim an entirely different blockchain from genesis though your victim may be alerted by checkpoints in Bitcoin Core's code that lets them know the network's recognized blockchain is different to the blockchain they have been validating up until now.

So in summary, the more resources and the more tools an attacker has the greater the probability of a successful attack. However, it is never certain that it will succeed as it does rely on the victim not doing cross checks and not having additional infrastructure to flag an attempted eclipse attack.

> **Comments:**
> **username_3**: Eclipse attacks have nothing to do with hashrate. It's just about making a victim node only have attacker connections. Once a victim is eclipsed, the attacker can leverage it to mount other attacks, like censoring transactions/blocks, double spending, selfish mining, feeding a forked chain...; which may require hashrate, but those aren't part of the Eclipsing itself.  
> **username_2**: I think we disagree then on how we are defining eclipse attack. I would include what the attacker does (e.g. double spend, feed blocks that rest of network isn't aware of) after successfully eclipsing a victim as part of the eclipse attack. You seem to want to define an eclipse attack as just the eclipsing part and not the part that ends up hurting the victim. If the victim is eclipsed but the attacker continues to feed them the actual blockchain the victim doesn't get hurt!  
> **username_3**: I'm just following the definition from the paper; "We presented an eclipse attack on bitcoin’s peer-to-peer network that undermines bitcoin’s core security guarantees, allowing attacks on the mining and consensus system, including N-confirmation double spending and adversarial forks in the blockchain.".  
> **username_2**: Hmm interesting. An eclipse attack on "the network" doesn't make much sense to me. Surely the whole point is to target a particular victim or subset of the network. The only thing you can do to the entire network is (as the paper says) undermine guarantees which doesn't sound to me like you are carrying out a specific attack.  
> **username_3**: The fact that it is an attack on the network doesn't mean it isn't targetting a specific victim or victims.  
> **username_2**: I guess this is getting rather philosophical. But we already know an eclipse attack is possible and it would surprise me if one hasn't been carried out either on early Bitcoin or an altcoin. So the fact that it is possible doesn't materially "undermine" the network. A monstrous one would have to be carried out to undermine the entire network. Otherwise it is just hurts the victims and the network shrugs it off and goes on unaffected.  
> **username_3**: Semantics discussions aside; I still disagree that hashrate is involved. Even if you see an eclipse attack as necessarily involving some other step to actually hurt the victim, that step may just be censoring transactions, or delaying blocks. Neither requires hashrate.  
> **username_0**: Yes, I just want to know the Eclipse attack itself. What resources are needed to launch a Eclipse attack?  

---

