[Bitcoin-development] CLTV opcode allocation; long-term plans?
pete at petertodd.org
Tue May 12 21:01:25 UTC 2015
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
The CLTV codebase specifically fails on negative arguments to avoid any
ambiguity or implementation differences here.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 650 bytes
Desc: Digital signature
More information about the bitcoin-dev