This proposal updates the rule for minimum transation size to clean up technical debt which causes harm and while still protecting users on SPV nodes from being harmed by an attacker.
In June 2018 research was published surrounding a weakness in the interaction of Merkle-tree and Bitcoin's Merkle-block message, as mostly used by SPV wallets.
From [Leaf-Node weakness in Bitcoin Merkle Tree Design](https://bitslog.wordpress.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design/):
> 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 problem is that transactions of size exactly 64 bytes become a small but certain weakness that have potential of being exploited in order to defraud or steal from honest players.
In the November 2018 Protocol upgrade Bitcoin Cash reacted to this by making the transaction size have a minimum of 100 bytes. As a result this exploit is no longer possible on Bitcoin Cash.
This solution, however, created several problems.
The first and most hit is that a default coinbase transaction is smaller than 100 bytes. This means that new mining software creating a coinbase will often hit this limit which is an expensive mistake to make.
Alternative transaction types can be created which are similar smaller than 100 bytes, completely valid transactions.
These usecases all show that the entire ecosystem needs to take this limit into account, a limit unique to Bitcoin Cash. And a limit that is rather arbitrary.
Developers of libraries and software will hit this limit in many cases as well in their library testing software where the transactions created for testing are not about real money, and thus the scripts will not reflect reality. There are many places where automated testing systems had to be adjusted to account for this 100 bytes limit.
* Full nodes need to change the current test for minimum size of a transaction to now check the transaction is any size other than 64 bytes. This is a widening of the allowed transactions and therefore should be scheduled for a future protocol upgrade.
This CHIP is mostly aimed at cleaning up technical debt. The result is less rules for most software. Additionally should this get solved in future on the p2p layer, then we can simply drop even the new rule.
Discussion on [bitcoincashresearch](https://bitcoincashresearch.org/t/consensus-change-proposal-min-tx-size-of-100-bytes-instead-forbid-64-byte-txs/154)
[Leaf-Node weakness in Bitcoin Merkle Tree Design](https://bitslog.wordpress.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design/)
> I reviewed this and would support activation of this CHIP (revision [75b97e22a3dc295de7373255025f38cd0911b866](https://gitlab.com/bitcoin.cash/chips/-/blob/75b97e22a3dc295de7373255025f38cd0911b866/CHIP-2021-01-Allow%20Smaller%20Transactions.md)) in the first network upgrade after May 2021. ([source](https://bitcoincashresearch.org/t/consensus-change-proposal-min-tx-size-of-100-bytes-instead-forbid-64-byte-txs/154/32?u=tom))
> I’ve reviewed the CHIP and support it as written. My interest is as a development stakeholder. ([source](https://bitcoincashresearch.org/t/consensus-change-proposal-min-tx-size-of-100-bytes-instead-forbid-64-byte-txs/154/31?u=tom))
> Awemany (working as a BU dev) and I originally brought this problem to the BCH community’s attention. When ABC chose to limit at 100 bytes I pointed out this was idiocy way back before the original fork, and was ignored. So BU is happy to support a change that fixes yet-another-dumb-decision autocratically made during the ABC days. ([source](https://bitcoincashresearch.org/t/consensus-change-proposal-min-tx-size-of-100-bytes-instead-forbid-64-byte-txs/154/36))
