Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from <luke@dashjr.org>) id 1YsGxi-0004UL-HZ for bitcoin-development@lists.sourceforge.net; Tue, 12 May 2015 20:39:34 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of dashjr.org designates 85.234.147.28 as permitted sender) client-ip=85.234.147.28; envelope-from=luke@dashjr.org; helo=zinan.dashjr.org; Received: from 85-234-147-28.static.as29550.net ([85.234.147.28] helo=zinan.dashjr.org) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YsGxh-0002YN-An for bitcoin-development@lists.sourceforge.net; Tue, 12 May 2015 20:39:34 +0000 Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id D0A76108371C; Tue, 12 May 2015 20:38:29 +0000 (UTC) X-Hashcash: 1:25:150512:bitcoin-development@lists.sourceforge.net::X55WnCAZ9JpYFMGP:bIjKK X-Hashcash: 1:25:150512:btcdrak@gmail.com::IR5n3d8c9U0btUh9:6k39 X-Hashcash: 1:25:150512:jtimon@jtimon.cc::ef=EQjsq3d69BQsA:75hy From: Luke Dashjr <luke@dashjr.org> To: bitcoin-development@lists.sourceforge.net Date: Tue, 12 May 2015 20:38:27 +0000 User-Agent: KMail/1.13.7 (Linux/3.14.37-gentoo; KDE/4.14.3; x86_64; ; ) References: <20150504050715.GA18856@savin.petertodd.org> <CABm2gDqVu9OqNpOgCa6hMw3CXp7ePWTaAGPtMq4T9rG658K=ow@mail.gmail.com> <CADJgMzv1NdoXKDScQ1+OycijzME=W2YSut3GMF=EEuKQf6VeUg@mail.gmail.com> In-Reply-To: <CADJgMzv1NdoXKDScQ1+OycijzME=W2YSut3GMF=EEuKQf6VeUg@mail.gmail.com> X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201505122038.28831.luke@dashjr.org> X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 TVD_RCVD_IP Message was received from an IP address -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1YsGxh-0002YN-An Subject: Re: [Bitcoin-development] CLTV opcode allocation; long-term plans? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: <bitcoin-development.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> List-Post: <mailto:bitcoin-development@lists.sourceforge.net> List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> X-List-Received-Date: Tue, 12 May 2015 20:39:34 -0000 It should actually be straightforward to softfork RCLTV in as a negative CLTV. All nLockTime are >= any negative number, so a negative number makes CLTV a no-op always. Therefore, it is clean to define negative numbers as relative later. It's also somewhat obvious to developers, since negative numbers often imply an offset (eg, negative list indices in Python). Luke