What #BIP110 does is pretty minimal actually.
1. It limits new ScriptPubKeys to 34 bytes;
2. It limits OP_RETURN outputs to 83 bytes;
3. It limits data pushes and witness elements (contiguous data) to 256 bytes;
4. It removes OP_IF inside Tapscript;
5. It disables the Taproot annex and undefined witness versions / OP_SUCCESS;
6. It limits Taproot control block size (~257 bytes);
This only applies to newly created UTXOs.
And the following are my 80 IQ interpretations of each of those changes:
1. It restricts how complex a new payment address can be so people can’t sneak large chunks of arbitrary data into normal Bitcoin payments.
2. It caps how much extra data can be attached to a transaction so Bitcoin blocks don’t turn into general-purpose message boards / free cloud storage.
3. It prevents hiding large files inside transaction data by limiting how big any single chunk of stored data can be.
4. It removes a scripting trick that lets people hide data like inscriptions inside conditional branches that aren’t meant to be used for payments.
5. It closes lesser-known backdoors in Taproot that can carry arbitrary data while pretending to be normal transaction components.
6. It limits how large Taproot script trees can grow so they can’t be abused to store massive hidden data structures.
This soft fork is intended to be TEMPORARY. It means that after a one-year period the new rules automatically expire if they aren’t explicitly extended. The main reasons are:
1. A permanent soft fork consensus change can otherwise only realistically be reversed with a hard fork.
2. It acts as a pressure valve while longer-term policy and consensus rules are debated.
3. The one-year window serves as a trial period to verify no critical bugs exist, no unintended consequences appear, and no new methods for stuffing arbitrary data into scripts are discovered.
