Numerous proponents of the BIP-110 soft fork have claimed that decreasing the limits of various data pushes helps reduce the blockchain size. However, they have not provided any numbers. This calculator does.
Given a spammer that is sufficiently wealthy to try spamming in the first place and their desire to put x bytes of data into the chain, this calculator calculates both how much more it would cost him (weight) and how much more it would cost the network (size). The calculator can compute the results for multiple techniques used to bypass the limits, so you can also compare those.
| With current limits | With new limits | |
|---|---|---|
| Stored size on full archival (non-pruned) node | - | - |
| Transaction weight paid | - | - |
| Size increase | - |
| Weight increase | - |
| Damage factor | - |
Bitcoin scripts and transaction structures impose limits on the size of individual data pushes and certain script fields. When spammers attempt to embed large amounts of arbitrary data in transactions, these limits often require splitting the data across multiple pushes, outputs, or witness elements.
Each split introduces additional overhead such as opcodes, push length prefixes, extra script structure, and transaction metadata. This overhead increases both:
This tool estimates that overhead by comparing two scenarios:
The difference between these scenarios shows how protocol limits can increase both blockchain storage requirements and transaction fees.
Different techniques exist to bypass script size restrictions. Each method stores data in different parts of the transaction and introduces different types of overhead. The calculator includes several approaches, each of which can be selected in the input section above.
As you can see, the default limits in the calculator match those in BIP-110. You can thus play with different data sizes and bypass techniques to find how it will affect the spammers and the network. The amount of damage to the spammer can be measured by weight, the amount of damage caused to the network can be measured by size.
As can be seen from the results, except for weird edge cases, the limits damage the network disproportionately more than the spammers (expressed by damage factor). For multi-output workaround the difference is huge. As a result, after the BIP-110 fork, things like Citrea would cause much more damage to the network than they would without the limits while paying only a little bit more fees.
Additionally, it can be seen that some techniques require only extremely tiny overhead. E.g. inscriptions can be updated such that they will only suffer less than 0.4% cost increase while the network will suffer slightly more than what they pay for.
As such, the BIP-110 is practically ineffective at stopping inscriptions, contiguous data (as demonstrated at the root page of this website), other kinds of spam or illegal content. It's just an empty virtue signal that only complicates the Bitcoin network, risks freezing funds or losing them in the chain split, damages the reputation of Bitcoin as a reliable system and increases the load on the network. This is not worth 0.4% increase on spam cost.
You might still be wondering "but isn't it at least annoying to have to change the code?" Here's the thing: anyone who wanted to put a significant amount of data on chain was already using witness because it was cheaper. And that already required splitting up the data into 520B chunks. So the only change that is required is to find all occurrences of the number 520 and change it to 256. This takes about a minute. If the developer used a constant this takes about 5 seconds. I know this from first hand experience dealing with the project presented on the main page.
This calculator calculates the actual size of data that will end up on disk. In case of full archival (non-pruned) nodes that means the size of UTXO as stored in the database is added to the size of the spam and overhead because that is exactly what full archival nodes store.
While it might look strange that nodes store some data twice, it'd be very hard to de-duplicate it. Either the UTXOs would need to point to the transactions which would make pruning much more complicated or transaction outputs would need to be put into UTXO set only but then removing them from UTXO set would require moving them back to the transactions. Both of these options seem unworkable. But if you have a clever solution to this I'm sure the Core developers will aprreciate a PR.
The calculator makes a few assumptions:
The additional costs of the spammer - the weight of inputs and the change output is not added to the result but the assumption that there is a change output affects the lengths of input/output counts thus it will (correctly) show a bit more overhead in some special cases than what the transaction would have if there was no change output.
While great care was put to make the calculator accurate I cannot guarantee that there aren't weird edge cases, in particular for cases when the limits are very small or very large (close to the block size).