Hi all,

I’ve attempted to implement OP_INOUT_AMOUNT. The purpose of OP_INOUT_AMOUNT is to push the input value and a set of output values onto the Script interpreter stack.

Here is my draft BIP:

Here is the implementation.

One purpose of implementing this is to see how this works in conjunction with my 64bit op code PR. For more information on this PR see the delving bitcoin discussion here.

Design questions

One limitation of the current implementation is that it only can push the input and output amounts at the current index being verified inside of the Script interpreter. While easiest to implement, I wonder if this should be extended to verifying more than just the input and output at the current input index being verified. It seems like something similar to how SIGHASH flags work would be interesting. Interested in hearing others thoughts.

Implementation questions

Currently I extend BaseTransactionSignatureChecker to have 2 new methods

  • GetNIn() - the input index we are currently verifying
  • GetTransactionData() - gives us access to PreComputedTransactionData so we have access to the output that is funding us, and the set of outputs we are spending to.

I don’t think this is necessarily the best place to put these methods, but it seemed like the most convenient place for putting these to hack something together. Would be interested in hearing others thoughts of how to structure the implementation.

My end goal is to use all this stuff in conjunction for OP_TLUV.

1 Like

Thanks for moving this along!

I think it would be a missed opportunity to have this be available only for the current input/output pair.

Having it be possible to specify indexes would be very helpful in creating more sophisticated merges/splits of UTXOS. And I think the implementation complexity would not drastically increase?

1 Like