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
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
