Here's @mononautical doing the work that I would have expected done by the people who proposed the Reduce Data Temporary Soft Fork: check and see what legitimate transactions your proposed rule changes actually make invalid.
It is necessary to do such checks when proposing making invalid certain currently valid transactions because it's important to know all the use cases you are breaking (even if you intend on breaking some of them) and because your changes might lead to people getting their coins frozen by your rule change -- which is equal to confiscated as far as I am concerned.
People like Chris Guida, Mechanic, and Luke have been dismissive of the confiscation risk of their proposal. Frankly, I find their attitude outrageous. Guaranteeing that we don't confiscate users' coins is as important as the 21 million hard cap. It should be a red line that hopefully never gets crossed.
In the charts below, Mononaut identifies both the transactions types that would be made invalid by the Reduce Data Temporary Soft Fork and the transactions that would be essentially frozen by the soft fork. Identifying transaction types that will no longer be valid ways to use Bitcoin is important because it helps us know how drastic are the changes proposed by this fork; but identifying transactions that may be frozen is imperative because I would argue that the community deciding to freeze even one bitcoiner's coins is something that ought to be very bluntly spelled out: ie. this fork will stop x number of UTXOs from moving for one year.
Mononaut's thread:
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."
Mononaut points out that "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."
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.
Here, Mononaut links to a post from May about someone using the annex to embed 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.
In particular, there is at least one actively used address with historic spends all at control block depth 11, which would be disabled by RDTS.
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.
Here Mononaut notes:
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.
In particular, they provide 2 examples:
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
Mononaut's conclusion:
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.
60% of all blocks historically, but close to 100% of blocks since the launch of ordinal inscriptions contain transactions that the Reduce Data Temporary Soft Fork would make invalid
Here are all the previous transactions that violate rules proposed by the Reduce Data Temporary Soft Fork:
Dathon Ohm's response
Mononaut's thread was published last night, but the only response I saw that was at all technical was the one pictured here from Dathon Ohm. Nothing from Mechanic, Guida, or Luke.