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 E5B711178; Fri, 22 Mar 2019 02:58:56 +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 E9A5D148; Fri, 22 Mar 2019 02:58:54 +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 1h7AOQ-0001Zj-SF; Fri, 22 Mar 2019 12:58:52 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Fri, 22 Mar 2019 12:58:46 +1000 Date: Fri, 22 Mar 2019 12:58:46 +1000 From: Anthony Towns To: ZmnSCPxj Message-ID: <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> 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: Fri, 22 Mar 2019 13:40:26 +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 02:58:57 -0000 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), 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. > > 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, update-2, and settlement-2. > If update-1 is placed onchain, update-1 is also immediately spendable by 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