Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D9A01AF7 for ; Wed, 13 Mar 2019 06:41:55 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EA36E12E for ; Wed, 13 Mar 2019 06:41:54 +0000 (UTC) Date: Wed, 13 Mar 2019 06:41:47 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1552459312; bh=9+gEKWO3I+9JYxRvIvpSFuQbNDQjGeG9MeudoHfIRqc=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=mcbhCKJjCfQk5I7INoCzG+bU4Jew8Vb870nfidAl3459/gw9IOkM30tlK8ZNRMzSO TUG1DdeTjx423bBkuGrVY+SoGHJ+7G8GsW8lOvpkgVW68Vw8MIfroX9IIiXQwENMvF gRXJGargRYhosUZ0Nhz+ofdXyxpN2P7g+ySU6WAs= To: Anthony Towns From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <20190313014143.ifffshwdux2jt7w5@erisian.com.au> References: <20190313014143.ifffshwdux2jt7w5@erisian.com.au> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW 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, 13 Mar 2019 06:47:00 +0000 Cc: "bitcoin-dev@lists.linuxfoundation.org" , "lightning-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety 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, 13 Mar 2019 06:41:56 -0000 Good morning aj, First off, I have little to no idea of the issues at the lower-level Bitcoi= n. In any case --- > - alternatively, we could require every script to have a valid signatur= e > that commits to the input. In that case, you could do eltoo with a > script like either: > > CHECKSIGVERIFY CHECKSIG > or
CHECKSIGVERIFY CHECKSIG > > > where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is > a key they both know the private key for. In the first case, Alice > would give Bob a NOINPUT sig for the tx, and when Bob wanted to publish > Bob would just do a SIGHASH_ALL sig with his own key. In the second, > Alice and Bob would share partial NOINPUT sigs of the tx with P, and > finish that when they wanted to publish. > > This is a bit more costly than a key path spend: you have to reveal > the taproot point to do a script (+33B) and you have two signatures > instead of one (+65B) and you have to reveal two keys as well > (+66B), plus some script overhead. If we did the variant, > we could provide a "PUSH_TAPROOT_KEY" opcode that would just push > the taproot key to stack, saving 33B from pushing P as a literal, > but you can't do much better than that. All in all, it'd be about 25% > overhead in order to prevent cheating. [0] > > I think that output tagging doesn't provide a workable defense against th= e > third party malleability via a deeper-than-the-CSV-delay reorg mentioned > earlier; but requiring a non-NOINPUT sig does: you'd have to replace > the non-NOINPUT sig to make state 5 spend state 3 instead of state 4, > and only the holders of the appropriate private key can do that. At my point of view, if a NONINPUT sig is restricted and cannot be used to = spend an "ordinary" 2-of-2, this is output tagging regardless of exact mech= anism. So the restriction to add a non-NOINPUT sig in addition to a NOINPUT sig is= still output tagging, as a cooperative close would still reveal that the o= utput is not a 2-of-2. Ideally, historical data of whether onchain coin was used in Lightning or n= ot should be revealed as little as possible. So in a cooperative close (which we hope, to be a common case), ideally the= spend should look no different from an ordinary 2-of-2 spend. Of course if the channel is published on Lightning, those who participated = in Lightning at the time will learn of it, but at least the effort to remem= ber this information is on those who want to remember this fact. Now, this can be worked around by adding a "kickoff" transaction that spend= s the eltoo setup transaction. The eltoo setup transaction outputs to an ordinary 2-of-2. The kickoff outputs to an output that allows NOINPUT. Then the rest of the protocol anchors on top of the kickoff. The kickoff is kept offchain, until a non-cooperative close is needed. Of course, as it is not a NOINPUT itself, it must need onchain fees attache= d to it. This of course complicates fees, as we know. Alternately maybe the kickoff can be signed with `SIGHASH_SINGLE | SIGHASH_= ANYONECANPAY` so that it is possible to add a fee-paying UTXO to it. Regards, ZmnSCPxj