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

The discussion revolves around the introduction of a new Tapscript leaf version to address the concerns that led to the disabling of many opcodes in Bitcoin script execution version 0.3.1. This move was primarily motivated by the need to mitigate denial-of-service attacks, which exploited excessive computational time and memory usage. The proposed solution involves generalizing the sigops budget, now referred to as the varops budget, and applying it across all operations before considering the restoration of any computationally intensive operations or lifting other script limits. The varops budget is intricately linked to transaction weight, allowing larger transactions more compute units proportionally, with the current rate set at 5,200 units per weight unit of the transaction.

Benchmarking plays a crucial role in determining the feasibility and efficiency of this approach. To establish a baseline, the evaluation focuses on block-sized scripts, capped at 4M weight units, translating to a varops budget of 20.8 billion compute units. Various operational patterns are tested, including simple hashing loops and bit operations, to gauge their performance within the defined budget. These tests aim to identify the slowest possible script validation scenarios under the new system. For comparison, signature validations, specifically using Schnorr signatures, serve as a benchmark. The goal is to ensure that the varops budget restricts script execution times to within acceptable limits, comparable to the worst-case scenario for signature validation, which is currently estimated at one to two seconds for 80,000 checks on a modern CPU.

The proposal also emphasizes the importance of community involvement in refining the varops budget. Developers are encouraged to participate by checking out the GSR prototype implementation, compiling it with benchmarks enabled, and running specific benchmarks. Results from these benchmarks, particularly those detailing varops limited script performances and Schnorr checksig times, are invaluable. They will be used to predict a maximum value for the varops budget tailored to individual machines, thereby ensuring its effectiveness across different systems. Community contributions in this regard are critical to adjusting and validating the proposed budget, ensuring its reliability and functionality. Interested parties can find more details and contribute to the ongoing development through the provided GitHub links to both the BIP documentation and the GSR prototype implementation branch.