The Bitcoin Empty Block attack, revisited

Jose Femenias
8 min readMar 31, 2021
Empty blocks

In this youtube video, you can watch a rather interesting -if harsh- debate between Mike Green, chief strategist and portfolio manager at Logica Capital, and Anthony Pompliano (Pomp), investor at Pomp Investments and a very popular podcaster. During the debate, Mike raised a valid concern that wasn’t properly addressed by Pomp: “The Empty Block Attack”.

Anthony Pompliano and Mike Green

The attack can be summarized readily: A non-economic actor -the villain is usually China- buys, builds or somehow coerces enough hashing power to guarantee control over the Bitcoin blockchain, so it can continually produce the longest chain. Then, it uses that power to mine only empty blocks, thus destroying the usefulness of the blockchain and causing its ultimate demise.

The key word here is ‘non-economic’. While most attack scenarios, such as the double spending reorg attack don’t make much sense -because they go against the economic interests of the potential attacker- ‘non-economic’ agents aren’t bound by those constraints. As such, they can mount attacks that can be way harder to defend from.

In his medium article “Debunking the Empty Block Attack”, Jimmy Song, with his always engaging and clear style, points out first how difficult it would be for a state agent to amass such large amount of hashpower and then a possible answer that the Bitcoin ecosystem could mount to resist such attack.

I am not going over his arguments since Jimmy does a very good job explaining why the Empty Block Attack is easily defeated with a soft fork.

However, unfortunately, that is not the end of the story. An Empty Block Attack is just the lamest attack a ‘non-economic’ agent can mount against Bitcoin. Other attacks are more nuanced and much harder to protect from, so it pays to study them and consider how the Bitcoin ecosystem could address them, should the need arise.

Censoring 101

Empty blocks can be viewed as an extreme form of censoring by miners. In this scenario, the miner chooses to censor -that is to reject- every single transaction waiting in the mempool. Thus, it generates only empty blocks.
As such, this attack is quite easy to defend from. As Jimmy points out, users can simply choose to ignore empty blocks, thus creating a fork of the blockchain that would have less hashpower, but a much higher economic value.

Unfortunately, Jimmy’s analysis stops there and doesn’t consider other types of censoring, which require a deeper study.

To begin with, the most obvious counter attack the villain can mount is to produce blocks with greater-than-zero transactions. Just including a single transaction in each block would render the defense useless. An attempt to counter-counter attack this, by rejecting blocks with less than n-transactions can be answered by the attacker easily. They only have to produce as many ‘fake’ transactions as needed to avoid being rejected by the users. In the most extreme scenario, the attacker can produce full blocks, filled with valid transactions of non-economic value. The attacker simply has to create n-transactions where the sender and receiver is itself, thus keeping out of the blockchain all the valid transactions, that would be waiting in the mempool forever.

These blocks would not be easy to differentiate from regular, fairly produced blocks. Thus, countering this attack would be much harder.

In an even more nuanced scenario, the attacker could simply reject (censor) transactions that include a subset of the UTXO, transactions above a certain value, transactions that include Coinjoins, transactions with a fee below a threshold, etc., etc.

Could this be the end of Bitcoin?

We haven’t explored but a few of the harmful ways a non-economic attacker can use to undermine the utility of the Bitcoin blockchain. In the most extreme case, the attacker can detract so much value from the blockchain, as to totally destroy Bitcoin. Or can he?

The role of mining pools

Pool stats. Source: https://btc.com/stats/pool

Except for the very first period of Bitcoin history, in most cases, mining bitcoin can only be profitable when the owner of the mining equipment joins other miners in ‘mining pools’. Mining pools are entities that coordinate many mining computers and distribute the rewards among them. They measure the contribution each individual miner makes (using smart trick to measure how many almost-solutions, called shares, each participant generates) and distribute the rewards in fair way. In addition to this, mining pools are also in charge of building the blocks of transactions. Insofar as they decide which transactions are added to or kept out of each block they produce, they have a great amount of power.
There are several recent proposals to decouple the task of coordinating the members of the pool with the task of generating the blocks. By outsourcing the block-building process to the individual miners of the pool, the pool operators can remain neutral and limit themselves to the tasks of mining coordination and profit distribution. The Stratum V2 protocol aims to accomplish this task, thus improving decentralization.

Sun Tzu

Know thy enemy, win the war

“Know thy enemy and know yourself; in a hundred battles, you will never be defeated”. Sun Tzu. The art of war.

As we have seen, pools are ultimately in control of what transactions are recorded in the blockchain. Thus, the many attacks that we have talked about in previous sections can only be orchestrated by the pool administrators.
As you can see in any blockchain explorer such as this, pools usually leave information on each block, so they can be recognized as the solver of the block.

Blocks and pools

The solver of a block, can be usually detected either by the addresses they use to collect the block reward, or by some text they include to claim their ownership. However, that is -for now- entirely optional. Mining pools do it probably for marketing reasons, letting them claim ‘my hose is longer than yours…’.

Bitcoin is, above anything, a social construct. Much like languages, the internet protocols, the unit standards or any other human work that benefits from its network effects, the power of Bitcoin stems from its user base as much as -if not more- its technical properties. That’s what many shitcoin proponents don’t understand: Of course you can build a better Bitcoin than Bitcoin. Any core developer surely has many ideas on how to fix many of the quirks the Bitcoin blockchain has. But the value of Bitcoin is derived in a large part from its successful history. Even with its problems, Bitcoin has proven to be the most reliable and most secure crypto asset. And their users reward it with a market cap and liquidity well above its competitors.

As such, some of the problems Bitcoin may face in the future will need a social, rather than technical answer.

The Empty Block Attack, or -in its more general form- The Bad Block Attack is, in essence a social problem. We are positing that a part of society, a rogue nation in this case, may pose a big threat by acting against the interests of the Bitcoin community, with the sole purpose of destroying it.

Insofar as the attack is social, not technical, it may very well need a social defense.

UASF, round two: censoring the censors

During the Bitcoin wars of 2017, the pseudonymous Bitcoin developer Shaolinfry promoted the first UASF (User Activated Soft Fork) in history, which resulted in the ultimate adoption of Segwit. In essence, UASF is a tool that gives the winning hand to the users of the blockchain, removing power from other actors in the Bitcoin ecosystem (miners, exchanges, developers…). As such, I believe this is the tool that will render any malicious mining attack moot, irrespective of the economic intentions of the attacker.

As Jimmy Song correctly identified in his article, by forking off the blockchain, users can choose the sequence of blocks that better protects their interests.

However, as we have seen, detecting which blocks are valid or not, can’t always be easily accomplished with a technical solution. Thus, we need to combine a technical solution with the social power of UASF.

How can we then prevent those malicious attacks from happening?

The solution I propose is twofold:

a) Know thy enemy
In order to prevent bad actors from adding ill-formed blocks to the blockchain, the very first thing we need is the ability to identify the hand that rocks the cradle, so to speak.
A soft fork can force pool operators (or independent miners, if they wish) to sign every block they produce. They can do this easily, for instance, by spending funds from a known address (that belongs to the pool operator) in the very first transaction. Or by including some kind of signed hash in the coinbase transaction. The method itself is not important. What is critical is that blocks that don’t identify the solving pool will be rejected by the users.

b) My house, my rules
Once pool operators are required to sign their blocks, defending from any attack (empty blocks, censoring, unfair fees, etc.) just becomes a social problem. Whenever a pool operator engages in anti-social behavior a UASF can be orchestrated to reject their blocks, thus negating the incentive to misbehave in the first place.

Conclusion

As we have seen, a non-economic operator can do much more harm than trying to insert empty blocks in the blockchain; the Bitcoin ecosystem is not, however defenseless.
By combining the technical power of UASFs with the social power of their users, the Bitcoin network can and will defend itself from any attack that tries to undermine its value, whether the attacker is an economic actor or not.
In the end, mounting an attack that is doomed from the beginning is a foolish act, since it has a significant cost that will bear no fruit.
As a result, the mere knowledge that the Bitcoin community has the tools and the will -as proven in the past- to fight any such attack should be a good enough deterrent to prevent those attacks from ever happening.

--

--

Jose Femenias

Software engineer, creator of the Easypaysy protocol, with interest in Bitcoin, Economics, IoT