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.