OP_CHECKCONTRACTVERIFY and its amount semantic

Thanks for finally writing a real life BIP!

Given the value forwarding piece is the most bike-sheddy part, I’m going to pick on that for now.

An alternative, which IIRC I proposed for OP_VAULT, was having explicit ability to introspect the (aggregate) output amounts.

Something like:

  1. OP_IN_AMOUNT: pushes input amount on stack
  2. CCV with value introspection: takes value off stack (can be >4 bytes), allocates to an output, and pushes residual of input back on stack, where residual is always the full amount minus the specified amount

This way value forwarding is always explicit when desired, no there’s no default/deduct mode split, you can do math checks on the values (below a certain value), rate-limiting / collateral is pretty straight forward. Obviously it has downsides including that Bitcoin Script math is probably more footgun than feature in practice… but muh GSR?