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

The discussion revolves around the computational budget allocated for validating blocks within a blockchain system. There is an observation that, given the high limit set for the computational budget, it's unlikely that the average block will approach this limit. This leads to the suggestion that validating a block could be significantly quicker than preparing for the worst-case scenario. Consequently, there's a proposal to reconsider the computational budget, possibly reducing it to align with a more realistic worst-case target.

There's also a consideration about Initial Block Download (IBD) times and how they are impacted by current practices. The core protocol's default behavior utilizes an assumevalid feature, which bypasses the full validation of nearly all scripts by relying on very recent checkpoint blocks. This method significantly reduces the time required for a new node to synchronize with the network by assuming that the historical data has been correctly validated up to the specified checkpoints. The conversation suggests that planning for new resource requirements should not be heavily influenced by these kinds of optimizations, which are essentially workarounds for historical challenges.

Finally, there's an agreement on the value of conducting benchmarks on the enhanced capabilities provided by new opcodes. This suggests a forward-looking interest in understanding how these new features could affect overall performance and efficiency, rather than focusing solely on mitigating past issues.