PreprintPDF Available

Uncle Maker: (Time)Stamping Out The Competition in Ethereum

Authors:
Preprints and early-stage research may not have been peer reviewed yet.

Abstract and Figures

We present an attack on Ethereum's consensus mechanism which can be used by miners to obtain consistently higher mining rewards compared to the honest protocol. This attack is novel in that it does not entail withholding blocks or any behavior which has a non-zero probability of earning less than mining honestly, in contrast with the existing literature. This risk-less attack relies instead on manipulating block timestamps, and carefully choosing whether and when to do so. We present this attack as an algorithm, which we then analyze to evaluate the revenue a miner obtains from it, and its effect on a miner's absolute and relative share of the main-chain blocks. The attack allows an attacker to replace competitors' main-chain blocks after the fact with a block of its own, thus causing the replaced block's miner to lose all transactions fees for the transactions contained within the block, which will be demoted from the main-chain. This block, although "kicked-out" of the main-chain, will still be eligible to be referred to by other main-chain blocks, thus becoming what is commonly called in Ethereum an uncle. We proceed by defining multiple variants of this attack, and assessing whether any of these attacks has been performed in the wild. Surprisingly, we find that this is indeed true, making this the first case of a confirmed consensus-level manipulation performed on a major cryptocurrency. Additionally, we implement a variant of this attack as a patch for Go Ethereum (geth), Ethereum's most popular client, making it the first consensus-level attack on Ethereum which is implemented as a patch. Finally, we suggest concrete fixes for Ethereum's protocol and implemented them as a patch for geth which can be adopted quickly and mitigate the attack and its variants.
Content may be subject to copyright.
Uncle Maker: (Time)Stamping Out The Competition in
Ethereum
AVIV YAISH, The Hebrew University, Israel
GILAD STERN, The Hebrew University, Israel
AVIV ZOHAR, The Hebrew University, Israel
We present an attack on Ethereum’s consensus mechanism which can be used by miners to obtain consistently
higher mining rewards compared to the honest protocol. This attack is novel in that it does not entail
withholding blocks or any behavior which has a non-zero probability of earning less than mining honestly, in
contrast with the existing literature.
This risk-less attack relies instead on manipulating block timestamps, and carefully choosing whether and
when to do so. We present this attack as an algorithm, which we then analyze to evaluate the revenue a miner
obtains from it, and its eect on a miner’s absolute and relative share of the main-chain blocks.
The attack allows an attacker to replace competitors’ main-chain blocks after the fact with a block of its
own, thus causing the replaced block’s miner to lose all fees for the transactions contained within the block,
which will be demoted from the main-chain. This block, although “kicked-out” of the main-chain, will still be
eligible to be referred to by other main-chain blocks, thus becoming what is commonly called in Ethereum an
uncle.
We proceed by dening multiple variants of this attack, and assessing whether any of these attacks has been
performed in the wild. Surprisingly, we nd that this is indeed true, making this the rst case of a conrmed
consensus-level manipulation performed on a major cryptocurrency.
Additionally, we implement a variant of this attack as a patch for Go Ethereum (geth), Ethereum’s most
popular client, making it the rst consensus-level attack on Ethereum which is implemented as a patch. Finally,
we suggest concrete xes for Ethereum’s protocol and implemented them as a patch for geth which can be
adopted quickly and mitigate the attack and its variants.
CCS Concepts: Applied computing
Digital cash;Security and privacy
Economics of security and
privacy;Distributed systems security.
Additional Key Words and Phrases: cryptocurrency, blockchain, proof of work, consensus, security
ACM Reference Format:
Aviv Yaish, Gilad Stern, and Aviv Zohar. 2022. Uncle Maker: (Time)Stamping Out The Competition in Ethereum.
1, 1 (July 2022), 66 pages. https://ia.cr/2022/1020
Authors’ addresses: Aviv Yaish, aviv.yaish@mail.huji.ac.il, The Hebrew University, Jerusalem, Israel; Gilad Stern, Gilad.
Stern@mail.huji.ac.il, The Hebrew University, Jerusalem, Israel; Aviv Zohar, avivz@cs.huji.ac.il, The Hebrew University,
Jerusalem, Israel.
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee
provided that copies are not made or distributed for prot or commercial advantage and that copies bear this notice and
the full citation on the rst page. Copyrights for third-party components of this work must be honored. For all other uses,
contact the owner/author(s).
©2022 Copyright held by the owner/author(s).
https://ia.cr/2022/1020
Publication date: July 2022.
2 Aviv Yaish, Gilad Stern, and Aviv Zohar
1 INTRODUCTION
Cryptocurrencies such as Bitcoin [
89
] and Ethereum [
15
] rely on an elaborate incentive system to
encourage users to participate in operating the decentralized mechanism which underlies them and
maintain the mechanism’s integrity in the face of adversaries. Such participants are called miners.
Thus, a cryptocurrency’s incentive mechanism is inherent to its security. Indeed, among the
myriad cryptocurrencies and theoretical protocols which have arrived after Bitcoin, some have
dedicated considerable eorts in order to analyze existing mechanisms or design new ones to
make sure miners will not have an incentive to foul-play and game the system for their advantage
[70, 78, 92, 111, 127].
Ethereum, in particular, is known for adopting changes rapidly, without always carefully exam-
ining them and the eect they might have on the incentives of miners [
103
,
104
]. Thus, changes
which were designed to mitigate one attack [14], open the door for multiple new ones [98, 126].
On the eve of the transition of Ethereum to a completely new mechanism, also known as
The Merge [
39
], we present a new incentive-driven attack on the current Ethereum mechanism.
Informally, the attack entails setting block timestamps to be relatively low, thereby increasing their
diculty and allowing them to replace previous blocks.
This attack is novel not only in that it relies on the new, unexplored foundations of timestamp
manipulations, but also because it is always more protable than following the “honest” rules laid
down by the protocol’s designers, meaning that our attack strategy strictly dominates the honest
strategy.
Previously, Ethereum miners were mostly known to manipulate Ethereum’s application layer,
for example by exploiting vulnerabilities in smart contracts, which are applications built on top of
blockchains [
17
], while attacks on the underlying consensus were either entirely theoretical yet
practically infeasible, or targeted small implementation bugs which were quickly xed [5, 126].
In our work, we introduce the rst consensus-level attack which is actually feasible to execute.
Additionally, we provide the rst proof that a consensus-level attack was performed in the wild.
Our Contributions. We make the following contributions:
We introduce a novel attack vector on proof-of-work (PoW) cryptocurrencies which relies
on timestamp manipulations, instead of traditional ones such as block withholding [
50
,
102
].
We provide a thorough description of a concrete attack called the riskless uncle maker (RUM)
attack which relies on this new attack technique.
We prove that the RUM attack is riskless in Ethereum in the sense that an attacker which
utilizes it is guaranteed to make at least the same absolute and relative prots when compared
to mining according to the honest protocol.
We describe multiple variants of the attack.
We investigate the Ethereum blockchain and prove the attack was executed in the wild, thus
providing the rst conclusive evidence of consensus tampering in a major cryptocurrency.
We have written a fully-functioning implementation of a variant of the attack as a patch for
geth, Ethereum’s most popular client.
We provide several techniques to mitigate the attack and its variants, including a patch for
geth which prevents the attack altogether.
A summary of our contributions is given in Table 1.
Paper structure. The paper is structured as follows: we begin by going over some implications
arising from our work in Section 2. Then, we review the relevant background information required
for this work in Section 3, and proceed to describe the paper’s model in Section 4. We utilize the
model to give an algorithmic description of the attack in Section 5, and then theoretically prove
Publication date: July 2022.
Uncle Maker: (Time)Stamping Out The Competition in Ethereum 3
Table 1. A comparison of our aack and previous ones.
Uncle Selsh Stubborn Coin Energy Stretch &
Maker Mining Mining Hopping Equilibria Squeeze
Analyzed on - -
Ethereum
Doesn’t require - -
block withholding
Always more
- - - - -protable than
mining honestly
Has a patch for - - - - -
Ethereum clients
that the attack is riskless and guaranteed to be more protable than mining honestly in Section 6.
We describe the ngerprints which a successful execution of the attack leaves on the blockchain
and prove that indeed such attacks have been performed in the wild in Section 7. We suggest
mitigations for the attack in Section 8. We review related works in Section 9, and nally conclude
in Section 10.
2 IMPLICATIONS
In this section, we would like to discuss some important implications arising from our work.
2.1 Reducing Mechanism Aack Surface
In Ethereum, miners have quite a lot of “wiggle-room” when setting timestamps. Users then partially
use their local clock in order to verify them, instead of using some consensus-achieved notion of
time.
We argue that when consensus mechanisms allows such user decisions, their attack surface
grows. One natural conclusion is to design mechanisms such that users have the bare minimum
of choice in setting certain parameters, like timestamps. If users have some choice, the protocol’s
designers must make sure that this choice has the minimal possible eect on the protocol’s safety.
Timestamps, in particular, aect the diculty of mining and thus the consensus mechanism. As
we will show in our paper, this allows miners to use timestamps which do not correspond to the
actual real-world time in order to gain an upper-hand over their competitors.
In spite of this, previous academic research has only made a cursory attempt at examining the
potential use of timestamp manipulations to attack the consensus layer of cryptocurrency systems
[13, 108, 126], focusing instead on the application layer [2, 17, 24, 84, 105].
2.2 Ethereum-like Mechanisms
In this work, we mainly focus on Ethereum. However, our work has major implications for any
mechanism which relies on timestamps in a similar manner.
Among the notable protocols that belong to this category we can list Ethereum Classic (which
has publicly committed to continue using the standard Ethereum-like PoW protocol “indenitely”
[
19
,
20
]) and EthereumPoW (a planned fork of Ethereum which is planned to go live when Ethereum
nally transitions to its new mechanism [42, 97]).
Publication date: July 2022.
4 Aviv Yaish, Gilad Stern, and Aviv Zohar
2.3 Traceable Safety
In this work, we used publicly available on-chain data to retroactively discover an attack on the
Ethereum blockchain, making this the rst such real-world consensus-level attack discovered on
a major cryptocurrency. This is in spite of previous works attempting to do so, even using very
sophisticated means such as setting up multiple nodes in various geographical locations, collecting
data and analyzing it [79, 80, 82].
These works have specically attempted to nd instances of block-withholding attacks, which
requires being online and nding out about the attacks as they happen. That is to say, block
withholding does not leave clear ngerprints in publicly available transcripts of the underlying
mechanisms, e.g. it is not immediately apparent from the actual blockchain. Thus, such attacks
cannot be retroactively traced using on-chain data.
We would like to crystallize the above insight into the following property:
Definition 1 (
A
-Traceability). Given a mechanism Πand attack on it
A
, we will say Πis
A
-traceable if the attack is detectable from the public transcript of Π, up to some negligible probability.
Mechanisms preferably should be designed to make sure there is a public record of potential
malfeasance; ideally, to allow post-fact identication of attacks, even those which the mechanism’s
creators haven’t conceived when designing the system. This can be compared to the traditional
cryptographic notion of public veriability, which allows actors to check the correctness of protocol
transcripts even after the fact, and even if they did not originally participate in the protocol. This is
in contrast to traditional distributed systems in which real-time participation is required in order
to attest to the validity of its execution at the time.
3 BACKGROUND
We will now briey go over the background knowledge required for understanding our work.
3.1 Proof-of-Work Cryptocurrencies
The mechanism utilized by both Ethereum and Bitcoin is called PoW. It requires entities called
miners to collect user-made transactions into blocks. As blocks are limited in capacity, users can
incentivize miners to prefer their transactions over competing ones by paying them transaction
fees [27, 76, 83, 101].
In order to create a block which will be considered valid under the PoW mechanism, miners
must expend tremendous computational resources to nd a solution to a cryptographic puzzle,
a process which is also called mining. The solution for the puzzle is dened to be an input to a
cryptographic hash function such that the corresponding output will be lower than some target
value. The currently known best method for nding such an input is to perform a brute-force
search [
26
,
69
,
112
]. Once this solution is found, it is included in the block and broadcasted to the
network, with each user validating the solution to ensure it is indeed correct.
In order to make sure that the diculty of the cryptographic puzzle is neither too easy for
the network nor does it exceed the computational resources of the network, cryptocurrencies
employ a diculty-adjustment algorithm (DAA) [
23
,
126
] which periodically attempts to gauge the
amount of computational resources currently available on the network and adjust mining diculty
accordingly.
3.2 Economics of Mining
To compensate miners for their eorts, the mechanism allocates a certain amount of tokens to the
creator of each valid block. These tokens are commonly called the block rewards. Cryptocurrencies
commonly pursue a notion of giving miners a fair share of the rewards, meaning that the fraction
Publication date: July 2022.
Uncle Maker: (Time)Stamping Out The Competition in Ethereum 5
of the all rewards which they earn should be equal to the fraction of computation which they
contribute to upholding the underlying mechanism [50, 92].
PoW cryptocurrencies are known for their unsteady revenue ow, leading miners to usually
team-up and form mining pools. Participants in the pool split prots among themselves using a
variety of schemes, often-times doing so according to each participant’s relative contribution to
the pool. This contribution is measured by counting the amount of shares which each user submits;
these are blocks which are below the protocol’s real diculty threshold, but above some inner one
set by the pool [58, 77, 100, 107].
3.3 Blockchains and Block-DAGs
In Bitcoin-esque cryptocurrencies, each block must reference at least one previous block, which
is called the block’s parent. Thus, a chain of blocks is formed, also known as a blockchain. The
rst and last blockchain blocks are usually respectively nicknamed the genesis and the tip of the
blockchain, while the currently mined block is commonly called the pending block.
As the blockchain contains all user-made transactions, it in essence provides some notion of
“history”. Thus, the entire network must agree on some specic history in order to facilitate money
transfers between users in a way which preserves the system’s integrity. A race or tie occurs if
there are multiple possible chains, e.g. when a miner hears of two blocks at the same time. Usually,
protocols dene a tie-breaking rule to pick between the dierent options. The chain which is picked
is referred to as the main-chain.
In Ethereum, blocks which are mined after a tie can pick, in addition to a parent, up to two uncle
blocks. Ethereum’s mechanism was designed to take such uncle blocks into consideration when
deciding on the network’s main-chain in the hopes that doing so would increase the mechanism’s
security [
78
]. The resulting structure is no longer a blockchain but rather a block directed-acyclic-
graph (block-DAG) [
78
,
109
]. Although Ethereum relies on uncle blocks and thus on a block directed-
acyclic-graph (block-DAG), for brevity we will refer to the resulting data structure as a block-chain.
3.4 Ethereum Clients
In order to participate in the Ethereum protocol, one must use an Ethereum client, meaning a
program which implements the protocol’s rules. The most popular client is Go Ethereum (geth)
[
38
,
40
,
43
,
73
], which is ocially endorsed by the Ethereum Foundation. Communication with
a local client and with other nodes is performed using a standardized protocol based on remote
procedure calls [121].
Additional Background. For more details on cryptocurrencies see [3, 7, 90, 120].
4 MODEL
We proceed to formally dene the model used in the paper.
4.1 Cryptocurrency System
We will begin our model description by giving precise denitions for Ethereum’s consensus and
reward mechanisms. All notations and acronyms used in this section (and throughout the paper)
are detailed in Appendix G.
Block-DAG Structure. In Ethereum, each block must reference a parent block, and can reference
up to two uncle blocks; these are blocks that share a common ancestor with it (up to a depth of
8blocks), but were not referenced by any main-chain block [
35
,
124
]. Uncles are also sometimes
called ommer blocks by the Ethereum Foundation [
124
]. An ommer is the equivalent gender-neutral
term for the same familial relation.
Publication date: July 2022.
6 Aviv Yaish, Gilad Stern, and Aviv Zohar
Block Timestamps. Ethereum blocks store timestamps in the UNIX time format, which measures
time by counting the number of seconds elapsed since January 1st, 1970 [
66
]. Timestamps are
saved as integer values and thus do not have a resolution of less than one second. Using these
timestamps, miners check the time that has passed between blocks and adjust mining diculty if
the time exceeds some predened window.
Ethereum enforces relatively strict requirements on timestamps compared to other cryptocur-
rencies: a newly heard-of block’s timestamp cannot be more than 15 seconds in the future when
compared to the local clock, and it must be at least one second after its parent’s timestamp
[29, 35, 124].
Mining Diculty. Ethereum’s diculty-adjustment algorithm (DAA) strives to keep a rate
of one block per 12
14 seconds [
31
,
54
,
124
]. It does so by lowering the diculty of the block
which is currently mined if too much time has passed, according to the block’s and its parent’s
timestamps. Ostensibly, the mechanism’s designers hoped that this would prevent long stretches of
time wherein no new block is mined. Unfortunately, as we will show, such DAAs are susceptible to
manipulations.
Formally, each block’s diculty depends on:
Its parent’s diculty, which we denote by𝑑.
The timestamp dierence from its parent, denoted as 𝑡.
If it references uncles or not: 𝑢def
= 1 i has uncles.
Using these, the diculty of the block is dened as the maximum between 2
17
and the following
term [32, 36, 124]:
𝑑+ max 1 + 𝑢 𝑡
9,99· 𝑑
2048(1)
For posterity, the diculty of the genesis block is 2
34
. As Ethereum’s diculty has skyrocketed
compared to 2
17
and was above 2
34
since block 15, meaning that the diculty was higher for at
least 15
·
10
6
blocks. Consequently, we use Eq. (1) as-is for conciseness. Additionally, to facilitate
Ethereum’s long-delayed migration to a new mechanism which does not rely on PoW, the DAA
increases diculty exponentially every 10
5
blocks [
103
,
104
]. This is irrelevant in our setting and
thus omitted.
Tie Breaking. In Ethereum, a block can have just a single parent. There might be cases where
multiple blocks can serve this role, for example if a miner sees multiple blocks at the same height.
In such a scenario, it can only choose one of those blocks as a parent for its currently mined block,
while the other blocks will be picked as uncles. We will term such events ties.
As mining diculty determines the amount of work invested in each block, Ethereum relies
on the notion of the total diculty (TD) of a block to break ties. The TD of a block is dened as
the simple sum of the diculties of the block itself and all of its main-chain ancestors [
34
]. In
case of ties between blocks, the one with a higher TD is chosen as the parent, and if blocks have
equal TDs miners will prefer the one they received earlier [
30
,
33
]. Ethereum’s mechanism is an
approximation of the one dened by [
78
] and is an attempt at incentivize publishing newly mined
blocks quickly, thus discouraging withholding them [15].
Mining Rewards. We denote the reward received for mining a main-chain block as
𝑅
ETH. The
miner of a block which references an uncle receives
1
32 𝑅
. The miner of the referenced uncle receives
a reward too, according to the depth of the most recent common shared ancestor of the two: if it
is two blocks deep, the uncle’s miner gets
7
8𝑅
. The reward diminishes by
1
8𝑅
for each increase in
depth, until reaching 0ETH [35, 103, 124].
Publication date: July 2022.
Uncle Maker: (Time)Stamping Out The Competition in Ethereum 7
Example 1 provides an example of a block-DAG which is structured according to the aforemen-
tioned consensus rules.
Example 1. We will now go over four blocks and use them to illustrate the various denitions given
in Section 4.1. These blocks and their relations are depicted visually in Fig. 1.
Parent
Uncle
Parent
Timestamp
32
Difficulty
4096
Reward
2.0625 ETH
Timestamp
27
Difficulty
Reward
1.75 ETH
Timestamp
26
Difficulty
Reward
2 ETH
Timestamp
0
Difficulty
Reward
2 ETH
Parent
Fig. 1. A graphical depiction of the blocks of Example 1.
Let block
𝑏0
be the parent of blocks
𝑏1
and
𝑢1
, and let block
𝑏2
point to
𝑏1
as its parent, and
𝑢1
as its
uncle. Let 𝑏0’s timestamp be 0,𝑏1’s timestamp be equal to 26,𝑢1’s timestamp be 27, and 𝑏2be 32.
If
𝑏0
has a diculty of 4096, then according to Eq. (1) the diculties of
𝑏1
and
𝑢1
should be 4094
and 4092, correspondingly. Consequently, according to the same equation 𝑏2’s diculty is 4096.
The standard block-reward for a main-chain Ethereum block which did not refer to uncles is 2ETH
[
124
], so the miners of
𝑏0
and
𝑏1
earned 2ETH each, while the miner of
𝑏2
earned 2ETH, plus
1
32 ·
2ETH
for referencing
𝑢1
as its uncle, making the total reward earned by the
𝑏2
’s miner 2
.
065 ETH. Because
𝑢1
is parallel to
𝑏2
’s parent, the reward earned by
𝑢1
’s miner is
7
8·
2ETH, which amounts to 1
.
75 ETH.
For an example of real Ethereum blocks which share the same relations as the blocks described here,
see Example 2.
4.2 Threat Model
We will now describe the actors that interact with the cryptocurrency and the range of actions
available for each one.
Actors. We model the network as being comprised of two parties, an honest miner who has a
total hash-rate of
𝐻
hashes-per-second, and an attacker that has a hash-rate of
𝐴
hashes-per-second.
We will call the attacker’s fraction of the total hash-rate as its hash-ratio, and dene it as follows:
𝛼def
=𝐴
𝐴+𝐻.
Note that the honest miner need not necessarily be a single entity, but can be a mining pool or
even a number of mining pools, though for the sake of brevity we will mostly refer to it as a single
miner. Similarly, the attacker can be a mining pool, or a coalition of mining pools.
Our attack and its analysis do not require looking at more than two consecutive blocks, which
according to historical data lasts an average of roughly 13 seconds (see Appendix F). Thus, we
follow the literature by assuming that miners cannot obtain or lose hash-power, no new miners
enter the network, mining hardware is bought by actors in advance, and all associated costs (such
as electricity) are prepaid [
50
,
59
,
67
,
102
,
110
,
131
133
]. Indeed, historical data shows that the total
hash-rate active on the network does not change by much over such short periods [9].
Attacker Objective. Ethereum, similarly to other cryptocurrencies, has a notion of fairness
which stipulates that in expectation a miner with a
𝛾
fraction of the hash-rate should mine
𝛾
of the
blocks and obtain a 𝛾fraction of all mining rewards [50, 92, 124].
Our attacker’s objective will be to mine more than its fair share of the blocks, e.g. more than
𝛼
of the blocks. As we will show, this will increase its rewards to be above the fair amount, too.
Publication date: July 2022.
8 Aviv Yaish, Gilad Stern, and Aviv Zohar
Honest Mining. We dene the honest mining protocol similarly to other blockchain papers
[
50
,
59
,
110
,
126
,
127
]: our honest miner follows the rules laid down in Ethereum’s yellow paper
[
124
]. Thus, the honest miner will always mine on top of the block with highest TD, and will not
withhold blocks or manipulate block timestamps.
Allowed Attacker Deviations. Our attacker can rationally deviate from the honest protocol,
as long as blocks it produces are indeed valid according to Ethereum’s consensus rules [
35
,
124
].
Specically, the attacker is free to manipulate the timestamps of blocks that it mines to be within
the valid range dened in Section 4.1, and can mine on top whichever block it chooses. In order to
create a clean separation between our attack and the previous literature [
3
,
12
,
50
,
59
,
102
,
133
], we
limit our attacker by forbidding it from withholding blocks.
5 THE UNCLE MAKER ATTACK
We will now describe our attack. Conceptually, the attack manipulates Ethereum’s DAA to create
blocks which retroactively replace existing main-chain blocks, thus increasing an attacker’s share
of main-chain blocks beyond its fair share. Honest blocks that were “sidelined” in this manner can
later be referred to by main-chain blocks as uncles, thus we will term blocks created by our attacker
as Uncle Makers.
A major novelty of our attack is that it replaces blocks without using block withholding, which
is the common method used in the literature [50, 59, 67, 131–133].
Recall that in case of ties between dierent chains, Ethereum’s protocol dictates that the one with
a higher TD is picked as the main chain. As Ethereum’s DAA assigns mining diculty according
to a block’s timestamp, an attacker can set the timestamp for the currently mined block to be low
enough to win in case of ties, whether as a preemptive defense mechanism, or to actively replace
existing main-chain blocks. Unfortunately, as the block has a higher diculty, it is harder to mine.
We will soon show that this can be avoided.
5.1 Riskless Uncle Making
By carefully picking when to execute the attack, we can make sure that the attacker’s blocks will
have a higher diculty when compared to the current tip of the blockchain, and thus will replace
it, but still will not have a higher diculty compared to the block which the attacker would’ve
mined had it been following the honest protocol.
By doing so, we will allow our attacker to execute the attack without incurring any additional
mining “risk” when compared to mining honestly: the probability that mining the attack block will
succeed will be at least the probability of the attacker successfully mining an honest block, while
the attacker’s share of the rewards will be higher than its fair portion. We call this attack a riskless
uncle maker (RUM) attack.
Let the tip of the blockchain be block
𝑏1
with a
𝑡1
time dierence relative to its parent
𝑏0
, and
denote the number of seconds that have passed since
𝑏1
’s timestamp by
𝑡𝐻
. According to the
honest protocol, the honest miner mines a block, which we will denote by
𝑏𝐻
, and sets the block’s
parent to be
𝑏1
, and its timestamp dierence to be
𝑡𝐻
. See Fig. 2 for a graphical depiction of the
aforementioned blockchain state.
If
𝑡1[9,18)
, then as long as the honest miners still haven’t successfully mined a block and
𝑡𝐻<
9, an attacker who wishes to execute the RUM attack should mine a block on top of
𝑏0
, and
set the block’s time dierence to be some value strictly lower than 9seconds, for example
𝑡𝐴
def
=
8
seconds. If the attacker succeeds in mining this block in time, it should be published immediately.
In any other case, the attacker should mine according to the honest protocol.
Publication date: July 2022.
Uncle Maker: (Time)Stamping Out The Competition in Ethereum 9
Parent
Parent
Parent
Fig. 2. The blockchain’s state when executing a
RUM aack.
Parent
Parent
Uncle
Parent
Fig. 3. The blockchain’s state aer a successful
RUM aack.
Observe that the time we picked for
𝑡𝐴
increases
𝑏𝐴
’s diculty compared to
𝑏1
. Due to Ethereum’s
tie-breaking mechanism, if it is indeed mined successfully, it will take 𝑏1’s place as the new tip of
the main-chain. Thus, the honest miner will pick
𝑏𝐴
as the parent of its currently mined block, and
𝑏1as its uncle, leading the current blockchain state to be as depicted in Fig. 3.
Note that our attack replaced an honest main-chain block with an attacker block without relying
on withholding blocks. Instead, the attack actually requires the attacker to immediately publish its
blocks, standing in stark contrast to other attacks which rely on withholding blocks.
An algorithmic description of the attack is presented in Algorithm 1. The algorithm follows the
event-driven model which was used by other works in the eld, such as [50, 52].
6 THEORETICAL ANALYSIS
We will now theoretically analyze the RUM attack using a series of theorems, relegating all proofs
to Appendix D. Afterwards, we will analyze the block and reward share of an attacker which
executes the attack using a Markov decision process (MDP), similarly to other works in the eld
[50, 59, 63, 67, 102, 126, 132, 133].
In Theorem 1 we prove that the conditions specied in Section 5 for executing a RUM attack are
necessary, and that an attacker’s probability of successfully mining the attack block is equal to the
that of successfully mining an honest block.
Theorem 1. Let the current tip of the main-chain be block
𝑏1
. Denote its parent as
𝑏0
, the parent’s
diculty as
𝑑0
, the timestamp dierence between them as
𝑡1
, and the dierence between the current
time and 𝑏1’s timestamp as 𝑡𝐻.
If the following conditions hold, then a rational attacker can execute a RUM attack:
𝑡𝐻
9= 0,𝑡1
9= 1
Moreso, if 𝑑0222, these are the only values for which a RUM attack is possible.
Remark 1. Any node active on the network, for example our attacker, can learn the values of
𝑡1
and
𝑡𝐻.
The former,
𝑡1
, is publicly available on the blockchain, as valid blocks must include their timestamps
[
124
]. The latter,
𝑡𝐻
, can be obtained by sending a standard Ethereum remote procedure call (RPC)
request to the honest miner, as responses contain the local time of the responder.
The proof is detailed in full in Appendix D. Briey, we break the attack down to its dierent
constituents: the blocks generated by the attacker should be valid according to the system’s
consensus rules, the attacker should successfully replace honest blocks with the attacker’s blocks,
Publication date: July 2022.
10 Aviv Yaish, Gilad Stern, and Aviv Zohar
and mining these blocks should be riskless, meaning that it should not be harder when compared
to mining honestly. Each constituent is handled via a series of claims which are then combined,
culminating with Theorem 1.
The proof of Theorem 1 shows that if the last block’s diculty is lower than 2
22
, an attacker
might have additional timeframes within which an attack is feasible. Remark 2 elaborates on this.
Remark 2. Although a diculty of 2
22
is permitted by Ethereum’s DAA, which places the lower
diculty limit at 2
17
, no block has ever had such a diculty, the closest being block number 6, which
has a diculty of 232.
We proceed to show in Theorem 2 that an attacker’s relative share of mainchain blocks exceeds
the fair share that can be obtained honestly.
Theorem 2. Let there be some block
𝑏0
. If the attacker uses the RUM mining strategy, its expected
relative share of main-chain blocks will be larger than mining honestly, while the absolute number
will remain the same.
As before, the proof is given in Appendix D. The proof relies on analyzing a MDP of the attack,
which we describe in Appendix D.3.
In Theorem 3 we prove the corresponding claim regarding an attacker’s share of the rewards.
Theorem 3. For any block
𝑏0
, an attacker can increase its expected absolute and relative rewards by
using the RUM mining strategy instead of mining honestly.
The proof for Theorem 3 is similar to that of Theorem 2. Again, it is given in full in Appendix D.
Corollary 1. As Theorems 2 and 3 show, both the relative and absolute share of blocks and rewards
obtained by the attacker are higher when compared to mining honestly, thus a direct consequence
is that the relative and absolute share of honest miners are lower, meaning that the attack not only
benets the attacker, but also harms its competitors.
As Theorem 1 shows, the attack is riskless, meaning that the probability of successfully mining an
attack block is equal to that of mining an honest block. By combining all of these results, one can
obtain that the RUM mining strategy dominates the honest one.
7 IN SEARCH OF LOST TIME: UNCLE MAKING IN THE WILD
We will now attempt to give a conclusive answer to a long-standing question: do miners attack the
consensus layer of major cryptocurrencies? The surprising answer is a resounding yes!
To reach this armative answer, we crawled Ethereum’s blockchain using a standard Ethereum
full node and collected relevant data for all main-chain and uncle blocks starting from block
15
,
226
,
042, down to 12
,
000
,
000. All the data we collected, and the code used to collect this data
and generate all the graphs presented in this section are provided in Appendix F.
Most previous works usually only attempted to nd evidence for block withholding attacks,
and have tried doing so by planting many nodes throughout the network, collecting data and
then analyzing it using various statistical methods. On the other hand, we show that the evidence
proving that miners attack the consensus layer is hiding in plain sight and can be obtained using a
single node and closely inspecting publicly available on-chain data. We cover these related works
and provide a more in-depth comparison with the current paper in Section 9.
7.1 Ethereum Mining Pools
Using the previously mentioned data, we identied Ethermine as the largest mining pool currently
active in Ethereum, consistently mining at least 22% of all main-chain blocks, more than any other
mining pool in the past 3years.
Publication date: July 2022.
Uncle Maker: (Time)Stamping Out The Competition in Ethereum 11
According to our analysis, the second largest mining pool for the same time-frame is F2Pool,
which roughly amounts to about half as many main-chain blocks as Ethermine. Notably, F2Pool
has a considerable amount of hash-rate active on other cryptocurrencies, such as Bitcoin [
82
]. The
pool’s founder has made a relatively well publicized condemnation of competing mining pools,
blaming them for attacking his own mining pool, but without providing any concrete proof [
114
].
This is in stark contrast to the evidence that we uncover in this work which shows that, in fact,
F2Pool are attacking other mining pools.
7.2 Identifying Uncle Maker Aacks
Before we examine real-world data, we would like to rst crystallize a few insights which will
allow us to identify uncle maker-esque attacks.
Miners that execute uncle maker attacks should have a higher than expected main-
chain block share and lower than expected uncle block share. Recall that the RUM attack
allows an attacker to replace main-chain blocks mined by other miners with a block of its own.
Thus, it follows that miners which perform the attack will have fewer uncles and more main-chain
blocks when compared to honest miners.
Uncle maker attacks can be observed from block timestamps. As our attack relies on
manipulating block timestamps, one can attempt to uncover blocks which were created as part of
such an attack by carefully analyzing the timestamps of historical Ethereum blocks.
By denition, the RUM attack requires an attacker to falsely set block timestamps to be earlier
than they are. Thus, it is reasonable to expect that main-chain blocks created by an attacker will
have an over-representation of low timestamp dierences relative to their parents.
In comparison, timestamp dierences between honest blocks and their parents should be dis-
tributed according to the exponential distribution [
8
,
13
,
49
,
50
,
106
,
109
], with a slight under-
representation of low timestamp dierences due to propagation delay in the network [57, 72].
Miners usually use a publicly identiable coinbase address. In order for a miner to receive
the rewards for the blocks that it mines, the miner must include an address to transfer the reward
to within a mined block, also called a coinbase address. Large mining pools commonly use a specic
address for their block-rewards and advertise it, in the hopes it might attract new participants or
help assert “political” control over the mined cryptocurrency [57].
In spite of this, there is no mechanism in place to force mining pools to stick to a single address
throughout their lifespan, and pools are free to change their address to a new secret one at will.
For example, mining pools might do so when executing an attack, in order to cover their tracks.
Still, it is common for works in the eld to assume that mining pools do identify themselves in a
truthful manner [
57
,
72
,
91
,
107
,
119
,
129
]. Indeed, a large percentage of all Ethereum blocks belong
to miners who identify their addresses using sites such as [44, 88].
7.3 Block Shares
We will now attempt to apply our previous insights to real-world Ethereum data, starting with the
main-chain and uncle shares of the 4largest mining pools in Ethereum, given in Fig. 4 and Fig. 5,
respectively. Note that these top 4pools have mined a combined share of more than 50% of both
main-chain and uncle blocks.
Previous works have shown that larger pools such as Ethermine have a “size-advantage” leading
them to win in cases of ties more often when compared to smaller pool like F2Pool. This leads them
to having a higher share of main-chain blocks and a lower share of uncle blocks when compared to
smaller mining pools, solely due to having more computational resources at their behest [79, 82].
Publication date: July 2022.
12 Aviv Yaish, Gilad Stern, and Aviv Zohar
Ethermine
25%
F2Pool
13%
0x5a...4c
10%
Hiveon
8%
Others
43%
Fig. 4. The 4largest mining pools’ share of main-
chain blocks.
Ethermine
17%
Nanopool
15%
0x5a...4c
10%
F2Pool
9%
Others
49%
Fig. 5. The 4largest mining pools’ share of uncle
blocks.
By comparing Figs. 4 and 5, it is apparent that F2Pool has considerably fewer uncles than
is expected for a mining pool of their size: Ethermine and 0
𝑥
5
𝑎 . . .
4
𝑐
maintain their respective
positions with regards to both mainchain blocks and uncles, with Ethermine having the largest
share of both, and 0
𝑥
5
𝑎 . . .
4
𝑐
having the third largest share. On the other hand, F2Pool has the
second largest share of mainchain blocks, but drops to the fourth place when it comes to uncle
blocks.
A metric which is commonly used to compare mining pools is the uncle rate, dened per-miner
as the ratio between the number of uncles which the miner has mined for some time period, and the
total amount of blocks of all kinds (uncle and main-chain) it mined during the same period. A lower
rate is better due to main-chain blocks receiving a higher block-reward and earning the fees for all
transactions contained within them. Fig. 7 depicts this metric over time for both Ethermine and
F2Pool. Although both were relatively comparable in the year between July 2019 and September
2020, F2Pool took the lead starting in October 2020.
One could argue that F2Pool might have achieved this feat by investing in good network connec-
tivity to other nodes, thus propagating its blocks faster, leading its blocks to win ties by virtue of
arriving to peers earlier. Indeed, at the end of October 2020, roughly when F2Pool’s uncle rate has
started improving, a company called bloXroute has published a blog-post describing how it helped
reduce F2Pool’s uncle rate by improving it’s networking layer [18].
In order to rule out this possibility, we will now turn to analyzing the timestamps of blocks over
this period.
7.4 Block Timestamps
Recall that according to Ethereum’s documentation [
31
,
54
,
124
], the target time-dierence between
the mining of two blocks is 12
14 seconds. Indeed, the average time dierence between mainchain
blocks and their parents is 13
.
45 seconds, with the same comparison between uncle blocks and
their parents yielding another reasonable average of 13.81 seconds.
The average dierence might obscure more minute details, leading us to plot a histogram of the
timestamp dierences between main-chain blocks and their parents in Fig. 8, and between uncles
and their parents in Fig. 9. Both histograms were truncated at 18 seconds to maintain readability.
Publication date: July 2022.
Uncle Maker: (Time)Stamping Out The Competition in Ethereum 13
Jul '19 Dec '19 May '20 Oct '20 Apr '21 Sep '21
Date
0
500
1000
1500
2000
2500
3000
3500
4000
Amount of blocks with timestamp diff. divisible by 9
Ethermine
F2Pool
0x99...e3
Fig. 6. The monthly amount of main-chain blocks
with a timestamp dierence from their parent
which is divisible by 9. Note that both F2Pool
and 0
𝑥
99
. . . 𝑒
3stop mining such blocks starting
October ’20, while Ethermine continues doing so.
Jul '19 Dec '19 May '20 Oct '20 Apr '21 Sep '21
Date
3%
4%
5%
6%
Monthly uncle rate
Ethermine
F2Pool
0x99...e3
Fig. 7. The monthly uncle rate for Ethermine,
F2Pool and 0
𝑥
99
. . . 𝑒
3, defined per-miner as the
ratio between the number of uncle blocks it mined
in some month and the total amount of blocks it
mined that month.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Timestamp difference from parent, in seconds
0
25000
50000
75000
100000
125000
150000
175000
200000
Number of blocks
Fig. 8. Total number of main-chain blocks with
a given timestamp dierence from their parent,
since block 12,000,000.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Timestamp difference from parent, in seconds
0
2000
4000
6000
8000
10000
Number of uncles
Fig. 9. Total number of uncle blocks with a given
timestamp dierence from their parent, since
block 12,000,000.
Fig. 9 looks precisely as predicted in Section 7.2 with regards to the honest scenario: it has a slight
under-representation at the 1second mark, and its trend seems to t the expected exponential
distribution.
On the other hand, Fig. 8 has quite a sizable under-representation of timestamp dierences which
are divisible by 9, and an over-representation at seconds 8and 17. This seems to match the expected
ngerprint of an uncle maker-style attack.
7.5 Catching F2Pool Red-handed
In order to get to the bottom of the anomalies we observed so far, we created more detailed
histograms which separate blocks according to the identity of their miner. Specically, in Fig. 10
we plot the per-miner histogram for the timestamp dierence between main-chain blocks and their
parents, and in Fig. 11 we do the same for uncles.
Figs. 10 and 11 explain the reason for F2Pool’s advantage very clearly: F2Pool did not mine even
a single main-chain block or uncle with a timestamp dierence which is divisible by 9since block
Publication date: July 2022.
14 Aviv Yaish, Gilad Stern, and Aviv Zohar
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Timestamp difference from parent, in seconds
0
10000
20000
30000
40000
50000
Number of blocks
Miners
Ethermine
F2Pool
0x5a...4c
Hiveon
Fig. 10. Number of main-chain blocks with a
given timestamp dierence from their parent,
separated by mining pool, for the 4largest min-
ing pools. Note that F2Pool has no blocks with
timestamp dierences divisible by 9, and an over-
representation for a dierence of 8seconds.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Timestamp difference from parent, in seconds
0
500
1000
1500
2000
Number of uncles
Miners
Ethermine
F2Pool
Hiveon
0x5a...4c
Fig. 11. Number of uncle blocks with a given
timestamp dierence from their parent, sepa-
rated by mining pool, for the 4largest mining
pools. Note that pools except F2Pool have an over-
representation of blocks with timestamp dier-
ences divisible by 9, due to F2Pool’s aack.
11
,
064
,
754, which was mined almost two years ago. Whenever the honest timestamp dierence
should have been 9seconds, they instead have falsely set it to be 8, as required to execute an uncle
maker attack. We provide an example of a suspected uncle maker block by F2Pool in Example 2.
Fig. 11 shows that F2Pool’s foolhardy behavior harms other mining pools, as can be deduced by
looking at the larger-than-expected number of uncles with a timestamp dierence of 9seconds
mined by Ethermine, Hiveon and an unnamed pool which uses the address 0
𝑥
5
𝑎 . . .
4
𝑐
. This is
due to F2Pool using a timestamp manipulation tactic which precisely targets this time dierence
window, while they mine honestly at all other windows.
7.6 F2Pool’s Aack is not Riskless
We proved in Section 6 that in order for an uncle maker attack to be riskless, very specic conditions
must hold. These conditions preclude the possibility of executing a riskless attack in certain time
windows, for example if the time since the last valid block was observed is at least 18 seconds. Yet,
as Fig. 12 shows, F2Pool do not shy from executing uncle maker-style attacks even at later periods
but only for time dierences which are divisible by 9, leading us to believe they employ a variant
of the attack.
7.6.1 Risky Uncle Maker Aack. One possibility is that F2Pool executes the attack if the expected
prot from it is higher when compared to mining honestly, even if it incurs additional risk. E.g. even
if the probability of mining the attack block is lower than the probability of mining an honest one.
Due to this, we call this variant the risky uncle maker attack.
Such a risky uncle maker attack can be protable in expectation under certain scenarios, for
example if another miner “snatched” transactions which pay exuberantly high fees and included
them in its block before the attacker, or if the attacker has a suciently high hash-rate and good
network connectivity.
7.6.2 Preemptive Uncle Maker Aack. Another option is that F2Pool, instead of actively trying to
replace existing blocks, actually attempts to preemptively assure their blocks will win in case of
ties by setting block timestamps to be within an earlier 9second window when compared to the
honest timestamps. This increases mining diculty and makes sure their blocks have a higher TD,
Publication date: July 2022.
Uncle Maker: (Time)Stamping Out The Competition in Ethereum 15
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
Timestamp difference from parent, in seconds
0
5000
10000
15000
20000
25000
30000
Number of blocks mined by F2Pool
Fig. 12. Number of main-chain blocks mined
solely by the F2Pool mining pool, with a given
timestamp dierence from their parent, since
block 12,000,000.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Timestamp difference from parent, in seconds
0
5000
10000
15000
20000
25000
30000
Number of blocks
Miners
F2Pool
0x99...e3
0xbc...8e
0xf2...04
Fig. 13. Number of main-chain with a given times-
tamp dierence from their parent, separated by
mining pool, for mining pools suspected to ma-
nipulate timestamps.
meaning that their blocks will be picked as main-chain blocks over competing honest blocks. We
term this variant of the attack as a preemptive uncle maker attack.
This type of attacks allows miners not to waste computation resources by mining on top of a tip
that has been made “stale” by another block mined on top of it, but which has not been received yet.
If that is the case, attackers setting their clock to a second earlier can be assured that their mined
block will replace any block honestly mined in specic time intervals, which might be disseminated
through the network currently, but hasn’t reached the attackers yet.
7.6.3 RUM is Hard to Implement. Lastly, we would like to raise the possibility that F2Pool chose
to implement the attack which we observe in the wild simply because it was easier to implement
than any other attack, including RUM. In fact, we implemented an arguably less outrageously
apparent variant of the observed attack as a patch for geth. In this patch we set geth’s clock to be
late by exactly one second. This achieves the same eect as F2Pool’s attack, while producing a
more natural-looking timestamp dierence curve. We provide additional details in Appendix F.
7.7 Other Aackers
Although F2Pool is the largest mining pool which is currently engaging in uncle maker-esque
attacks, it is not the only one; Fig. 13 shows the timestamp histogram of three additional miners
which use the same exact attack, meaning that they abstain from using timestamp dierences
which are divisible by 9.
The second largest such attacker after F2Pool is 0
𝑥
99
. . . 𝑒
3. This miner did not have a name in
Etherscan’s database, and thus we will call it Sneezy. Sneezy’s histogram spikes at the 8seconds
mark to be almost twice as high than the corresponding bin at the 1second mark, while F2Pool’s
8second bin is only roughly 20% taller, suggesting that Sneezy executes the attack over longer
periods of time.
Indeed, as Fig. 7 shows, this aggressive attack is worthwhile, and has decreased Sneezy’s uncle
rate considerably, even moreso than it has beneted F2Pool. Fig. 6 shows the monthly amount
of blocks with a timestamp dierence which is divisible by 9for Ethermine, F2Pool and Sneezy.
While Ethermine’s graph looks relatively uneventful, F2Pool’s and Sneezy’s drop to 0at almost the
same time. A closer inspection of the blockchain reveals that Sneezy started the attack at block
11,080,310, meaning slightly more than two days after F2Pool.
Publication date: July 2022.
16 Aviv Yaish, Gilad Stern, and Aviv Zohar
8 MITIGATION
We will now go over mitigation techniques that arise from the previously discussed results. It is
well known that cryptocurrencies are leary of making changes to their consensus mechanisms,
oftentimes forking the blockchain and thus creating two communities, one which abides to the
previous consensus rules and rejects the change, and another which adopts it [
71
,
74
]. Thus, we
would like to focus on solutions which are reasonable in scope, e.g. similar to previously adopted
Ethereum improvement proposals (EIPs) [37].
8.1 Minimize aacker flexibility by increasing the minimal diiculty
In the proofs given in Section 6, we have shown that if the minimal diculty is strictly less than
2048
2
, then an attacker could execute a riskless attack in less restrictive conditions than those
described in Theorem 1.
As we have mentioned in the same section, mining diculty did not come close to such a
diculty in the seven years since Ethereum was launched, but the x is worthwhile for any small
cryptocurrency which is based on Ethereum’s mechanism and might reach such low levels of
mining diculty.
The above mitigation was implemented in Appendix F.
8.2 Reject competing chains more aggressively
The RUM attack and the variants which we observe in the wild can be mitigated completely by
rejecting competing chains in a more aggressive manner.
More concretely, denote the tip of the competing chain by
𝑏
and of the local chain by
𝑏
. A miner
should reject it if all of the following conditions hold:
(1) If 𝑏and 𝑏share a parent
(2) If 𝑏has at least the same number of uncles as 𝑏
(3) If the timestamp of 𝑏is less than the miner’s local clock by one second or more
If at least one of these conditions do not hold, the miner should adhere to Ethereum’s existing
protocols.
Notice that an attack block for either RUM or the variant which we observe in the wild must
fulll all of these conditions, thus if all honest miners would reject competing chains based on this
criteria, the attack will be prevented.
We would like to mention that the third condition is actually not as strict as it appears. Accord-
ing to [
72
], 85% of blocks are propagated in less than 100 milliseconds, while in recent history
propagation time did not exceed 650 milliseconds [6, 10, 48].
Additionally, although this mitigation is similar to already existing Ethereum consensus rules
which use a node’s local clock to reject blocks in some cases, we emphasize that such considerations
might open the door for various attacks. Specically, we have not analyzed the implications of this
mitigation with regards to any other attack besides the RUM attacks and the variations which we
have covered in this work.
We have implemented this mitigation in Appendix F.
8.3 Migrate to Other Mechanisms
An obvious mitigation technique which will solve both this attack, and any other PoW-related one,
is to migrate Ethereum’s consensus mechanism to proof-of-stake (PoS). This transition, which is also
called The Merge [
39
], is scheduled to happen by the end of 2022 (though it has been scheduled to
happen since 2017 and has been postponed multiple times by now [
16
]). Alternatively, it is possible
Publication date: July 2022.
Uncle Maker: (Time)Stamping Out The Competition in Ethereum 17
to other protocols with theoretical guarantees, like [
56
,
92
], and even [
109
], which Ethereum’s
current mechanism is based on.
Other solutions which might be smaller in scope and thus easier to implement are to adopt better
fork-choosing rules [
130
,
131
], use reliable timestamps [
1
,
4
,
28
,
75
] or avoid using timestamps for
diculty adjustments altogether [108].
9 RELATED WORK
We will now review the major related works of the eld and compare these to our paper, when
appropriate. A summary is provided in Table 1. Additionally, in order to paint a complete picture
of the current research landscape, we surveyed a few additional related papers in Appendix E.
Withholding Attacks. Most consensus-level attacks rely on block withholding and on an
attacker’s ability to both immediately hear about new blocks, and broadcast withheld blocks to
some fraction of the network before this fraction hears of these new blocks. Usually, such attacks
theoretically allow miners to increase expected prots, although they do have a non-zero probability
of failing and causing a loss. As far as we know, there is currently no software in place to facilitate
this attack.
In contrast, we do not require such assumptions, instead relying on an attacker’s ability to
manipulate timestamps. This is indeed feasible, as seen in our empirical evaluation and by the geth
patch we provide which implements the attack.
Examples of such attacks include the celebrated Selsh Mining attack [
50
], which increases an
attacker’s share of the blocks beyond its share of the mining power. This is achieved by mining
blocks and withholding them. Withheld blocks are published in a manner which discards blocks
mined by honest parties. Variants of the attack were further explored in Bitcoin by [
23
,
59
,
102
]
and in Ethereum by [
52
,
61
,
62
,
98
]. A notable extension of selsh mining is the Stubborn Mining
attack, in which attackers continue mining on selsh forks even if these trail behind the honest
chain [81, 91, 122].
As both selsh and stubborn mining are not proven to be optimal mining strategies, several works
have attempted creating general frameworks for mining attacks which rely on block withholding,
such as [
67
,
131
133
], which employ machine learning (ML) techniques to recreate classic results
and derive new ones. These have the same pitfalls as the selsh-mining papers.
Manipulating DAAs Without Withholding Blocks or Manipulating Timestamps. A
strand of research focused on directly manipulating DAAs to increase mining prots, thus avoiding
block withholding. All such attacks are not currently known to be implemented in software. In
contrast, our attack can be executed by applying a simple software patch.
For example, in Coin Hopping attacks miners “hop” between cryptocurrencies and mine the one
which is currently the most protable [
86
]. Certain DAAs are susceptible to cyclical mining dicul-
ties, which can be exploited by miners that join when the diculty is low and leave when it is high
[
123
]. These attacks assume miners can indeed “hop” between mining dierent cryptocurrencies in
a minute’s notice and xed exchange-rates between the attacked cryptocurrencies, but these are
known to be extremely volatile and do not always move in unison [68, 127].
Similarly but in the scope of just a single cryptocurrency, Energy Equilibria attacks show that
Bitcoin miners can both minimize operational costs and manipulate mining diculty to increase
the average amount of rewards per unit of time by repeatedly turning their mining hardware on
and o, but the protability of this mining strategy for a specic miner depends on the fraction of
mining expenses which it dedicates to electricity and whether this electricity is bought in advance
or not [53, 60].
Publication date: July 2022.
18 Aviv Yaish, Gilad Stern, and Aviv Zohar
On the other hand, the Stretch & Squeeze attack presented in [
126
] focuses on increasing and
decreasing Bitcoin’s and Ethereum’s block-rates, and then using this to create interest-rate arbitrage
between decentralized nance (DeFi) lending platforms, which can be exploited to make a prot
by taking a large collateralized loan from one platform and depositing it in another. The market’s
response to such an attack has not been explored, and it is reasonable to assume that such arbitrage
will be closed by other players, thus voiding potential gains from being made.
Timestamp Attacks. In Ethereum, timestamps have been mostly used to attack smart contracts
[
17
]. An exception is the Stretch & Squeeze paper [
126
], that found two timestamp weaknesses
in geth’s code. The rst is a simple bug that was quickly xed. The second weakness is inherent
to Ethereum’s consensus and still remains; it allows miners to intentionally mine uncles with a
diculty which is lower by 5% compared to the honest one. This can be used to increase mining
diculty and slow-down the blockrate, but was not included in the analysis performed in the paper.
The Diculty Raising attack presented by [
5
] is an attack on Bitcoin’s DAA. Similarly to our
attack, it relies on manipulating timestamps in order to increase mining diculty and replace
existing blocks. In contrast, it focuses on Bitcoin, and as claimed by the work, the attack is infeasible
and entirely theoretical. A framework for Bitcoin that allows deriving conditions which eliminate
the theoretical possibility of such an attack is analyzed in [56].
Real-world Evidence of Attacks. Many have wondered why selsh mining and related attacks
are not observed in the wild [
67
,
91
], with one glaring reason being the lack of concrete software
implementations to facilitate such attacks [
116
]. Some previous works relied on statistical methods
to detect abnormalities such as a large amount of blocks consecutively mined by a single miner,
or a high number of forks, but have not found any conclusive evidence of a major attack [
79
,
80
],
while [
82
] found that one Bitcoin mining pool performs coin-hopping, specically between Bitcoin
and Bitcoin Cash, the latter of which is a fork of Bitcoin [74].
Two exceptions are [
82
,
126
]. The former used data from Ethereum nodes to compare block
timestamps with the actual block arrival times, and has concluded that the two are roughly similar.
The latter claims that the last three years of Ethereum blocks do not bear the mark of timestamp
manipulations, and has done so by looking at basic metrics such as the mean and median dierences
between blocks and their direct ancestors, which indeed are not indicative of any apparent manip-
ulation. As we’ve shown, by looking at the histogram of timestamp dierences, it becomes clear
that, in fact, miners disregard the honest protocol and set timestamps to gain an unfair advantage.
10 CONCLUSIONS
In this work, we have presented a novel attack on Ethereum’s consensus mechanism and multiple
variations on it, including an implementation of one such variation as a patch for geth, Ethereum’s
most popular client.
We have analyzed this attack and have proved that miners can execute it in a risk-less manner,
thereby increasing both their relative share of blocks and their absolute and relative share of block
rewards.
We have shown that this attack has been executed by Ethereum’s second largest mining pool,
F2Pool, for over two years, thereby nding the rst-ever proof of an attack on the consensus
mechanism of a major cryptocurrency.
Finally, we have suggested concrete mitigation techniques which can be quickly implemented
until Ethereum’s migration to PoS is nalized.
Publication date: July 2022.
Uncle Maker: (Time)Stamping Out The Competition in Ethereum 19
AVAILABILITY
To maintain anonymity, all code and data used in this paper were uploaded to a Google Drive
account which was opened under the pseudonym Uncle Maker. This account can be accessed using
the following link.
Details about our data sources, installation and usage instructions are provided in Appendix F.
ACKNOWLEDGMENTS
The authors are partially supported by grants from the Ministry of Science & Technology, Israel, the
Israel Science Foundation (grants 1504/17 & 1443/21) and by a grant from the Hebrew University of
Jerusalem, Israel (HUJI) Federmann Cyber Security Research Center in conjunction with the Israel
National Cyber Directorate.
REFERENCES
[1]
Aydin Abadi, Michele Ciampi, Aggelos Kiayias, and Vassilis Zikas. 2020. Timed Signatures and Zero-Knowledge
Proofs—Timestamping in the Blockchain Era—. In International Conference on Applied Cryptography and Network
Security (2020). Springer, Springer International Publishing, 335–354. https://doi.org/10.1007/978-3-030-57808-4_17
[2]
Nicola Atzei, Massimo Bartoletti, and Tiziana Cimoli. 2017. A Survey of Attacks on Ethereum Smart Contracts (SoK).
In Principles of Security and Trust, Matteo Maei and Mark Ryan (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg,
164–186.
[3]
Sarah Azouvi and Alexander Hicks. 2020. SoK: Tools for Game Theoretic Models of Security for Cryptocurrencies.
https://doi.org/10.21428/58320208.8e7f4fab arXiv:1905.08595 [cs.CR]
[4]
Christian Badertscher, Peter Gazi, Aggelos Kiayias, Alexander Russell, and Vassilis Zikas. 2019. Ouroboros Chronos:
Permissionless Clock Synchronization via Proof-of-Stake. IACR Cryptol. ePrint Arch. 2019 (2019), 838. https:
//eprint.iacr.org/2019/838
[5]
Lear Bahack. 2013. Theoretical Bitcoin Attacks with less than Half of the Computational Power (draft). https:
//doi.org/10.48550/ARXIV.1312.7013
[6] BDN. 2022. Blockchain Distribution Network. https://www.bdn-explorer.com/
[7]
Matthew Bernhard, Andrea Bracciali, Lewis Gudgeon, Thomas Haines, Ariah Klages-Mundt, Shiníchiro Matsuo,
Daniel Perez, Massimiliano Sala, and Sam Werner. 2021. SoK: Algorithmic Incentive Manipulation Attacks on
Permissionless PoW Cryptocurrencies. In Financial Cryptography and Data Security. FC 2021 International Workshops
- CoDecFin, DeFi, VOTING, and WTSC, Virtual Event, March 5, 2021, Revised Selected Papers (Lecture Notes in Computer
Science, Vol. 12676). Springer, 507–532. https://doi.org/10.1007/978-3- 662-63958-0
[8]
George Bissias and Brian N Levine. 2020. Bobtail: Improved Blockchain Security with Low-Variance Mining. In ISOC
Network and Distributed System Security Symposium (2020). Internet Society. https://doi.org/10.14722/ndss.2020.23095
[9]
BitInfoCharts. 2022. Bitcoin, Ethereum, Dogecoin, XRP, Ethereum Classic, Litecoin, Monero, Bitcoin Cash, Zcash,
Bitcoin Gold Hashrate historical chart. https://web.archive.org/web/20220522122528/https://bitinfocharts.com/
comparison/hashrate-btc-eth-doge-xrp- etc-ltc-xmr-bch-zec-btg.html#3y
[10] BLOCKCYPHER. 2022. Blockchain Web Services. https://www.blockcypher.com
[11]
Carl Boettiger. 2015. An introduction to Docker for reproducible research. ACM SIGOPS Operating Systems Review 49,
1 (2015), 71–79.
[12]
Joseph Bonneau, Andrew Miller, Jeremy Clark, Arvind Narayanan, Joshua A Kroll, and Edward W Felten. 2015. Sok:
Research perspectives and challenges for bitcoin and cryptocurrencies. In 2015 IEEE symposium on security and
privacy. IEEE, IEEE, 104–121. https://doi.org/10.1109/SP.2015.14
[13]
R. Bowden, H. P. Keeler, A. E. Krzesinski, and P. G. Taylor. 2018. Block arrivals in the Bitcoin blockchain. ArXiv
e-prints (Jan. 2018). arXiv:1801.07447 [cs.CR]
[14]
Vitalik Buterin. 2016. EIP-100: Change diculty adjustment to target mean block time including uncles. https:
//eips.ethereum.org/EIPS/eip-100
[15]
Vitalik Buterin. 2022. Ethereum Whitepaper. https://web.archive.org/web/20220728020709/https://ethereum.org/en/
whitepaper/
[16]
Vitalik Buterin and Virgil Grith. 2017. Casper the friendly nality gadget. arXiv preprint arXiv:1710.09437 (Oct.
2017). arXiv:1710.09437 [cs.CR]
[17]
Huashan Chen, Marcus Pendleton, Laurent Njilla, and Shouhuai Xu. 2019. A Survey on Ethereum Systems Security:
Vulnerabilities, Attacks and Defenses. https://doi.org/10.1145/3391195 arXiv:1908.04507 [cs.CR]
Publication date: July 2022.
20 Aviv Yaish, Gilad Stern, and Aviv Zohar
[18]
Shen Chen. 2020. The Secret Weapon F2Pool Used to Tackle Its Uncle Rate. https://web.archive.org/
web/20220806080656/https://medium.com/bloxroute/the-secret-weapon-f2pool-used- to-tackle-its-uncle-rate-
1ecb6fe47ef8
[19]
Ethereum Classic. 2017. Ethereum Classic. Ethereum Classic (accessed 16 October 2017) https://ethereumclassic. github.
io (2017).
[20]
Ethereum Classic. 2022. Proof of Work. https://web.archive.org/web/20220519111931/https://ethereumclassic.org/
why-classic/proof-of-work/
[21]
Nicolas T Courtois and Lear Bahack. 2014. On subversive miner strategies and block withholding attack in bitcoin
digital currency. arXiv preprint arXiv:1402.1718 (2014).
[22]
Philip Daian, Steven Goldfeder, Tyler Kell, Yunqi Li, Xueyuan Zhao, Iddo Bentov, Lorenz Breidenbach, and Ari Juels.
2020. Flash Boys 2.0: Frontrunning in Decentralized Exchanges, Miner Extractable Value, and Consensus Instability.
In 2020 IEEE Symposium on Security and Privacy, SP 2020, San Francisco, CA, USA, May 18-21, 2020. IEEE, 910–927.
https://doi.org/10.1109/SP40000.2020.00040
[23]
Michael Davidson, Tyler Diamond, et al
.
2020. On the Protability of Selsh Mining Against Multiple Diculty
Adjustment Algorithms. IACR Cryptol. ePrint Arch. 2020 (2020), 94.
[24]
Monika Di Angelo and Gernot Salzer. 2019. A survey of tools for analyzing ethereum smart contracts. In 2019 IEEE
international conference on decentralized applications and infrastructures (DAPPCON). IEEE, 69–78.
[25] Docker. 2022. Get Started with Docker. https://www.docker.com/get-started/
[26]
Maya Dotan and Saar Tochner. 2021. Proofs of Useless Work Positive and Negative Results for Wasteless Mining
Systems. arXiv:2007.01046 [cs.CR]
[27]
David Easley, Maureen O’Hara, and Soumya Basu. 2019. From mining to markets: The evolution of bitcoin transaction
fees. Journal of Financial Economics 134, 1 (2019), 91–109.
[28]
Gabriel Estevam, Lucas M. Palma, Luan R. Silva, Jean E. Martina, and Martín Vigil. 2021. Accurate and decentralized
timestamping using smart contracts on the Ethereum blockchain. Information Processing & Management 58, 3 (2021),
102471. https://doi.org/10.1016/j.ipm.2020.102471
[29] Ethereum. 2020. Block timestamps. https://git.io/JLQVd
[30]
Ethereum. 2021. forkchoice.go. https://github.com/ethereum/go-ethereum/blob/
be9742721f56eb8bb7ebf4f6a03fb01b13a05408/core/forkchoice.go#L43
[31] Ethereum. 2021. Geth’s diculty adjustment code. https://git.io/JXuhA
[32]
Ethereum. 2021. protocol_params.go. https://github.com/ethereum/go-ethereum/blob/
377c7d79962c6060939a4f95532df93a345f63/params/protocol_params.go#L168
[33]
Ethereum. 2022. backend.shouldPreserve. https://github.com/ethereum/go-ethereum/blob/
ecae8e4f655775bf6935543e3e9136566f4823a2/eth/backend.go#L404
[34]
Ethereum. 2022. blockchain.writeBlockWithState. https://github.com/ethereum/go-ethereum/blob/
be9742721f56eb8bb7ebf4f6a03fb01b13a05408/core/blockchain.go#L1219
[35]
Ethereum. 2022. consensus.go. https://github.com/ethereum/go-ethereum/blob/
a52bcccfe1fd9b10d27b1121a8465982af7714/consensus/ethash/consensus.go#L44
[36]
Ethereum. 2022. consensus.makeDicultyCalculator. https://github.com/ethereum/go-ethereum/blob/
377c7d79962c6060939a4f95532df93a345f63/consensus/ethash/consensus.go#L404
[37]
Ethereum. 2022. Ethereum Improvement Proposals. https://web.archive.org/web/20220710202618/https://eips.
ethereum.org/
[38] Ethereum. 2022. Go Ethereum. https://web.archive.org/web/20220512071235/https://geth.ethereum.org/
[39] Ethereum. 2022. The Merge. https://ethereum.org/en/upgrades/merge/
[40]
Ethereum. 2022. Nodes and clients. https://github.com/ethereum/ethereum-org-website/blob/
35c262525ae69bdcfee7e35ad6bc3046d282fc56/src/content/developers/docs/nodes-and- clients/index.md?plain=1#L1
[41] ethereum/devp2p. 2017. DEV’s p2p network protocol & framework. https://web.archive.org/web/20220729125908/
https://gitter.im/ethereum/devp2p?at=59bea341614889d4750c29ac
[42] EthereumPoW. 2022. EthereumPoW. https://web.archive.org/web/20220806223601/https://ethereumpow.org/
[43] Ethernodes. 2021. The popularity of Ethereum clients. ethernodes.org.
[44]
Etherscan. 2021. Top 25 Miners by Blocks. https://web.archive.org/web/20210930170721/https://etherscan.io/stat/
miner/
[45] Etherscan. 2022. Blocks. https://etherscan.io/blocks
[46] Etherscan. 2022. Ethereum Network Transaction Fee Chart. https://etherscan.io/chart/transactionfee
[47] Etherscan. 2022. Uncles. https://etherscan.io/uncles
[48] ethstats. 2022. Ethereum Network Status. https://ethstats.net/
[49]
Ittay Eyal. 2015. The Miner’s Dilemma. In 2015 IEEE Symposium on Security and Privacy. 89–103. https://doi.org/10.
1109/SP.2015.13
Publication date: July 2022.
Uncle Maker: (Time)Stamping Out The Competition in Ethereum 21
[50]
Ittay Eyal and Emin Gün Sirer. 2014. Majority is not enough: Bitcoin mining is vulnerable, In International conference
on nancial cryptography and data security. Commun. ACM 61, 436–454. https://doi.org/10.1145/3212998
[51]
Eugene A Feinberg and Adam Shwartz. 2012. Handbook of Markov decision processes: methods and applications. Vol. 40.
Springer Science & Business Media.
[52]
Chen Feng and Jianyu Niu. 2019. Selsh Mining in Ethereum. In 2019 IEEE 39th International Conference on Distributed
Computing Systems (ICDCS). 1306–1316. https://doi.org/10.1109/ICDCS.2019.00131
[53]
Amos Fiat, Anna Karlin, Elias Koutsoupias, and Christos Papadimitriou. 2019. Energy Equilibria in Proof-of-Work
Mining. In Proceedings of the 2019 ACM Conference on Economics and Computation (Phoenix, AZ, USA) (EC ’19).
Association for Computing Machinery, New York, NY, USA, 489–502. https://doi.org/10.1145/3328526.3329630
[54]
Ethereum Foundation. 2022. Blocks. https://github.com/ethereum/ethereum-org-website/blob/
e98c23119c1514f46b2bcdcc8b2ea59154069bbd/src/content/developers/docs/blocks/index.md?plain=1#L57
[55] Mark Friedenbach. 2018. Forward Blocks.
[56]
Juan Garay, Aggelos Kiayias, and Nikos Leonardos. 2017. The bitcoin backbone protocol with chains of variable
diculty. In Annual International Cryptology Conference. Springer, 291–323.
[57]
Adem Efe Gencer, Soumya Basu, Ittay Eyal, Robbert van Renesse, and Emin Gün Sirer. 2018. Decentralization in
Bitcoin and Ethereum Networks. In Financial Cryptography and Data Security, Sarah Meiklejohn and Kazue Sako
(Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 439–457.
[58]
A. Gervais, G. O. Karame, V. Capkun, and S. Capkun. 2014. Is Bitcoin a Decentralized Currency? IEEE Security Privacy
12, 3 (May 2014), 54–60. https://doi.org/10.1109/MSP.2014.49
[59]
Arthur Gervais, Ghassan O. Karame, Karl Wüst, Vasileios Glykantzis, Hubert Ritzdorf, and Srdjan Capkun. 2016. On
the Security and Performance of Proof of Work Blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on
Computer and Communications Security (Vienna, Austria) (CCS ’16). Association for Computing Machinery, New
York, NY, USA, 3–16. https://doi.org/10.1145/2976749.2978341
[60]
Guy Goren and Alexander Spiegelman. 2019. Mind the mining. In Proceedings of the 2019 ACM Conference on Economics
and Computation. ACM, 475–487. https://doi.org/10.1145/3328526.3329566 arXiv:1902.03899
[61]
Cyril Grunspan and Ricardo Pérez-Marco. 2019. Selsh Mining and Dyck Words in Bitcoin and Ethereum Networks.
https://doi.org/10.48550/ARXIV.1904.07675
[62] Cyril Grunspan and Ricardo Pérez-Marco. 2019. Selsh Mining in Ethereum. https://doi.org/10.48550/ARXIV.1904.
13330
[63]
Runchao Han, Zhimei Sui, Jiangshan Yu, Joseph Liu, and Shiping Chen. 2021. Fact and ction: Challenging the honest
majority assumption of permissionless blockchains. In Proceedings of the 2021 ACM Asia Conference on Computer and
Communications Security. 817–831.
[64]
Timo Hanke. 2016. AsicBoost - A Speedup for Bitcoin Mining. arXiv e-prints, Article arXiv:1604.00575 (Apr 2016),
arXiv:1604.00575 pages. arXiv:1604.00575 [cs.CR]
[65]
Charles R. Harris, K. Jarrod Millman, Stéfan J van der Walt, Ralf Gommers, Pauli Virtanen, David Cournapeau,
Eric Wieser, Julian Taylor, Sebastian Berg, Nathaniel J. Smith, Robert Kern, Matti Picus, Stephan Hoyer, Marten H.
van Kerkwijk, Matthew Brett, Allan Haldane, Jaime Fernández del Río, Mark Wiebe, Pearu Peterson, Pierre Gérard-