Miners forego revenue in order to 51% attack the Bitcoin protocol by rejecting blocks I was recently listening to Mike Green and Anthony Pompliano debate the future of Bitcoin on RealVision. And Mike raised an interesting point regarding Bitcoin (I'm paraphrasing). &quot;Scenario: Let's say the majority of miners, which are no longer bound by financial incentives, decides to attack the Bitcoin network by continuously rejecting blocks, could they do it? Could you essentially reject-spam Bitcoin's network?&quot;
That, I found to be an interesting question to which I haven't been able to find an answer. Is anyone able to shed light on the plausibility of this scenario?
Bitcoin nodes consider the chain with the most work the best chain. Whenever a miner finds a new block that extends the best chain, they broadcast it to the network and all nodes update their chaintip as they hear about it. Miners could ignore that new blocks are found, but this would not affect any other network participants.
They could however instead provide a competing chaintip. As your scenario states that the attackers have a majority of the hashrate, (among other things), they could build a chain of empty blocks, i.e. blocks that only pay the block subsidy to the miners, but don't confirm any transactions. This would allow the attackers to collect the block subsidy, but they would no longer be collecting transaction fees, reducing their revenue by (currently) about 15%. However, the delay in confirmations would drive up the feerates of the waiting transactions, and the lost revenue would quickly increase.
Note that the attackers must continue to mine blocks in order to maintain their denial of service, or they would be out-competed by the minority eventually. So, the attacker is still spending energy cost (and has already invested in hardware). Depending on how the scenario exactly specifies &quot;no longer bound by financial incentives&quot;, I'd surmise that the rising transaction fees would eventually entice miners to break rank from the attack.