Delivery-date: Sat, 27 Sep 2025 02:23:32 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of rusty@gandalf.ozlabs.org designates 150.107.74.76 as permitted sender) client-ip=150.107.74.76;
From: Rusty Russell <bitcoin-dev@rustcorp.com.au>
To: bitcoindev@googlegroups.com
Cc: Julian Moik <julianmoik@gmail.com>
Subject: [bitcoindev] [0/4] A Bitcoin Scripting Proposal BIP Quartet
Date: Sat, 27 Sep 2025 17:42:25 +0930
Message-ID: <877bxknwk6.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

Hello all!

	As some of you know, I've been chipping away (with help now from
Julian Moik, Cc'd) at a framework to restore bitcoin's scripting
language to its original power.  My approach has been to stick with
Script: even if you prefer other approaches, you should find this
restoration and enhancement of script capabilities a useful comparison.

Current drafts in "review me!" format:

	https://github.com/rustyrussell/bips/pull/1

Here is a brief description of each:

1. Varops Budget For Script Runtime Constraint (bip-unknown-varops-budget.mediawiki)

This extends and generalizes the sigops budget into a "variable
operations" budget, using benchmarks taken from the prototype
implementation across various machines.  This budget is per transaction,
by weight, designed to constrain usage to ensure rapid evaluation
without overly restricting scripting ability.

2. Restoration of Script Capabilities

Once the safety net of the varops budget is in place, disabled opcodes
can be re-enabled, stack object size and total capacity extended, and
abitrary-length arithmetic restored (though numbers are now always
unsigned).

3. OP_TX

Once script can handle large data once more, the problem of
introspection is signficantly simplified: we can simply have an opcode
which pushes parts of the current transaction onto the stack.  The
concrete design proposed here is a fruitful area for debate and review.

4. New Opcodes for Tapscript v2

The most speculative part of the series suggests some opcodes which
would allow more optimal use of Script: OP_CHECKSIGFROMSTACK,
OP_SEGMENT, OP_BYTEREV, OP_ECPOINTADD, OP_INTERNALKEY and OP_MULTI.
Some of these are old friends, and others may be new to you: I look
forward to your feedback.

There is also a prototype implementation we used for testing:

	https://github.com/jmoik/bitcoin/tree/gsr

Thankyou in advance for your consideration!
Rusty & Julian.

-- 
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/877bxknwk6.fsf%40rustcorp.com.au.