Now we get into one of the more recent developments in selfish mining defenses.
This one is called Publish or perish, and was published by Zhang and Preneel in 2017.
Previous defenses we’ve seen had many flaws, such as requiring a hard fork — for example in fork-punishment — or not disincentivizing selfish mining when the selfish miner has a longer chain — for example in unforgeable timestamps.
Publish or perish claims to be the best-yet defense of selfish mining, and addresses all these previous issues.
It doesn’t require a hard fork, which means that it’s backwards compatible with the old chain, and it also disincentivizes selfish mining even when the selfish miner has a longer chain.
The idea of selfish mining boils down to maliciously building a secret block, and then publishing that off into a chain.
Publish or perish’s main goal was to make sure that secret blocks do not help selfish miners at all.
To do this, Publish or perish’s approach focuses on amending Bitcoin’s Fork Resolving Policy, or FRP.
By default, we know that miners choose the longest chain to be valid, so for Bitcoin, we say that it has a length FRP.
Publish or perish’s insight was to switch from length to weight as a heuristic for the fork resolving policy.
Instead of just counting the length of chains, we also consider weight, which is roughly speaking a function of how much exposure a block gets in the network — thereby making it disadvantageous to withhold blocks.
There’s a lot of terminology and formal definitions, so we’ll be going into that first.
We define Tau as an assumed upper bound on the time it takes to propagate blocks across the Bitcoin network.
And from a miner’s perspective, the term in time means that for a valid received block, either (1) its height value is greater than that of the local head, or (2) its height value is the same as that of the local head, but was propagated within tau time.
The bottom diagrams illustrate the two possible requirements for a block to be in time.
On the left side, a block is received within tau time, so that block is in competition with the current head.
On the right side, the block received has a height value that’s one greater than the local head, so we just append it to the blockchain.
The term uncle refers to an in-time block that competes with a block’s parent — the parent being the previous block to the current.
To formalize, the uncle of a block B is one less the height of B. Makes sense because the uncle of B has to be at the same height as B’s parent.
And for the uncle of B to be in time, it must be within tau time of B’s parent.
The diagram on the right hand side nicely summarizes the definition of an uncle block.
We have our child block B, and previous to that, we have its parent A. At the same block height to A, we have blocks C and D. Block C is an uncle to B because it is within tau time of B’s parent, A. Block D on the other hand is not an uncle to B because while it has the correct block height — one less the height of B — it was not seen in tau time of B’s parent, A. So it’s not an uncle.
The weight of a chain — from a miner’s perspective — is the number of its in time blocks plus the number of in time uncle blocks . And to make sure we have valid in time blocks and in time uncles, we make miners embed Hashes of the blocks that count towards a blocks weight.
That way, others can easily verify the blocks weight.
And Again, we say everything is from a miner’s perspective because whether a block is in time is evaluated from the miner’s local perspective.
And we calculate the weight of a chain starting from the block after its root, since competing chains always have a shared root.
For example in the diagram on the right hand side, all three of these chains are all rooted at root block R.
Having defined weight, you can kinda see how miners are disincentivized from withholding blocks.
If you withhold blocks, then your blocks won’t be in time, and so they’ll have less weight.
With all these definitions, we can now specify the weighted fork resolving policy.
It has three main rules.
If one chain is longer height-wise than the other(s) by k or greater blocks, then miners will mine on this chain.
If a chain is longer than the others by k blocks, we can probably trust it to be a valid chain.
This kind of inherits the notion of an honest majority from the default Bitcoin length FRP.
If a chain is longer than other chains by k blocks and is malicious, then we have a bigger problem on our hands; everything’s broken so we should just stop using Bitcoin since someone probably owns a majority of the network hash power.
If all chains are within k blocks height of each other, then the miner will choose to mine on the chain with the largest weight.
If the largest weight is achieved by multiple chains simultaneously, then the miner chooses one among them randomly.
One note is that in the first rule k is a failsafe parameter that gages the allowed amount of network partition.
if we set k to infinity, then the rule never applies.
Ok so now that we’ve spent all this time defining all these terms and procedures, let’s look at how publish or perish actually disincentivizes selfish mining.
So here’s the general scenario.
Say that a selfish miner has already secretly mined one block.
Before they can mine a second secret block, the honest network publishes a competing block.
There’s now a block propagation race.
At this point in time, the selfish miner has two options: option 1, to publish, or option 2, not to publish.
If the selfish miner publishes their block, the next honest block would gain a higher weight because it could embed a proof of having seen its uncle.
On the other hand, publishing the block would ensure that it would contribute to the weight of the selfish chain, since it’s in time.
So, the selfish miner’s block gets a weight of 1, but also contributes to the weight of the honest chain.
On the other hand, if the selfish miner keeps their block secret and misses the time window for being in time, then the secret block would not contribute to the weight of its own chain.
So, the selfish miner’s block gets a weight of 0, but since the honest network wouldn’t have seen this secret block either , it wouldn’t contribute to the weight of the honest chain .
The key takeaway is that no matter which option the selfish miner chooses in the end, neither option gives weight to the selfish chain that is not also given to the honest chain.