Griefing Bitcoin with a 61% attack

It’s fun and easy to make Bitcoin miserable if you have a supermajority of the hashrate.

Suppose you are a nation-state that’s has dedicated many billions of dollars to effectively ruining Bitcoin. You’ve amassed well over 51% of the hashrate. You now want to shut it down. The easiest thing to do would be simply to mine empty blocks. As Jimmy Song pointed out, the nodes aren’t just going to sit there and keep validating your empty blocks. They will use a command called invalidateblock. So what do you do?

There are many possibilities — in fact, there are literally infinitely many possibilities. Your goal is to disrupt consensus. You can be creative as you wish, but here’s probably what I’d do.

Monopolize the blockchain and make it suck worse than any legacy alternative

This attack is two-pronged. One goal is to chase all other miners out of the arena to gain an effective monopoly. 2) The other is then to run it like an abusive capitalist — demanding excessive fees, allowing governments or big players to blacklist addresses, especially for a fee, anything you want. You’re the boss. Once you’ve controlled it, it’s not Bitcoin.

Step 1. Signal to other miners that you will be ignoring their blocks. You do this by simply ignoring their blocks, and keep plowing away. If you have 60% of the hashrate, this won’t be a problem, you will always control the longest chain. Eventually, competing miners will have no choice but to capitulate.

But wait, what about a soft fork in which miners are whitelisted or others blacklisted?

Now the miners, and also the nodes, will see that you’re doing this. Doing this blatantly is actually part of the strategy. One option the network could do is a User Activated Soft Fork — all nodes in the network decide to invalidate your blocks. The problem here with a decentralized network is that there is no way to tell the good blocks from the bad blocks, especially because we haven’t yet started to do nefarious things with the blocks. At this stage, we are only chasing the other miners out of the market by making all of their efforts unprofitable. Now the nodes and miners could form a cabal and choose to whitelist certain miners. This is possible, but then we’ve created a centralized entity, controlled by a designed set of people, and suddenly we no longer have Bitcoin. Maybe people won’t care — it’s just centralized Bitcoin and you just hope that the cabal remains benevolent. But this cabal, which will be a defined and finite number of entities with their own set of governance properties, will be vulnerable to more classical government attacks. In particular, since they’re no longer a moving target it should be fairly easy for the NSA to identify them and make life miserable. You also have denial-of-service attacks, for the same reason. If only whitelisted miners can mine, any process by which a miner can become whitelisted is necessarily centralized and politicized. So now you just have a blockchain with permission block-scribes. This is far from Bitcoin.

Now suppose that whitelisting doesn’t happen. You have control of the blockchain. You can refuse to process transactions that don’t include a 2% fee, at least for a few weeks, until you bump it up to 4%, maybe 5.7%. You can decide not to process transactions from addresses you don’t like. You can be worse than the worst fiat bank. You can throttle the chain, slowing down the number of blocks processed to 1 per day. You have the hashing power to accelerate when you need to, so you won’t be challenged. In the meantime, you can also reorg back quite a long way back.

What if the nodes decide to invalidate reorgs more than k blocks deep?

This is a good question. In any of the attacks, one defense is to declare that nodes will invalidate, say any chains that fork more than 6 blocks back from what the node has seen lately. This would have a couple of advantages. First, it would give finality — 6 blocks would mean the transaction has actually confirmed. Also, this would mean that if a group of loyalist miners could get lucky and push some transactions past the 6 block mark, there would be no way for the 61% attacker to ever perform a reorg.

But what could go wrong? Why didn’t Satoshi hardcode this into the protocol? What could happen is that if you get a legitimate fork to last more than 6 blocks, it will never be resolved conclusively. The beauty of the simple rule determining the correct chain as put forward by Satoshi is that there will never be any discrepancy. If nodes agree to such a rule they will be forced to either disagree or abandon one chain for the choice of the Economic Majority, if that fork ever happens. So if by miscommunication or other shenanigans the fork happens, the only hope would be for some communication and discussion, and some agreement on which chain is real. This will bother miners who will be cheated out of a fair shot at keeping the blocks. If you had superior hash power, this could be exploited. You could simultaneously publish sets of six blocks to different sets of miners. Somehow the rule, whatever it is, will force them to decide. If you play this correctly, you’ve just created a fork that can’t be undone without discussion by the nodes.

The goal was to disrupt consensus and force the people who run Bitcoin, whoever they may be, to be confused and bicker with one another.

Karen attack

This attack is inspired by a statement from Jimmy Song last week on Clubhouse, who said that he would know which blocks are invalid because these will be the blocks that don’t process his transactions. Let’s run with this. Once we have 61%, we pick someone like Jimmy and we don’t process any transactions nor build on blocks that process his transactions. We let this go on for some time. Jimmy sees this and determines that his blocks are being censored. So Jimmy knows for sure which blocks are bad. What is his recourse? He can’t run that many nodes, so he has to channel his inner Karen and try to convince all of the other nodes to invalidate these blocks. This might be a hard sell, and Jimmy might not be successful. So we add more Karens. We pick more people, preferably big players, and slowly add them to our excluded list, and eventually there a huge mob of Karens who are demanding that the nodes invalidate the transactions.

Eventually, the Karens win, and the nodes have to make some decisions. Someone’s gotta be the manager. You have to come up with a criterion for invalidating blocks. The criterion can not simply be that some transaction got left in the mempool, for a number of reasons: First there is no The Mempool, each node could claim a different mempool. Further, you can flood the mempool with small transactions. They won’t all fit, and from each transaction that doesn’t make a block, you get an angry Karen. Remember, because you are part of a coalition that is controlling the blockchain, you can both offer and collect large mining fees to push other transactions out of the mempool. So Bitcoin users will become an angry mob of Karens, demanding to know why their transaction isn’t going through. Some of these could be real Karens, but they could also be Sybil Karens, demanding to know why their fake transactions didn’t make the blockchain.

So what do the nodes do? If the mempool is overfull, and only 10% of transactions are being processed, is that Bitcoin?

There’s a basic principle at play here. For every possible rule that nodes could adopt to thwart your attack, you can always come up with a block that doesn’t violate these rules but is also clearly malicious. I like to call this Cantor Diagonalization. Eventually, there will be so many rules for blocks and transactions that running a node will be a hands-on full time job and Bitcoin will be pretty much useless.