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 55E0FCA6; Thu, 3 Oct 2019 01:48:06 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C7A92735; Thu, 3 Oct 2019 01:48:05 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian)) id 1iFqDq-0006F7-DC; Thu, 03 Oct 2019 11:48:03 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Thu, 03 Oct 2019 11:47:58 +1000 Date: Thu, 3 Oct 2019 11:47:58 +1000 From: Anthony Towns To: ZmnSCPxj Message-ID: <20191003014758.gtgfge5yokcxkfsj@erisian.com.au> References: <87wodp7w9f.fsf@gmail.com> <20191001155929.e2yznsetqesx2jxo@erisian.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DOS_RCVD_IP_TWICE_B, KHOP_HELO_FCRDNS,UNPARSEABLE_RELAY autolearn=no 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] [Lightning-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: Thu, 03 Oct 2019 01:48:06 -0000 On Wed, Oct 02, 2019 at 02:03:43AM +0000, ZmnSCPxj via Lightning-dev wrote: > So let me propose the more radical excision, starting with SegWit v1: > * Remove `SIGHASH` from signatures. > * Put `SIGHASH` on public keys. > OP_SETPUBKEYSIGHASH I don't think you could reasonably do this for key path spends -- if you included the sighash as part of the scriptpubkey explicitly, that would lose some of the indistinguishability of taproot addresses, and be more expensive than having the sighash be in witness data. So I think that means sighashes would still be included in key path signatures, which would make the behaviour a little confusingly different between signing for key path and script path spends. > This removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`, as they are allowed only if the output specifically says they are allowed. I don't think the problems with NONE and SINGLE are any worse than using SIGHASH_ALL to pay to "1*G" -- someone may steal the money you send, but that's as far as it goes. NOINPUT/ANYPREVOUT is worse in that if you use it, someone may steal funds from other UTXOs too -- similar to nonce-reuse. So I think having to commit to enabling NOINPUT for an address may make sense; but I don't really see the need for doing the same for other sighashes generally. FWIW, one way of looking at a transaction spending UTXO "U" to address "A" is something like: * "script" lets you enforce conditions on the transaction when you create "A" [0] * "sighash" lets you enforce conditions on the transaction when you sign the transaction * nlocktime, nsequence, taproot annex are ways you express conditions on the transaction In that view, "sighash" is actually an *extremely* simple scripting language itself (with a total of six possible scripts). That doesn't seem like a bad design to me, fwiw. Cheers, aj [0] "graftroot" lets you update those conditions for address "A" after the fact