5fe90b644417db0a72f938089a06106c570fbd
1 Return-Path: <aj@erisian.com.au> 2 Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org 3 [172.17.192.35]) 4 by mail.linuxfoundation.org (Postfix) with ESMTPS id E516519B7; 5 Thu, 21 Mar 2019 09:06:23 +0000 (UTC) 6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 7 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 8 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) 9 by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 630A9D3; 10 Thu, 21 Mar 2019 09:06:23 +0000 (UTC) 11 Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) 12 by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian)) 13 id 1h6teU-0001pZ-QC; Thu, 21 Mar 2019 19:06:20 +1000 14 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); 15 Thu, 21 Mar 2019 19:06:14 +1000 16 Date: Thu, 21 Mar 2019 19:06:14 +1000 17 From: Anthony Towns <aj@erisian.com.au> 18 To: ZmnSCPxj <ZmnSCPxj@protonmail.com> 19 Message-ID: <20190321090614.7ir64g2ehn3pz2cb@erisian.com.au> 20 References: <20190313014143.ifffshwdux2jt7w5@erisian.com.au> 21 <87k1gubdjm.fsf@rustcorp.com.au> <87woku9q3g.fsf@rustcorp.com.au> 22 <UOdt33VfD8o6NfeDKMSip0hUmy1_jyo65-ihunuMRRg8IfXEOq-W60-TPoINm5HErPqnY_-yd1x_VnnVihrvtXRA2OHkjeROZheZ_QV0Zvo=@protonmail.com> 23 <isp2OcX23r-Tfl-WSbybuKnppjVlZV52AM1GGEaQd8uHlkliikUBvK49WOnzgaxOjDuOCNdu6CsmHt6kfK0z_FRrOgYAYWrWaDniZA3EEZQ=@protonmail.com> 24 MIME-Version: 1.0 25 Content-Type: text/plain; charset=us-ascii 26 Content-Disposition: inline 27 In-Reply-To: <isp2OcX23r-Tfl-WSbybuKnppjVlZV52AM1GGEaQd8uHlkliikUBvK49WOnzgaxOjDuOCNdu6CsmHt6kfK0z_FRrOgYAYWrWaDniZA3EEZQ=@protonmail.com> 28 User-Agent: NeoMutt/20170113 (1.7.2) 29 X-Spam-Score: -1.9 30 X-Spam-Score-int: -18 31 X-Spam-Bar: - 32 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY 33 autolearn=ham version=3.3.1 34 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on 35 smtp1.linux-foundation.org 36 X-Mailman-Approved-At: Thu, 21 Mar 2019 16:54:19 +0000 37 Cc: "bitcoin-dev@lists.linuxfoundation.org" 38 <bitcoin-dev@lists.linuxfoundation.org>, 39 "lightning-dev@lists.linuxfoundation.org" 40 <lightning-dev@lists.linuxfoundation.org> 41 Subject: Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety 42 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org 43 X-Mailman-Version: 2.1.12 44 Precedence: list 45 List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> 46 List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 47 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> 48 List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> 49 List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> 50 List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> 51 List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 52 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> 53 X-List-Received-Date: Thu, 21 Mar 2019 09:06:24 -0000 54 55 On Wed, Mar 20, 2019 at 08:07:00AM +0000, ZmnSCPxj via Lightning-dev wrote: 56 > Re-reading again, I think perhaps I was massively confused by this: 57 > > that commits to the input. In that case, you could do eltoo with a 58 > > script like either: 59 > > <A> CHECKSIGVERIFY <B> CHECKSIG 60 > > or <P> CHECKSIGVERIFY <Q> CHECKSIG 61 > 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`? 62 63 I meant "either of the two scripts is okay". 64 65 > In the blob sent to Watchtower, A (or B) includes the `SIGHASH_NOINPUT` as well as the `q` private key. 66 > Would it be safe for Watchtower to know that? 67 68 I think so. From Alice/Bob's point-of-view, the NOINPUT sig ensures they 69 control their money; and from the network's point-of-view (or at least 70 that part of the network that thinks NOINPUT is unsafe) the Q private 71 key being shared makes the tx no worse than a 1-of-n multisig setup, 72 which has to be dealt with anyway. 73 74 > Then each update transaction pays out to: 75 > OP_IF 76 > <csv_delta> OP_CSV OP_DROP 77 > <muSig(A_si,B_si)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG 78 > OP_ELSE 79 > <i> OP_CHECKLOCKTIMEVERIFY OP_DROP 80 > <muSig(A_u,B_u)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG 81 > OP_ENDIF 82 83 Yeah. 84 85 I think we could potentially make that shorter still: 86 87 IF OP_CODESEPARATOR <i> OP_CHECKLOCKTIMEVERIFY OP_DROP ENDIF 88 <muSig(A_u,B_u)> OP_CHECKDLSVERIFY <Q> OP_CHECKDLS 89 90 Signing with NOINPUT,NOSCRIPT and codeseparatorpos=1 enforces CLTV 91 and allows binding to any prior update tx -- so works for an update tx 92 spending previous update txs; while signing with codeseparatorpos=-1 93 and NOINPUT but committing to the script code and nSequence (for the 94 CSV delay) allows binding to only that update tx -- so works for the 95 settlement tx. That's two pubkeys, two sigs, and the taproot point 96 reveal. 97 98 Cheers, 99 aj 100 101