Skip to content
Cheshire

What Bitcoin Needs: GSR

Cheshire needs Great Script Restoration (GSR): two BIPs that are not active on Bitcoin.

  • BIP-441 restores the opcodes disabled in 2010 (OP_CAT, OP_SUBSTR, OP_LSHIFT, OP_RSHIFT, OP_MUL, OP_DIV, OP_MOD, OP_AND, OP_OR, OP_XOR, OP_INVERT and more). It raises the 520-byte stack item limit to 4 MB and the 1,000-item stack to 32,768, and makes script numbers arbitrary-length unsigned integers.
  • BIP-440 gives each transaction a varops budget: every opcode pays for the bytes it reads and writes, so the restored opcodes cannot be used to make a block slow to check.

Both apply only in a new tapscript leaf version, 0xc2. Nothing changes for existing scripts.

Only GSR

Section titled “Only GSR”

Cheshire uses leaf version 0xc2 with BIP-342 tapscript and the BIP-440/441 opcodes, and nothing else. The GSR test node also enables some draft opcodes in 0xc2 that are not part of BIP-440 or BIP-441. Cheshire uses none of them, and its own checker refuses to build a leaf that contains one.

It is also wrong to call Cheshire “OP_CAT-only”. An earlier version tried OP_CAT alone: it needed about 156 transactions per settlement and could not bind the published records to the proof. Cheshire needs GSR as a whole.

What the opcodes are for

Section titled “What the opcodes are for”
  • The verifier. A STARK verifier is field arithmetic, hashing and Merkle paths. Over the M31 field, multiplication is OP_MUL and OP_MOD; the proof’s transcript is OP_SHA256 with OP_CAT; Merkle paths are OP_CAT and OP_SHA256; query positions are read with OP_SUBSTR. The 7 queries are packed into lanes of one wide number, so one OP_MUL does seven multiplications.
  • The covenant. The leaf rebuilds the previous and current transactions from witness data with OP_CAT, checks the current one with a signature it computes itself (the transaction), and reads the state from the previous one’s caboose.
  • Big items. A settlement’s record blob (~1,900 × 92 bytes) and the proof’s data need stack items far above 520 bytes and a stack deeper than 1,000 items.

How much of the budget it uses

Section titled “How much of the budget it uses”

A settlement’s verifier uses about 13% of its transaction’s varops budget (with the packed query lanes, 2026-11-03). Every leaf has been run through the GSR authors’ gsr check (0 errors, 0 warnings) and through the repository’s own interpreter, which is itself checked against the node’s 629 published BIP-440/441 test vectors.

Where it runs

Section titled “Where it runs”
  • gsr-net: a public signet run by the GSR authors, with 30-second blocks, on bitcoin-gsr/bitcoin branch gsr at commit de567461, where 0xc2 is active. It resets whenever the GSR branch changes consensus, and a reset wipes every coin on it.
  • Local signets and regtests, on the same node software.
  • Not Bitcoin. Neither BIP is active or scheduled there. Cheshire shows what the restoration would make possible; it is not a product.

Semantics worth knowing

Section titled “Semantics worth knowing”

Written down so nobody trips on them again:

  • Under 0xc2, OP_1NEGATE, OP_NEGATE and OP_ABS are OP_SUCCESS (anyone can spend).
  • Shift and bitwise results are not trimmed to a minimal form.
  • Pushes must be minimal for a standard spend.
  • On the node, 0xc2 is a BIP 9 deployment that must be switched on (vbparams=tapleaf_0xc2:-1:0). Without it, a 0xc2 leaf is an unknown leaf version that anyone can spend. Every Cheshire script checks the deployment is active first.