ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-01 📝 Original message:Good morning aj, > On Mon, ...

📅 Original date posted:2019-10-01
📝 Original message: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