Posted by Julian'
Nov 28, 2025/13:09 UTC
In the development of Tapscript V2, a significant change has been introduced involving the implementation of a new SigVersion::TAPSCRIPT_V2. This version diverges from the original by not taking the sigops constraint into account. Instead, it introduces a varops budget to replace the sigops constraint, which is detailed in a modified EvalScript function. This adjustment aims at making the cost calculation more static, proposing that the varops cost should be subtracted regardless of the success of the checksig operation.
The motivation behind this shift towards a varops budget stems from the necessity to avoid transforming block assembly into an NP-hard packing problem. This requires maintaining a singular dimension of constraint solving rather than juggling both the new varops and the original sigops constraints. In parallel, the framework utilized in Simplicity inherits the budget mechanism from tapscript V1, opting for static rather than dynamic cost calculations at runtime.
Addressing the issue of opcodes leading to denial-of-service attacks due to excessive computational demands during Bitcoin script execution, a proposal to generalize the sigops budget in a new Tapscript leaf version has been put forward. The aim is to apply this generalized budget across all operations before considering the restoration of computationally intensive operations or removing other script limits. This approach is designed to manage the compute units available based on transaction weight, with the current budget set at 5,200 units per weight unit of the transaction.
For a comprehensive understanding of how these changes impact script execution, a benchmark methodology has been established. It involves evaluating script execution for block-sized scripts under constraints of size and varops budget to identify the slowest possible script validation scenarios. This methodology considers various operations and their computational intensity, setting a baseline for signature validation as a comparative measure of performance.
Contributions to this evolving discussion are encouraged, with a call to action for interested parties to engage in benchmarking efforts. By compiling and running benchmarks, individuals can contribute valuable data that will inform adjustments to the varops budget. This collaborative process is crucial for fine-tuning the system to ensure its effectiveness and reliability. Information on how to participate in this benchmarking effort, including accessing the necessary code and compiling instructions, is provided to enable broad participation from the community.
TLDR
We’ll email you summaries of the latest discussions from high signal bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project.
Give Feedback