Skip to content

Instantly share code, notes, and snippets.

@douglaz

douglaz/bip-110-analysis.md

Last active July 10, 2026 14:30
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save douglaz/0b31f924ec6f6c63a3c425ccac6ec1d1 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save douglaz/0b31f924ec6f6c63a3c425ccac6ec1d1 to your computer and use it in GitHub Desktop.
Download ZIP
BIP-110: 10-point analysis with counterarguments
Raw
bip-110-analysis.md

  1. BIP-110 is a temporary consensus soft fork against arbitrary data. It adds one-year consensus restrictions meant to reject large data-storage patterns and refocus Bitcoin on money. Counterargument: the problem is not just duration. Even a temporary consensus fork can create permanent governance precedent, coordination risk, and chain-split risk. (GitHub)

  2. It moves data limits from relay policy into consensus. The BIP turns things like OP_RETURN size and large data pushes into block-validity rules. Counterargument: this changes Bitcoin from "valid transaction is valid" toward "valid transaction is valid only if the current majority approves the use case." That is the protocol-neutrality concern.

  3. It caps most new output scriptPubKeys at 34 bytes, while allowing OP_RETURN only up to 83 bytes. The goal is to prevent large spendable-looking outputs from bloating the UTXO set. Counterargument: OP_RETURN is the least harmful place for arbitrary data because nodes can see it is unspendable and exclude it from the UTXO set. If BIP-110 makes OP_RETURN too small for data users, determined users may instead encode data inside many fake P2TR or P2WSH outputs. Those outputs look spendable, so every node must keep them in the UTXO set, creating a worse long-term burden than prunable OP_RETURN data.

  4. It caps OP_PUSHDATA and script-argument witness items at 256 bytes. This blocks large contiguous data blobs. Counterargument: the BIP itself admits users can split, obfuscate, or disguise data. So it does not eliminate data. It mainly raises the fee and complexity cost. (GitHub)

  5. It bans Taproot annex usage during the active period. The annex is currently undefined and can carry arbitrary data, so BIP-110 disables it. Counterargument: the annex is also a forward-compatibility hook. Disabling it blocks or complicates future upgrades, including designs related to LN-symmetry/eltoo-style protocols. (GitHub)

  6. It disables undefined witness/Tapleaf versions and OP_SUCCESS opcodes. The BIP treats these as unused upgrade hooks that can be abused for data. Counterargument: these are exactly the mechanisms Bitcoin uses to preserve future soft-fork flexibility. Freezing them for a year weakens Taproot's upgrade design. (GitHub)

  7. It limits Taproot control blocks to 257 bytes, about 7 Merkle levels or 128 leaves. The BIP wants to stop huge Taproot trees being used for data. Counterargument: this directly constrains advanced Taproot protocols. The BIP itself admits this can complicate or impede BitVM-like smart-contract designs. (GitHub)

  8. It invalidates OP_IF and OP_NOTIF execution in Tapscript. The BIP argues Taproot should use separate leaves instead of script branches, and that skipped branches are used for spam. Counterargument: OP_IF is also useful for Miniscript, vaults, inheritance, escrow, and recovery scripts. The BIP admits Miniscript may need compiler changes and that edge-case Taproot funds could be temporarily frozen or lost. (GitHub)

  9. It includes UTXO grandfathering. UTXOs created before activation are exempt, and after expiry all UTXOs become unrestricted again. Counterargument: this helps old confirmed coins, but not necessarily pre-signed future contract flows where a transaction creates a Taproot UTXO after activation and then needs a now-invalid emergency path during the active window. (GitHub)

  10. It uses an aggressive activation mechanism: 55% threshold, no normal timeout, mandatory signaling, and one-year expiry. The BIP justifies this by saying data rejection is urgent and temporary. Counterargument: there is no clear technical emergency like an inflation bug or consensus vulnerability. A 55% contested soft fork plus mandatory signaling is a dangerous precedent for resolving cultural disputes through consensus changes. (GitHub)

Condensed takeaway:

BIP-110 is a temporary anti-data consensus intervention. Its strongest defense is that arbitrary data creates externalities for node operators. Its strongest criticism is that it uses consensus, with aggressive activation, to enforce a policy preference while only partially solving the data problem and risking damage to Taproot contract design.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment