ZmnSCPxj <zmnsc...@protonmail.com> writes: > To elucidate further --- > > Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode, > `OP_CHECKSIG_WITHOUT_INPUT`. > > This new opcode ignores any `SIGHASH` flags, if present, on a > signature, but instead hashes the current transaction without the > input references, then checks that hash to the signature. > > This is equivalent to `SIGHASH_NOINPUT`. > > Yet as an opcode, it would be possible to embed in a Taproot script. > > For example, a Decker-Russell-Osuntokun would have an internal Taproot > point be a 2-of-2, then have a script `OP_1 > OP_CHECKSIG_WITHOUT_INPUT`. Unilateral closes would expose the hidden > script, but cooperative closes would use the 2-of-2 directly. > > Of note, is that any special SCRIPT would already be supportable by Taproot. > This includes SCRIPTs that may potentially lose funds for the user. > Yet such SCRIPTs are already targetable by a Taproot address. > > If we are so concerned about `SIGHASH_NOINPUT` abuse, why are we not > so concerned about Taproot abuse?
That would certainly be another possibility, which I have not explored in detail so far. Due to the similarity between the various signature checking op-codes it felt that it should be a sighash flag, and it neatly slotted into the already existing flags. If we go for a separate opcode we might end up reinventing the wheel, and to be honest I feared that proposing a new opcode would get us into bikeshedding territory (which I apparently failed to avoid with the sighash flag anyway...). The advantage would be that with the sighash flag the spender is in charge of specifying the flags, whereas with an opcode the output dictates the signature verification modalities. The downside is the increased design space. What do others think? Would this be an acceptable opt-in mechanism that addresses the main concerns? Cheers, Christian _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev