Block Validation

One of the earlier proposed solutions to solving selfish mining was to validate blocks using dummy blocks that hold metadata.

This technique was proposed by Schultz in 2015, and later by Solat and Potop-Butucaru in 2016.

The idea is that in addition to having regular blocks, we also create additional (dummy) blocks that contain signatures for that block.

So, for any given block, it is easy to look at the corresponding dummy block to verify how many users have seen and signed off on that block.

Blocks that are selfishly mined would only have been seen by the one withholding the blocks, and would not have sufficient signatures.

This proves that an honest block is witnessed by the network, and also proves that a competing block is absent before miners are able to work on it.

So when a malicious actor that has been withholding blocks finally publishes their chain, all but the first block will be automatically rejected, since the first block would not have sufficient signatures.

With this method, selfish miners can’t make more than their expected reward, which is just for one block.

This invalidates a lot of the work they do to build the chain off of the first block they find.

Therefore, block validation with this dummy block signature scheme disincentivizes selfish mining.

One immediate flaw that we can see is that this technique is vulnerable to Sybil attacks.

There’s no way to guarantee that the signatures on a block all come from different users.

And so the selfish miner could just generate as many fake signatures as needed to make it seem like the withheld blocks are valid.

They can do this because as we know from before, it’s easy to generate new identities in Bitcoin.

And furthermore, there’s no real way of determining how many signatures is enough to show that a block is valid.

For example… What order of magnitude is the threshold number of signatures? And would it have to change depending on the changing number of users within the network? These questions are all hard to answer but are important to this schemes implementation Also, no matter how many signatures are needed, a malicious user could still easily Sybil attack the system.

So in the end the fact that there’s no good way of determining a signature volume threshold and the fact that it’s susceptible to a Sybil attack makes the entire defense useless.

Furthermore, another downside to having dummy signature blocks is that their implementation would require fundamental changes to the already established block validity rules.

Such a change would require a hard fork, which is undesirable.

Fork Publishment