Benchmarking Bitcoin Script Evaluation for the Varops Budget (Great Script Restoration)

The discussion emphasizes the importance of establishing a computational budget for scripts, particularly in the context of Generalized Script Reduction (GSR) within blockchain technology. The aim is to ensure that even with GSR activated, the performance degradation does not exceed the current worst-case scenarios experienced on most or all machines. The concern highlighted is the transition from being vulnerable solely to deliberate attackers to being susceptible to anyone deploying new logic. This shift could potentially make it profitable rather than just possible to create slow blocks, changing the dynamics of block creation and possibly incentivizing undesirable practices.

A safer approach suggested involves limiting the worst-case GSR execution costs to levels comparable to a block filled with normal transactions, which might equate to around 13k signature operations per block. This contrasts significantly with the higher costs associated with more complex transactions. Furthermore, aiming for a validation time target of one or two microseconds per byte, translating to one or two seconds per block, is proposed as a more optimal goal. This, however, would necessitate defining baseline hardware standards to ensure feasibility and consistency across the board.

Additionally, the conversation touches upon the possibility of integrating the varops budget with existing sigversions, albeit recognizing this as a fundamentally different discussion. It highlights the delicate nature of restricting existing script functionality due to the potential risk of confiscating coins. The discourse suggests that while it's crucial to consider restrictions to mitigate attacks, as exemplified by BIP 54, exploring other improvements that obviate the need for restrictions altogether is equally valuable. In this vein, references are made to proposals and discussions such as PR16902 and CVS-2025-46598, which represent efforts to enhance the system without compromising existing functionalities. The underlying message is that introducing new functionalities presents an opportunity to reevaluate and potentially improve upon the mechanisms for analyzing and managing computational costs, moving away from merely replicating past practices without critical examination.