Defending against empty or near empty blocks from malicious miner takeover?

Summary:

The proposed techniques by Peter R to reduce the chances of a split in the coming network upgrade to larger blocks are different from the way soft forks have historically worked. The bar for miners being on the new chain is extremely high, 95%. Soft forks make rule restrictions on classes of transactions that are already non-standard so that any non-upgraded miners are unlikely to be including txs in their blocks which would violate the new rules and should not have their blocks orphaned even after the fork. Soft forks are designed to only be used when there is a very wide community consensus and the intention is not to overrule anyone's choice to remain on the old rules but to ensure the security of nodes that may have neglected to upgrade. The proposed BU hard fork suggests that there is a significant fraction, in fact likely a majority of users who intentionally want to remain on the old rules. As a Bitcoin user, it is abhorrent to see the way this method proposes to intentionally cripple the chain and rules one wants to use instead of just peacefully splitting.CANNON, via bitcoin-dev, raises concerns about a potential 50% attack if centralized mining power is used to attack the valid chain with intentions on killing it. Peter R suggests that miners begin to orphan the blocks of non-upgraded miners once a super-majority of the network hash power has upgraded. This would serve as an expensive-to-ignore reminder to upgrade. In the scenario where Levels 1 and 2 protection fails to entice all non-compliant miners to upgrade, a small-block minority chain may emerge. To address the risk of coins being spent on this chain (replay risk), majority miners will deploy hash power as needed to ensure the minority chain includes only empty blocks after the forking point. Like after a soft forking change, a minority that does not want to abide by the current ruleset enforced by the majority could change the proof-of-work and start a spin-off from the existing Bitcoin ledger.

Updated on: 2023-06-11T22:31:16.578157+00:00