As suggested by petertodd here https://www.reddit.com/r/Bitcoin/comments/3wt1b9/bip65_cltv_just_went_into_full_enforcement/cxywon5
:)
As suggested by petertodd here https://www.reddit.com/r/Bitcoin/comments/3wt1b9/bip65_cltv_just_went_into_full_enforcement/cxywon5
:)
Concept ACK
Could you please squash those commits? Commits should be as small as possible but still atomic.
It'd be a good idea to note that the name has changed in the release notes, as this has the (small) potential to break some code that depends on what decodescript returns; we probably won't release this until v0.13
225 | @@ -226,7 +226,8 @@ def __new__(cls, n): 226 | 227 | # expansion 228 | OP_NOP1 = CScriptOp(0xb0) 229 | -OP_NOP2 = CScriptOp(0xb1) 230 | +OP_CHECKLOCKTIMEVERIFY = CScriptOp(0xb1) 231 | +OP_NOP2 = OP_CHECKLOCKTIMEVERIFY
I am not sure this "compatibility" should be retained. If someone is specifying OP_NOP2, they may actually be expecting OP_NOP2 behaviour. Better to error and let them explicitly change to OP_CHECKLOCKTIMEVERIFY.
@petertodd If they depend on OP_NOP2 being returned, they are likely to be more subtley broken by not updating this...
Updated with release note update and the compatibility define removed.
concept/once-over utACK 0bf46e0
@paveljanik Only if the verbose option is specified, the json output contains an asm script field. Standard hex output is not.
@mb300sd Right. Thank you. Can you please add "(in verbose mode)"?
utACK 37d271d
utACK (but the tests are sufficient here) 37d271d7cce44885f835292ffe99b54399b014d6
tested ACK