Good morning aj,
> On Mon, Sep 30, 2019 at 11:28:43PM +0000, ZmnSCPxj via bitcoin-dev wrote: > > > Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode, > > `OP_CHECKSIG_WITHOUT_INPUT`. > > I don't think there's any meaningful difference between making a new > opcode and making a new tapscript public key type; the difference is > just one of encoding: > > 3301<key>AC [CHECKSIG of public key type 0x01] > 32<key>B3 [CHECKSIG_WITHOUT_INPUT (replacing NOP4) of key] > > > This new opcode ignores any `SIGHASH` flags, if present, on a signature, > > (How sighash flags are treated can be redefined by new public key types; > if that's not obvious already) Thank you for this thought, I believe under tapscript v0 we can give `OP_1` as the public key to `OP_CHECKSIG` to mean to reuse the internal Taproot pubkey, would it be possible to have some similar mechanism here, to copy the internal Taproot pubkey but also to enable new `SIGHASH` flag for this particular script only? This seems fine, as then a Decker-Russell-Osuntokun funding tx output between nodes A, B, and C would have: * Taproot internal key: `P = MuSig(A, B, C)` * Script 1: leaf version 0, `<MuSig(A,B,C) + pubkeytype 1> OP_CHECKSIG` Then, update transactions could use `MuSig(A,B,C)` for signing along the "update" path, with unique "state" keys. And cooperative closes would sign using `P + h(P | MAST(<MuSig(A,B,C) + pubkeytype 1> OPCHECKSIG)) * G`, not revealing the fact that this was in fact a Decker-Russell-Osuntokun output. Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev