I don't understand what you mean by "hash cycle". Could you explain that further? It sounds like you're saying that if you specify the exact inputs, it would create hash cycle. Are you saying its *possible* to create this hash cycle, or a hash cycle will always happen if you specify the exact inputs?
I'm saying that it always would require you to be able to generate a hash cycle, which is cryptographically impossible.
If I have a scriptPubKey corresponding to input 5 to a transaction, there is a txid for input 5 "ABCDEF...". ABCDEF commits to the scriptPubKey. But the scriptPubKey commits to spending ABCDEF. But ABCDEF = H(... || scriptPubKey || ...) = H(... || ABCDEF || ...).
So ABCDEF is a hash which contains itself (not quite a fixed point, but close). That shouldn't be possible for SHA256!
So committing to the number of inputs is redundant if and only if you commit to the input sequence. But not if you don't want to commit to that sequence. Right? I'm trying to clarify my understanding here.
Presently, without an OP_CAT like thing, you always commit to both. But in the future, you may want to restrict just the number of inputs and not the sequences.
I don't understand the distinction you're making there. Restricting to "a specific number of inputs" and "programmatically selecting a number of inputs" sound identical to me. Could you give an example use case for this?
Ok then they are the same. Semantics.
Example is given above in the discussion of adding fees dynamically.
So are you telling me that, no, this isn't the fee issue Greg mentioned, then? I had already read the BIP. It doesn't seem to properly explain what the half-spend problem is, but seems to expect the reader to know what it is already. What is it? An example would help.
Straight from the BIP:
If we allow more than one input to be spent in the transaction then it would be possible for two outputs to request payment to the same set of outputs, resulting in half the intended payments being discarded, the "half-spend" problem.
I can't give you a good example of the issue occuring, because CTV is generally not vulnerable to this class of error, the example would probably only confuse you more. But I'll try.
Let's say I create an output R for 1 BTC that is spk
OP_CTV. And I create another one P that is 1 BTC to spk OP_CTV.
Let's say hash A covers a transaction that has 2 inputs and one output to address X for 1 BTC.
If you were able to create a transaction that spends P and R to create X, it would be valid, and create 1 output to X for 1 BTC, paying 1 BTC in fees. Spent separately, you would get two payments to X.
HOWEVER because A commits to the input index (e.g., index 0) if those values are actually identical then they can't be co-spent, avoiding the half-spend problem from key reuse.
No. What I said translates to "I want to be able to arbitrarily restrict how the coins can be spent in whatever manner I want."
Then use Ethereum? I'm not kidding; there's no roadmap anywhere for supporting completely arbitrary restrictions in Bitcoin. You need to narrow your request to things that fall within Bitcoin's abstractions and informational barriers, as well as validation computational limits.
What mechanism is that?
Because you commit to the scriptsigs if you're using a P2SH or bare script you can commit to:
1) if non witness, the exact txid via the signatures
2) if witness, the program being spent from
because the hash commits to the scriptSig.
This is a bit weird, but the alternative would be to disallow spending with any scriptSigs in the txn, forcing it to always be segwit spends (or OP_CTVs, things without a scriptSig)
Future work should just add a new covenants mechanism for inspecting the other inputs COutpoint or witness script if we want to have a more robust mechanism for using this (we may).
The next transaction's locktime cannot be committed to. I assume that's what op_ctv's locktime commitment is as well.
What do you mean it can't be committed to? Either use OP_CTV again, recursively, or use an OP_CLTV/OP_CSV?