Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 09E31E2B; Fri, 22 Mar 2019 01:59:23 +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 1B4442D5; Fri, 22 Mar 2019 01:59:22 +0000 (UTC) Date: Fri, 22 Mar 2019 01:59:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1553219959; bh=OMYRukINuDhfCqQMbF29z1gG4PP2GbzRFVLa/z3CUIU=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=Qya1GBo4o9LLkFY2G39R8tKvI4v87G0PZKiafdwXDFfZf+9BzYiXFsh78mQxcb/ZI gVmB0UnS2V9q8v9Ro2ieUxBli1uMAe1k/oQapkpmmy/0Qcm1OKkBpAHnAedcrQUgY5 HCIdr/iH3mNGA6KIg+5eZ2JDP6nxAc0JmSLI5tow= To: Anthony Towns From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <20190321115522.lf7z6xb224lqqfla@erisian.com.au> References: <20190313014143.ifffshwdux2jt7w5@erisian.com.au> <87k1gubdjm.fsf@rustcorp.com.au> <87woku9q3g.fsf@rustcorp.com.au> <20190321090614.7ir64g2ehn3pz2cb@erisian.com.au> <5v4CPrMXyoMw0i1WtYYuIa_rMgkpq5NpnDhTNqTTZtfKKnFtwrbEGJnTD8ul71EM-MNpuo1R4znv4tPpwwm3Ys3m2Dbm3xsOGi96NYE9qfU=@protonmail.com> <20190321115522.lf7z6xb224lqqfla@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: Fri, 22 Mar 2019 02:59:36 +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: Fri, 22 Mar 2019 01:59:23 -0000 Good morning aj, > > If you are committing to the script code, though, then each settlement > sig is already only usable with the corresponding update tx, so you > don't need to roll the keys. But you do need to make it so that the > update sig requires the CLTV; one way to do that is using codeseparator > to distinguish between the two cases. > > > Also, I cannot understand `OP_CODESEPARATOR`, please no. > > If codeseparator is too scary, you could probably also just always > require the locktime (ie for settlmenet txs as well as update txs), ie: > > OP_CHECKLOCKTIMEVERIFY OP_DROP > OP_CHECKDLSVERIFY OP_CHECKDLS > > and have update txs set their timelock; and settlement txs set a absolute > timelock, relative timelock via sequence, and commit to the script code. > > (Note that both those approaches (with and without codesep) assume there'= s > some flag that allows you to commit to the scriptcode even though you're > not committing to your input tx (and possibly not committing to the > scriptpubkey). BIP118 doesn't have that flexibility, so the A_s_i and > B_s_i key rolling is necessary) I think the issue I have here is the lack of `OP_CSV` in the settlement bra= nch. Consider a channel with offchain transactions update-1, settlement-1, updat= e-2, and settlement-2. If update-1 is placed onchain, update-1 is also immediately spendable by se= ttlement-1. But settlement-1 cannot be spent by update-2 and thus the invalidation of o= lder state fails. The `OP_CSV` in the settlement branch of the update transaction outputs exi= sts to allow later update transactions have higher priority over settlement= transactions. To ensure that a settlement signature can only take the settlement branch, = we need a distinct public key for the branch, so at least `A_s` and `B_s` w= ithout rolling them for each `i`, if we use `nLockTime` on the settlement t= ransactions and enforce it with `OP_CHECKLOCKTIMEVERIFY`. It might be possible to do this with `OP_CODESEPARATOR`, but we do need the= `OP_CSV` in the settlement branch. Regards, ZmnSCPxj