Long-Range Attack

A long-range attack is a proof-of-stake threat in which former validators use old signing keys to build an alternative history from far back in the chain and reveal it later. It matters most to a new node or one that has been offline for a long time: old validator signatures may still look valid unless the software has a way to know which recent chain state to trust.

Why old validator keys matter

In many proof-of-stake designs, validators can eventually withdraw their stake and leave. A protocol that evaluates only signatures and chain rules from genesis may have difficulty distinguishing the real history from a competing history signed by validators who no longer have funds at risk. This differs from an ordinary short-range reorganization, which tries to replace recent blocks while current validators are participating.

The risk is not that old keys automatically let an attacker replace the canonical chain in every live node. Attack details and defenses depend on the specific protocol, its finality rules, fork choice, and client implementation.

Weak subjectivity and checkpoints

Ethereum addresses this bootstrapping problem through weak subjectivity. A node joining or returning after a long absence uses a recent weak-subjectivity checkpoint from a trusted source, then verifies the chain forward from that state. The checkpoint acts as a boundary that prevents the client from accepting an incompatible history stretching back before it.

This introduces a limited social trust assumption about the checkpoint source. Users can reduce that risk by comparing independent providers and running maintained clients. A checkpoint is not a substitute for validating the blocks and state that follow it.

What the term does not imply

Long-range attacks are not unique to every proof-of-stake network in the same form, and the Ethereum defense should not be assumed to describe all chains. Nor does the term mean that proof-of-stake clients blindly accept any historical fork. Protocol-specific protections can include finality, checkpoint rules, and limits on which older histories a client will consider.

For operators, the practical lesson is to follow the node client’s documented recovery process after a prolonged outage rather than syncing from an untrusted history or an arbitrarily old snapshot.

Social Media Sentiment

A January 2022 r/CryptoCurrency discussion asked whether proof of stake is less secure than proof of work and raised weak-subjectivity and trust questions. Participants debated the assumptions rather than agreeing on a single conclusion. It is a historical discussion, not a current technical assessment of every proof-of-stake chain. Read the referenced Reddit discussion.

Last updated: 2026-10

Related Terms

See Also

Sources