Quote from: fresheneesz on January 31, 2020, 06:07:36 AM

I think I see what you're saying. You're saying the output would depend on the input, but the input would also depend on the output.

Yep. And because "depend" means contains a cryptographic hash of, we have a hash cycle. If SHA-256 is secure we can't do this.

Quote from: fresheneesz on January 31, 2020, 06:07:36 AM

Well, I suppose I misspoke. I detailed the 4 cases I would like supported. Committing to an exact transaction, committing to sending to a particular address, committing to a fee, and committing to a next-locktime.

You're just communicating in a way that is a bit unclear. I'm doing a lot of work to try to explain the concept to you -- which is my burden -- but you aren't giving me a whole lot of detail to understand exactly what you want. Can you maybe draw some diagrams?

1. You can't commit to an exact transaction ahead of time in any scheme because it has the same hash cycle problem (can't observe your own TXID). You could commit to all the outputs. In CTV we elect not to commit to the other inputs, because then we would have more types of hash cycle issues (e.g., input A commits to B, input B commit to A, hash cycle). We therefore commit to none of the inputs. If you want this functionality, it should come as a separate opcode (and I am fine to prepare & propose it after CTV).
2. If I understand what you're asking: You want to have a coin that you say it can be spent in whatever transaction you want, but it MUST go to this specific address? You can do this with CTV if you are OK not specifying additional outputs, which for most applications of this should be fine. (Once OP_CAT is re-added it's a bit more flexible again).
3. I'm not sure what this means. I've separately discussed wanting to have some "safety" opcodes to check the total transaction value.
4. You can do this already in script without CTV using CLTV. Not sure what you're asking for beyond that.