For a bit more clarity, let’s take a more rigorous approach to our analysis of the previous scenario.
In the diagram on the bottom, the dark circles represent blocks that are found by the selfish miner, and the dark triangles represent blocks are found by honest miners.
The circle and triangle outlines represent a count in the weight of the selfish and honest chains, respectively, and as always, blocks are mined from left to right.
So imagine at this point in time, as before, the selfish miner has one block, let’s call it S, and the honest network just published a competitor to S.
In option 1, the selfish miner chooses to publish S. Since S is published within tau time of the honest competitor, it counts into the weight of the selfish chain.
However, since S then becomes an uncle to the next honest block, it also counts into the weight of the honest chain.
So, S counts into the weight of both the honest and selfish chains.
Fast forward to the point in time where we the have diagram below, both the honest and selfish chains have a weight of 3 despite the fact that there are only two honest blocks but three selfishly mined blocks
In option 2, the selfish miner doesn’t publish S, and instead chooses to wait, and publish later on as part of the selfish chain.
Since S is published late — as in not within tau time — it would not contribute to the weight of the selfish chain.
And also it wouldn’t an uncle of the next honest block, so S doesn’t contribute to the weight of the honest chain either.
So in option 2, S contributes to neither the weight of the honest nor the selfish chain.
If we have scenario depicted in the diagram below, both the honest and selfish chains have a weight of 2, despite there being three selfishly minedblocks and only two honestly mined blocks So the result is that regardless of which option the selfish miner chooses, S will NOT contribute to only the weight of the selfish chain.
It will only contribute to both or neither.
This completely nullifies the advantage of having S in the first place.
Here are a couple graphs on the expected revenue of selfish miners when publish or perish is in effect.
On the left side, we have a graph of selfish miners’ profit, given that certain defenses are in place.
Particularly notable is the performance of publish or perish in comparison to optimal tie breaking.
Optimal tie breaking is the theoretical optimal defense that always rejects selfish blocks whenever there’s a tie, with 100% accuracy.
Notice that publish or perish even outperforms this theoretical optimal tie breaking defense.
On the right side, we have revenue given different values of k, which again is the threshold number of blocks ahead a chain has to be in order for miners to just automatically choose to mine on that one.
As it turns out, the higher the value of k, the less revenue selfish miners will make.
Revenue is the lowest when we set k to infinity, at which point miners will always look to mine on the chain with the most weight.
One important note is that there’s still a big gap between the ideal expected profits, which is linear in the amount of mining power one has, and even the lowest revenue publish or perish scheme at k = infinity.
So as good as publish or perish says it is, it still doesn’t reach Bitcoin’s intended goal of having hash power being directly proportional to mining reward.
As it stands, selfish mining is still an effective way to gain more profit, given that you have a significant amount of hash power, but with publish or perish it’s more difficult to pull off.
Publish or perish actually has a lot of limitations too.
First off, it assumes synchrony, and Bitcoin is asynchronous.
It’s not useful to define an upper bound on block propagation time because you can never be sure if all the blocks at a certain block height have been delivered or not.
This is something inherent in large distributed systems like Bitcoin, and we’ll be exploring this in detail in our second course.
For example, for any fail-safe parameter k > 1, an attacker could broadcast their blocks right before they are late.
This would cause inconsistent views among honest miners, since some would see the blocks as in time, and some would see them as late, depending on how long it took these blocks to propagate across the network.
It’s not just publish or perish though.
For all defenses or upgrades or proposals that assume Bitcoin is synchronous, everything just falls apart, because you can’t realistically make these assumptions about the network, especially since Bitcoin is publish and open to anyone.
Also, since publish or perish would be rolled out as a software update to bitcoin miners, not all miners would update their software at the same time.
During the transition period from Bitcoin’s default length FRP to the weighted FRP, attackers could potentially leverage the situation and launch double-spend attacks on confused users.
Another limitation of publish or perish is that it neglects some real world factors.
Due to network latency, there are often naturally occuring forks, but there are not permitted in this model.
It doesn’t consider transaction fees as an additional incentive on top of block rewards.
And it also doesn’t consider when there are multiple selfish miners, and how they would interact with each other and with the rest of the network.
So in the end, publish or perish doesn’t achieve true incentive compatibility.
However, analyzing publish or perish and all the other works we’ve looked through is a very good start in designing better defenses for Bitcoin.
Maybe porting over publish or perish into an asynchronous model is a good direction for how we can approach defending against selfish miners.