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 24D69AF8; Thu, 10 May 2018 02:13:08 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from ozlabs.org (ozlabs.org [203.11.71.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6B79E67F; Thu, 10 May 2018 02:13:07 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 40hGwJ4W1nz9s3D; Thu, 10 May 2018 12:13:04 +1000 (AEST) From: Rusty Russell To: Anthony Towns , Bitcoin Protocol Discussion , Christian Decker , Bitcoin Protocol Discussion In-Reply-To: <20180508144021.GA15921@erisian.com.au> References: <871sewirni.fsf@gmail.com> <87sh73fe4h.fsf@gmail.com> <20180508144021.GA15921@erisian.com.au> Date: Thu, 10 May 2018 08:34:58 +0930 Message-ID: <87in7we8h1.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=no 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: Thu, 10 May 2018 02:13:08 -0000 Anthony Towns via bitcoin-dev writes: > 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. If I can convince you to sign with SIGHASH_NONE, it's already a problem today. > 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. That was also suggested by Mark Friedenbach, but I think we'll end up with more "magic key" a-la Schnorr/taproot/graftroot and less script in future. That means we'd actually want a different Segwit version for "NOINPUT-can-be-used", which seems super ugly. > 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. In a world where SIGHASH_NONE didn't exist, this might be an argument :) Cheers, Rusty.