Data restriction soft forks are true soft forks

⚠️ Time-sensitive — not re-verified since `asOf` (2026-07-22). The definitional argument (block-validation compatibility vs. user-expectation compatibility) does not expire, but the proposal status wrapped around it does: BIP-110 and the companion "Cat" UTXO draft are described here in the present tense as live proposals, down to "its later revisions added a height check to exclude pre-fork outputs." BIP-110's signaling window has since closed without activation — recorded in op-return-and-arbitrary-data on owner testimony (2026-08-11) rather than a primary source, so even that update is unverified. asOf records the last verification, not the last edit — any editing since then left the date unchanged because it added no re-verification of either draft's status or text. Re-verify both against a primary source before citing them as pending.

Proposals like BIP-110 that invalidate previously-standard transaction patterns are genuine soft forks — backward-compatible tightenings of the rules, not breaks.

For (strongest version as argued): The definition is mechanical: a soft fork only narrows the set of valid blocks, so unupgraded nodes accept every block upgraded nodes produce, and the chain does not split so long as majority hash power enforces the new rules. Previously mined data transactions remain valid and spendable under BIP-110; only new pattern-matching transactions are excluded. Every prior soft fork (P2SH, SegWit, Taproot) likewise made previously-valid things invalid — that is what soft forks are.

Against (strongest version as argued): Mechanically true, substantively misleading. Prior soft forks restricted patterns nobody was using in order to add opt-in capability; a data-restriction fork targets patterns in active use with the explicit purpose of terminating existing workflows — users holding presigned transactions or protocol commitments can find them unmineable through no protocol mistake of their own. Calling that "backward compatible" is a definitional shell game, and the companion "Cat" UTXO proposal — rendering certain existing outputs unspendable — pushed the same logic to where even neutral observers called it asset seizure.

Nuance: Two different compatibility standards are in play: block-validation compatibility (satisfied) and user-expectation compatibility (violated for affected users). Both sides are correct within their chosen definition; a rigorous debate should force the definition into the open. The confiscation-adjacent objections apply with materially more force to UTXO-invalidating designs than to forward-only restrictions.

Common misstatements: "Soft forks can't invalidate anything" (they exist precisely to invalidate — the question is what). "BIP-110 makes existing coins unspendable" (it targets new transactions; the unspendable-output design is the separate Cat draft, and its later revisions added a height check to exclude pre-fork outputs). "A soft fork needs every node to upgrade" (it needs enforcing hash-power majority; non-upgraded nodes follow along).