Bitcoin’s Attack Vectors: Sybil & Eclipse Attacks
Bitcoin is undoubtedly the most secure cryptocurrency to date, with factors at multiple levels of the protocol often rendering sustained sophisticated attacks too expensive to pull off. This doesn’t mean that such attacks don’t exist. In this series, we’ll look at the various hypothetical and attempted iterations that have cropped up over the years.
Sybil and eclipse attacks take place at the peer-to-peer network level, referring to an adversary generating multiple pseudonymous identities in order to interfere with the protocol. Bitcoin Core dev Pieter Wuille has pointed out that, in the context of Bitcoin, the term ‘Sybil’ had traditionally been used to describe both of these vectors, though a 2015 paper entitled Eclipse Attacks on Bitcoin’s Peer-to-Peer Network shone some light on (if you’ll pardon the pun) what we now know simply as an eclipse attack.
The Sybil Attack
A Sybil attack is something you’ll undoubtedly be familiar with if you’ve browsed certain subreddits, sketchy product reviews, or dark corners of Twitter. Leveraging the ease of spinning up new identities, an opponent will create multiple pseudonyms to game the reputation system of a network.
An attacker wishing to carry out this attack on Bitcoin would flood the network with new nodes and connect to honest participants in order to feed them false information, or to manufacture support for something.
Naturally, a large part of what makes this vector exploitable is the ease with which an entity can spin up such identities. For instance, on an online forum where the only prerequisite to registering an account is providing an email address, an opponent would have a much easier time creating 500 identities than if they had to register an email address, phone number and passport scan.
Bitcoin is permissionless, but it incorporates certain barriers to entry that require a degree of skin in the game — notably, through Proof-of-Work. In order to craft blocks accepted by the network, a participant needs to expend significant resources (both electricity and computational power). This, too, can be manipulated by an attacker, as we’ll discuss in the next article in this series.
It’s possible for an opponent to spawn multiple nodes to hoodwink an honest peer, but provided the latter connects to even a single honest node at some point (or check an online block explorer), they’ll realise that the dishonest nodes are broadcasting chains with less accumulated difficulty.
Worth noting is that blockchain analysis firms have, in the past, been accused of engaging in such activities to siphon information from network participants.
The Eclipse Attack
An eclipse attack involves the adversary targeting a specific node (as opposed to the network as a whole) so as to cut off all of their inbound/outbound communications with other peers (which effectively suffocates the victim). A successful iteration of this attack results in the victim receiving a warped view of the blockchain, which the opponent can use either to cause general disruption and to segregate the targeted peer from other nodes, or as a springboard to mount further attacks.
Indeed, one can foresee how an eclipse attack could be used to turbocharge the efficiency of hashpower deployed in a 51% attack. By isolating a portion of rival miners from the chain, you remove their hashpower from the competition, thus enabling you to commandeer a greater percentage of the total hashpower with your existing hardware. Other attacks at the mining level where an eclipse attack can boost the adversary’s efforts is in selfish mining or in deliberately causing targeted peers to waste power.
Perhaps more feasible (and certainly cheaper) is duping an isolated peer by double-spending using 0-confirmation – in this instance, the attacker would eclipse a merchant that doesn’t wait for confirmations (for faster transaction times). The merchant would receive what appears to be a valid transaction and dispatch goods.
Unbeknownst to them, however, is that these coins have also been spent elsewhere, a fact they’ll learn the hard way when they reconnect to the broader network and find themselves without payment. A variant on this is the N-confirmation double-spend, where an eclipsed miner includes the transaction to said merchant into a block (confirming the tx), prompting the merchant to release the goods — before the miner is ‘uneclipsed’, orphaning the block containing what appeared to be a valid transaction.
Sybil/eclipse attacks can be used to wreak havoc on a peer-to-peer network, though a number of countermeasures can be employed to mitigate the damage they’re capable of doing (PoW mechanisms, tweaks to a node’s connection settings, etc.). In the grand scheme of things, Sybil attacks are not a huge threat, though eclipse attacks can be potentiators for more serious ones.
Cover image by the author.