Op_inout_amount

[Chris_Stewart_5]

@salvatoshi

It only works for cases where the structure of the transaction (that is, “what inputs will be spent together”) is known in advance and can be hardcoded in Script.

Why? By “it” I assume you are referring to OP_CCV/OP_VAULT. Is there some security consideration I am missing?

@salvatoshi

You might receive a number of transactions to a vault address, and then at spending time (trigger transaction) you’ll want to select which of the vault UTXOs you want use as part of the withdrawal.

This is tested in the BIP345 case study. I didn’t have this issue you are talking about. Both test_batch_unvault and test_batch_recovery test cases work with OP_{IN,OUT}_AMOUNT.

@salvatoshi

The number and the position of those UTXOs can’t be known in advance when their script is defined. In order to avoid having to hardcode these bitmaps, you’d need some cross-input logic to somehow make sure that all those inputs are using compatible bitmaps

Yes, that is why they should be provided on the witness stack at spending time rather than when the utxos are created. I modified your OP_CCV test code code to do just that.

@salvatoshi

I believe this is in fact the most interesting part of the amount logic of CCV (inspired from VAULT rather than from the original applications of CCV to MATT and fraud proofs).

Admittedly I am confused, as far as I can tell your test framework defines the index parameter for OP_CCV in the output script rather than placing it in the witness when the OP_CCV utxo is spent. Here is a link to the code I am looking at: 1 2 3 4 5.

I understand that both of our proposals are works in progress – is the the goal to remove the hard coded indices in favor of providing them on the witness stack in your OP_CCV test cases?

@salvatoshi

Assuming that a clean solution to (1) is found, since all the related inputs that are being aggregated need to have a matching bitmap, the trivial implementation would require to report this same bitmap for all the inputs. This has O(n^2) cost both in terms of space occupation and computational cost. While O(n^2) bits and O(n^2) additions might not be a huge deal for many common use cases, it seems rather unsatisfactory to do in O(n^2) cost something that can be done optimally in O(n) cost.

I think this is a fair critique and something I’m going to look into.

@salvatoshi

Without a real, embedded cross-input logic, the only way to achieve the optimal O(n) cost seems to be something like this demo from burak (TL;DR: one special input performs all the amount checks, while the other inputs merely check the presence of the special input), which is not exactly ergonomic.

Thank you for sharing this, I wasn’t aware of this work. I’ll look into it. I’m always interested in alternative designs for amount locks :-).

@salvatoshi

More generally, any covenant opcode that constrains the destination seems to be pointless if the covenant opcode itself doesn’t also enforce the presence of the amount logic,

I think that is right. However I’m not sure the inverse is true. I think amount locks may be useful without destination locks. See my coinjoin example. If privacy is your #1 concern, you want to enforce at the Script level that your utxos follow a specific amount pattern – you can enforce the destinations with digital signatures as coinjoin protocols do today.

I also think we can make more general purpose primitives to implement amount locks rather than baking them into a single covenant opcode. I like the design of OP_CCV for implementing destination locks from what I’ve learned so far, but I’m not a big fan of the amount lock side of things.

@salvatoshi

I strongly believe that some amount of redundancy is unavoidable for any mechanism that extracts the amount logic out of the covenant opcode.

I’ll think about this more.

Thank you for the thoughtful reply, you’ve given me a lot to think about.