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 23CBDD94 for ; Wed, 19 Dec 2018 00:39:38 +0000 (UTC) X-Greylist: domain 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 6377082F for ; Wed, 19 Dec 2018 00:39:37 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 43KGHW2xbtz9s1c; Wed, 19 Dec 2018 11:39:35 +1100 (AEDT) From: Rusty Russell To: Johnson Lau , bitcoin-dev In-Reply-To: <6DE5291C-629D-4080-9B0C-E18BEFA28B16@xbt.hk> References: <87ftv3xerx.fsf@rustcorp.com.au> <87pnu6s3v5.fsf@rustcorp.com.au> <87h8fiqn1z.fsf@rustcorp.com.au> <20181214093002.p2nvfrlaycqblww3@erisian.com.au> <8736qyhsej.fsf@rustcorp.com.au> <6DE5291C-629D-4080-9B0C-E18BEFA28B16@xbt.hk> Date: Wed, 19 Dec 2018 11:09:26 +1030 Message-ID: <87efaenydd.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 19 Dec 2018 12:40:29 +0000 Subject: Re: [bitcoin-dev] Safer sighashes and more granular 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: Wed, 19 Dec 2018 00:39:38 -0000 Johnson Lau writes: >> On 16 Dec 2018, at 2:55 PM, Rusty Russell via bitcoin-dev wrote: >>=20 >> Anthony Towns via bitcoin-dev wr= ites: >>> On Thu, Dec 13, 2018 at 11:07:28AM +1030, Rusty Russell via bitcoin-dev= wrote: >>>> And is it worthwhile doing the mask complexity, rather than just >>>> removing the commitment to script with NOINPUT? It *feels* safer to >>>> restrict what scripts we can sign, but is it? >>>=20 >>> If it's not safer in practice, we've spent a little extra complexity >>> committing to a subset of the script in each signature to no gain. If >>> it is safer in practice, we've prevented people from losing funds. I'm >>> all for less complexity, but not for that tradeoff. >>=20 >> There are many complexities we could add, each of which would prevent >> loss of funds in some theoretical case. > > Every security measures are overkill, until someone get burnt. If these s= ecurity measures are really effective, no one will get burnt. The inevitabl= e conclusion is: every effective security measures are overkill. > >>=20 >> From practical experience; reuse of private keys between lightning and >> other things is not how people will lose funds[1]. > > So you argument seems just begging the question. Without NOINPUT, it is j= ust impossible to lose money by key reuse, and this is exactly the topic we= are debating. I think we're getting confused here. I'm contributing my thoughts from the lightning implementer's point of view; there are other important considerations, but this is my contribution. In *lightning* there are more ways to lose funds via secret reuse. Meanwhile, both SIGHASH_NOINPUT and OP_MASK have the reuse-is-dangerous property; with OP_MASK the danger is limited to reuse-on-the-same-script (ie. if you use the same key for a non-lightning output and a lightning output, you're safe with OP_MASK. However, this is far less likely in practice). I state again: OP_MASK doesn't seem to gain *lightning* any significant security benefit. > It does not need to be something like GetMaskedScript(GetScriptCodeForMul= tiSig()). After all, only a very small number of script templates really ne= ed NOINPUT. A GetMaskedScript() in a wallet is just an overkill (and a vuln= erability if mis-implemented)=20 Our current transaction signing code is quite generic (and, if I may say so, readable and elegant). We could, of course, special case GetMaskedScript() for the case we need (the Eltoo examples I've seen have a single OP_MASK at the front, which makes it trivial). > It=E2=80=99s also about functionality here: as I mentioned in another rep= ly, OP_CODESEPARATOR couldn=E2=80=99t function properly with NOINPUT but wi= thout OP_MASKEDPUSH The mailing list seems a bit backed up or something; I replied to that in the hope you can clear my confusion on that one. > This debate happens because NOINPUT introduces the third way to lose fund= with key reuse. And once it is deployed, we have to support it forever, an= d is not something that we could softfork it away. A would use the same words to encourage you to create the simplest possible implementation? I don't think we disagree on philosophy, just trade-offs. And that's OK. Cheers, Rusty.