Attack Blocks

Abstract: In this piece we examine “attack blocks”, blocks constructed such that they are difficult to validate. This is when an entity hostile to Bitcoin produces an “attack transaction”, designed specifically such that it takes a long time for nodes to verify. This concept was first discussed in January 2013, when an attack transaction around 1MB in size, that would take an ordinary computer around three minutes to verify, was proposed. There are variations of this attack, not discussed in detail in this report, that could make the situation orders of magnitude worse. The BIP-54 softfork proposal contains a fix for this issue, a limit on the total number of CHECKSIG and CHECKMULTISIG operations in the non-SegWit inputs for any given transaction.

Overview

This is the fourth article in a series of articles about potential Bitcoin vulnerabilities, which are fixed or mitigated with BIP-54:

1. Bitcoin's Duplicate Transactions - March 2025

2. The Timewarp Attack - March 2025

3. 64 Byte Transactions - December 2025

In this fourth and final piece we look at one of the most severe potential vulnerabilities, the possibility of a malicious block, that takes an extremely long time for a node to verify. This issue is often called the worst case block validation problem.

Worst Case Block - History

In January 2013, Bitcoin security researcher Sergio Lerner made a post to Bitcointalk. In this post Sergio explained that one could construct a valid Bitcoin transaction that would take at least three minutes for a node to verify. This can be achieved by creating a transaction with many (pre-SegWit) inputs. These types of inputs suffer from the quadratic scaling of sighash operations weakness.

Sergio explained that a single Bitcoin transaction, a transaction which was just under 1MB in size, could result in over 19GB of data being hashed, which would take over three minutes for an ordinary computer to verify. The constraint on the severity of this vulnerability was the 1MB blocksize limit, without this limit, the attack could be even worse. In Sergio’s example the transaction was invalid, but the attack is still potentially critical, since it can take a long time for a node to determine if the transaction is valid or not. In later iterations of this malicious transaction, the transaction can also be valid. Nevertheless, taking three minutes to verify just one transaction is obviously a serious problem. We have outlined some of these problems in the below table.

Potential Negative Consequences of An Attack Transaction

The Blocksize War

The issue of the hard to verify attack blocks came up during the Blocksize War, which was waged from 2015 to 2017, as a key reason for not increasing the blocksize limit, at least without adding new limits, to restrict the impact of this attack.

In December 2015, Bitcoin security researcher Jonas Nick gave a presentation in Hong Kong, as part of “Scaling II”, about this very topic and in his presentation he explained why the blocksize limit should not be increased, without taking steps to add new resource limits to each Bitcoin block, to mitigate the impact of this attack.

^{Source: https://youtu.be/vfIs_trEhao?si=oRu2x6CfWhFbxG2R&t=3692}

In January 2016, a blog post on the Bitcoin Core website explained the advantages of SegWit. A key advantage is that SegWit fixes the non-linear scaling of sighash operations bug. This is why SegWit seemed like such a strong solution to the problem of scaling Bitcoin, it kept a 1MB limit for old buggy transactions, while it increased the blocksize for transactions that were not exposed to this potentially critical vulnerability.

In essence, doubling the size of a transaction can double both the number of signature operations, and the amount of data that has to be hashed for each of those signatures to be verified. This has been seen in the wild, where an individual block required 25 seconds to validate, and maliciously designed transactions could take over 3 minutes.

^{Source: https://bitcoincore.org/en/2016/01/26/segwit-benefits/}

In March 2021, we published a book on the Blocksize War, where we discussed the worst case block issue. We mentioned that such a block could take “many hours” to validate, which is very different from the three minutes mentioned publicly from 2013 to 2016. This is because certain Bitcoin security researchers mentioned to us that they had found ways to optimise the attack and make the situation significantly worse, such that multiple hours were in play. On the other hand perhaps our “many hours” comment was a bit unrealistic, unless one is using a low end device like a Raspberry Pi.

The non-linear scaling of sighash operations means that, as the number of inputs in a transaction increase, the number of hashing operations required to validate the transaction increases quadratically rather than linearly. This scaling problem was an impediment to larger blocks, as attackers could create transactions which took so long to verify that the network could grind to a halt. This issue was actually one of the main reasons cited by small blockers for opposing blocksize limit increases, as attackers could exploit this weakness. An attacker could construct a block which contained many of these large transactions, such that it could take an ordinary computer many hours to validate. Therefore, to many small blockers fixing this issue was a prerequisite to a blocksize limit increase. They derided the large blockers for complacency in overlooking this weakness and lacking an adversarial mindset.

^{Source: The Blocksize War}

Malicious Block Calculations

In this section of the report, we try to explain the attack in more detail. There are three Bitcoin consensus limits to consider when preparing the malicious attack transaction.

For the purpose of our calculation, we explain the most basic form of the attack, even more simple and oversimplified than the one outlined by Sergio in 2013. The idea is that one first needs to conduct set-up transactions, presumably in a different block, to avoid wasting resources with the 1MB blocksize limit constraint. In the set-up transactions the attacker creates many outputs that consist of the opcode OP_CHECKSIG, 200 times. After this, using those outputs, the attacker is ready to create the malicious transaction. This attack transaction spends all these outputs as inputs and has perhaps one output of its own, in our scenario. Each input could have 1 valid CHECKSIG and 200 dummy CHECKSIGs, padded to the 10KB limit. This maxes out the impact of the attack, using up all the relevant limits.

Given this transaction set-up, we used the very basic approximate formula below, to calculate the total data that would need to be hashed, to verify the transaction. Please note that the formula includes a square of the number of inputs, to reflect the quadratic scaling of sighash operations bug, the more inputs are added, the more hashing is required, with a quadratic relationship.

Total data to be hashed (KB) = 201 * N * (10KB + N)

Where: N = The number of transaction inputs

Using the above formula, the below chart shows how the amount of data one needs to hash varies depending on the number of transaction inputs in this set-up. One can see the shape of the curve resembles a quadratic function. To clarify, the above formula is inaccurate and does not precisely count the amount of data hashing required, it is meant as an illustration, to very roughly approximate the scale problem and the mathematical relationships involved.

Total amount of data required to be hashed Vs the number of transaction inputs

The chart stops at just over 8,000 inputs, this is because at this point the transaction is likely to be around 1MB in size, which is the limit for pre-SegWit transactions. To verify this transaction a node would need to hash over 30GB of data. This is therefore the worst case, in our very basic example and perhaps somewhat inaccurate example of an attack transaction. Our understanding is that the amount of data that needs to be hashed is the key vulnerable metric for these attack transactions, as opposed to other tasks like ECDSA signature verification and therefore it is what we are focusing on.

Using the 0.005 ms of time required for each KB of hashing, mentioned by Jonas Nick in his 2015 presentation, with his laptop from 2014 (a 2 core 3GHz i7 machine), the below chart shows how long these attack transactions could take to verify. In the worst case scenario, it takes over 150 seconds to verify a transaction, which is over two and a half minutes. This is clearly potentially a critical vulnerability. In a recent report we published, on node performance, our nodes typically verified around 15 blocks per second. This attack block is therefore a slowdown in verification speed compared to a typical block, of around 2,300x.

Time taken to verify the attack transaction Vs the number of transaction inputs

On the other hand, machines are a lot faster now than in 2015 and inputs can be verified in parallel. Therefore, the verification time chart above may be a little conservative for today’s machines.

The BIP-54 Fix

The fix for this problem proposed in BIP-54 is relatively simple. There is a new consensus limit which restricts the total number of the following, in each transaction:

1. CHECKSIG and CHECKMULTISIG operations in all of the non-SegWit inputs

2. Previous output's scriptPubKeys

If a transaction contains more than 2,500 of the above, it's invalid.

With this fix in place, the attack transaction scenario we outlined above, would only contain 12 inputs, which results in just 24MB of hashing per block. This could take around 0.1 seconds to verify. The problem is clearly pretty much fixed, at least in our very basic example.

Conclusion

It should be noted that our calculation and example was pretty basic and an oversimplification. There are a number of clever tweaks one can do to make the situation significantly worse, well over an order of magnitude worse, to be a bit more precise. For example outputs with long scripts could be added to further increase the amount of data that needs to be hashed. In these extremely bad case scenarios, this may present a crisis for the Bitcoin network, with an attack block taking over an hour to verify and perhaps with a significant percentage of the nodes dropping off, perhaps permanently.

However, fortunately, the attack is incredibly complex to pull off. Firstly the attacks involve non-standard transactions and it is very likely that a miner would have to conduct these attacks. Even if using a direct to miner submission service (e.g. Marathon’s Slipstream), the miner probably has some safety logic built in and is not going to sit there spending hours verifying the transaction an attacker submitted to them. Therefore, a miner would need to conduct the attack themselves. Secondly, these worst case scenarios involve many complex set-up transactions, which would take up the space of multiple blocks before the attack block was produced. It is possible, if the attacker isn't careful, that people monitoring the Bitcoin network could detect these set-up transactions and warn users about the need for an emergency softfork, which may or may not be able to occur to prevent the attack. Therefore this vulnerability may have similar characteristics to the Timewarp Attack, in this respect.

Nevertheless, despite the complexity of the attack, in our view this is a very significant problem for Bitcoin and it requires a fix. This issue is perhaps the most severe of the four issues that BIP-54 would fix. In order of the most severe to the least severe, we would rank the four issues as follows:

1. Attack Blocks

2. The Timewarp Attack

3. 64 Byte Transactions

4. Bitcoin's Duplicate Transactions