Three Chain Selection Rules

Our next goal is to start reasoning about the security of a chain selection rule. However, having this discussion in the abstract, without any concrete examples to consider an analyze, will not be very illuminating. For that purpose, we will now familiarize ourselves with three chain selection rules. The two "big ones" are of course Bitcoin's heaviest chain rule, and GHOST. As a third example, we will use the more exotic "proof of entropy minima", more known as PoEM. The latter is not very common (I am only aware of one project that actually uses it), but it has theory behind it and it brings its own flavor to the discussion.

Heaviest Chain Rule (HCR)

The longest chain rule is as simple as the name suggest. Given a tree, choose the tip that is furthest from the genesis block:

However, the rule is called heaviest chain, not longest chain, which begs two questions: what makes a chain heavy, and why is it important.

To answer the first question, recall that proof-of-work defines what the difficulty of af a block is. If the difficulty target is TT, then the difficulty is 1/T1/T. We use this as the weight of our block. Consider a tip BB and lets say that the difficulty targets along the chain were T1,,TnT_1,\ldots,T_n, then the weight of the chain is simply 1T1++1Tn\frac{1}{T_1} + \ldots + \frac{1}{T_n}, and HCR will return the chain for which this is maximized.

When the difficulty is fixed, it follows that all blocks have the same weight, and so the heaviest chain rule and longets chain rules become synonymous. For this reason, some people still refer to it as the longest chain rule while actually meaning heaviest chain rule.

Note that this rule does not break ties. Consider this situation again:

While it is true that AA and BB are different blocks that have different nonces and different hashes, they both point at the same tip which means they both have the same difficulty target.

As for why we need the heaviest chain rule? The short answer is that a small miner can cheaply create very long chains, much longer than the honest network, by manipulating the difficulty adjustment to make block production very easy. This attack will create a very long chain, but it will also be very light. The accumulated weights do not measure how many blocks were created, but how much work was put into them. It doesn't matter how cleverly the small miner manipulates the difficulty adjustment, they cannot spend more work than the rest of the network. We will revisit this attack in more detail at the end of the section.

Interestingly, in the original Bitcoin white paper, Satoshi missed this attack and proposed the longest chain rule (despite discussing difficulty adjustment). Fortunately, in the two years between the white paper and the launch of the actual network, this issue was noticed and fixed.

Greedy Heaviest Observed Subtree (GHOST)

The GHOST rule was first introduced by Yonatan Sompolinsky and Aviv Zohar in 2013, in their aptly named paper Fast Money Grows on Trees, Not Chains.

Many people, including yours truly, see GHOST as the first meaningful innovation withing the block chain paradigm since Bitcoin was launched. While other attempts to improve on Bitcoin included superficial parameter changes (like playing with block sizes and delays), GHOST quite literally turns HCR on its head.

While in HCR you find the selected tip by starting from the tips and looking back in time to see who is standing on the most weight. In GHOST, you start from the genesis and climb your way up, choosing each step the block that has most work above it.

More concretely, for any block BB, we can define the subtree rooted at BB to contain BB and all blocks from which BB is reachable (when we switch to DAG parlance, we will simply call this B.FutureB.\overline{Future}):

We can define the weight of each tree like we did in HCR, as the sum of difficulties.

To find the selected tip of a given tree, we start from the Genesis block. We then look at all of its children and for each child calculate the size of the tree rooted at this child. We repeat the process for the child with the most weight above it again and again until we find a tip, which will be returned as the selected tip.

Let us follow an example.

Assume that all blocks weigh the same, and consider this tree:

The chain selection rule's job is to output one of the tips T1,,T5T_1,\ldots,T_5. You are welcome to check that T5T_5 has the longest/heaviest chain below it, so this is the tip that HCR will return. What about GHOST?

Well, lets work it out. GHOST starts at genesis, and computes the weight of its children:

It then chooses the child with the most weight above it, and repeats the process:

GHOST repeats the process until it reaches a tip, and outputs it as the selected tip:

And that's really all there is to it.

While I have your attention, I would like to address a few common misconceptions about GHOST that need to go away:

  • The purpose of GHOST is not to pay block rewards to so called "uncle blocks" (which are orphaned blocks, but in a close proximity to the blocks that were not, like T2T_2 above but not like T5T_5). Ethereum indeed intended to use GHOST for such a feature in their implementation, but it is not the motivation for the original design and in fact, the GHOST paper explicitly recommends against it.

  • In fact, Ethereum 1.0 never used GHOST in production. They used some (home brewed) variation of the Inclusive protocol (Lewenberg, Sompolinsky, Zohar). Post-merge Ethereum uses an adaptation of GHOST for PoS called LMD-GHOST.

  • Most importantly, and I can't say this emphatically enough, GHOSTDAG is not a DAG version of GHOST. I am going to repeat this statement several times throughout this book so be prepared. The worst thing about GHOSTDAG is how misleading its name is. In the next part of the book, when we survey the jungle of attempted blockDAG protocols, we will see that GHOSTDAG is pretty much the only one that is not a DAGified version of GHOST, but rather a DAGified version of HCR.

One might wonder at this point, if GHOSTDAG is not a DAGified version of GHOST, then why is it called GHOSTDAG?!? Well, the answer is, obviously, that it is named after the movie "Ghost Dog: The Way of the Samurai".

Proof of Entropy Minima (PoEM)*

This last chain rule is an interesting one. In particular, unlike GHOST and HCR, PoEM couples the difficulty mechanism to the chain selection rule.

PoEM was introduced in a note by Karl Kreder (a.k.a. "Dr. K") and Shreekara Shastry, and more thoroughly analyzed by Zindros, Kreder et al. in a 2025 preprint.

Instead of just looking at the topology of the block, it uses the difficulty hit by the blocks to weigh the chain. Recall that in order for a block BB to be considered valid it should contain a nonce nn such that H(B[n])T\mathsf{H}(B[n])\le T where TT is the difficulty target.

In the context of HCR and GHOST, we don't really care about the actual value H(B[n])\mathsf{H}(B[n]). Even when we use difficulty to weigh the chain, we used targets and not actual values. PoEM uses the actual values. That is, if a block happened to get H(B[N])\mathsf{H}(B[N]) which is twice as small as the target, then in some sense, it will be considered "twice as heavy".

In practice, the PoEM weighting works a little different than described, they don't take the sum of reciprocals but their logarithms. So in the example above if H(B[N])\mathsf{H}(B[N]) is twice smaller than TT then the block BB is "one more" heavier,log(1/H(B[N]))=log(2/T)=1+log(1/T)\log(1/\mathsf{H}(B[N])) = \log(2/T)=1+\log(1/T)

They have good reasons to do this which I will not get into.

One interesting thing about PoEM is that ties are extremely rare. If two blocks point at the same block, they are only tied if they happen to have the same hash, which is extremely unlikely (how unlikely? Despite years of usage and scrutiny, including all Bitcoin mining, not a single collision in SHA-256 is known).

Recall this situation:

In HCR and GHOST miners are advised to mine over the blocks they heard about first. In particular, the only way to determine whether AA or BB is the ultimate successor is to wait for sufficiently long and see where the wind blows.

In contrast, in PoEM, you can read off the blocks themselves which will be preferred by a miner, which can give more certainty that, as their analysis shows, translates to faster transaction confirmation.

Note that just because block BB has more weight than block AA does not guarantee that it will be the chosen block. Indeed, it could be that even though BB has more weight, the network managed to mine an additional block over block BB, and their combined weight is higher:

Here BB is heavier than AA but lighter than AA'. From the point of view of a node that does not know AA, BB is the tip selected by PoEM, but from the point of view of a node that knows AA', PoEM selects AA', and BB is orphaned.

Note that it would be unfair to call this property a criticism of PoEM. It only establishes that PoEM can't guarantee something we already know HCR and GHOST can't guarantee either.

In fact, no chain selection rule can guarantee which side of the fork is going to win, because that's a form of deterministic finality. In other words, the existence of a chain rule with such a strong guarantee will contradict the 3f+13f+1 theorem.

However, these benefits are not without costs, as we will see in the sequel.

Why Heaviest and Not Longest?*

We stated above that the longest chain rule is not secure due to the difficulty adjustment mechanism, that allows creating long (though not heavy) chains for cheap.

Lets work out the math. Consider a blockchain that uses difficulty epochs like Bitcoin, say that the block delay is λ\lambda and that there are NN blocks per epoch. Consider an attacker with α\alpha of the global hash rate. Also, let qq be the maximal decrease in difficulty across difficulty windows. (recall that in Bitcoin we have λ=10 min\lambda = 10\text{ min}, N=2016N = 2016 (so λN=20160 minutes=2 weeks\lambda\cdot N = 20160\text{ minutes} = 2\text{ weeks}), and q=14q=\frac{1}{4}).

Since the adversary only has a fraction α\alpha of the hash rate, before the difficulty has changed, it will take them 1αλ\frac{1}{\alpha} \lambda to create each block. So the first entire difficulty epoch will require 1αλN\frac{1}{\alpha} \lambda\cdot N. After which, the adversary can reduce the difficulty by qq making the second difficulty epoch take 1αλNq\frac{1}{\alpha} \lambda\cdot N\cdot q, and similarly the third will take 1αλNq2\frac{1}{\alpha} \lambda\cdot N\cdot q^2 and so on.

Obviously, at some point the difficulty will be so low that other overhead will dominate the computation, but if we ignore this, we get that an adversary can create "infinitely many blocks" in a finite time, which we can compute using the geometric series formula to be

Nλαn=0qn=1αλN1qN\frac{\lambda}{\alpha}\sum_{n=0}^{\infty}q^{n}=\frac{1}{\alpha}\frac{\lambda\cdot N}{1-q}

In particular, if we plug in the values for Bitcoin we get that λN1q=26880 min\frac{\lambda\cdot N}{1-q} = 26880\text{ min} which is less than 2020 days. So we get, for example, that a 1%1\% attacker would be able to create a longer chain in less than 20002000 days, or 5.55.5 years, and a 10%10\% attacker could revert the entire Bitcoin chain in just six months.

This becomes even worse if you consider adversaries that start their competing chain in the genesis block, where difficulty is already low.

Last updated