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 E516519B7; Thu, 21 Mar 2019 09:06:23 +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 630A9D3; Thu, 21 Mar 2019 09:06:23 +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 1h6teU-0001pZ-QC; Thu, 21 Mar 2019 19:06:20 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Thu, 21 Mar 2019 19:06:14 +1000 Date: Thu, 21 Mar 2019 19:06:14 +1000 From: Anthony Towns To: ZmnSCPxj Message-ID: <20190321090614.7ir64g2ehn3pz2cb@erisian.com.au> References: <20190313014143.ifffshwdux2jt7w5@erisian.com.au> <87k1gubdjm.fsf@rustcorp.com.au> <87woku9q3g.fsf@rustcorp.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.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY 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: Thu, 21 Mar 2019 16:54:19 +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: Thu, 21 Mar 2019 09:06:24 -0000 On Wed, Mar 20, 2019 at 08:07:00AM +0000, ZmnSCPxj via Lightning-dev wrote: > Re-reading again, I think perhaps I was massively confused by this: > > that commits to the input. In that case, you could do eltoo with a > > script like either: > > CHECKSIGVERIFY CHECKSIG > > or

CHECKSIGVERIFY CHECKSIG > Do you mean that *either* of the above two scripts is OK, *or* do you mean they are alternatives within a single MAST or `OP_IF`? I meant "either of the two scripts is okay". > In the blob sent to Watchtower, A (or B) includes the `SIGHASH_NOINPUT` as well as the `q` private key. > Would it be safe for Watchtower to know that? I think so. From Alice/Bob's point-of-view, the NOINPUT sig ensures they control their money; and from the network's point-of-view (or at least that part of the network that thinks NOINPUT is unsafe) the Q private key being shared makes the tx no worse than a 1-of-n multisig setup, which has to be dealt with anyway. > Then each update transaction pays out to: > OP_IF > OP_CSV OP_DROP > OP_CHECKSIGVERIFY OP_CHECKSIG > OP_ELSE > OP_CHECKLOCKTIMEVERIFY OP_DROP > OP_CHECKSIGVERIFY OP_CHECKSIG > OP_ENDIF Yeah. I think we could potentially make that shorter still: IF OP_CODESEPARATOR OP_CHECKLOCKTIMEVERIFY OP_DROP ENDIF OP_CHECKDLSVERIFY OP_CHECKDLS Signing with NOINPUT,NOSCRIPT and codeseparatorpos=1 enforces CLTV and allows binding to any prior update tx -- so works for an update tx spending previous update txs; while signing with codeseparatorpos=-1 and NOINPUT but committing to the script code and nSequence (for the CSV delay) allows binding to only that update tx -- so works for the settlement tx. That's two pubkeys, two sigs, and the taproot point reveal. Cheers, aj