BIP 440/441: adjust varops budget calculation and add missing OP_BOOLAND

bip-0440.mediawiki

@@ -10,7 +10,7 @@
   License: BSD-3-Clause
   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
-  Version: 0.2.1
+  Version: 0.2.2
 </pre>
 
 ==Introduction==
@@ -49,7 +49,7 @@ The last two assumptions make a large difference in practice: normal usage on sm
 
 ==Design==
 
-A per-transaction integer "varops budget" is determined by multiplying the total transaction weight by the fixed factor 10,000 (chosen to make operation costs all integer values). The budget is transaction-wide (rather than per-input) to allow for cross-input introspection: a small input may reasonably access larger inputs.
+A per-transaction integer "varops budget" is determined by multiplying the transaction weight, excluding the weight of inputs not evaluated under Tapscript v2, by the fixed factor 10,000 (chosen to make operation costs all integer values).  For this calculation, an input's weight is the serialized size of its outpoint, scriptSig, and sequence multiplied by the witness discount factor, plus the serialized size of its witness stack; all CompactSize prefixes are included.  A transaction without a Tapscript v2 input has no varops budget.  Transaction-level fields and outputs remain included, so the total transaction weight is used when every input uses Tapscript v2.  Excluding other inputs prevents their weight from funding both pre-existing resource limits and Tapscript v2 execution; for example, a BIP342 input's witness weight could otherwise fund both its own sigops budget and Tapscript v2 execution.  The budget is transaction-wide (rather than per-input) to allow for cross-input introspection: a small input may reasonably access larger inputs.
 
 Opcodes consume budget as they are executed, based on the length (not generally the value) of their parameters as detailed below.  A transaction which exceeds its budget fails to validate.
 
@@ -67,7 +67,7 @@ The script is assumed to execute in a single thread and acts on initial stack el
 
 Ideally, on each platform we tested, the worst case time for each opcode would be no worse than the Schnorr signature upper bound: i.e. the block would get no slower.  And while CHECKSIG can be batched and/or done in parallel, it also involves hashing, which is not taken into account here (the worst-case being significantly slower than the signature validations themselves).
 
-The signature cost is simply carried across from the existing [[bip-0342.mediawiki|BIP-342]] limit: 50 weight units allow you one signature.  Since each transaction gets varops budget for the entire transaction (not just the current input's witness), and each input has at least 41 bytes (164 weight), this is actually slightly more generous than the sigops budget (which was 50 + witness weight), but still limits the entire block to 80,000 signatures.
+The signature cost is simply carried across from the existing [[bip-0342.mediawiki|BIP-342]] limit: 50 weight units allow you one signature.  For transactions containing both BIP342 and Tapscript v2 inputs, excluding the BIP342 input weight prevents its witness weight from funding both validation budgets.  Each input has at least 41 bytes (164 weight), so its excluded weight covers BIP342's allowance of 50 plus its witness weight.  The transaction weight funding the remaining varops budget is disjoint from that allowance and bounded by block weight, preserving the limit of 80,000 signatures per block.
 
 ===Benchmarks===
 
@@ -348,6 +348,7 @@ Work in progress:
 
 ==Changelog==
 
+* 0.2.2: 2026-07-31: exclude non-Tapscript-v2 input weight from the varops budget.
 * 0.2.1: 2026-06-15: define wordspan notation and clarify byte-length versus word-span costs.
 * 0.2.0: 2026-02-21: increase in cost for hashing and copying based on benchmark results.
 * 0.1.0: 2025-09-27: first public posting

bip-0441.mediawiki

@@ -617,6 +617,7 @@ The varops costs of the following opcodes are defined in
 * OP_PICK
 * OP_TUCK
 * OP_ROLL
+* OP_BOOLAND
 * OP_BOOLOR
 * OP_NUMEQUAL
 * OP_NUMEQUALVERIFY