Slow Block Validation Attacks

One potential threat for disrupting the game theory of mining is an attack in which an adversarial miner constructs complex blocks containing transactions that take an inordinately long amount of computational resources (and thus time) to validate. This is one of many reasons for which developers have advocated for keeping block sizes small.

The quadratic signature hashing attack is one such issue that was addressed with the addition of Segregated Witness. There are still other outstanding issues that need resolution, and Rusty Russell's Great Script Restoration Project aims to rectify them by implementing a more precise system of calculating computation cost of transaction validation.

Recently I wondered: how much of an advantage would performing a slow block validation attack actually give to an adversarial miner? To describe the effective hashrate advantage a miner gains by delaying other miners from starting to mine a new block for X seconds, we can model the situation with the following factors:

Variables:

• T: Expected time to find a block in seconds (600).
• X: Time delay (in seconds) the miner imposes on other miners by sending them a block that's slow to validate.
• Z​: Proportion of total hashrate the attacking miner controls.

Of course in reality, the X delay will vary from miner to miner because it's dependent upon the speed of the hardware that's running their fully validating node software.

Any given miner’s expected time to mine the next block follows an exponential distribution with a rate proportional to their hashrate. Given that the expected block time for the entire network is 600 seconds, the rate of block finding will be:

• Miner's rate: Z / 600
• Rest of network's rate: (1-Z) / 600

We can now calculate the probability that a slow block validation attacking miner finds the next block before the rest of the network if they have a head start of X seconds:

Graphing Some Scenarios:

The resulting outcome is actually not as bad as I expected, as I was naively thinking that an attacker that can delay the rest of the network by 10 minutes can effectively 51% attack the network. But we have to keep in mind that the attacker themselves is still required to mine a block at the same high difficulty and their true hashrate doesn't increase, thus their expected time to find a valid block remains the same.

Another surprising finding is that this attack actually becomes less effective as the attacker's hashrate increases. That is to say, the required head start in order to achieve a similar multiplier effect increases more as the attacker's real hashrate increases.

An attacker with 1% of the total network hashrate can double their effective hashrate if they can give themselves a 7 minute head start mining the next block.

An attacker with 5% of the total network hashrate can double their effective hashrate if they can give themselves a 8 minute head start mining the next block.

An attacker with 10% of the total network hashrate can double their effective hashrate if they can give themselves a 9 minute head start mining the next block.

An attacker with 20% of the total network hashrate can double their effective hashrate if they can give themselves a 12 minute head start mining the next block.

What Would Happen Practically?

To be clear, if extremely complex blocks that were slow to validate started flooding the network, sophisticated miners would not simply stop hashing. I expect that most of them would validate the block header (which is always fast) and would start working on mining a template for an empty block that contained no transactions.

Miners won't add transactions into their block template until they're sure it's safe to do so by updating their UTXO set after the previous block's transactions are fully validated.

Thus, if such an attack were to occur, the attacking miner would not suddenly become the dominant miner for all blocks, but they likely WOULD become the only miner including transactions in blocks. As such, we'd expect the on chain transaction throughput to plummet, causing the supply of block space to plummet, and thus if demand remained the same then the going rate for block space and thus transaction fees would spike rather high.

As such, the expected profitability from such an attack would be excess transaction fees achieved by essentially cornering the market for block space. This could potentially be a fairly profitable attack if it is conducted during a time in which demand for block space is already high.