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 30EA226DF; Thu, 21 Mar 2019 10:05:20 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 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 65D6AD3; Thu, 21 Mar 2019 10:05:19 +0000 (UTC) Date: Thu, 21 Mar 2019 10:05:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1553162717; bh=tZpIxhiSlYB2lJuHTsoXZXWUXIH/6kLACx4GOCoJTI0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=X5pPxkZQgSYQj+xGOrOhxPApT0COkjDHJVSz3jCofrxOwe0R0tKSUkRl7K7ZLWrUu QpGGOFzXQp3a7FERVPUzOfxWkW7b8LK+iwLieedALSsd1v/WrF43+vNSiix4++rLxy SEKCG5SS9qI/mfR2/bARmP5P6kMzfJbExq10kBxw= To: Anthony Towns From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <5v4CPrMXyoMw0i1WtYYuIa_rMgkpq5NpnDhTNqTTZtfKKnFtwrbEGJnTD8ul71EM-MNpuo1R4znv4tPpwwm3Ys3m2Dbm3xsOGi96NYE9qfU=@protonmail.com> In-Reply-To: <20190321090614.7ir64g2ehn3pz2cb@erisian.com.au> References: <20190313014143.ifffshwdux2jt7w5@erisian.com.au> <87k1gubdjm.fsf@rustcorp.com.au> <87woku9q3g.fsf@rustcorp.com.au> <20190321090614.7ir64g2ehn3pz2cb@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: 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 10:05:20 -0000 Good morning aj, > > 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=3D1 enforces CLTV > and allows binding to any prior update tx -- so works for an update tx > spending previous update txs; while signing with codeseparatorpos=3D-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. Actually, the shared keys are different in the two branches above. The "update" branch (which has no `OP_CSV`) uses the same constant `A_u` an= d `B_u` points. The "state commit" branch (which has `OP_CSV`) uses different `A_si` and `B= _si` points depending on `i` (state/sequence number). Also, I cannot understand `OP_CODESEPARATOR`, please no. Regards, ZmnSCPxj