[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
complex.

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

-- 
'peter'[:-1]@petertodd.org
00000000000000000e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7
-------------- 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