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 EC4661361; Fri, 22 Mar 2019 07:46:39 +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-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 376AB19B; Fri, 22 Mar 2019 07:46:38 +0000 (UTC) Date: Fri, 22 Mar 2019 07:46:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1553240796; bh=D1sCRECmIpxfNPmYGJJLg0/u40GfsUZs0XMyPEHiCrI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=f8lrBR4LeM7GVqk9ZHfTMXkimP9mRVnSsTUcPFRRHoVrRF0Aype/Anr5c5uImGTks xQrDsoJA3z/uV1/TyA/cVnk3e2M8zPClOj5R4k3HxoTVeLixGIVw8ACcRD6A6VN9on vU0Yzam5WceVa61H7z4/tf0Zw1BQoQ0SjyEfGJso= To: Anthony Towns From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <20190322025846.ltsqgknp4s7um6lg@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> <20190322025846.ltsqgknp4s7um6lg@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 13:41:42 +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 07:46:40 -0000 Good morning aj, I understand. Looks like that makes sense. It seems possible to use this, then, together with watchtowers. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Friday, March 22, 2019 10:58 AM, Anthony Towns wrote= : > On Fri, Mar 22, 2019 at 01:59:14AM +0000, ZmnSCPxj wrote: > > > > If codeseparator is too scary, you could probably also just always > > > require the locktime (ie for settlmenet txs as well as update txs), i= e: > > > OP_CHECKLOCKTIMEVERIFY OP_DROP > > > OP_CHECKDLSVERIFY OP_CHECKDLS > > > and have update txs set their timelock; and settlement txs set a abso= lute > > > timelock, relative timelock via sequence, and commit to the script co= de. > > > > I think the issue I have here is the lack of `OP_CSV` in the settlement= branch. > > You can enforce the relative timelock in the settlement branch simply > by refusing to sign a settlement tx that doesn't have the timelock set; > the OP_CSV is redundant. > > > Consider a channel with offchain transactions update-1, settlement-1, u= pdate-2, and settlement-2. > > If update-1 is placed onchain, update-1 is also immediately spendable b= y settlement-1. > > settlement-1 was signed by you, and when you signed it you ensured that > nsequence was set as per BIP-68, and NOINPUT sigs commit to nsequence, > so if anyone changed that after the fact the sig isn't valid. Because > BIP-68 is enforced by consensus, update-1 isn't immediately spendable > by settlement-1. > > Cheers, > aj