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

In the discussion regarding Taproot's potential vulnerabilities, it's highlighted that the primary concern isn't necessarily the maximization of signatures but rather the exploitation of the highest validation time per witness byte. This is achieved through a method of repeatedly hashing a maximum size stack element using a specific sequence of operations (3DUP RIPEMD160 DROP RIPEMD160 DROP RIPEMD160 DROP). The initial assumption was that with the introduction of the Generalized Schnorr Signature (GSR), attackers could bypass the signature cache more effectively by utilizing the CAT operation to generate excessive signatures, subsequently inflating the witness size with repeated hashing processes.

However, this strategy of generating an overwhelming number of distinct signatures to max out the 80k sigops limit, alongside padding the witness size, encounters a significant constraint due to Tapscript's consensus rules. Specifically, Tapscript mandates that signatures must either be valid or constitute an empty vector, which significantly limits the extent of potential attack vectors by imposing restrictions on the construction of exploitative transactions.

The conversation also touches upon the oversight in Tapscript design where hash operations do not contribute to the sigop budget. This exclusion is pointed out as a loophole that could potentially be exploited, suggesting that including hash operations in the sigop budget might have been a prudent measure to mitigate such attack strategies. This aspect underscores the need for careful consideration of operational limits within blockchain protocols to prevent abuse while maintaining system integrity and security.