[Bitcoin-development] CLTV opcode allocation; long-term plans?

Peter Todd 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...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150512/40ff0fa9/attachment.sig>

More information about the bitcoin-dev mailing list