Good morning list, 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? Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
