I don’t find these arguments particularly convincing. Input validation parallelization is already an approach that can be argued to have caused a certain amount of additional code complexity. Therefore, if (?) it can be proven (with benchmarks) that it doesn’t bring any substantial benefit - then that could be an argument for its removal. Today, the counter-example to this no-benefits claim is the fact that parallel input validation (poorly) mitigates the damage of quadratic hashing - which I look forward to see mitigated more properly with your work on the Great Consensus Cleanup. Simplifying the interpreter code would benefit any present and future cross-input logic - not just CCV.
In any case, I will not pursue this approach further at this time, as it widens the scope of the change too much.
You’re right, it doesn’t make a difference. I was thinking of cases where CCV makes sense without signatures (for example it seems to make sense for the recover transaction of vaults, which can be implemented so that jut knowledge of the spending path is enough to execute it. It seems to me that the little malleability possible is not an issue - but then it wouldn’t be an issue even with your annex approach.
You demonstrated the amount logic based on the annex, but there’s still a non-trivial amount of code that is missing to make it work with a covenant opcode, and that’s required for a fair comparison. An opcode adopting this system will have to:
- parse the parameters relevant to the amount constraints
- make sure that these constraints are indeed present in the annex
This will require adding the annex constraints in a place that is accessible during the opcode execution (perhaps in ScriptExecutionData), with some due care as they should be stored in a format that can be queried efficiently like a hash table in order to avoid introducing quadratic annexing…
I’m convinced that your approach is somewhat simpler than the deferred checks, but it’s definitely more complicated/redundant than the current implementation based on a mutex from the current PR. (for comparison the current amount logic is entirely contained in interpreter.h#L246-L301 plus interpreter.cpp#L1896-L1943).
Taking a step back, my general impression is that for even for something like batch validation (that is already useful today), one of:
- synchronization with mutexes
- a mechanism like deferred checks
- removal of parallel input validation
will be necessary. Whatever solution is deemed best, it will be re-usable for CCV without sacrificing the desirable semantic (and avoiding redundant bytes).