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 776E9AF6 for ; Thu, 22 Sep 2016 08:47:09 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out02.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B8D3E128 for ; Thu, 22 Sep 2016 08:47:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from mx04.mykolab.com (mx04.mykolab.com [10.20.7.102]) by mx-out02.mykolab.com (Postfix) with ESMTPS id 7458263480; Thu, 22 Sep 2016 10:47:05 +0200 (CEST) From: Tom To: bitcoin-dev@lists.linuxfoundation.org, adiabat Date: Thu, 22 Sep 2016 10:47:03 +0200 Message-ID: <1530052.vkWv7VPOpL@garp> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 22 Sep 2016 09:13:33 +0000 Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions. 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, 22 Sep 2016 08:47:09 -0000 On Wednesday 21 Sep 2016 18:45:55 adiabat via bitcoin-dev wrote: > Hi- > > One concern is that this doesn't seem compatible with Lightning as > currently written. Most relevant is that non-cooperative channel close > transactions in Lightning use OP_CHECKSEQUENCEVERIFY, which references the > sequence field of the txin; if the txin doesn't have a sequence number, > OP_CHECKSEQUENCEVERIFY can't work. > > LockByBlock and LockByTime aren't described and there doesn't seem to be > code for them in the PR (186). If there's a way to make OP_CLTV and OP_CSV > work with this new format, please let us know, thanks! LockByBlock and LockByTime are still TODOs because I didn't have time to go in-dept into how BIP68 does the encoding. The intent is that these tags, while loading, will set the sequence integer in the txin as the old version does. And while saving we do the reverse. In other words; the lack of sequence number in the saved format doesn't affect the in-memory format of the transaction. The in-memory version is the one that script will operate on. This means that there is no change in how CSV will work before and after on any level other than serialisation. Flexible Transactions is definitely meant to support the Lightning Network, so any problems you find is something we should solve before it ships. Thanks for your email!