From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9474F190F for ; 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 ; 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 From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: 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> 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 , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: > > 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_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, ` 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( OPCHECKSIG)) * G`, not revealing the fact that this was in fact = a Decker-Russell-Osuntokun output. Regards, ZmnSCPxj