From aj at erisian.com.au  Tue Oct  1 14:45:48 2019
From: aj at erisian.com.au (Anthony Towns)
Date: Wed, 2 Oct 2019 00:45:48 +1000
Subject: [Lightning-dev] [bitcoin-dev] Continuing the discussion about
 noinput / anyprevout
In-Reply-To: <gPtVJarazpIb7PaNu3ngXLKG2U4cIBfT9lb-04tltIrxufUUP4hMr08vU8Af19My-b5UeVwwo3BYhkDrVwEu1EjS_MMW5aXOx1sVub8MCIE=@protonmail.com>
References: <87wodp7w9f.fsf@gmail.com>
	<-5H29F71ID9UFqUGMaegQxPjKZSrF1mvdgfaaYtt_lwI7l1OTmN_8OgcooyoMt2_XuyZ5aDljL6gEup9C7skF8iuP_NbMW_81h0tJIGbJno=@protonmail.com>
	<gPtVJarazpIb7PaNu3ngXLKG2U4cIBfT9lb-04tltIrxufUUP4hMr08vU8Af19My-b5UeVwwo3BYhkDrVwEu1EjS_MMW5aXOx1sVub8MCIE=@protonmail.com>
Message-ID: <20191001144548.hrne6mlhmof7tpkr@erisian.com.au>

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)

Cheers,
aj