Sure, but CHECKSIG is precomputed before the execution of the scripts. In a sense, my suggestion achieves exactly the same for the amount constraints.
I think this is the wrong direction to take. There are a few reasons:
- On its face, reducing parallelization (and most likely efficiency as a consequence) to match a proposal seems inappropriate if the same goal can be achieved without reducing parallelization.
- Although this is implementation specific, i think breaking a property the implementation was able to rely upon raises questions about whether this property is desirable to keep when designing extensions to the Script language.
- Input-level parallelization is key to reducing the validation time for unconfirmed transactions[1], where a would-be attacker does not have to expend a PoW to incur costs on a node, as well as worst case block validation times which adds up across a block propagation path.
Benefits include not breaking cross-input parallelization, a cleaner implementation and a more composable primitive (separation of concerns).
I agree the repetition isn’t ideal, but i don’t see a few weight units more as a major downside. Overall i think it’s a good tradeoff to make.
If your transaction doesn’t have a signature, malleability already goes out the window.
Why “would”? I demonstrated it already, and it’s much simpler.
In a sense you could see my suggestion as “preemptive” (“eager”?), rather than “deferred”, checks. Existing features, for instance absolute locktimes, could have also been designed to have transaction-level checks be deferred to after executing the inputs scripts. Instead they were designed with transaction-level checks performed beforehand (surely because for those the field already existed in the transaction), and i think it is much cleaner.
Although we don’t actually do it today! (h/t Greg Sanders) ↩︎