Formal Barriers to Longest-Chain Proof-of-Stake Protocols

The security of most existing cryptocurrencies is based on a concept called Proof-of-Work, in which users must solve a computationally hard cryptopuzzle to authorize transactions (`one unit of computation, one vote'). This leads to enormous expenditure on hardware and electricity in order to collect the rewards associated with transaction authorization. Proof-of-Stake is an alternative concept that instead selects users to authorize transactions proportional to their wealth (`one coin, one vote'). Some aspects of the two paradigms are the same. For instance, obtaining voting power in Proof-of-Stake has a monetary cost just as in Proof-of-Work: a coin cannot be freely duplicated any more easily than a unit of computation. However some aspects are fundamentally different. In particular, exactly because Proof-of-Stake is wasteless, there is no inherent resource cost to deviating (commonly referred to as the `Nothing-at-Stake' problem). In contrast to prior work, we focus on incentive-driven deviations (any participant will deviate if doing so yields higher revenue) instead of adversarial corruption (an adversary may take over a significant fraction of the network, but the remaining players follow the protocol). The main results of this paper are several formal barriers to designing incentive-compatible proof-of-stake cryptocurrencies (that don't apply to proof-of-work).


page 1

page 2

page 3

page 4


A Cooperative Proof of Work Scheme for Distributed Consensus Protocols

We propose a refinement to the well known, and widely used, proof-of-wor...

Proof-of-Stake Mining Games with Perfect Randomness

Proof-of-Stake blockchains based on a longest-chain consensus protocol a...

Transaction Fee Mechanism Design

Demand for blockchains such as Bitcoin and Ethereum is far larger than s...

Towards a Multi-Chain Future of Proof-of-Space

Proof-of-Space provides an intriguing alternative for consensus protocol...

The Gap Game

Blockchain-based cryptocurrencies secure a decentralized consensus proto...

Towards a Game-Theoretic Security Analysis of Off-Chain Protocols

Off-chain protocols constitute one of the most promising approaches to s...

Bias-Resistant Social News Aggregator Based on Blockchain

In today's world, social networks have become one of the primary sources...

1 Introduction

Since Nakamoto’s white paper in 2008 [19], Bitcoin and other cryptocurrencies have become ubiquitous, with hundreds of billions of USD worth of various cryptocurrencies currently in circulation.111 While existing technology is already remarkable, it remains an active research area on many fronts. This paper focuses on one aspect of this agenda: Proof-of-Work versus Proof-of Stake. We provide a brief overview of the salient aspects of cryptocurrencies below before highlighting our contributions.

1.1 What is a Cryptocurrency?

At their core, all cryptocurrencies are simply decentralized ledgers. A network of participants wish to agree upon a sequence of events and the order in which they occurred. These events could be monetary transactions in the case of Bitcoin, script commands in the case of Ethereum, or many others. Two salient features of cryptocurrencies that define their purpose are the following:

  • [leftmargin=*]

  • It is crucial that the entire network reach consensus on the occurrence of events. For instance, a currency isn’t very useful if users can’t agree on who owns which coins. A shared virtual machine isn’t very useful if users can’t agree on its state.

  • The network is permissionless and pseudonymous. That is, no identification outside the network is necessary to join and participate.222“Permissioned blockchains” are becoming popular in finance, but these are fundamentally different than permissionless cryptocurrencies.

Basic cryptography ensures that users can’t forge transactions from other accounts, or undetectably propose otherwise invalid commands, so the main challenge is ensuring that users all agree on a state of the ledger, and also that no adversary can unduly influence the ledger’s state, or otherwise gain by subverting the protocol. The typical attack to keep in mind is called a “double-spend:” imagine that you wish to purchase a car with Bitcoin. You digitally sign a transaction paying the owner a large sum of Bitcoin and broadcast it. The network agrees on a state of history where this transaction occurs, and then you get the car keys. As soon as this happens, you announce a digitally signed transaction that pays the same Bitcoin to an alternate account that you control, and do your best to subvert the protocol to agree on a ledger that includes this new transaction instead, leaving you with your Bitcoin intact as well as your new car.333Note that no ledger can possibly contain both transactions, as they spend the same coins. A currency would have no use if it were possible to spend the same coins twice. The point here is that the ledger is the currency: if the network believes that a transaction didn’t take place, then by definition that transaction didn’t take place.

A strawman proposal to cope might sound like this: every ten minutes, a uniform random participant from the network is selected. They may output a list of any number of consistent, valid transactions they like, and broadcast this to the entire network, along with a hash pointer to a previous selectee’s output. Each output is assigned some numerical score,444

For instance, Bitcoin’s “longest-chain rule” (essentially) assigns a score to output

equal to ’s distance from the root (when following hash pointers). See Definition 4 in Section 2. and users are asked to “believe” the history associated with the highest-scoring output they’ve seen so far. The key problem with this proposal is that selecting a uniformly random participant in a permissionless environment is absurd: users can freely create many “Sybils,” making a uniformly random participant simply the participant who successfully created the most IDs. One of the key ingredients in successful cryptocurrencies is a random selection process that is Sybil-proof.

Proof-of-Work Versus Proof-of-Stake

The two most popular approaches to the above challenge are termed “Proof-of-Work” and “Proof-of-Stake.” Proof-of-Work is employed by Bitcoin and Ethereum, and aims to select a user randomly, but proportional to their computational power. The idea is that while an attacker can certainly go out and purchase more computational power, exaggerating your computational power comes at a cost (unlike creating additional IDs). Proof-of-Work is typically implemented by requiring that all messages are concatenated with a nonce such that , for some ideal hash function HASH with 256-bit output. It is widely believed that the best way to find such a nonce is to randomly guess (referred to as mining

), and so every unit of computational power gives you a small additional probability of being able to send a valid message. As a result, some estimates predict over 2 billion USD spent annually (between electricity, cooling, etc.)

just computing hashes (more than a fourth of the NSF budget for 2017) [20].

Proof-of-Stake isn’t as widespread, but is an ongoing research focus of Ethereum [4], and is still responsible for billions of USD through cryptocurrencies such as NEM [7], Cardano,555 BlackCoin [25], PeerCoin [18], Nxt [8], and Tezos [14]. The goal is to select a user randomly, and proportional to their wealth (in the currency itself). The idea again is that while an attacker can certainly go out and purchase more stake in the currency, it comes at a cost. In comparison to Proof-of-Work, Proof-of-Stake wastes no electricity.

1.2 Security Concerns Specific to Proof-of-Stake

From a security perspective, it’s actually convenient that Proof-of-Work wastes resources: this guarantees that certain deviations (discussed in the next paragraph) from the intended protocol also cost additional resources, and are naturally disincentivized (this, of course, does not mean that deviations are never profitable, see e.g. [11, 10, 22, 5]). Proof-of-Stake, on the other hand, has the property that such deviations consume no resources and this is exactly because Proof-of-Stake is wasteless, so it falls on the protocol to disincentivize such behavior through clever reward schemes.

This phenomenon is commonly referred to as “Nothing-at-Stake,” and refers to the fact that it consumes no additional resources for participants to, for instance, copy an outdated history of the currency and participate simultaneously with the “real” one, or even to copy every outdated history and participate in all of them simultaneously. Numerous recent works, both commercial and academic, aim to address this challenge with clever reward schemes. Commercial protocols indeed propose interesting approaches, and don’t seem to have suffered major security setbacks to date. However, these ideas appear informally in whitepapers, often without formal definitions or rigorous reasoning, and are far from being fully explored. Academic proposals, on the other hand, provide rigorous, provable security guarantees, usually in “network intrusion” models (where a fraction of the network is malicious, but the remainder is honest).

In contrast to both existing streams of literature, we focus on rigorous guarantees in a “strategic” model (100% of users act to maximize their own reward). The main result of this paper is a formal barrier to incentive-compatible proof-of-stake protocols. Specifically, we introduce a model for Proof-of-Stake protocols that captures the vast majority of commercial and academic proposals. Next, we show that every protocol fitting into this model must satisfy one of two complementary properties. Finally, we show how an attacker can exploit each one of these properties in order to benefit by strategically deviating from the prescribed protocol.

At a conceptual level, the barriers stem from the following: all cryptocurrencies require some source of (pseudo)randomness. In Proof-of-Work, this pseudorandomness is in some sense external to the cryptocurrency: the first miner to successfully find a good nonce produces the next block, and this miner is selected completely independently of the current state of the cryptocurrency.

In Proof-of-Stake, it is highly desirable that the pseudorandomness comes from within the cryptocurrency itself, versus an external source (due to network security concerns discussed in Section 2). One might initially suspect that with sufficiently many hashes or digital signatures of past blocks, this can indeed serve as a good source of pseudorandomness for future blocks. However, we formalize surprising barriers showing a fundamental difference between external pseudorandomness and pseudorandomness coming from the cryptocurrency itself.

1.3 Our Model: Formal Guarantees in Ideal Network Conditions

Seminal work of Fischer, Lynch, and Paterson [12] proves that if one desires formal consensus guarantees, even in the presence of a single adversarial user, one must make some network assumptions. Existing academic works therefore aim to make the minimal assumptions necessary.

Consider instead an ideal network where every node has perfectly synchronized clocks, and every message is received with zero latency by every other node. It is not hard to design secure Proof-of-Stake cryptocurrencies in this model (at least, ones that are secure against known attacks), but these protocols will look completely unrealistic. The key power that this assumption buys is the ability to ignore messages that arrive even slightly late, as they cannot have been sent by an honest participant. The problem with targeting a solution that is only secure in this ideal model is that you wind up with an extremely fragile protocol which can’t handle even minimal latency.

Still, despite how unrealistically strong this model is, the authors aren’t aware of existing protocols without incentive issues even in this ideal network model (put another way, it is surprisingly daunting to develop a protocol that is secure in the typical sense for any non-trivial network model, yet secure in the strategic sense in the ideal network model). Rather than posing a long list of similar looking attacks, we formalize intuitively undesirable properties of a Proof-of-Stake protocol that capture the issues in many existing proposals. For each property, we show that any Proof-of-Stake protocol with this property is vulnerable to a certain kind of attack. We elaborate further on these properties and attacks in the technical sections.

1.4 Comparison to Related Work

The “incentive-driven” threat to cryptocurrencies appears well-understood even as far back as Nakamoto’s whitepaper, yet has received considerably less formal attention (some notable exceptions unrelated to Proof-of-Stake include [2, 10, 11, 16, 5, 22]). While such “attacks” aren’t a direct threat to consensus, they pose a severe indirect threat: [11] observes that such attackers gobbling up profits from honest participants could drive them out of the market, enabling a threat to consensus.

The most obviously related works to the present paper are academic Proof-of-Stake proposals [9, 17, 13]. These works focus primarily on the network intrusion threat model, as it is obviously important that proposals be secure in the classical sense before concerning oneself with incentives.

Some works go further and provide incentive guarantees, proving that miners who strategically deviate from the prescribed protocol can only gain a small fraction of the total rewards [9, 17]. Still, [9] notes that it is preferable for known strategic deviations to be strictly disincentivized (and prove that their scheme achieves this for Nothing-at-Stake), and [17] observes that not all known deviations are captured by such claims (and prove that their scheme successfully disincentivizes double-spending). In the context of these works, we propose that the deviations formalized in this paper receive similar treatment to currently-known attacks in future analyses. We provide much more detail regarding how our results interact with existing proposals in Appendix C.

1.5 Summary of Contributions and Roadmap

Our model aims to isolate the incentive-driven threat, and we formalize two complementary properties such that every longest-chain Proof-of-Stake protocol must satisfy one of them. We further demonstrate incentive-driven attacks against protocols satisfying either of these properties.

Section 2 contains necessary definitions related to cryptocurrencies and Proof-of-Stake (where even our formal definition of Proof-of-Stake may be of interest). Section 3 defines generic properties shared by a wide class of protocols. Section 4 poses generic attacks against any protocol with the properties defined in Section 3. Section 5 provides more detailed context for our paper with respect to prior work and proposes future directions.

2 Preliminaries

Definition 1 (Block).

A cryptocurrency stores its decentralized ledger in a set of objects called blocks. Every block contains a pointer to its predecessor , a previous block (via its HASH). Every block is created by a single miner, denoted by , and has a timestamp that indicates its claimed creation time (that is, the creator of the block can insert any value they like for , independent of the actual time at which it was created). Blocks also contain some other information that has semantic meaning (such as transactions in the case of Bitcoin, scripts in the case of Ethereum, etc.).

Each block describes a potential history of events, as defined by the semantic contents of and its predecessors. For example, a Bitcoin block describes a series of monetary transactions.

Definition 2 (Coin).

The basic monetary unit of any cryptocurrency is called a coin, referenced by a unique ID. Every coin has an owner, referenced by a unique public key. Certain transactions have an associated semantic meaning that changes the owner of a coin. So for a given block , and coin , one can define to be the owner of a coin as defined by the semantic meaning of transactions included in the history defined by block . Here, we are referring to the smallest discrete monetary unit (so one Satoshi in the case of Bitcoin, rather than one bitcoin).

The key problem that all cryptocurrencies need to resolve is the consensus problem: how can we get all nodes in the network to eventually agree on the occurrence of events? All such protocols necessarily have a notion of validity. That is, users cannot just generate arbitrary messages and send them at arbitrary times and have the rest of the network recognize these as potential blocks to be added to history (for instance, the block could contain invalid transactions, or it might not be that user’s “turn” to send a message). We focus on protocols that satisfy the following assumptions:

Assumption 1.

Let be the graph whose nodes are blocks who share an ancestor with , and whose edges are pointers to predecessors. We assume that:

  1. [label=(),leftmargin=*]

  2. (Chain Dependence) Block ’s validity at time only depends on , and ’s predecessors.

  3. (Monotonicity) If a block is valid at time for a given graph , then it is valid for all graphs that contain as a subgraph and for all times .

Before continuing, let’s quickly motivate/discuss Assumption 1. All protocols that the authors are aware of satisfy Assumption 1, and this is for good reason: all protocols are vulnerable to what are called “Eclipse” attacks. An Eclipse attack occurs when an adversary prevents or blocks messages to honest participants of the protocol. If an adversary can temporarily partition the network into disjoint sets, of course the network can’t reach consensus while partitioned. However, one might hope that the network can reach consensus once reunited. A major barrier to this possibility would be if a user once believed block to be valid (and built a deep history on top of it), and only learned once reunited that in fact was invalid all along. Without Chain Dependence and Monotonicity, this situation is entirely possible. With Chain Dependence and Monotonicity, Eclipse attacks are still a threat, but at least they cannot trick a user into believing a block is valid only to discover later that it was in fact invalid. Toy examples are provided in Appendix A.1 to aid the interested reader in parsing Assumption 1.

Now, we begin restricting attention to Proof-of-Stake protocols, in which the owner of a coin is eligible to mine a new block at some time according to the rules of the protocol. That is, every block further references a coin, that is used to witness ’s validity. For any protocol satisfying Assumption 1, the validity of a block can be determined by a function that takes only a block and the current time as input. This is because all of ’s predecessors can be accessed by following back the predecessor pointers to the root (and are both included in ). Thus, under these assumptions, a Proof-of-Stake Protocol can be defined as follows:

Definition 3 (Proof-of-Stake Protocol).

A Proof-of-Stake Protocol is fully defined via two deterministic functions: a validating function and a mining function . The validating function satisfies the following requirements:

  • takes as input a block (which includes the claimed time of creation, , and the claimed coin witness, ), and outputs an element of .

  • must be efficiently computable by every participant in the protocol.

  • A block is valid at time if and only if is valid and

The mining function satisfies the following requirements:

  • takes as input a block , a coin and timestamp and outputs a block.

  • is efficiently computable by .

  • For any coin and any time , if there exists a block such that is valid at time , where , , and , then where is valid, , , and .

  • For any coin and any time , if there is no block such that is valid at time , where , , and , then .

Again before continuing, let’s parse some aspects of this definition and what separates Proof-of-Stake from Proof-of-Work. The first two bullets are uncontroversial: a block is valid or it isn’t, and every user in the network better be able to tell which blocks are valid. The third bullet might at first appear confusing, but recall that contains a reference to , the claimed time of creation, and , the coin witnessing validity. So can in fact depend on these. Beyond that, the first indicator is necessary to ensure that miners can’t cheat by moving the same coin around different public keys in a potential block in order to make that block itself valid.666Appendix A.2 contains a brief discussion on “freezing” coins for longer than just a single block, which only requires modifying to for some . The second indicator is necessary to guarantee that a miner can’t claim to have produced a block before s/he heard about its predecessor, nor claim to have produced a block in the future (but otherwise the current timestamp is irrelevant for determining a block’s validity, due to Assumption 1).

As for , the second bullet captures two salient features. The first is that is efficiently computable. This is what separates Proof-of-Stake from Proof-of-Work: if were not efficiently computable (e.g. because it involved inverting an ideal hash function), it would require non-trivial work to mine (Proof-of-Work). Because is efficiently computable, the owner of coin need only run once during timestep for each coin they own, and has nothing to gain by doing additional work. The second salient feature is actually an omission: that is not necessarily efficiently computable by miners other than (e.g. because it perhaps requires producing a digital signature). The other three bullets are straight-forward.

So far we have only discussed the validity of blocks. We also need to discuss where an honest user should mine (i.e. which block should be input to ). The dominating paradigm among existing proposals (including all commercial protcols referenced in Section 1, but excluding Algorand [6, 13], Casper [4], and GHOST [24]) are variants of the longest-chain protocol, where each block is given a monotone increasing score, and nodes are asked to “believe” the highest scoring block.777GHOST [24] technically cannot be phrased in this language because the score of a block depends on the existence of descendants of ’s ancestors not referenced directly in . If instead blocks are required to include pointers to these other blocks in order to “get credit,” then GHOST would also fit in this language. See also Appendix D for a further discussion of different concerns regarding GHOST and Proof-of-Stake.

Definition 4 (Longest-Chain Variant).

A Longest-Chain Variant has an associated scoring function . takes as input a block , outputs a score , and is monotone increasing: if , then . A Longest-Chain-Variant consensus protocol associated with asks users to mine on the valid block maximizing (among blocks they are aware of).888Ties are allowed to be broken arbitrarily, but consistently (i.e. if , users can arbitrarily decide to adopt or , but cannot switch between adopting and ).

Longest-Chain Variants are particularly common within cryptocurrencies because of their robustness to Eclipse attacks. Even if the network is partitioned for an extended period, and both disjoint subsets produce completely different histories, the entire network will quickly converge to the higher-scoring history as soon as the subsets reunite. Alternative protocols based on Byzantine Consensus [6, 4] lack this property, and instead achieve finality. That is, once a user considers a block to be included in the ledger, they will never consider valid any ledger that not including . Indeed, in protocols with finality, if the network is partitioned for an extended period, progress will either stall, or the network will never reach consensus even after being reunited.

3 Properties of Protocols

In this section we introduce two simple, intuitively desirable properties for Proof-of-Stake protocols.

3.1 (Un)-Predictability

The first desirable property we define is unpredictability. Intuitively, it is good for protocols to be unpredictable in the sense that miners do not learn that they are eligible to mine a block until shortly before it is due to be mined. Many attacks, such as double-spending (discussed in Section 1), or selfish-mining ([11], discussed in Section 4), can become much more profitable if miners know in advance when they become eligible to mine. We begin with the definition of local predictability, which describes protocols where the owner of a coin knows in advance if she is eligible to mine a block with that coin. Let be the -th predecessor of a block . That is, is the block that is mined on top of, , etc.

Definition 5 (-locally predictable).

A coin is -locally predictable at block for timestamp if can efficiently predict whether or not there will exist a block with such that , where and .

Observation 1.

For any Proof-of-Stake protocol, every coin is -locally predictable at every block for every timestamp .


Fix a coin , block , and timestamp . If there is some block with such that , and , then outputs such a block. If not, then . Since is efficiently computable by , we have that the coin is 1-locally predictable at block for timestamp . ∎

In many existing protocols, every coin in a given protocol will be -locally predictable at every block and for every timestamp. In such cases, we will refer to the protocol itself as being D-locally predictable. Intuitively, local predictability captures that a miner can predict in advance when they will be able to produce a block (whereas in Proof-of-Work protocols, they learn only the instant that the block is produced). Global predictability is a stronger definition which describes protocols in which every participant knows in advance if the owner of a given coin is eligible to mine a block.

Definition 6 (-globally predictable).

A coin is -globally predictable at block for timestamp if every participant of the protocol can efficiently predict whether or not there will exist a block with such that , where and .

For the reader interested in further understanding predictability, Appendix A.3 contains some sample definitions for and analyzes their predictability.

3.2 (Non)-Recency

The second property we consider is recency, which is just the negation of local predictability. Intuitively, a protocol is -recent at if the validity of block depends on some information contained in the last predecessors of . The main security concern with -recent protocols is that intuitively each chain has its own pseudorandomness (but this is not a formal claim).999By chain, we mean a set of blocks . We’ll again get into more detail with respect to security implications in Section 4, but just note here that certain deviations are easier to detect when chains share the same pseudorandomness.

Definition 7 (-recent).

A coin is -recent at a block for timestamp if the owner of cannot efficiently predict whether or not there will exist a block such that , where , , and .

As with predictability, in many existing protocols every coin will be -recent at every block and for every timestamp. We will refer to such examples as -recent protocols. Due to the following observation, further examples illustrating recency aren’t necessary, as it’s simply the negation of -local predictability.

Observation 2.

For any , any block and any timestamp , a coin is either -locally predictable or -recent.

4 Security Implications

In this section, we elaborate on the security implications of predictability and recency.

4.1 Global Predictability

Here, we’ll describe two attacks against protocols with coins that are globally predictable that we call “globally predictable selfish-mine” and “globally predictable double-spend.” In the former, the attacker attempts to claim extra mining rewards by delaying the announcement of mined blocks, and in the latter the attacker attempts to receive goods for free by overwriting a transaction in order to effectively spend the same coins twice. Both attacks are also possible, but weaker and a touch more complex, against locally predictable protocols. So we begin with the globally predictable versions, and defer the locally-predictable variants to Appendix B.1. Both attacks have a similar flavor, so we detail selfish mining here, and also defer double spending to Appendix B.2.

Definition 8 (Globally-Predictable Selfish Mining).
  1. [leftmargin=*]

  2. At all times , let denote the current longest chain (that is, let be the block you are aware of maximizing ).

  3. For all , find the minimum time such that there exists a block , where (for some ), , you own coin for all , , and . That is, for all , find the earliest time that you can create a block with , where you created all blocks on the path from to .

  4. For all , find the minimum time such that there exists a block , where (for some ), , you don’t own coin for all , , and . That is, for all , find the earliest time that the rest of the network can create a block with , and you did not create any blocks on the path from to .

  5. If at time , there exists a such that , immediately stop publishing blocks until (if there are multiple such , take the largest one). At time , output the promised and its predecessors.

Figure 1: Globally Predictable Selfish Mining (illustrated with number of predecessors of ): If you know you can make a node at time whose predecessors after are also all created by you, and for all possible that could be created by time without you (whose predecessors after are also all created without you), stop publishing blocks and output the full chain all at once at time .

The high-level idea behind the attack is the following: the original selfish mining attack [11] proposes withholding a block upon creation (i.e. not broadcasting it). You continue mining on top of , while the rest of the network continues mining on top of . If you create a new block on top of before the rest of the network creates a new block on top of , then you now possess the unique longest chain. So you can continue mining on top of and its descendants until the rest of the network finds a chain that is almost as long as yours. At this point you can announce your chain, causing the entire chain built by the rest of the network to be orphaned (because they will all adopt your uniquely longest chain). Of course, the attack could go completely differently: maybe the rest of the network successfully mines on top of before you mine on top of . In this case, now you’re in trouble and run the risk of losing because there is a competing chain of the same length.

With sufficient global predictability, however, there is no risk! You can predict before deciding whether to withhold if you’ll mine on top of before another miner mines on top of . So you can only withhold those for which the attack will succeed, completely avoiding the risk. For instance, if a protocol is -globally predictable, and # predecessors of , then the above attack can be carried out for any . The attacker’s incentives to carry out such an attack of course depend on exactly how minng rewards are distributed, but it is clear that globally predictable selfish mining allows the attacker to produce a greater fraction of blocks on the longest chain. For standard reward schemes this is indeed profitable [11, 5].

The frequency with which an attacker will have the ability to predictably selfish-mine depends on the exact nature of the scoring function and the Proof-of-Stake protocol . In Appendix B, we analyze the probability of a miner being able to launch a predictable selfish-mining or predictable double spend attack assuming that is the simple longest-chain rule and that acts as a random oracle (formal definition in Appendix B - without some assumption like this it’s impossible to begin talking about probabilities). The key takeaway from this section is that Predictable Longest-Chain Variant Protocols are vulnerable to Predictable Selfish Mining.

4.2 Recency

Here, we discuss an attack on -recent protocols, which we call Undetectable Nothing-at-Stake. In the Nothing-at-Stake attack miners try to mine on top of many blocks simultaneously, instead of just the one maximizing over all valid blocks. We call it undetectable if, information theoretically, there is no proof that a miner engaged in Nothing-at-Stake. To make this formal, it is helpful to first recall the behavior of an honest miner.

Definition 9 (Honest Miner).

An Honest Miner participating in a Proof-of-Stake protocol will do the following at every time step :

  • [leftmargin=*]

  • Find maximizing among all blocks that the miner is aware of.

  • For all owned coins , attempt to mine a new block . If announce the new block , otherwise do nothing.

Any deviation from this behavior would be considered dishonest, and problematic for the functionality of the underlying protocol. Sometimes, these deviations will be detectable, in the sense that there is clear evidence that a miner deviated from the protocol. Formally:

Definition 10 (Provable Deviation).

We say that two valid blocks and with are a provable deviation by the owner of coin if , or if both and .

The first part of this definition captures that honest nodes only output one block per timestep. The second half captures that at time , the owner of coin created block . Then at time , they are claiming that maximizes over all blocks they are aware of. Clearly this is not true if . The proof of Proposition 1 is in Appendix B.3.

Proposition 1.

If a miner is caught having announced a provable deviation, then they must have deviated from the intended protocol. Also, any sequence of announcements from a miner that does not contain a provable deviation could have been sent by an honest miner experiencing latency.

Proposition 1 tells us that without a provable deviation, we cannot “punish” suspected deviant miners without the risk of punishing honest but poorly-connected miners. Now, we propose one specific protocol deviation that is guaranteed never to produce a provable deviation.

Definition 11 (Undetectable Nothing-at-Stake).

First, ensure that all of your coins are owned by different public keys. Then, for each owned coin , do the following during every timestep :

  • [leftmargin=*]

  • Find maximizing among all blocks that you are aware of.

  • Find maximizing among all blocks that are not descendants of .

  • Mine with , and with .

  • If , announce the new block . If , and announcing would not create a provable deviation, announce .

Figure 2: Undetectable Nothing-at-Stake: The attacker creates two blocks, and . There is no resource cost in checking if both are valid. Depending on reward scheme, there may be an expected monetary gain for announcing both.

By definition, announcing and at time does not create a provable deviation at time . But, it could be the case that at some later time , announcing some new block would reveal that the miner was not following the honest protocol. We show next that this is impossible.

Observation 3.

The Undetectable Nothing-at-Stake strategy never produces a provable deviation.

So the proposed deviation will never “get caught” (that doesn’t necessarily mean that a clever protocol can’t still enact punishment - see Section 5). But we also want to understand whether the proposed deviation will ever actually deviate (it’s conceivable that the safety check will prevent the miner from ever announcing an “illegitimate” block), and this is where recency comes in. Essentially what’s going on is that if a protocol is -Recent, then whether or not a you can build a valid block on top of with coin at time actually depends on some of the blocks between and (which, by Chain Dependence + Monotonicity, the validity of any block built on top of doesn’t depend on). So each coin is kind of getting a “fresh shot” at being eligible to mine a block on top of during time , and one might reasonably expect this shot to succeed with non-zero probability (with the success probability of course dependent on the exact behavior of ).

Again, any meaningful probabilistic analysis requires some assumption on and (otherwise we don’t even have a probability space to work with). We consider the case where is the simple longest chain rule and acts as a random oracle, and show essentially that when the number of coins in the system is larger than the recency of the protocol, then Undetectable Nothing-at-Stake is announcing twice as many blocks as the honest strategy. See Appendix B for a formal statement.

Again, the profitability of Undetectable Nothing-at-Stake depends on the exact reward scheme, but what is clear is that Undetectable Nothing-at-Stake allows the attacker to (undetectably) produce a greater fraction of blocks. The main takeaway from this section is that Recent Longest-Chain Variant Protocols are vulnerable to Undetectable Nothing-at-Stake.

5 Discussion

In summary, we’ve shown that even in an ideal model with perfect connectivity and no latency, every Longest-Chain-Variant-Proof-of-Stake protocol has some undesirable property. Below, we discuss possible fixes for the attacks enabled by these properties, draw conclusions and pose directions for future work.

Preventing predictable selfish mining.

Preventing predictable selfish mining is challenging, but some clever ideas exist in the literature. At a high level, Fruitchains [21], Ouroboros [17], and Tezos [14] design protocols where blocks need to be “supported” once mined (eligibility to support is also proportional to stake), so one would not only need a majority of blocks mined but also a majority of “support tokens(/fruit)” in a given window to successfully selfish mine. Both Snow White [9] and Ouroboros [17] provide proofs that any deviation from their prescribed protocol can only provide a small in additional mining rewards. However, [9] notes that it would be preferable for known attacks to be strictly disincentivized (more on this in Appendix C), and it remains open whether these reward schemes accomplish this.

Preventing predictable double-spend.

A simple defense specifically against predictable double-spend attacks is to accept long confirmation times (e.g. a transaction is not considered “finalized” by vendors until several blocks have been announced descending from the block containing the transaction). Our analysis (Appendix B) indicates that several hundred blocks might be necessary, making it virtually impossible to have quick confirmation times in a predictable Proof-of-Stake protocol without further defenses. For example, the authors of the Ouroboros [17] Protocol (which is predictable) suggest using confirmation times of 148 minutes to defend against double spend attacks by an attacker controlling of the stake when blocks are created at a rate of one per minute (and this is consistent with our analysis).

Defending against Undetectable Nothing-at-Stake.

Existing literature proposes roughly three paradigms that attempt to defend against Undetectable Nothing-at-Stake. The most common defense in commercial protocols is to set very large (these protocols are therefore -locally predictable for large ), and to use some form of “checkpointing” every blocks. This “checkpointing” might be run externally by a trusted party, hard-coded into the protocol, or just a form of trust among network participants that they would never seriously consider a fork more than blocks back. In practice, there don’t seem to have been any serious issues with this approach, but to our knowledge its security hasn’t previously been rigorously analyzed.

Algorand proposes a different approach: instead of using a longest-chain variant, it uses a Byzantine consensus protocol. Under some network connectivity assumptions, they show that the probability of a fork is negligible. As such, any deviant behavior that results in a fork (such as Undetectable Nothing-at-Stake) can be readily recognized as malicious, and safely ignored.

Ethereum’s Casper [1] proposes a third solution that they call “dunkles”: punish every miner whose block winds up being orphaned (not a predecessor of the block maximizing ). The high-level goal of this is to essentially copy the incentives from Proof-of-Work: if your block is orphaned, you still lose the electricity that went into mining it. By punishing the miner of every orphaned block, some honest miners will get punished just by bad luck, but it will also discourage attackers from mining off the longest chain. This seems like a promising direction, but there is currently no formal specification or rigorous evaluation of the proposal.

There’s no reason for global predictability.

There’s a real tradeoff to explore between -local predictability and -recency (since one cannot avoid both, by definition). But there doesn’t seem to be any benefit to global predictability, only the risk of stronger predictable-selfish-mining attacks. There also doesn’t seem to be a black-box reduction stating that mixing any existing protocol properly with digital signatures removes global predictability (although this would be a great future result), but it seems likely that a clever use of digital signatures as in Algorand could modify most existing protocols to be no longer globally predictable with low cost.

Trusted External Randomness, Trusted Checkpointing, or Not?

Our work shows that there is a fundamental difference between trusted external randomness and “internal pseudorandomness” derived pseudorandomly using the cryptocurrency itself. Essentially, the difference is that all internal pseudorandomness is in the end locally predictable or recent and therefore susceptible to some form of attack. External randomness (such as the NIST beacon) is not, and recall that protocols that use external randomness fail to satisfy Chain Dependence (so none of our results apply). Can such a protocol be the basis for a secure, incentive compatible Proof-of-Stake protocol? Even if the answer is yes, how does one resolve the (possibly just-as-challenging) issue of obtaining trusted randomness?101010Chapter 9.4 of [20] describes how functional cryptocurrencies can serve as sources of trusted randomness. So it is indeed unclear whether trusted randomness is really an easier problem. Trusted checkpointing provides a cheap solution to Undetectable Nothing-at-Stake, and does seem simpler than trusted randomness. Can trusted checkpointing provide guarantees that are otherwise hard (or impossible) to come by?

Byzantine Consensus versus Longest-Chain Variants.

With the exception of Algorand and Casper: the Friendly Finality Gadget, every proposal that the authors are aware of uses a longest-chain variant. The upside of longest-chain variants is that they are inherently robust to Eclipse attacks. Byzantine consensus protocols require some network connectivity assumptions in order to safely ignore messages sent too far in the past, and are less robust to Eclipse attacks. Are there provable limits to what can be achieved by longest-chain variants, necessitating the use of Byzantine Consensus? Or is it possible to achieve the same guarantees with a true Longest-Chain variant?

Rigorously and Transparently Evaluate Protocols in the Ideal Model.

Our work shows that already it is quite challenging to design incentive compatible Longest-Chain Variants in the ideal model. Numerous reasonable ideas have been proposed to address the vulnerabilities arising from predictability and recency, but none have transparent yet rigorous analysis. We believe that the vulnerabilities we’ve uncovered are serious enough that future Proof-of-Stake proposals should include transparent proofs of how they defend against predictable double-spend, predictable selfish-mine, and undetectable nothing-at-stake in the ideal model.

It is obviously necessary to also continue evaluating network security aspects of proposed protocols, but it is important that any incentive-related security claims in these rich models easily map to transparent claims in the ideal model.


  • cas [2017] Ethereum wiki: Proof-of-stake faq., 2017.
  • Babaioff et al. [2012] Moshe Babaioff, Shahar Dobzinski, Sigal Oren, and Aviv Zohar. On bitcoin and red balloons. In Proceedings of the 13th ACM conference on electronic commerce, pages 56–73. ACM, 2012.
  • Bentov et al. [2016] Iddo Bentov, Ariel Gabizon, and Alex Mizrahi. Cryptocurrencies without proof of work. In International Conference on Financial Cryptography and Data Security, pages 142–157. Springer, 2016.
  • Buterin and Griffith [2017] Vitalik Buterin and Virgil Griffith. Casper: The friendly finality gadget, 2017.
  • Carlsten et al. [2016] Miles Carlsten, Harry Kalodner, S Matthew Weinberg, and Arvind Narayanan. On the instability of bitcoin without the block reward. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, pages 154–167. ACM, 2016.
  • Chen and Micali [2016] Jing Chen and Silvio Micali. Algorand: the efficient and democratic ledger. arXiv preprint arXiv:1607.01341, 2016.
  • Community [2015] NEM Community. NEM Technical Reference., 2015.
  • Community [2014] Nxt Community. Nxt Whitepaper., 2014.
  • Daian et al. [2016] Phil Daian, Rafael Pass, and Elaine Shi. Snow white: Provably secure proofs of stake. IACR Cryptology ePrint Archive, 2016:919, 2016.
  • Eyal [2015] Ittay Eyal. The miner’s dilemma. In Proceedings of the 36th IEEE Symposium on Security and Privacy (Oakland), 2015.
  • Eyal and Sirer [2014] Ittay Eyal and Emin Gün Sirer. Majority is not enough: Bitcoin mining is vulnerable. In International conference on financial cryptography and data security, pages 436–454. Springer, 2014.
  • Fischer et al. [1985] Michael J. Fischer, Nancy Lynch, and Michael S. Paterson. Impossibility of distributed consensus with one faulty process. Journal of the ACM, 32(2):374–382, 1985.
  • Gilad et al. [2017] Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich. Algorand: Scaling byzantine agreements for cryptocurrencies. In Proceedings of the 26th Symposium on Operating Systems Principles, SOSP ’17, pages 51–68, New York, NY, USA, 2017. ACM. ISBN 978-1-4503-5085-3. doi: 10.1145/3132747.3132757. URL
  • Goodman [2014] L.M Goodman. Tezos A self-amending crypto-ledger white paper., 2014.
  • Hanke et al. [2017] Timo Hanke, Mahnush Movahedi, and Dominic Williams. Dfinity technology overview series consensus system, 2017.
  • Kiayias et al. [2016] Aggelos Kiayias, Elias Koutsoupias, Maria Kyropoulou, and Yiannis Tselekounis. Blockchain mining games. In Proceedings of the 2016 ACM Conference on Economics and Computation, pages 365–382. ACM, 2016.
  • Kiayias et al. [2017] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov. Ouroboros: A provably secure proof-of-stake blockchain protocol. In Annual International Cryptology Conference, pages 357–388. Springer, 2017.
  • King and Nadal [2012] Sunny King and Scott Nadal. PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake., 2012.
  • Nakamoto [2008] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008.
  • Narayanan et al. [2016] Arvind Narayanan, Joseph Bonneau, Edward Felten, Andrew Miller, and Steven Goldfeder. Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction. Princeton University Press, 2016.
  • Pass and Shi [2017] Rafael Pass and Elaine Shi. Fruitchains: A fair blockchain. pages 315–324, 2017. doi: 10.1145/3087801.3087809. URL
  • Sapirshtein et al. [2016] Ayelet Sapirshtein, Yonatan Sompolinsky, and Aviv Zohar. Optimal selfish mining strategies in bitcoin. In International Conference on Financial Cryptography and Data Security, pages 515–532. Springer, 2016.
  • Sompolinsky and Zohar [2013] Yonatan Sompolinsky and Aviv Zohar. Accelerating bitcoin’s transaction processing. fast money grows on trees, not chains. IACR Cryptology ePrint Archive, 2013:881, 2013. URL
  • Sompolinsky and Zohar [2015] Yonatan Sompolinsky and Aviv Zohar. Secure high-rate transaction processing in bitcoin. In International Conference on Financial Cryptography and Data Security, pages 507–527. Springer, 2015.
  • Vasin [2014] Pavel Vasin. Blackcoin’s proof-of-stake protocol v2, 2014.

Appendix A Examples Aiding Definitions From Section 2

a.1 Assumption 1

To get some intuition for Assumption 1, here are two toy examples that violate Chain Dependence and Monotonicity (respectively). First, consider a protocol where the validity of a block depends on a trusted source of external randomness (e.g. the NIST beacon). This external randomness is not contained in the blockchain itself, so such a protocol does not satisfy Chain Dependence.

Next, consider a protocol that declares a block invalid if its creator proposed another block within the same -week time period. Then will be considered valid for the graph that contains only and its predecessors, but invalid for the graph which contains and all of their predecessors. So this protocol violates Monotonicity. These protocols are not absurd, but are much more vulnerable to Eclipse attacks than virtually all existing proposals.

a.2 Freezing

In the definition for Proof-of-Stake we provided, it may sometimes be desirable to “freeze” coins used to mine for longer than just one block. That is, the first indicator in bullet three requires that coin be owned by in the block before (so that the miner could not move in the same block s/he is trying to mine). For many protocols, it may be desirable to additionally insist that the owner of coin did not change in any of the last blocks (i.e. that was frozen for blocks before used for mining). We note that our definition can easily be modified to replace with , where is a freezing parameter of (and Definition 3 is then a special case with hardcoded). Of course, this could also be offloaded into , but the astute reader will later notice that treating freezing separately makes future technical definitions cleaner.

a.3 Predictability

Below we provide examples of predictable and unpredictable protocols for the sake of further explanation. In what follows, let and be some positive threshold.

  • [leftmargin=*]

  • Protocol where if and only if .111111Note that this is (essentially) the initial proposal made in Peercoin: Every coin in is -globally predictable at , for all and all . This is because every user can compute for all and check whether or not it’s . So every user can compute the minimum such that a block can be built on top of . Similarly, every user can compute for all , which determines the minimum that a block can be built with (note that must be monotonically non-decreasing in ). If , then a block indeed exists with , , . Otherwise, no such exists.

  • Protocol where if and only if . Every coin in is -globally predictable at for all and all . This is because every user can compute for all coins and times . Therefore, every user can determine all potential timesteps where a block could be created. If there are such timesteps between and , and , then the answer is yes. If not, then the answer is no.

  • Protocol where:121212 is based on the seed-selection portion of Algorand.

    • Each block contains a signature computed by .

    • outputs a block with , where denotes the function which digitally signs a message using the secret key of .

    • if and only if .

    is a good example to clarify potentially subtle aspects of the definitions. Every coin in is -locally predictable at , for all (as with all Proof-of-Stake protocols). In addition, can computationally efficiently find certain kinds of blocks with and : namely, those for which for all for . This is because can efficiently compute all blocks that they themselves can build on top of , and then all blocks that they themselves can build on top of these blocks, etc. using . However, cannot computationally efficiently predict whether there exists a block with , , but for some . This is because knowing the existence of this block would require being able to digitally sign as , which cannot do computationally efficiently. So every coin in is not -locally predictable for any . Similarly, no coin is -globally predictable for any because in order to know whether is valid, one must be able to digitally sign messages as (which one cannot do computationally efficiently unless one is ).

Appendix B Omitted Proofs from Section 4

b.1 Locally Predictable Selfish Mining

Here, we’ll show how to modify the globally predictable attacks of the previous section to be locally predictable. Locally predictable selfish mining is no longer risk-free (because you can’t predict when the rest of the network will find their blocks), but you can still gain a statistical edge by knowing when in the future your blocks will come (essentially, if your blocks come earlier than normal, this is a good time to withhold. If your blocks come later than normal, this is a bad time).

Definition 12 (Locally-Predictable Selfish Mining).
  1. [leftmargin=*]

  2. For all , define a time cutoff .

  3. For all , find the minimum time such that there exists a block , where (for some ), , you own coin for all , , and . That is, for all , find the earliest time that you can create a block with , where you created all blocks on the path from to .

  4. If at time , there exists a such that , immediately stop publishing blocks until (if there are multiple such , take the largest one). At time , output the promised and its predecessors.

As referenced above, the key difference between Locally-Predictable and Globally-Predictable Selfish Mining is that you can no longer compute how long it will take for the rest of the network to produce a block with score . Still, you can get a statistical edge because you know at what time in the future you’ll be able to produce a block with score . So set the cutoff so that you will actually gain in expectation by withholding. Note that there certainly exists such a (e.g. ), although the probability of producing blocks before might be extremely small (e.g. for it is zero). Still, for all existing Longest Chain variants that fit our framework, for all , a user with an -fraction of the total stake could set appropriate thresholds for Locally Predictable Selfish Mining and produce a -fraction of the total blocks on the longest chain (and also strictly increase their expected reward).

Moreover, since Locally Predictable Selfish Mining only requires predicting your own blocks, -Local Predictability actually suffices for this attack. By Observation 1, this means that in fact every Longest-Chain Variant Proof-of-Stake Protocol is vulnerable to Locally Predictable Selfish Mining.

Lemma 1.

Every Proof-of-Stake protocol is vulnerable to the Locally Predictable Selfish Mining attack. In particular, every time a miner is eligible to mine a block, she can also attempt to launch a Predictable Selfish Mining attack (for all ).


By Observation 1, for any block , any coin owned by the attacker, and any time , the attacker can determine whether or not there exists a block with , , and . Therefore, the attacker can do the following for all :

  • [leftmargin=*]

  • Initialize .

  • While there exists a block with owned by the attacker, , (in English: while the attacker can mine a block on top of some block in at time ): Add to all such blocks.

  • Let . If , then we’ve found an opportunity to selfish mine. If not, then there’s no opportunity.

Note that the attacker can implement every step above due to Observation 1 and the prior reasoning, and it’s trivial to see that the algorithm above implements locally predictable selfish mining. ∎

Minor Improvements with Greater Local Predictability.

If a protocol happens to have -locally predictable coins for larger instead of just -locally predictable, then an attacker intending to launch a predictable selfish mining attack is aware blocks in advance. It’s unclear that this advanced notice is significant, but it’s not completely negligible. For example, a miner who can predict that she will likely succeed with a locally predictable selfish mine several hours in the future may offer to accept bribes in order to fork for a double-spend attack (similarly, the miner could try to prepare their own double-spend attack - see Appendix). The idea is that if the goal of this attack is simply to get increased mining rewards, then the advanced notice doesn’t help. But if the goal is to use this attack in more “outside-the-box” ways (or to do a predictable double-spend), then the advanced notice might actually help.

The key takeaway from this subsection is that Every Longest-Chain Variant Proof-of-Stake Protocol is vulnerable to Locally Predictable Selfish Mining. Again, the improved rewards for participating in the attack vary from protocol to protocol, but in all existing protocols that the authors are aware of, the reward increase is non-zero. There are interesting ideas for potential defenses posed in both commercial and academic protocols, but without transparent analyses.

b.2 Predictable Double-Spend

We first describe a “predictable double-spend,” which requires an initial definition of a “confirmation time.” Confirmation times aren’t hard-coded into cryptocurrencies, but determine when a vendor is comfortable considering a transaction “finalized” and exchanging goods. The required confirmation may vary depending on the transaction. For instance, a cafe may be willing to hand over a cup of coffee even before the payment transaction has been included in a Bitcoin block (but at least verifying that the transaction has been digitally signed and broadcast). But a homeowner may not hand over the deed to their house until several Bitcoin blocks have been mined on top of the block containing the payment transaction.

Definition 13 (Confirmation Time).

For a given block containing transaction , and block a descendant of , we say that is confirmed by if a vendor would exchange whatever goods are being purchased by once believing (according to whatever Longest-Chain-Variant is used) the history defined by .

Below we now describe a predictable double-spend attack which is costless to the attacker, and may result in the attacker receiving goods for free if confirmation times are lax enough.

Definition 14 (Globally Predictable Double-Spend).

Do the following:

  1. Produce a transaction in order to purchase some good, but don’t yet announce it to the network or vendor.

  2. At all times , let denote the current longest chain (that is, let be the block you are aware of maximizing ).

  3. For all , find the minimum time such that there exists a block , where (for some ), , you own coin for all , , and . That is, for all , find the earliest time that you can create a block with , where you created all blocks on the path from to .

  4. Similarly, for all , find the minimum time such that there exists a block , where (for some ), , you don’t own coin for all , , and . That is, for all , find the earliest time that the rest of the network can create a block with , where you did not create any blocks on the path from to .

  5. If at time , there exists a such that , immediately announce the transaction and stop publishing blocks until (if there are multiple such , take the largest one).

  6. Hope that at some , a block is announced that confirms .

  7. Get the good from the vendor at time .

  8. At time , output the promised and its predecessors.

It should be clear that if this attack is successful, it will result in the attacker getting their goods for free, as will become the new history and no history built upon can possibly contain the transaction . Notice that the above description is essentially the same as the globally predictable selfish-mining attack, but the goal of predictable selfish mining is to claim extra mining rewards rather than free goods for a canceled transaction. For locally predictable protocols, there is a corresponding locally predictable double-spend attack that is identical to the locally predictable selfish mining attack, except for the addition of the steps announcing the transaction which the attacker intends to cancel.

Let’s see how this plays out with a relevant example. To do any meaningful analysis, we’ll want to restrict attention to protocols with mining functions that act as a random oracle (otherwise we can’t even begin to talk about probabilities). By this, we mean protocols where no matter how many times has already been queried on other inputs, querying

on fresh input appears to be an independent random variable (this is a standard cryptographic assumption when discussing ideal hash functions).

Definition 15 (Random Oracle).

We say that a mining function acts as a random oracle with recency if there exists a function such that for all blocks , coins and timestamps :

  • There exists a success probability function such that with probability .

  • For all the set are independent random variables.131313Obviously no protocol actually achieves this quality of randomness, but all existing proposals use some proxy such as a call to HASH or a “Follow-the-Satoshi” [3, 14].

So let’s now consider Bitcoin’s canonical longest-chain variant: , and a protocol where acts as a random oracle with recency . This means that the potential attacker is capable of computing the following two quantities correctly with high probability:

  • For all , what is the minimum such that there exist and coins all not owned by the attacker, and . Call this number .

  • For all , what is the minimum such that there exist and coins all owned by the attacker, and . Call this number .

That is, for every the attacker makes the following thought experiment: “Can I create blocks faster than the rest of the users?”. If , i.e. the answer to the previous question is “Yes”, the attacker can attempt to launch a predictable selfish-mine or predictable double-spend attack (but of course, whether or not the attacks achieve the attacker’s goal depends on further details of the protocol). Note that in the setting where every coin is -locally predictable at all blocks and timestamps , the attacker can compute but not . However, if acts as a random oracle, then the attacker can estimate the value of with high probability. If every coin is -globally predictable, then the attacker can compute with probability 1.

Now the first question one might wish to ask is: given that the attacker controls an -fraction of the stake, what is the probability that we will ever see for any block before the end of the universe (a similar question was addressed by figures in [17])? Assuming that acts as a random oracle (with any recency), the probability that can be analyzed in the following way. biased coins are flipped; the probability of heads is . Notice that every outcome of this experiment will have either at least heads or at least tails, but not both. Therefore, the probability that we see at least heads is exactly the same as the probability that the attacker creates

blocks faster than the rest of the users. The random variable of interest follows the binomial distribution with parameters

and , so the calculation is straightforward. Let . We say that is safe if for some tolerance threshold . For every such threshold we can find the smallest safe , i.e. the smallest window in which an adversary can win the race against the rest of the users with probability within the threshold. Intuitively, we would like to set a threshold so that is small.

The next question is how to set this threshold. If a block is created every minute, a cryptocurrency that lasts years has approximately blocks. If we want the probability that the attacker succeeds at some time during the lifetime of the currency to be at most , the threshold should be set to . Given , we can plot as a function of . See Figure 3.

Figure 3: and on a log-scale

So if, for instance, one is comfortable assuming that no miner will exceed 40% of the total stake, one can reasonably expect to never see for any block throughout the cryptocurrency’s entire lifetime.

b.3 Recency

Proof of Proposition 1.

The first part of the proposition, i.e. provable deviations can only be created by miners who actually deviate from the honest protocol, is obvious. We show that any sequence of blocks that do not contain a provable deviation could conceivably have been created by a miner honestly following the protocol. Consider a set of valid blocks, , sorted in increasing order of , and with for all , that contains no provable deviation (this immediately implies that for all ). If there are no provable deviations, this also means that for all . Now, consider an honest miner who owns coin and no other coins. It is possible that at time , the miner was aware of blocks of the form , as these sets are monotone increasing.141414Of course, it is not possible in the ideal network model if all other miners are participating honestly. But it is certainly possible if any other miner is dishonest, or our strong ideal network conditions are violated Moreover, by hypothesis that the blocks contain no provable deviations, we also have that (because the miner also must have been aware of all of these blocks in order to mine block at time ).151515If there is a tie, have the miner tie-break in favor of . This is consistent as . So it is entirely possible (although perhaps unlikely, depending on the exact protocol and behavior of other miners) that the owner of coin was aware of exactly the blocks at time and therefore produced their proofs by honestly following the protocol. ∎

Proof of Observation 3.

First, it is clear that announcing the block with , where maximizes over all blocks you are aware of cannot possibly create a provable deviation. This is because the block you just announced necessarily has and for any other you previously produced (by definition of ). So announcing a block on top of the longest chain can never produce a provable deviation. Moreover, there is an explicit check before announcing any which doesn’t build on top of the longest chain to guarantee that it also doesn’t cause a provable deviation: simply check that , where is the most recent block you have mined. ∎

In this section we provide a formal analysis of how much of an advantage can be won by an attacker using the Undetectable Nothing-at-Stake strategy in a protocol with -recent coins.

As a helpful (non)-example, consider the following protocol which is not -Recent for any : if and only if . Now, for every pair of candidate blocks and with , we have . In this case, announcing together with will always create a provable deviation, and the Undetectable Nothing-at-Stake behaves exactly as an honest miner. This is essentially because in the above protocol the blocks and on separate forks use an identical source of pseudorandomness to determine if the owner of a given coin should be allowed to mine.

The problem with -Recent protocols that act as random oracles with recency is that the two sides of a fork will have independent pseudorandom seeds, so the safety check rarely prevents the attack from announcing the illegitimate block. We will need one more definition to describe the full generality in which the following analysis holds.

Definition 16 (More-Than-Honest).

We say that a strategy is More-Than-Honest if at every timestep :

  • Let maximize over all blocks of which the miner is aware.

  • If for any coin that the miner owns, the miner announces some valid block with .

  • The miner may also announce other blocks.

Observe that both the honest protocol and Undetectable Nothing-at-Stake are More-Than-Honest. We now present a formal analysis of the mining advantage enjoyed by an attacker using the Undetectable Nothing-at-Stake strategy.

Proposition 2.

Let be a -Recent Proof-of-Stake protocol where acts as a random oracle with recency . Let also there be at least coins in the network, all using a More-Than-Honest strategy. Finally, let . Then the Undetectable Nothing-at-Stake strategy announces blocks at least times the rate as the honest strategy.

To help parse the above proposition, it is suggesting that any -Recent protocol which expects at least coins to be actively mining must defend against Undetectable Nothing-at-Stake whenever .

Proof of Proposition 2.

Recall the following notation from the strategy definition: refers to the block maximizing over all blocks the attacker is aware of. refers to the block maximizing over all blocks not descended from . refers to the block built on top of that may or may not be announced, pending the safety check.

The only way that the safety check will stop the deviating miner from announcing is if the same coin was previously used to mine a block that is a descendant of . This is because for all other , so no other can possibly contribute to a provable deviation. So we just need to analyze the probability that the same coin was previously used to mine a block on top of .

In order for coin to have mined a block on top of , it must be the case that the longest chain has not grown by more than since the last time that has mined a block (this is a necessary, but not sufficient condition). Taking the converse, this means that a sufficient condition for the safety check to allow the announcement of the illegitimate block is if the longest chain has grown by more than since the last time that coin was used to mine a block. So we now just need to understand the fraction of timesteps for which the last time that a block mined by coin has height within of the current longest chain, and those for which it doesn’t.

So now, in every timestep, consider the three possible events:

  • Some coin besides is eligible to mine on top of the longest chain. Because all coins are using a More-Than-Honest strategy, the length of the longest chain grows by one.

  • Coin is eligible to create a block (regardless of whether or not it chooses to announce it).

  • The longest chain does not grow, and is not eligible to create a block (but perhaps other miners announce blocks that don’t affect the length of the longest chain).

Note first that there are at least equally likely outcomes corresponding to the first event since there are coins other than . There are two equally likely outcomes corresponding to the second event since the attacker attempts to use the coin to mine in two independent locations. Thus during every timestep, the second event occurs at most a fraction of the time (this would be tight if each other miner was honest, or otherwise only mining on top of a single longest chain). We can now also see that every timestep in which event two happens “claims” timesteps in which event one happens as the timesteps where the safety check could have conceivably prevented announcing the illegitimate block (the next such timesteps). For all other timesteps, the safety check would definitely have allowed the illegitimate block to be announced.

So in the limit, only a fraction of the “event-one” timesteps are claimed, and in all remaining timesteps the safety check would have allowed publication of both blocks. Therefore, a fraction of the time, the Undetectable Nothing-at-Stake strategy is considering publication of two blocks, and will announce blocks at a rate of at least times as often as an honest miner. ∎

Appendix C Existing Proof-of-Stake Protocols

In this section, we discuss several popular Proof-of-Stake protocols, how they fit into our language, and the extent of their susceptibility to the attacks we discuss. Many of these protocols can get quite involved, with several layers of defenses, but our goal is to focus on the core protocols underneath.

Snow White.

The Snow White protocol [9]

separates time into epochs; each epoch has

time steps. Within each epoch a committee and a hash function/random oracle are decided by looking at blocks in the common history. At each time step, if for some member of the committee with public key it holds that , then that member becomes the leader and gets to make a new block. Therefore, the protocol is predictable by our definitions, and vulnerable to predictable selfish mining and predictable double spend.

To address this, Snow White adopts the reward scheme of Fruitchain [21]. That is, blocks don’t directly contain transactions, but rather fruit, and fruit directly contain transactions. Miners are then rewarded for creating fruit, rather than blocks. They further prove the following: if a miner controls an fraction of the stake, and all other miners follow the intended protocol, that miner receives at most a fraction of the total rewards (for a small decided by the designer). Their proof has the flavor of a differential privacy guarantee: essentially any strategy that miner uses will in fact result in a fraction of the total rewards.

As such, Snow White further notes that it would be more desireable to strictly disincentivize known attacks. To this end, they show that the (detectable, because Snow White is not Recent) Nothing-at-Stake attack is strictly unprofitable against their reward scheme. Our work is essentially proposing that it would be worthwhile to do a similar analysis for predictable selfish mining and predictable double-spending. So in summary: (1) Snow White is not vulnerable to undetectable Nothing-at-Stake, because it is not Recent. (2) Snow White is vulnerable to predictable selfish mining, but provably it cannot improve a miner’s rewards by more than an additive fraction of the total rewards. (3) Snow White is vulnerable to predictable double spending, which could be mitigated by sufficiently long confirmation times but is otherwise not addressed.


At the level of granularity relevant to this paper, Ouroboros is similar to Snow White. The Ouroboros protocol[17] divides time into epochs, each of which is made up of time slots. Each of the time slots is assigned to a miner chosen randomly with probability proportional to her stake. Each miner is then eligible to create a block in her assigned time-slot. The set of miners assigned to time slots in an epoch is called the committee for that epoch. The miners in the committee additionally run a secure multiparty coin-flipping protocol in order to generate the randomness needed to select the committee for the next epoch.

The protocol adds an additional category of miner called an “input-endorser.” Multiple input-endorsers are randomly selected to each time slot with probability proportional to their stake (using the same source of randomness as the original miners). An input-endorser is responsible for signing the valid transactions they hear about in their given time slot. Miners then include endorsed inputs into their blocks (so endorsed inputs play a similar role to fruit).

Since miners for the time-slots in an epoch are determined in advance, the protocol is -globally predictable. The input-endorses introduce additional complexity, but it is also predictable when a miner will become eligible to be an input endorser. The authors of Ouroboros seem aware of the predictable double-spend attack, and require long block confirmation times. For example, suppose that of the stake is controlled by an attacker attempting a double-spend attack. The authors of [17] compute that in order to achieve confidence that this double spend attack cannot succeed, block confirmation times must be at least 148 minutes. If the attacker controls of the stake, confirmation times must be further increased to 663 minutes (these mirror our own calculations).

Like Snow White, Ouroboros proves that as long as a miner controls an fraction of the stake, and all other miners follow the intended protocol, the miner receives a fraction of the total rewards for essentially any strategy (including honesty, or predictable selfish mining). Similarly to Snow White, our work suggests that it is worthwhile to understand whether predictable selfish mining is indeed profitable. Since the protocol is predictable, Ouroboros is not vulnerable to Undetectable Nothing-at-Stake.

No Rewards.

Consider either of the aforementioned protocols, but in absence of rewards (i.e. copy Snow White, but don’t reward miners for either fruit or blocks). This reward scheme achieves the same formal guarantees as the previous protocols, with : if all other miners are following the intended protocol, another miner gains nothing by deviating. Therefore, no-rewards is at least as robust to predictable selfish mining as proved in these prior works. However, no-rewards is also at least as vulnerable to predictable double-spend (even if the confirmation time exceeds the predictability, there is nothing lost by giving it a shot anyway).

It’s not clear whether no-rewards is actually a viable reward scheme in Proof-of-Stake proposals. On one hand, it achieves the same formal guarantees as prior works (in fact, stronger as one can take ), and one could informally assert that those with stake in the currency have incentive to remain online and follow the protocol to maintain its value. On the other hand, one might equally reasonably worry that without strict incentive to follow the protocol, attempts to double-spend may run rampant.

By most existing formal measures, no-rewards is at least as incentive compatible as the previously discussed reward schemes are proven to be. The lone exception is that Nothing-at-Stake is provably strictly unprofitable against Snow White, but not against no-rewards. Our work proposes that predictable selfish mining, predictable double-spend, and undetectable nothing-at-stake be given the same treatment in future analyses.


Algorand [6, 13] doesn’t fit into our framework, because it is not a Longest-Chain Variant. Algorand is instead based on a Byzantine Consensus protocol. Ideas related to predictable selfish mining are relevant, but there is no formal connection between our work and Algorand.


The authors of [3], design a protocol that selects miners with probability proportional to their stake using a procedure called “follow-the-Satoshi.” In this process, a random minimal denomination (one Satoshi) of the currency is chosen and whomever currently owns it is selected as eligible to mine. The authors initially discuss many of the problems with being predictable, and with nothing-at-stake.

In the authors’ first proposed protocol, Chains-of-Activity (CoA), the chain is divided into groups of consecutive blocks. Every miner includes a supposedly random bit in her block, and the concatenation of all the random bits from the -th group of consecutive blocks is used as a random seed . These seeds are then used to run “follow-the-satoshi” in order to select miners for later blocks in an interleaved way. In particular seed is used to determine miners for blocks in the -th group of blocks. Thus the CoA protocol is -globally predictable. The authors discuss how transactions should not be considered confirmed until timesteps, and show that its unlikely for an attacker to succeed in bribing others for a double spend that lasts longer than . However, predictable selfish mining is not discussed.

The authors’ follow-up proposal “Dense-CoA”, randomly chooses users to be involved in the creation of the -th block. In particular, one special user is selected to actually create the block, but all of them run a secure coin-flipping protocol to produce the random seed for the next block. Thus, Dense-CoA is -Recent.


DFinity [15] doesn’t cleanly fit inside out framework. In fact, DFinity deviates from our framework as early as the definition of Block. In DFinity, some blocks require a threshold signature161616A -of- threshold signature scheme is such that participants each have a public and private key, and there is a public poly-time algorithm Verify. For a given message , it is possible for each participant to generate (in poly-time) a message such that: if and only if at least of inputs are of the form . Moreover, one cannot generate a message of the form without the private key for . from multiple different miners to act as a future source of pseudorandomness. The authors are not commenting on the security of DFinity, but note that these ideas aren’t widely used (DFinity is the only instance the authors are aware of) as threshold signatures require a trusted setup every time the set of stake-holders eligible to sign blocks changes. Further, a whole new consensus problem arises when deciding (for example) how long to wait for the signatures in the threshold scheme.

Appendix D Proof-of-Stake and GHOST

The Greedy Heaviest-Observed Subtree (GHOST) protocol is an alternative to longest-chain variants, originally proposed for proof-of-work blockchains in [23]. The authors observed that even if some blocks did not end up in the main chain, they could still be used as proof that another block should be included. In particular, suppose every miner maintains a tree of blocks that have been published so far. For a given block , every block in the subtree descending from was created by a miner who believed that block should be included in the main chain. Thus, one can think of every block in the subtree descending from as a vote to include . The GHOST protocol is based on this idea.

The protocol proceeds starting from the root of the tree of blocks and greedily moving down the tree along the fork corresponding to the largest subtree.

Definition 17 (GHOST Protocol).

For a block let denote the size of the subtree rooted at .

  • Initialize to be the root of the tree of blocks and do the following:

    1. If has no direct descendants return

    2. Let be the block maximizing among all blocks with in the tree.

    3. Set and go to step 1.

  • Attempt to mine on top of the block returned by the above algorithm.

This has advantages in proof-of-work protocols as it allows faster creation of blocks since forks still contribute to the main chain. However, it has serious shortcomings for a -Recent proof-of-stake protocol. The basic reason for this is that even with a small fraction of the total stake, an attacker can greatly increase the size of a chosen subtree by simultaneously mining on top of every node in the subtree.

For simplicity we will consider a -Recent protocol which acts as a random oracle with recency . Below we describe an exponential forking attack against GHOST protocols, which allows an attacker with a small fraction of the total stake to force all miners following the GHOST protocol into mining on top of the attacker’s chosen subtree.

Definition 18 (Exponential Forking).

Suppose you wish to introduce a fork rooted at a block . Do the following at every timestep t:

  • For every block in the subtree rooted at , and every coin you own, let .

  • If , then announce C.

Now suppose an attacker with an fraction of the total stake uses the exponential forking attack rooted at a block . Note that by definition, honest miners following the GHOST protocol only attempt to add a block at one location per timestep. Thus, all honest miners will add blocks at a rate of per unit time. However, if we let be the size of the subtree rooted at at time , the attacker will add, on average, blocks at time . So if we let denote the total number of blocks added by honest miners up until time we have, on average:

Solving both recurrences yields that after steps we have:

That is, the size of the subtree rooted at grows exponentially faster than the total number of other blocks mined. Thus, all miners following the GHOST Protocol will quickly be forced to mine on the subtree rooted at produced by the attacker.