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 CC5D1AEF; Tue, 8 May 2018 14:40:35 +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 33B1214F; Tue, 8 May 2018 14:40:35 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1fG3n5-0002qQ-KA; Wed, 09 May 2018 00:40:33 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Wed, 09 May 2018 00:40:21 +1000 Date: Wed, 9 May 2018 00:40:21 +1000 From: Anthony Towns To: Christian Decker , Bitcoin Protocol Discussion Message-ID: <20180508144021.GA15921@erisian.com.au> References: <871sewirni.fsf@gmail.com> <87sh73fe4h.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87sh73fe4h.fsf@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_20,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: lightning-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP sighash_noinput 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, 08 May 2018 14:40:35 -0000 On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev wrote: > Given the general enthusiasm, and lack of major criticism, for the > `SIGHASH_NOINPUT` proposal, [...] So first, I'm not sure if I'm actually criticising or playing devil's advocate here, but either way I think criticism always helps produce the best proposal, so.... The big concern I have with _NOINPUT is that it has a huge failure case: if you use the same key for multiple inputs and sign one of them with _NOINPUT, you've spent all of them. The current proposal kind-of limits the potential damage by still committing to the prevout amount, but it still seems a big risk for all the people that reuse addresses, which seems to be just about everyone. I wonder if it wouldn't be ... I'm not sure better is the right word, but perhaps "more realistic" to have _NOINPUT be a flag to a signature for a hypothetical "OP_CHECK_SIG_FOR_SINGLE_USE_KEY" opcode instead, so that it's fundamentally not possible to trick someone who regularly reuses keys to sign something for one input that accidently authorises spends of other inputs as well. Is there any reason why an OP_CHECKSIG_1USE (or OP_CHECKMULTISIG_1USE) wouldn't be equally effective for the forseeable usecases? That would ensure that a _NOINPUT signature is only ever valid for keys deliberately intended to be single use, rather than potentially valid for every key. It would be ~34 witness bytes worse than being able to spend a Schnorr aggregate key directly, I guess; but that's not worse than the normal taproot tradeoff: you spend the aggregate key directly in the normal, cooperative case; and reserve the more expensive/NOINPUT case for the unusual, uncooperative cases. I believe that works fine for eltoo: in the cooperative case you just do a SIGHASH_ALL spend of the original transaction, and _NOINPUT isn't needed. Maybe a different opcode maybe makes sense at a "philosophical" level: normal signatures are signing a spend of a particular "coin" (in the UTXO sense), while _NOINPUT signatures are in some sense signing a spend of an entire "wallet" (all the coins spendable by a particular key, or more accurately for the current proposal, all the coins of a particular value spendable by a particular key). Those are different intentions, so maybe it's reasonable to encode them in different addresses, which in turn could be done by having a new opcode for _NOINPUT. A new opcode has the theoretical advantage that it could be deployed into the existing segwit v0 address space, rather than waiting for segwit v1. Not sure that's really meaningful, though. Cheers, aj