Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9474F190F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  1 Oct 2019 15:42:14 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
	[185.70.40.130])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 016B38A9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  1 Oct 2019 15:42:12 +0000 (UTC)
Date: Tue, 01 Oct 2019 15:42:08 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1569944530;
	bh=NVTXEiV9npvvEKBmI+SeM4WSYrvJyVK2PpLlgRPVpD8=;
	h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
	Feedback-ID:From;
	b=mbQLpgvm4p8YN/RsT+GAqM6hjjh6zpPfx5owocRHhHeoEjJEgeucEL35bxYyDJYwP
	AcVdcskzo48FEo8zY2lcHmdN65jxKwxxbaULZ1hVszEjF5MAlUFvrYu9IixQs9O2Ac
	Z5bTqr2QxF3nwufMIF/C7BRzaktMxtPKRPbMotHg=
To: Anthony Towns <aj@erisian.com.au>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <cF916RaV0ndCBiZcXM0Cl6QOtCWn-bWz8Fs3MAKIIck85dlGEZFQkmWJXPQQ-342viaXHx8mA5xLYuD-fnoIYdIc3eyk5lNXgEj1hhx36mQ=@protonmail.com>
In-Reply-To: <20191001144548.hrne6mlhmof7tpkr@erisian.com.au>
References: <87wodp7w9f.fsf@gmail.com>
	<-5H29F71ID9UFqUGMaegQxPjKZSrF1mvdgfaaYtt_lwI7l1OTmN_8OgcooyoMt2_XuyZ5aDljL6gEup9C7skF8iuP_NbMW_81h0tJIGbJno=@protonmail.com>
	<gPtVJarazpIb7PaNu3ngXLKG2U4cIBfT9lb-04tltIrxufUUP4hMr08vU8Af19My-b5UeVwwo3BYhkDrVwEu1EjS_MMW5aXOx1sVub8MCIE=@protonmail.com>
	<20191001144548.hrne6mlhmof7tpkr@erisian.com.au>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, DOS_RCVD_IP_TWICE_B, FREEMAIL_FROM,
	FROM_LOCAL_NOVOWEL, 
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	"lightning-dev@lists.linuxfoundation.org"
	<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Continuing the discussion about noinput /
	anyprevout
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Oct 2019 15:42:14 -0000

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_CHE=
CKSIG_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_CH=
ECKSIG` to mean to reuse the internal Taproot pubkey, would it be possible =
to have some similar mechanism here, to copy the internal Taproot pubkey bu=
t also to enable new `SIGHASH` flag for this particular script only?

This seems fine, as then a Decker-Russell-Osuntokun funding tx output betwe=
en nodes A, B, and C would have:

* Taproot internal key: `P =3D 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 "u=
pdate" path, with unique "state" keys.
And cooperative closes would sign using `P + h(P | MAST(<MuSig(A,B,C) + pub=
keytype 1> OPCHECKSIG)) * G`, not revealing the fact that this was in fact =
a Decker-Russell-Osuntokun output.

Regards,
ZmnSCPxj