I was able to successfully create a "regtest" CLTV redeem script for a P2SH address using the block number 0x7f but if I change it to 0xff (which I thought should be block 255) it won't work (giving me a "Negative locktime" error).
As nLockTime is unsigned I don't understand why the op code is reading a signed value and testing for it being negative.
Did I miss something?
In Bitcoin Script, all numbers are signed, and CLTV uses the existing mechanism.
then how to check for block 255?
(if I use 0x02ff00 it won't work)
(as it thinks I am adding zeroes when I shouldn't)
What error do you get, exactly?
Negative locktime
What error do you get when pushing FF 00?
SCRIPT_ERR_NEGATIVE_LOCKTIME
oh - no error
but doesn't work
error: {"code":-26,"message":"64: non-mandatory-script-verify-flag (No error)"}
(so literally it told me "No error") as the error :D
Nice catch, that's a bug in the reporting. I'll fix that.
so - how should I redeem with block 255? use 0x02ff00 or something else?
btw - you can't send "coinbase' to P2SH using regtest either
(it screws up the sigScriptPub)
One issue at a time please.
0xFF00 is indeed how you'd encode 255.
thanks - I can create another issue for the other problem - should I do that?
Will this work correctly with 3 byte blocks also? (such as 0x03ffff00) (am not sure exactly what your change does but noticed the change was from check to check2)
Actually I think you are right - and I assume that the "Negative locktime" error will still happen. (I am not actually currently able to use anything other than a released version of Bitcoin though)
the relevant code in "interpreter.cpp" is this: // In the rare event that the argument may be < 0 due to // some arithmetic being done first, you can always use // 0 MAX CHECKLOCKTIMEVERIFY. if (nLockTime < 0) return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME); (the comment is interesting as it seems to indicate there is some way to handle the negative values)
Unfortunately I don't have the time to set up an environment for doing testing with Bitcoin but hopefully others that are playing around with the new OP_CHECKLOCKTIMEVERIFY will. I think the issue is easily enough repeated for others to show.
If the rule is that all stack values for Bitcoin scripts are "signed" then I guess there is perhaps a fundamental problem here (as nLockTime is unsigned).
@ciyam You are confusing two things. The fact that all script numbers are signed does not prevent you from creating values that are in range for CLTV. In fact, the input numbers to CLTV can be up to 5 bytes (instead of 4) to account for exactly that.
okay - but does your change allow for 5 bytes? (if it does then I guess the problem is resolved) clearly we need it to work for: 0x017f, 0x02ff00 and 0x03ffff00 at the very least
My change? The patch I'm linking to just fixes a bug so it stops reporting "No error" but reports the actual error.
