From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 06 Nov 2026 03:49:44 -0800 Received: from mail-oi1-f187.google.com ([209.85.167.187]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1xPIRz-000BUa-T9 for bitcoindev@gnusha.org; Fri, 06 Nov 2026 03:49:44 -0800 Received: by mail-oi1-f187.google.com with SMTP id 5614622812f47-5437a1d6688sf122080b6e.3 for ; Fri, 06 Nov 2026 03:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20260707; t=1793965777; x=1794570577; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :content-type:mime-version:subject:message-id:to:from:date:from:to :cc:subject:date:message-id:reply-to:content-type; bh=xypl6Wf0/K21aYUHs8WVairTObNZPXqfwUtCi4I4eg0=; b=ERD04T51AlyWeqAVT2pAkwe8KVoYhiu92PnSekY4E3UNtZY+vwg44KBIuqGoL3KVko +RzCFLgPIIkzIJkz8Urow1qge/oA6SYp+5MwGAlouxfC9viF4G0JsfIjA4ToV+vo6ecN KCS/oA16dBQe7SnaMBZXyOyg+srPAf5AT82GIJ5rpNyok/L+3OpbXNpykivDCpQ76BsI B755rV5bw6jBp635POHRcPYvnN9C9QkKdPqHkH+U6X4L9trIhlly3sTW6gUIp5RT/Ner toSbbxvIRWXGPt35xEGuhCD2n+XU0nwKxtFaCfcU5X9uYaBYJrK+yNphfRYbtybXAzOi CevQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793965777; x=1794570577; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :content-type:mime-version:subject:message-id:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=xypl6Wf0/K21aYUHs8WVairTObNZPXqfwUtCi4I4eg0=; b=YMKG1nCLRZ6MbLhX7yCLnv2UVgOjdwZiO+VopnkCyQq0hyWE7rtwToEwXk7rmMyBXm dxl32xLi4BRchzb03NGpTLbz6bXagF+Un28V+DFGcsCkqbF3MJk2Lc3Dh1dKLxP+lksJ ZnAf8Wx/YWLswF0a7ccbDbX6NWZLg8oaClbeY1x/z9wQql8Fx/YJjmtsharVOxweO6hS v6vLUA8Gc3niYnshX7Yq+aWBGxR0Ij1SOqtEBs8VkX8LA1/GaxNjB7RKPCdYQZUP9cXN 1RB89a+GADOvKpu5ZNdmwuULEh/hUY84R/7tQPJlALlYfVCPFx25UWjPxbL3qHtsIOxR gJnw== X-Forwarded-Encrypted: i=1; AKwUvBzYCdiVszcUqb4d0/DucXzpeMHJsG2/P8d8foSPIiV7jqdzVhNNUJQ8ljhM0MNU/22RYjUS/9rSesr6@gnusha.org X-Gm-Message-State: APuU4Z8SLXHi6f2in59VaVz7f8B80GiOVm63FiRTUISZT6mcKqm2NR2q hH3W9nJ/GA1TOobEfaRdekJfqY1FUkFTeVXKhUX5qAdmHcNmENx48ypN X-Received: by 2002:a05:687c:3007:b0:4a7:2342:e65e with SMTP id 586e51a60fabf-4ad9819dc60mr1599785fac.0.1793965777396; Fri, 06 Nov 2026 03:49:37 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdfSxD2fS9KE3JDevr6qdbyMnfPuviRAU8VcylLm8LyKUg==" Received: by 2002:a05:6871:e850:10b0:4ad:570e:d91c with SMTP id 586e51a60fabf-4ad96a4c240ls568034fac.0.-pod-prod-03-us; Fri, 06 Nov 2026 03:49:30 -0800 (PST) X-Received: by 2002:a05:6808:1246:b0:4b9:a8ac:47c with SMTP id 5614622812f47-567e14be887mr1436159b6e.26.1793965770676; Fri, 06 Nov 2026 03:49:30 -0800 (PST) Received: by 2002:a05:690c:a648:b0:8b2:da26:98d2 with SMTP id 00721157ae682-8b3412a71d5ms7b3; Fri, 6 Nov 2026 01:30:32 -0800 (PST) X-Received: by 2002:a05:690c:6e09:b0:8b3:392:dc1c with SMTP id 00721157ae682-8b341931a49mr9261687b3.36.1793957431259; Fri, 06 Nov 2026 01:30:31 -0800 (PST) Date: Fri, 6 Nov 2026 01:30:30 -0800 (PST) From: "'Julian' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <34b14b4f-7dce-466e-9d80-1af3b465c40fn@googlegroups.com> Subject: [bitcoindev] [Proposal] Tapleaf 0xc2: An overview of the Great Script Restoration (GSR) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_48267_615150551.1793957430759" X-Original-Sender: Julian.Moik@googlemail.com X-Original-From: Julian Reply-To: Julian Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) ------=_Part_48267_615150551.1793957430759 Content-Type: multipart/alternative; boundary="----=_Part_48268_1319132355.1793957430759" ------=_Part_48268_1319132355.1793957430759 Content-Type: text/plain; charset="UTF-8" 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. ------=_Part_48268_1319132355.1793957430759 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Tapl= eaf 0xc2,
the second Taproot leaf version. It restores the script capa= bilities
disabled in Bitcoin 0.3.1, adds transaction introspection and= extended
primitives, and limits the validation cost of each 0xc2 scri= pt with an
explicit computational budget. Legacy, segwit v0 and Taplea= f 0xc0
scripts are unchanged.

Together they form the Great = Script Restoration (GSR): we are safely
restoring Script to its origin= al 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 alr= eady proposed OP_TX and a set of new
opcodes; those opcodes are now Ex= tended Primitives, and Reusable Macros
is new.

The five doc= uments
-------------------------------

1. BIP 440: Varops B= udget For Script Runtime Constraint
=C2=A0 =C2=A0Generalizes BIP 342's= sigops budget to every operation: a
=C2=A0 =C2=A0transaction-wide bud= get funded by weight, from which each executed
=C2=A0 =C2=A0opcode pay= s. The calibration target is that no block validates slower
=C2=A0 =C2= =A0than the slowest block possible today.

2. BIP 441: Restoratio= n of disabled script (Tapleaf 0xC2)
=C2=A0 =C2=A0Defines the new leaf = version, re-enables the fifteen opcodes disabled
=C2=A0 =C2=A0in 0.3.1= , makes numbers arbitrary-length unsigned integers, and
=C2=A0 =C2=A0r= aises stack limits.

3. OP_TX
=C2=A0 =C2=A0Transaction intro= spection: a six-byte selector chooses fields from
=C2=A0 =C2=A0the spe= nding transaction, its spent outputs and the Taproot execution
=C2=A0 = =C2=A0context. Values are pushed individually for arithmetic, or collated=C2=A0 =C2=A0into one element for hashing.

4. Tapleaf 0xc2: = Extended Primitives
=C2=A0 =C2=A0OP_CHECKSIGFROMSTACK verifies a signa= ture over any message on the
=C2=A0 =C2=A0stack, OP_TWEAKADD lets a sc= ript compute the key of the next output,
=C2=A0 =C2=A0and OP_BYTEREV r= everses the bytes of an element. No new cryptography
=C2=A0 =C2=A0is i= ntroduced.

5. Reusable Macros in Tapleaf 0xc2
=C2=A0 =C2=A0= To optimize block space usage, a script can declare a repeated
=C2=A0 = =C2=A0instruction sequence once. References are replaced before execution,<= br />=C2=A0 =C2=A0so a script with macros behaves exactly like its inline e= xpansion.

Design and scope
----------------------------

- What it enables: General covenants, including recursive ones that=
=C2=A0 carry state from output to output; custom sighash modes and re= bindable
=C2=A0 signatures; Taproot outputs built from computed data; = and verification
=C2=A0 of proofs and hash-based signatures in script.= The last makes a
=C2=A0 post-quantum fallback expressible without a n= ew opcode, though Taproot
=C2=A0 key-path spends would still need to b= e disabled.
- Later opcodes become optimizations: Once script can expr= ess a
=C2=A0 construction, a dedicated opcode for it is only an optimi= zation. CTV-
=C2=A0 and TemplateHash-style commitments, for example, c= an already be built
=C2=A0 with OP_TX.
- Soft fork: Leaf 0xc2 is = anyone-can-spend today, so every rule here
=C2=A0 only restricts and t= he set is a soft fork.
- Static analysis: Control flow is limited to O= P_IF, OP_NOTIF, OP_ELSE
=C2=A0 and OP_ENDIF, as today: there are no lo= ops or jumps, and no stack data
=C2=A0 is executed as code. Macros don= 't change this: they are expanded
=C2=A0 before execution, into a scri= pt of at most 4,000,000 bytes. Each
=C2=A0 opcode in it runs at most o= nce, so a script can repeat code only up to
=C2=A0 a count fixed when = it is written. Numbers never wrap: they grow
=C2=A0 instead of overflo= wing, and a result below zero fails.
- Existing specifications: OP_CHE= CKSIGFROMSTACK and OP_TWEAKADD keep the
=C2=A0 names, values and seman= tics of BIP 348 and BIP 449, and the set is
=C2=A0 compatible with CTV= , CSFS or TEMPLATEHASH activating in Tapleaf 0xc0.

Changes to BI= P 440 since the last published version
-------------------------------= ----------------------------------------------------

- Fund= ing: Inputs with their own signature limits, such as Tapleaf 0xc0
=C2= =A0 inputs, no longer fund the budget.
- Prices: Costs are composed fr= om primitives, with prices (except the
=C2=A0 signature cost) refitted= from benchmarks. Results from more hardware
=C2=A0 are welcome and ca= n potentially raise the final costs.
- A fixed per-opcode cost: Every = executed opcode and data push now pays
=C2=A0 a fixed charge. This lim= its the logical operations a budget can fund
=C2=A0 even when the enco= ded script is compressed, so Reusable Macros can be
=C2=A0 added safel= y.

Deployment
-------------------

All five = documents define the one new leaf version, and we propose
activating t= hem together as a single soft fork, as the reference
implementation do= es under one deployment.

Implementation and tests
---------= --------------------------------

A Bitcoin Core fork implem= ents this proposal, including unit, functional
and fuzz tests matching= the JSON vectors in bip-0441/.

Open questions
------------= -------------

- Direction and risks: Whether this comprehen= sive consensus change is
=C2=A0 the right direction for Bitcoin, and w= hether the capabilities it adds
=C2=A0 outweigh its risks and potentia= l negative consequences. MEV is often raised as
=C2=A0 one: if covenan= ts enabled shared contracts whose outcome depends on
=C2=A0 transactio= n order, such as on-chain exchanges or auctions, miners
=C2=A0 might p= rofit from ordering transactions, which would favor large and
=C2=A0 s= ophisticated miners.
- Segmented evaluation: Whether OP_SEGMENT, in wh= ich an OP_SUCCESS
=C2=A0 opcode affects only its own segment, is usefu= l enough to add. It would
=C2=A0 let a covenant require a fixed prefix= , such as a delay, ahead of
=C2=A0 script another party supplies in th= e same leaf.
- Arity opcode: Whether OP_MULTI, which lets the followin= g opcode take a
=C2=A0 variable number of operands, is worth adding. I= t would let a script
=C2=A0 combine a large, variable number of values= , such as input amounts.
- Amount accounting across inputs: Whether an= opcode should let
=C2=A0 validation check the amounts that several in= puts claim, as
=C2=A0 OP_CHECKCONTRACTVERIFY (BIP 443) and OP_VAULT (B= IP 345) propose. Each
=C2=A0 input's script runs separately, so unless= the scripts coordinate, one output can satisfy
=C2=A0 two inputs= .

Links
--------

- BIP 440: https://github.= com/jmoik/bips/blob/gsr-full/bip-0440.mediawiki
- BIP 441: https://git= hub.com/jmoik/bips/blob/gsr-full/bip-0441.mediawiki
- OP_TX: https://g= ithub.com/jmoik/bips/blob/gsr-full/bip-unknown-optx.md
- Extended Prim= itives: https://github.com/jmoik/bips/blob/gsr-full/bip-unknown-extended-pr= imitives.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: h= ttps://github.com/bitcoin-gsr/varopsData
- Previous discussion:
= =C2=A0 https://groups.google.com/g/bitcoindev/c/GisTcPb8Jco/m/8znWcWwKAQAJ<= br />=C2=A0 https://delvingbitcoin.org/t/benchmarking-bitcoin-script-evalua= tion-for-the-varops-budget-great-script-restoration/2094


T= hank you in advance for your review and feedback!

Julian & Ru= sty

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/34b14b4f-7dce-466e-9d80-1af3b465c40fn%40googlegroups.com.
------=_Part_48268_1319132355.1793957430759-- ------=_Part_48267_615150551.1793957430759--