Is this BIP65 sample script standard?

[CIYAM]

The script construction is as follows

OP_DUP OP_SHA256 <HASH> OP_EQUAL
OP_IF
   OP_DROP
   <PUBKEY 2>
   OP_CHECKSIG
OP_ELSE
   <CLTV>
   OP_NOP2
   OP_DROP
   <PUBKEY 1>
   OP_CHECKSIG
OP_ENDIF

I have not yet tried redeeming by using the else block, as I think it may work as well.

Anyway, I am wondering if we can just eliminate the OP_DUP and both of the OP_DROP opcodes as there is a redundant secret value to the stack while evaluating the script.

The two OP_DROPs actually do different things so if we want to have the following two ways to do the redeem they have to stay:

1) PUSH <sig> PUSH <secret> P2SH
(redeem using the secret)

2) PUSH <sig> P2SH
(redeem using the CLTV refund - in this case the OP_DUP will actually make a second copy of the <sig>)

So the first OP_DROP is because of the redundant secret copy on the stack (in the case of the "reveal secret redeem") but the second one is because of the CLTV value (as in the second case it is expected that only the sig was pushed onto the stack before the P2SH script is executed).

Hope that makes sense and nice to see that the script appears to be running as expected!

[1715363211]

1715363211

[1715363211]

1715363211

[CIYAM]

I think we have basically nutted it out (https://webbtc.com/script/7fec1a377344333496cca3d67b06d418f199702cf4a9f5fcb8fbb38c5de963ca:0) where the P2SH script is as follows:

Code:

OP_DUP
OP_SHA256
c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f268646
OP_EQUAL
OP_IF
OP_DROP
OP_DUP
OP_HASH160
937fe2ee82229d282edec2606c70e755875334c0
OP_EQUALVERIFY
OP_CHECKSIG
OP_ELSE
c8f505
OP_NOP2
OP_DROP
OP_DUP
OP_HASH160
20fbf78ba8f2f36feaec0efc5b82d5e07fb261a9
OP_EQUALVERIFY
OP_CHECKSIG
OP_ENDIF

This tx has been issued on mainnet with the CLTV refund operating as expected: https://blockchain.info/tx/7fec1a377344333496cca3d67b06d418f199702cf4a9f5fcb8fbb38c5de963ca (thanks to @sonicskye for creating the txs).

Note that c8f505 is the CLTV value that will be checked against nLockTime for the CLTV refund redeem and c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f268646 is the hash of the secret that would need to be pushed for the secret revealing refund.

This version uses public key hashes rather than public keys so that you would only need to provide an "address" to the other user (which will be easier for end users to understand).

So the tx can be redeemed immediately by pushing signature 1, public key 1, secret and P2SH script or either at or after the CLTV block by pushing signature 2, public key 2 and the P2SH script (the OP_DUP and OP_DROPs in the P2SH script take care of the stack imbalance when using the CLTV redeem method). Note that nLockTime with a value >= to the CLTV must be provided for the refund redeem to work.

[CIYAM]

The one thing that is bothering me (taken from the BIP) is the following:

Code:

        // Finally the nLockTime feature can be disabled and thus
        // CHECKLOCKTIMEVERIFY bypassed if every txin has been
        // finalized by setting nSequence to maxint. The
        // transaction would be allowed into the blockchain, making
        // the opcode ineffective.

I'm not certain how to interpret this but I am concerned if it means that CLTV could be ignored. Can anyone better explain this?

[jl777]

The one thing that is bothering me (taken from the BIP) is the following:

Code:

        // Finally the nLockTime feature can be disabled and thus
        // CHECKLOCKTIMEVERIFY bypassed if every txin has been
        // finalized by setting nSequence to maxint. The
        // transaction would be allowed into the blockchain, making
        // the opcode ineffective.

I'm not certain how to interpret this but I am concerned if it means that CLTV could be ignored. Can anyone better explain this?

It does seem that if you cant control any of the txin, the nLockTime is just ignored if all sequence id is 0xffffffff (the default value)

for doing micropayment channel and other offchain tx where the same inputs are "reused", the sequence is set to a smaller value and increased, with the 0xffffffff meaning it is finalized, so I think the same logic is used here

however if at least one txin has a sequence that is not 0xffffffff then the CHECKLOCKTIMEVERIFY wont be bypassed. at worst, you would need to mix in some small satoshis worth of inputs

James

[CIYAM]

however if at least one txin has a sequence that is not 0xffffffff then the CHECKLOCKTIMEVERIFY wont be bypassed. at worst, you would need to mix in some small satoshis worth of inputs

Not so sure about that as this:

Code:

        // Testing if this vin is not final is sufficient to
        // prevent this condition. Alternatively we could test all
        // inputs, but testing just this input minimizes the data
        // required to prove correct CHECKLOCKTIMEVERIFY execution.
        if (txTo.vin[nIn].IsFinal())
            return false;

Means that it only actually tests the one vin.

[achow101]

however if at least one txin has a sequence that is not 0xffffffff then the CHECKLOCKTIMEVERIFY wont be bypassed. at worst, you would need to mix in some small satoshis worth of inputs

Not so sure about that as this:

Code:

        // Testing if this vin is not final is sufficient to
        // prevent this condition. Alternatively we could test all
        // inputs, but testing just this input minimizes the data
        // required to prove correct CHECKLOCKTIMEVERIFY execution.
        if (txTo.vin[nIn].IsFinal())
            return false;

Means that it only actually tests the one vin.

A proper OP_CLTV input needs to be nonfinal. It needs to have a sequence number that is not maxint. Since this code is part of the code that runs for each input (it loops and evaluates each input independently), it just needs to check that this one input with OP_CLTV is nonfinal in order for OP_CLTV to work. It doesn't need to check the sequence number of any of the other inputs if this one input is nonfinal. It would need to check those sequence numbers if this was final.

Also, I don't think that code is in production since I didn't find it in the source, although I may have just skipped over it. Here is the code in the actual source code: https://github.com/bitcoin/bitcoin/blob/327291af02d05e09188713d882bf68ac708c1077/src/script/interpreter.cpp#L331

[CIYAM]

Also, I don't think that code is in production since I didn't find it in the source, although I may have just skipped over it. Here is the code in the actual source code: https://github.com/bitcoin/bitcoin/blob/327291af02d05e09188713d882bf68ac708c1077/src/script/interpreter.cpp#L331

Aha - yes - so those final checks don't actually happen. I do know that we had created an ACCT tx but managed to "lock it up" by sending a refund tx that was basically invalid (but was not dropped so stayed in the mempools preventing the "secret reveal" tx from being able to be correctly sent).

That is my major concern (that the whole thing might actually be flawed).

If it is possible for the one party to just block the other party with an invalid tx then it basically means that CLTV is a fail for the ACCT use case (and presumably for any other use case also).

[sniveling]

I don't know if the discussion in the following thread is relevant, or if the information in it is up to date, but it references part of the bitcoin.org developer guide comcerning locktime and sequence number.

http://bitcoin.stackexchange.com/questions/40706/why-is-op-checklocktimeverify-disabled-by-maximum-sequence-number

This is the part of the developer's guide it references. However, I have often read warnings to only rely on the source code and find the functions relevant to your problem, as knightdk was attempting to do. The developer's guide isn't as authoritative as the source code and can contain errors, or be out of date.

https://bitcoin.org/en/developer-guide#locktime-and-sequence-number

Locktime allows signers to create time-locked transactions which will only become valid in the future, giving the signers a chance to change their minds.

...

Previous versions of Bitcoin Core provided a feature which prevented transaction signers from using the method described above to cancel a time-locked transaction, but a necessary part of this feature was disabled to prevent denial of service attacks. A legacy of this system are four-byte sequence numbers in every input. Sequence numbers were meant to allow multiple signers to agree to update a transaction; when they finished updating the transaction, they could agree to set every input’s sequence number to the four-byte unsigned maximum (0xffffffff), allowing the transaction to be added to a block even if its time lock had not expired.

Even today, setting all sequence numbers to 0xffffffff (the default in Bitcoin Core) can still disable the time lock, so if you want to use locktime, at least one input must have a sequence number below the maximum Since sequence numbers are not used by the network for any other purpose, setting any sequence number to zero is sufficient to enable locktime.

[fbueller]

Again I'm pretty sure that the IF..ELSE shown in the BIP65 example is not the same as OP_IF and OP_ELSE.

The way it reads in the BIP is:

IF
 <cond1> <cond2>
ELSE
 <cond3> <cond4>
ENDIF

but in Bitcoin Script AFAICT you would need to actually do this:

<cond1>
OP_IF
<cond2> (where this will be executed if <cond1> was true)
OP_ELSE
<cond3> (where these will be executed if <cond1> was false)
<cond4>
OP_ENDIF

It is odd that you would be having troubles pushing the tx to testnet (as it is more relaxed about things like txs being standard).

I do have a testnet peer running so perhaps I could help with trying to push the raw transactions (and seeing if anything appears to be wrong with say the P2SH address or the like).

I think you are right about this. It really helps me to understand how the conditional script works.

Anyway, here is another tx to study https://webbtc.com/script/1dcdcaad7cb6550170662d7190d4a5cab6c5e3c61e1f289a91331dec4b811835:0
Instead of redeeming the "else" conditional, it entered the "if" block by exposing the secret value.

Notice that in the example it's specified as an output script, or p2sh script. The ScriptSig is where you push <cond>, triggering the different branches.

[sniveling]

On the 14th of December Peter Todd tweeted that BIP65 OP_CHECKLOCKTIMEVERIFY can be used in production.

https://twitter.com/petertoddbtc/status/676453190443773954

BIP65 OP_CHECKLOCKTIMEVERIFY can now be used in production on Bitcoin mainnet.

He made this reddit post which contains a demo script that might be useful to the top coders here. His script time locked any Bitcoins sent to 3F6ZKHjT4iGW5vimA54htkVErTpdxw6994 until Dec 21st.

https://www.reddit.com/r/Bitcoin/comments/3wt8fw/bip65_op_checklocktimeverify_can_now_be_used_in/cxyvpo6

[–]petertodd - Bitcoin Expert 3 points 15 days ago

Here's a quick-n-dirty script to play with if you want to try it out:

https://github.com/petertodd/checklocktimeverify-demos/blob/master/hodl.py

For example, here's me creating a P2SH-using address with a locktime set to about a week in the future:

Code:

./hodl.py -v <my privkey> 1450719427 create
DEBUG:root:redeemScript: 04c3387856b1752103f5f810828bcb3805ed0c28afebbaf064977195dc06aed0e2edd6d0c4378fcc01ac
3F6ZKHjT4iGW5vimA54htkVErTpdxw6994

The verbose (-v) flag enabled debugging output, which lets me see the actual redeemScript for that address. We can use Bitcoin Core's decodescript RPC command to decode it:

Code:

$ bitcoin-cli decodescript 04c3387856b1752103f5f810828bcb3805ed0c28afebbaf064977195dc06aed0e2edd6d0c4378fcc01ac
{
  "asm": "1450719427 OP_NOP2 OP_DROP 03f5f810828bcb3805ed0c28afebbaf064977195dc06aed0e2edd6d0c4378fcc01 OP_CHECKSIG",
  "type": "nonstandard",
  "p2sh": "3F6ZKHjT4iGW5vimA54htkVErTpdxw6994"
}

OP_NOP2 is the same as OP_CHECKLOCKTIMEVERIFY - to keep the CLTV pull-req as minimal and risk-free as possible I didn't change the name! An easy project for a dev new to Bitcoin Core would be to fix this.

If anyone sends any bitcoins to 3F6ZKHjT4iGW5vimA54htkVErTpdxw6994, I'll be able to spend them after about Dec 21st 18:00 UTC with:

Code:

./hodl.py -v <my privkey> 1450719427 spend txid:n [txid:n ...] <my-address>

[CIYAM]

After taking a closer look at the code I found this (scroll down to the bottom):

Code:

bool TransactionSignatureChecker::CheckLockTime(const CScriptNum& nLockTime) const
{
    // There are two kinds of nLockTime: lock-by-blockheight
    // and lock-by-blocktime, distinguished by whether
    // nLockTime < LOCKTIME_THRESHOLD.
    //
    // We want to compare apples to apples, so fail the script
    // unless the type of nLockTime being tested is the same as
    // the nLockTime in the transaction.
    if (!(
        (txTo->nLockTime <  LOCKTIME_THRESHOLD && nLockTime <  LOCKTIME_THRESHOLD) ||
        (txTo->nLockTime >= LOCKTIME_THRESHOLD && nLockTime >= LOCKTIME_THRESHOLD)
    ))
        return false;

    // Now that we know we're comparing apples-to-apples, the
    // comparison is a simple numeric one.
    if (nLockTime > (int64_t)txTo->nLockTime)
        return false;

    // Finally the nLockTime feature can be disabled and thus
    // CHECKLOCKTIMEVERIFY bypassed if every txin has been
    // finalized by setting nSequence to maxint. The
    // transaction would be allowed into the blockchain, making
    // the opcode ineffective.
    //
    // Testing if this vin is not final is sufficient to
    // prevent this condition. Alternatively we could test all
    // inputs, but testing just this input minimizes the data
    // required to prove correct CHECKLOCKTIMEVERIFY execution.
    if (txTo->vin[nIn].IsFinal())
        return false;

    return true;
}

So the check for IsFinal (which is what checks for 0xffffffff) is actually preventing OP_CHECKLOCKTIMEVERIFY from being disabled.

Will be doing some further testing to see what happens if a CLTV redeem that accidentally (or on purpose) does set the nSequence to 0xffffffff (the main concern being that if the tx remains in the mempool it could actually block the secret revealing tx as a double spend attempt).

[CIYAM]

So far I have now come up with the following P2SH template:

76a820<SCTH>87637576a914<PKH1>88ac6703<BLKN>b17576a914<PKH2>88ac68

which can be better understood as this:

Code:

OP_DUP
OP_SHA256
<SCTH>
OP_EQUAL
OP_IF
OP_DROP
OP_DUP
OP_HASH160
<PKH1>
OP_EQUALVERIFY
OP_CHECKSIG
OP_ELSE
<BLKN>
OP_NOP2
OP_DROP
OP_DUP
OP_HASH160
<PKH2>
OP_EQUALVERIFY
OP_CHECKSIG
OP_ENDIF

Noting that:
<SCTH> is the SHA256 hash of the "secret"
<PKH1> is the public key hash for the "reveal secret" redeem script
<BLKN> is the block number for a CLTV refund to occur at and
<PKH2> is the public key hash for the "CLTV refund" redeem script

The lengths of things being pushed onto the stack has been hard-coded in this template which is fine for the hashes but would not be fine if you changed <BLKN> to instead be a timestamp (something I'll be looking into a little later).

[achow101]

What software are yous using to make these transactions? Or are you writing the hex by hand?

[CIYAM]

What software are yous using to make these transactions? Or are you writing the hex by hand?

@sonicskye was using BX (originally SX by Amir Taaki) but I am just doing the raw txs by hand (although I have developed my own tools which I will be using to make this simpler).

You can actually use bitcoin-cli to do quite a bit of this stuff also (apart from the above script template which is why I wanted to get that done first).

What is neat about this template is that it works with two addresses (well hashes but it is straight forward to convert an address to its hash rather than having to exchange public keys like you have to with multisig) with one being tied to revealing the secret and the other being tied to the CLTV refund.

[sonicskye]

So far I have now come up with the following P2SH template:

76a820<SCTH>87637576a914<PKH1>88ac6703<BLKN>b17576a914<PKH2>88ac68

which can be better understood as this:

Code:

OP_DUP
OP_SHA256
<SCTH>
OP_EQUAL
OP_IF
OP_DROP
OP_DUP
OP_HASH160
<PKH1>
OP_EQUALVERIFY
OP_CHECKSIG
OP_ELSE
<BLKN>
OP_NOP2
OP_DROP
OP_DUP
OP_HASH160
<PKH2>
OP_EQUALVERIFY
OP_CHECKSIG
OP_ENDIF

Noting that:
<SCTH> is the SHA256 hash of the "secret"
<PKH1> is the public key hash for the "reveal secret" redeem script
<BLKN> is the block number for a CLTV refund to occur at and
<PKH2> is the public key hash for the "CLTV refund" redeem script

The lengths of things being pushed onto the stack has been hard-coded in this template which is fine for the hashes but would not be fine if you changed <BLKN> to instead be a timestamp (something I'll be looking into a little later).

I was trying to add another branch of OP_ELSE to mimic Gmaxwell's CoinSwap but I don't really know how to skip the previous OP_ELSE and run the next OP_ELSE. Do you know how to do it?

[CIYAM]

I was trying to add another branch of OP_ELSE to mimic Gmaxwell's CoinSwap but I don't really know how to skip the previous OP_ELSE and run the next OP_ELSE. Do you know how to do it?

I think I remember reading that you can nest the OP_IFs - in which case you would do something like this:

<cond1>
OP_IF
<cond2>
OP_IF
...
OP_ELSE
...
OP_ENDIF
OP_ELSE
...
OP_ENDIF

[CIYAM]

Am trying now to get this to work with testnet but I'm having troubles working out how to construct the raw tx in a way that will let bitcoin-cli sign it for me.

This is basically what I have created:

Code:

0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e84100000000cc47304402204caf58993eceb55c5df0db0c4d96571327a6678c0acd648c21133ca39034b7d70220093a8b935d651d59330b3e6b0e1ce52c3610bad9f6f1b9cd1ae48e7e6528838e012103d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4043a6645983a479588ac68000000000140420f00000000001976a9148a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b88ac00000000

which when decoded looks like this:

Code:

{
    "txid" : "9ed60a3a4218fb5c8469e37ff9c726570527ab327f886e84fb8a3019c0a02919",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "304402204caf58993eceb55c5df0db0c4d96571327a6678c0acd648c21133ca39034b7d70220093a8b935d651d59330b3e6b0e1ce52
c3610bad9f6f1b9cd1ae48e7e6528838e01 03d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd759 76a820c775e7b757ede630cd0aa11
13bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8
c88d0b7a4043a6645983a479588ac68",
                "hex" : "47304402204caf58993eceb55c5df0db0c4d96571327a6678c0acd648c21133ca39034b7d70220093a8b935d651d59330b3e6b0e1ce
52c3610bad9f6f1b9cd1ae48e7e6528838e012103d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630c
d0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6
774de8c88d0b7a4043a6645983a479588ac68"
            },
            "sequence" : 0
        }
    ],
    "vout" : [
        {
            "value" : 0.01000000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 8a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a9148a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b88ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "mt9EHSSeERgWKNqYfdmkpa4Mjb4EXr4QY2"
                ]
            }
        }
    ]
}

Now the problem with the above is that I stuffed in a rubbish signature (first part of the scriptSig) in order to get the raw transaction to correctly decode (I tried numerous versions that were missing the signature but they all failed to decode). So the question is how do I remove the rubbish signature and end up with a raw transaction that "signrawtransaction" will work with?

[CIYAM]

Hmm... I have nearly got there (perhaps):

Code:

0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e8410000000085002103d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4043a6645983a479588ac68000000000140420f00000000001976a9148a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b88ac00000000

When I decode this I am seeing the following (which I think looks fine):

Code:

{
    "txid" : "b6ae7d90587b27adef7c36571cc1fdf4fbe04c77d2a3113a2239188285f581cf",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb",
            "vout" : 0,
            "scriptSig" : {
                "asm" : "0 03d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd759 76a820c775e7b757ede630cd0aa1113bd10266
1ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4
043a6645983a479588ac68",
                "hex" : "002103d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630cd0aa1113bd
102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d
0b7a4043a6645983a479588ac68"
            },
            "sequence" : 0
        }
    ],
    "vout" : [
        {
            "value" : 0.01000000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_DUP OP_HASH160 8a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b OP_EQUALVERIFY OP_CHECKSIG",
                "hex" : "76a9148a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b88ac",
                "reqSigs" : 1,
                "type" : "pubkeyhash",
                "addresses" : [
                    "mt9EHSSeERgWKNqYfdmkpa4Mjb4EXr4QY2"
                ]
            }
        }
    ]
}

But unfortunately if I try and sign it I get this output:

Code:

{
    "hex" : "0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e8410000000085002103d30f361b0d5dacba61a56db0903fe
32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243
a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4043a6645983a479588ac68000000000140420f00000000001976a91
48a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b88ac00000000",
    "complete" : false,
    "errors" : [
        {
            "txid" : "41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb",
            "vout" : 0,
            "scriptSig" : "002103d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630cd0aa1113
bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c8
8d0b7a4043a6645983a479588ac68",
            "sequence" : 0,
            "error" : "NOPx reserved for soft-fork upgrades"
        }
    ]
}

[CIYAM]

Actually the error now makes me wonder if testnet3 even currently supports CLTV?

If not should I be using -regtest instead of -testnet and generate my own test blockchain?

[sniveling]

This Bitcoin Script IDE might be useful, but there might be a bug in it.

http://www.cs.princeton.edu/~tongbinw/bitcoinIDE/build/editor.html

The following thread discusses signing transactions on the testnet, and using the IDE to track down problems, but one of the final comments says it was giving inconsistent results with known good values. However, the IDE might have been updated since then.

http://bitcoin.stackexchange.com/questions/36496/how-to-redeem-non-standard-script-tx-testnet-instance