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 ) 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 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> In-Reply-To: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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