Johnson Lau <
jl2012@xbt.hk> writes:
I don’t think this has been mentioned: without signing the script or masked script, OP_CODESEPARATOR becomes unusable or insecure with NOINPUT.
In the new sighash proposal, we will sign the hash of the full script (or masked script), without any truncation. To make OP_CODESEPARATOR works like before, we will commit to the position of the last executed OP_CODESEPARATOR. If NOINPUT doesn’t commit to the masked script, it will just blindly committing to a random OP_CODESEPARATOR position, which a wallet couldn’t know what codes are actually being executed.
My anti-complexity argument leads me to ask why we'd support
OP_CODESEPARATOR at all? Though my argument is weaker here: no wallet
need support it.
Because it could make scripts more compact in some cases?
But this is probably not a good example for taproot, as it could be more efficient by making the 2 branches as different script merkle leaves.
But I don't see how OP_CODESEPARATOR changes anything here, wrt NOINPUT?
Remember, anyone can create an output which can be spent by any NOINPUT,
whether we go for OP_MASK or simply not commiting to the input script.
Let me elaborate more. Currently, scriptCode is truncated at the last executed CODESEPARATOR. If we have a very big script with many CODESEPARATORs and CHECKSIGs, there will be a lot of hashing to do.
To fix this problem, it is proposed that the new sighash will always commit to the same H(script), instead of the truncated scriptCode. So we only need to do the H(script) once, even if the script is very big
In the case of NOINPUT with MASKEDSCRIPT, it will commit to the H(masked_script) instead of H(script).
To make CODESEPARATOR works as before, the sighash will also commit to the position of the last executed CODESEPARATOR. So the semantics doesn’t change. For scripts without CODESEPARATOR, the committed value is a constant.
IF NOINPUT does not commit to H(masked_script), technically it could still commit to the position of the last executed CODESEPARATOR. But since the wallet is not aware of the actual content of the script, it has to guess the meaning of such committed positions, like “with the HD key path m/x/y/z, I assume the script template is blah blah blah because I never use this path for another script template, and the meaning of signing the 3rd CODESEPARATOR is blah blah blah”. It still works if the assumptions hold, but sounds quite unreliable to me.
Johnson