OP_CHECKCONTRACTVERIFY and its amount semantic

The email discussion revolves around the intricacies of implementing a real-life Bitcoin Improvement Proposal (BIP) with a particular focus on value forwarding mechanisms within Bitcoin scripting. The sender critiques the current method, which may require a CHECKSIG or additional introspection to ascertain the exact amount being forwarded to a specific output (identified here as X), suggesting that the Conditional Close Verifiability (CCV) alone is insufficient for this purpose.

An alternative approach proposed involves enhancing the script's capability to introspect aggregate output amounts directly. This proposal outlines a two-step process: firstly, introducing an operation (OP_IN_AMOUNT) that pushes the input amount onto the stack; secondly, implementing CCV with value introspection capabilities. In this scenario, the value taken off the stack (which could exceed 4 bytes) would be allocated to an output, and the residual input amount would be pushed back onto the stack, ensuring that value forwarding remains explicit and avoids a default or deduct mode split. This method allows for mathematical checks on transaction values below a certain threshold and facilitates rate-limiting or collateral in a straightforward manner.

However, the sender acknowledges potential drawbacks to this approach, notably the complexity it adds to Bitcoin Script, which might make it more prone to errors ("footgun" than feature). Despite these concerns, the proposition aligns with the sender's broader goals and interests in the scripting language's development nuances, humorously dubbed as "muh GSR."