On Tue, May 12, 2015 at 08:38:27PM +0000, Luke Dashjr wrote:
> 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).

Doing this makes handling the year 2038 problem a good deal more
complex.

The CLTV codebase specifically fails on negative arguments to avoid any
ambiguity or implementation differences here.

-- 
'peter'[:-1]@petertodd.org
00000000000000000e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7