Resolves YES for a particular option if any official release of the Bitcoin Core software made before 2026 includes code that may begin enforcing new consensus rules related to that option, such as after an activation occurs. The activation may occur in 2026 or later (or it may never occur); this resolves YES if there is any situation by which released Bitcoin Core code will enforce a particular proposal.

Please feel free to suggest other options in the comments. I will add any that I think can be well specified.

Terms

• "Bitcoin Core" is the software available at https://bitcoincore.org/ . If the website becomes unavailable or no longer seems to be in control of the active Bitcoin Core developers for an extended period of time, I will update this definition.

• "Any official release" will include any version of Bitcoin Core released at the above website and for which there are valid GPG signatures from at least three long-term contributors (for comparison, the 26.0 release has nine signatures, see https://bitcoincore.org/bin/bitcoin-core-26.0/SHA256SUMS.asc ).

• "Soft fork" is a set of consensus rules that are more restrictive than the previous set of consensus rules.

• "Before 2026" shall be a release before 2026-01-01 00:00 UTC.

• Soft fork descriptions. Because proposals can change names and have their specifications updated, the following defines the minimal criteria that must be satisfied for one of the proposals above to be activated. All of these must be consensus changes---not just clever uses of existing features.

  • OP_CAT shall be an opcode that updates the stack with either the concatenation of two or more elements (e.g., basic OP_CAT) or a cryptographic hash digest of two or more elements (e.g., streaming SHA).

  • OP_CHECKTEMPLATEVERIFY (BIP119), AKA CTV, shall be a single opcode that only succeeds if at least one output of the transaction executing the opcode is identical to an output committed to by the CTV input data. Note, the "single opcode" condition means that a combination of (e.g.) OP_TXHASH and OP_CHECKSIGFROMSTACK can't also satisfy this option.

  • SIGHASH_ANYPREVOUT shall be a signature hash flag that allows a signature to be valid without committing to an input's previous output (prevout) but still requires any conditions of that prevout to be satisfied (e.g., its script).

  • OP_TX shall be an opcode that pushes to the stack serialized parts of the transaction executing it. OP_TXHASH shall be the same except that it pushes the hash digest of the serialized parts.

  • "Forbid 64-byte transactions" shall forbid any transaction's stripped size from being exactly 64 bytes after activation of the fork (it may also forbid other sizes).

  • OP_CHECKSIGFROMSTACK (CSFS) shall allow performing a cryptographic signature check of the same type performed by OP_CHECKSIG but with the data committed to coming from the stack rather than being implied from the transaction.

I will trade in this market.