Problem statement
Since protocol upgrade 1542300000 (November 15th 2018) there is a protocol rule which states that:
Transactions that are smaller than 100 bytes shall be considered invalid.
The reasoning for this is valid, this avoids an attack against a known Bitcoin merkle-tree weakness. (source: Leaf-Node weakness in Bitcoin Merkle Tree Design).
The downside of picking the value 100 bytes is that a default coinbase transaction is smaller than that. The coinbase is special in that it doesn’t have any signatures since it lacks inputs. This means that people (including mining software) creating a coinbase may well hit this limit without realizing and this simply makes life harder than it has to be.
More advanced usage of Bitcoin Cash does show there are quite a lot of valid transactions that can be created which are smaller than 100 bytes, only P2PKH and similar grow in size quite fast, but script certainly allows many other types. These kind of usecases being made impossible was the unintended sideeffect of the introduction of the 100 byte minimum rule.
We suggest to change this and simply refuse transactions of exactly 64 bytes instead. This is enough to avoid the attack explained in the linked article.
Evaluation of solution
In the linked research we find this summary (emphasis mine):
To summarize, the most space-efficient solution without a soft-fork would be hybrid: show inclusion proof of the rightmost tx id branch if the tree is not full, else the coinbase (showing mid-state and length) if length is greater than 64 bytes, or else show the full coinbase transaction.
The author suggests that the coinbase should be larger than 64 bytes. There is no explanation I could find why the BCH developers in 2018 picked 100 instead, which is indeed larger than 64 bytes. But as we saw above, this causes issues for normal usage.
A normal tx can not be smaller than 60 bytes (click for more)
The simplest tx has these values and we count the size in the first column:
Absolute Offs | Size | Description |
---|---|---|
0 | 4 | Version |
4 | 1 | Input count |
5 | 32 | Input 0 Tx hash |
37 | 4 | Input 0 Txout index |
41 | 1 | Input 0 script length |
42 | 0 | Empty Script |
42 | 4 | nSequence |
46 | 1 | Output count |
47 | 8 | value |
55 | 1 | Output 0 script length |
56 | 0 | Output 0 scriptPubKey |
56 | 4 | lock_time |
60 |
Total = 60 bytes with a completely empty transaction.
With regards to coinbases: the existence of BIP34, which forces a serialization of the block-height into the coinbase output script, implies that the minimum size at current height isn’t 60 bytes, BIP34 actually increases this by 4 bytes. The extranonce adds 9 bytes, and a nonempty output script (23 bytes for P2SH) brings a generally used coinbase up to 96 bytes, or 98 for P2PKH.
Following the suggestion from the problem statement to make a transaction any size other than 64 bytes we can see that this has no effect on normal mining where transactions are almost always larger. This affects only the simplest of transactions, and only very specifically crafted ones, and thus have a minimal impact on future users while still making the attack impossible due the the fact that only 64 byte transactions are described to have this issue.
No rationale was given for forbidding transactions lower than 100 bytes, or indeed lower than 64 bytes, as such it seems useful to re-allow them and avoid valid and non-harmful transactions to be forbidden. Future growth of the network is maximized by minimizing the number of rules.
As such we conclude that forbidding only transactions of exactly 64 bytes is the simplest way to protect the network from this issue with minimal impact both technically as well as a minimum harm to future opportunities for users.
Stakeholders
Who do we need to consult for opinion, or at minimum inform of this change.
The full node implementations are the ones currently validating this rule, they reject blocks with a transaction below the 100 bytes threshold. As such they need to implement this change.
SPV wallets can not create transactions below the 100 bytes limit anyway, as such they are not expected to have been affected by the introduction back in 2018, they will not be affected by the change.
Mining software already made for BCH currently forces the coinbase to be at minimum 100 bytes, while they do not need to be updated (their current behavior will stay compatible) it would be useful to inform them this rule is no longer so strict. This also helps people migrate BTC software as the rule is less strict there than it is on BCH.
Proposal
The current network has a rule of 100 bytes per transaction minimum. This rule will be revoked.
In its place we require that any transaction in a block can not be exactly 64 bytes.