The "Reduced Data Temporary Softfork" BIP proposes temporarily disabling various Bitcoin features in consensus. I have surveyed the blockchain to quantify the potential impact, by identifying historic transactions that violate each of these rules. 🧵↓

Rule #1: "New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid." This affects all P2PK and P2MS outputs, as well as a small number of non-standard SPKs.

Rule #2: "OP_PUSHDATA* with payloads larger than 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs." I assume this only applies to *executed* data pushes, so I've excluded pushes within taproot inscription envelopes, of which there are very many.

Rule #3: "Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141 nor Taproot/BIP 341) is invalid." There are just over 54k transactions with undefined version number outputs (mostly using fake outputs to bypass the op_return limit).

Howver, BIPs 141 and 341 define specific witness program lengths: - v0, length 20 (P2WPKH) - v0, length 32 (P2WSH) - v1, length 32 (P2TR) as written, RDTS seems to ban all other program lengths, including P2A anchors (v1, length 2).

Rule #4: "Witness stacks with a Taproot annex are invalid." So far, 11 transactions have attached an annex to taproot spends, mostly for jpegs.

Rule #5: "Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid." There are ~32k obviously data-embedding taproot spends with control block depth of 100+ (labitbus and similar). But also a handful of "legitimate" spends at lower depth.

Rule #6: "Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid." There are two historic taproot spends including OP_SUCCESS opcodes: Burak's lightning-breaker transaction, and this silly OP_CAT demo

Rule #7: "Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid." This aims to disable the "inscription envelope", which has been used by over 104m transactions so far.

However, RDTS goes beyond disabling the inscription envelope, banning OP_IF and OP_NOTIF entirely. About 70 non-inscription transactions have used OP_IF in taproot scripts. Many are bitvm-style experiments, but there are also examples of more straightforward financial use.

For example, there are a couple of spends using this "decaying multisig" script template, whih uses multiple OP_IFs

Most worryingly, there are multiple spends from a wallet using this HTLC script template behind a bip341 NUMS point (disabling the key path) The script uses OP_IF to choose between a branch requiring two signatures and a hash preimage, or one signature after a relative timeout

RDTS proponents have dismissed confiscation concerns relating to OP_IF and large control blocks in taproot by claiming users can always spend via the keypath instead. However, about 560k transactions have spent taproot outputs where the keypath was provably disabled.