* [bitcoindev] [Proposal] Tapleaf 0xc2: An overview of the Great Script Restoration (GSR)
@ 2026-11-06 9:30 'Julian' via Bitcoin Development Mailing List
0 siblings, 0 replies; only message in thread
From: 'Julian' via Bitcoin Development Mailing List @ 2026-11-06 9:30 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 7413 bytes --]
Hi all!
Building on the BIP quartet post from last year, we are excited to
update you with a more complete framework for restoring and enhancing
Script's capabilities.
Summary
---------------
This is now a set of five proposals that together define Tapleaf 0xc2,
the second Taproot leaf version. It restores the script capabilities
disabled in Bitcoin 0.3.1, adds transaction introspection and extended
primitives, and limits the validation cost of each 0xc2 script with an
explicit computational budget. Legacy, segwit v0 and Tapleaf 0xc0
scripts are unchanged.
Together they form the Great Script Restoration (GSR): we are safely
restoring Script to its original power and making it great to build on
with the addition of missing tooling and primitives. The name now refers
to all five documents, not only the varops budget and the restored
opcodes. The 2025 quartet already proposed OP_TX and a set of new
opcodes; those opcodes are now Extended Primitives, and Reusable Macros
is new.
The five documents
-------------------------------
1. BIP 440: Varops Budget For Script Runtime Constraint
Generalizes BIP 342's sigops budget to every operation: a
transaction-wide budget funded by weight, from which each executed
opcode pays. The calibration target is that no block validates slower
than the slowest block possible today.
2. BIP 441: Restoration of disabled script (Tapleaf 0xC2)
Defines the new leaf version, re-enables the fifteen opcodes disabled
in 0.3.1, makes numbers arbitrary-length unsigned integers, and
raises stack limits.
3. OP_TX
Transaction introspection: a six-byte selector chooses fields from
the spending transaction, its spent outputs and the Taproot execution
context. Values are pushed individually for arithmetic, or collated
into one element for hashing.
4. Tapleaf 0xc2: Extended Primitives
OP_CHECKSIGFROMSTACK verifies a signature over any message on the
stack, OP_TWEAKADD lets a script compute the key of the next output,
and OP_BYTEREV reverses the bytes of an element. No new cryptography
is introduced.
5. Reusable Macros in Tapleaf 0xc2
To optimize block space usage, a script can declare a repeated
instruction sequence once. References are replaced before execution,
so a script with macros behaves exactly like its inline expansion.
Design and scope
----------------------------
- What it enables: General covenants, including recursive ones that
carry state from output to output; custom sighash modes and rebindable
signatures; Taproot outputs built from computed data; and verification
of proofs and hash-based signatures in script. The last makes a
post-quantum fallback expressible without a new opcode, though Taproot
key-path spends would still need to be disabled.
- Later opcodes become optimizations: Once script can express a
construction, a dedicated opcode for it is only an optimization. CTV-
and TemplateHash-style commitments, for example, can already be built
with OP_TX.
- Soft fork: Leaf 0xc2 is anyone-can-spend today, so every rule here
only restricts and the set is a soft fork.
- Static analysis: Control flow is limited to OP_IF, OP_NOTIF, OP_ELSE
and OP_ENDIF, as today: there are no loops or jumps, and no stack data
is executed as code. Macros don't change this: they are expanded
before execution, into a script of at most 4,000,000 bytes. Each
opcode in it runs at most once, so a script can repeat code only up to
a count fixed when it is written. Numbers never wrap: they grow
instead of overflowing, and a result below zero fails.
- Existing specifications: OP_CHECKSIGFROMSTACK and OP_TWEAKADD keep the
names, values and semantics of BIP 348 and BIP 449, and the set is
compatible with CTV, CSFS or TEMPLATEHASH activating in Tapleaf 0xc0.
Changes to BIP 440 since the last published version
-----------------------------------------------------------------------------------
- Funding: Inputs with their own signature limits, such as Tapleaf 0xc0
inputs, no longer fund the budget.
- Prices: Costs are composed from primitives, with prices (except the
signature cost) refitted from benchmarks. Results from more hardware
are welcome and can potentially raise the final costs.
- A fixed per-opcode cost: Every executed opcode and data push now pays
a fixed charge. This limits the logical operations a budget can fund
even when the encoded script is compressed, so Reusable Macros can be
added safely.
Deployment
-------------------
All five documents define the one new leaf version, and we propose
activating them together as a single soft fork, as the reference
implementation does under one deployment.
Implementation and tests
-----------------------------------------
A Bitcoin Core fork implements this proposal, including unit, functional
and fuzz tests matching the JSON vectors in bip-0441/.
Open questions
-------------------------
- Direction and risks: Whether this comprehensive consensus change is
the right direction for Bitcoin, and whether the capabilities it adds
outweigh its risks and potential negative consequences. MEV is often
raised as
one: if covenants enabled shared contracts whose outcome depends on
transaction order, such as on-chain exchanges or auctions, miners
might profit from ordering transactions, which would favor large and
sophisticated miners.
- Segmented evaluation: Whether OP_SEGMENT, in which an OP_SUCCESS
opcode affects only its own segment, is useful enough to add. It would
let a covenant require a fixed prefix, such as a delay, ahead of
script another party supplies in the same leaf.
- Arity opcode: Whether OP_MULTI, which lets the following opcode take a
variable number of operands, is worth adding. It would let a script
combine a large, variable number of values, such as input amounts.
- Amount accounting across inputs: Whether an opcode should let
validation check the amounts that several inputs claim, as
OP_CHECKCONTRACTVERIFY (BIP 443) and OP_VAULT (BIP 345) propose. Each
input's script runs separately, so unless the scripts coordinate, one
output can satisfy
two inputs.
Links
--------
- BIP 440: https://github.com/jmoik/bips/blob/gsr-full/bip-0440.mediawiki
- BIP 441: https://github.com/jmoik/bips/blob/gsr-full/bip-0441.mediawiki
- OP_TX: https://github.com/jmoik/bips/blob/gsr-full/bip-unknown-optx.md
- Extended Primitives:
https://github.com/jmoik/bips/blob/gsr-full/bip-unknown-extended-primitives.md
- Reusable Macros:
https://github.com/jmoik/bips/blob/gsr-full/bip-unknown-reusable-macros.md
- Reference implementation: https://github.com/bitcoin-gsr/bitcoin/tree/gsr
- Benchmark data and code: https://github.com/bitcoin-gsr/varopsData
- Previous discussion:
https://groups.google.com/g/bitcoindev/c/GisTcPb8Jco/m/8znWcWwKAQAJ
https://delvingbitcoin.org/t/benchmarking-bitcoin-script-evaluation-for-the-varops-budget-great-script-restoration/2094
Thank you in advance for your review and feedback!
Julian & Rusty
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/34b14b4f-7dce-466e-9d80-1af3b465c40fn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 8532 bytes --]
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2026-11-06 11:49 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-06 9:30 [bitcoindev] [Proposal] Tapleaf 0xc2: An overview of the Great Script Restoration (GSR) 'Julian' via Bitcoin Development Mailing List
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox