From ZmnSCPxj at protonmail.com Tue Oct 1 15:42:08 2019 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Tue, 01 Oct 2019 15:42:08 +0000 Subject: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout In-Reply-To: <20191001144548.hrne6mlhmof7tpkr@erisian.com.au> References: <87wodp7w9f.fsf@gmail.com> <-5H29F71ID9UFqUGMaegQxPjKZSrF1mvdgfaaYtt_lwI7l1OTmN_8OgcooyoMt2_XuyZ5aDljL6gEup9C7skF8iuP_NbMW_81h0tJIGbJno=@protonmail.com> <20191001144548.hrne6mlhmof7tpkr@erisian.com.au> Message-ID: 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: > > 3301AC [CHECKSIG of public key type 0x01] > 32B3 [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, ` 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( OPCHECKSIG)) * G`, not revealing the fact that this was in fact a Decker-Russell-Osuntokun output. Regards, ZmnSCPxj