Sybil attacks, and why identities are not the scarce resource

The first assumption is that the victim selects peers without regard to their history. Bitcoin Core's address manager buckets addresses by network group and selects from the new and tried tables at random, so an attacker must control addresses spread across many groups rather than many addresses in one. This raises the number of identities an attacker needs to occupy a useful share of a victim's connections.

The second assumption is that the victim trusts its peers for something that matters. A Sybil peer can withhold a block or relay a stale one, which is the eclipse attack, but it cannot make the victim accept an invalid block. The influence a Sybil buys is over what the victim hears, not over what the victim accepts, and the victim's own validation is the backstop.

The third assumption is that the attacker is not detected. A node that sees an unusual concentration of peers from one network group, or peers that relay stale data, can drop them and reconnect. The model treats the victim as passive, which is a simplification.

The defence is twofold. The first part is that consensus does not count identities: a block is valid because it satisfies the rules and carries the work, not because many peers say so. The second part is peer-management hygiene: bucketed address selection, a bounded number of outbound connections, and block-relay-only connections that leak less about the node's activity. Together they make a Sybil attack a way to degrade a node's view rather than a way to change the ledger.

The Sybil attack and the eclipse attack are closely related: a Sybil is the means, and an eclipse is the end. The eclipse attacks page covers the isolation that a Sybil can achieve, and the node verification page explains why a node's own validation is the backstop.