Is this BIP65 sample script standard?

[CIYAM]

From the BIP section Trustless Payments for Publishing Data the following script appears:

Code:

    IF
        HASH160 <Hash160(encryption key)> EQUALVERIFY
        <publisher pubkey> CHECKSIG
    ELSE
        <expiry time> CHECKLOCKTIMEVERIFY DROP
        <buyer pubkey> CHECKSIG
    ENDIF

Although the release notes for Bitcoin core mention stuff about BIP65 it is not clear to me whether that means that the above is standard.

Assuming it is standard then if HASH160 was to be changed to say SHA256 would it still be standard?

[CIYAM]

Although I haven't confirmed it yet I get the feeling that one can make this or in fact any other similar script standard provided that it is created indirectly via a P2SH tx (so the script itself doesn't appear as an output but instead appears as in input when redeeming).

Hmm... seems I might be wrong about that: https://blockchain.info/tx/24a44ba982e4be2865c3c84fc408079871b49baa0d8a185ce45781228e8ae56e

(hovering the mouse over the little triangle displays: This transaction has a non-standard input.)

[cr1776]

Although I haven't confirmed it yet I get the feeling that one can make this or in fact any other similar script standard provided that it is created indirectly via a P2SH tx (so the script itself doesn't appear as an output but instead appears as in input when redeeming).

Hmm... seems I might be wrong about that: https://blockchain.info/tx/24a44ba982e4be2865c3c84fc408079871b49baa0d8a185ce45781228e8ae56e

(hovering the mouse over the little triangle displays: This transaction has a non-standard input.)

I've seen blockchain.info incorrectly mark standard transactions as non-standard in the past, so I don't think their note is dispositive. (Eg multi-sig, iirc - don't know if they've fixed that yet)

[CIYAM]

I've seen blockchain.info incorrectly mark standard transactions as non-standard in the past, so I don't think their note is dispositive. (Eg multi-sig, iirc - don't know if they've fixed that yet)

Am hoping that is the case but the tx is still unconfirmed despite being high priority and the CLTV expired 4 blocks ago (it is a refund tx for a CLTV approach to doing ACCT).

[var53]

I've seen blockchain.info incorrectly mark standard transactions as non-standard in the past, so I don't think their note is dispositive. (Eg multi-sig, iirc - don't know if they've fixed that yet)

Am hoping that is the case but the tx is still unconfirmed despite being high priority and the CLTV expired 4 blocks ago (it is a refund tx for a CLTV approach to doing ACCT).

Most of the blocks are full today so your transaction might take an exceptionally long time to confirm.



It took over an hour for my transaction to get one confirmation. It was missed out of the few small blocks with room for it.

If your test transaction's still unconfirmed by tomorrow then it's not standard.

[CIYAM]

It seems there was something wrong with that redeem script (still trying to work out exactly what) but this one seems to have done the trick:

https://webbtc.com/script/2bb5d0ac0eb17f5ebe2d660ec47b4888943b4a4f5433c09bd6514b7a36859a95:0

[amaclin]

Assuming it is standard then if HASH160 was to be changed to say SHA256 would it still be standard?

https://gist.github.com/gavinandresen/88be40c141bc67acb247

[CIYAM]

Assuming it is standard then if HASH160 was to be changed to say SHA256 would it still be standard?

https://gist.github.com/gavinandresen/88be40c141bc67acb247

Yup - from reading the code in IsStandardTx I had thought that it should be fine.

The tricky part is hand-crafting raw txs (very easy to get something wrong doing that) so the person helping me out with this is using BX (previously SX).

Basically what I am trying to get worked out is an ACCT tx "template" for Bitcoin that will be compatible with the ACCT AT implementation so that one will be able to exchange QORA or BURST for BTC without an exchange or other 3rd party.

[CIYAM]

So with the help of that online tool and my existing knowledge of the structure of raw transactions I've come up with this complete tx decomposition:

Code:

01000000 (version)
01 (number of inputs)
dfb1ee387eef27d2de91c824a467548a3879dd57691177591474fd2594d8bb23 (previous tx id reversed)
00000000 (previous tx output index)
be (190 bytes - input script length)
------------------------------------------------ 190 bytes ------------------------------------------- Inputs
48 PUSH_DATA (72 bytes - length of signature plus sig type byte)
[
3045 (DER sequence and length)
022100c9e7acd4f39a03acfcfc89438e764c4b5e4d7ab25f155aeb1a60bb47e63e52ad (DER X)
02201daaf42c4fbe3cba3b0c89f87e7aa2dfc5060ad4b44292e8371a2b561d28d42e (DER Y)
01 SIGHASH_ALL
]
00 OP_0 (why do this ???)
4c PUSH_DATA1
72 DATA_LENGTH (114 bytes - P2SH script length)
================================================ 114 bytes =========================================== Script
63 OP_IF
a8 OP_SHA256
20 PUSH_DATA (sha256 of secret)
[
c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f268646
]
88 OP_EQUALVERIFY
21 PUSH_DATA (public key)
[
03d7c6052544bc42eb2bc0d27c884016adb933f15576a1a2d21cd4dd0f2de0c37d
]
ac OP_CHECKSIG
67 OP_ELSE
03 PUSH_DATA (block #389900 - or should this be converted to hex and endian encoded???)
[
389900
]
b1 OP_NOP2 (OP_CLTV)
75 OP_DROP
21 PUSH_DATA (public key)
[
021844989a2bd7acd127dd7ed51aa2f4d55b32dbb414de6325ae37e05c1067598d
]
ac OP_CHECKSIG
68 OP_ENDIF
=============================================================================================================
-------------------------------------------------------------------------------------------------------------
5cf40500  (sequence 390236) which should probably be ffffffff
------------------------------------------------- 35 bytes ------------------------------------------ Outputs
01 (number of outputs)
1027000000000000 (value 0.0001 BTC)
19 PUSH_DATA (25 bytes - output script length)
[[
76 OP_DUP
a9 OP_HASH160
14 PUSH_DATA (hash160 of public key - i.e. address)
[
20fbf78ba8f2f36feaec0efc5b82d5e07fb261a9
]
88 OP_EQUALVERIFY
ac OP_CHECKSIG
]]
-------------------------------------------------------------------------------------------------------------
5cf40500 (nLockTime 390236)

So most of it is making sense to me (although it looks as though the sequence number was incorrectly set to the CLTV block #).

Also why is the OP_0 necessary (is this to do with the P2SH that was the output being used from the previous tx)?

[CIYAM]

BTW - for those who are wondering what the value of getting this stuff right you might want to check this out: http://blog.litecoin.org/2015/12/litecoin-core-v01040.html

Basically Litecoin will soon be accepting CLTV txs as well - so if we can get this ACCT working reliably then you will be able to trade LTC and BTC with any AT supporting platform (currently Qora and Burst).

The Bitcoin/Litecoin side will unfortunately not be so neat (it will require some additional scripts and off-chain communication between the two parties) but it would be a huge step in disbanding the need for crypto-to-crypto exchanges (which is *real disruption* IMO).

Assuming we can get this working in a reliable manner CIYAM will be looking to add support for this special kind of script to its Wallet package.

[sonicskye]

So with the help of that online tool and my existing knowledge of the structure of raw transactions I've come up with this complete tx decomposition:

Code:

01000000 (version)
01 (number of inputs)
dfb1ee387eef27d2de91c824a467548a3879dd57691177591474fd2594d8bb23 (previous tx id reversed)
00000000 (previous tx output index)
be (190 bytes - input script length)
------------------------------------------------ 190 bytes ------------------------------------------- Inputs
48 PUSH_DATA (72 bytes - length of signature plus sig type byte)
[
3045 (DER sequence and length)
022100c9e7acd4f39a03acfcfc89438e764c4b5e4d7ab25f155aeb1a60bb47e63e52ad (DER X)
02201daaf42c4fbe3cba3b0c89f87e7aa2dfc5060ad4b44292e8371a2b561d28d42e (DER Y)
01 SIGHASH_ALL
]
00 OP_0 (why do this ???)
4c PUSH_DATA1 (why do this ???)
72 PUSH_DATA (114 bytes - P2SH script length)
================================================ 114 bytes =========================================== Script
63 OP_IF
a8 OP_SHA256
20 PUSH_DATA (sha256 of secret)
[
c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f268646
]
88 OP_EQUALVERIFY
21 PUSH_DATA (public key)
[
03d7c6052544bc42eb2bc0d27c884016adb933f15576a1a2d21cd4dd0f2de0c37d
]
ac OP_CHECKSIG
67 OP_ELSE
03 PUSH_DATA (block #389900 - or should this be coverted to hex ???)
[
389900
]
b1 OP_NOP2 (OP_CLTV)
75 OP_DROP
21 PUSH_DATA (public key)
[
021844989a2bd7acd127dd7ed51aa2f4d55b32dbb414de6325ae37e05c1067598d
]
ac OP_CHECKSIG
68 OP_ENDIF
=============================================================================================================
-------------------------------------------------------------------------------------------------------------
5cf40500  (sequence 390236) which should probably be ffffffff
------------------------------------------------- 35 bytes ------------------------------------------ Outputs
01 (number of outputs)
1027000000000000 (value 0.0001 BTC)
19 PUSH_DATA (25 bytes - output script length)
[[
76 OP_DUP
a9 OP_HASH160
14 PUSH_DATA (hash160 of public key - i.e. address)
[
20fbf78ba8f2f36feaec0efc5b82d5e07fb261a9
]
88 OP_EQUALVERIFY
ac OP_CHECKSIG
]]
-------------------------------------------------------------------------------------------------------------
5cf40500 (nLockTime 390236)

So most of it is making sense to me (although it looks as though the sequence number was incorrectly set to the CLTV block #).

Also why are the OP_0 and OP_PUSHDATA1 necessary (is this to do with the P2SH that was the output being used from the previous tx?).

Hi Ian, I only know that it is the way P2SH is redeemed, as here http://www.soroushjp.com/2014/12/20/bitcoin-multisig-the-hard-way-understanding-raw-multisignature-bitcoin-transactions/ , the writer decomposed the P2SH and explained those opcodes you mentioned above.

OP_0 is included only to deal with an off-by-one error in Bitcoin Core when using OP_CHECKMULTISIG.

But I am not sure if we must include the OP_0 in P2SH without multisig.

For OP_PUSHDATA1, I was trying to construct a redeem tx for P2SH without the mentioned opcode, and it did not succeed.

[CIYAM]

OP_0 is included only to deal with an off-by-one error in Bitcoin Core when using OP_CHECKMULTISIG.

But I am not sure if we must include the OP_0 in P2SH without multisig.

I see - in that case I would be pretty sure that we don't need the OP_0 at all - in fact looking here: https://webbtc.com/script/2bb5d0ac0eb17f5ebe2d660ec47b4888943b4a4f5433c09bd6514b7a36859a95:0 it would appear to me at having OP_0 on the stack is actually causing it to always skip the OP_IF test (another thing that will need to be carefully checked).

For OP_PUSHDATA1, I was trying to construct a redeem tx for P2SH without the mentioned opcode, and it did not succeed.

Doh! Of course - the reason is that you need to push 114 bytes (the P2SH script) onto the stack but a normal PUSH_DATA (which just the length without a specific op code) can only push up to 75 bytes (will edit my earlier post to make this clear).

So apart from setting the "sequence" back to ffffffff I am still skeptical of the way that the CLTV "block number" has been provided (as it is neither in hex nor in he same endian as nLockTime itself is).

I guess a few test txs (which would be best initially done on testnet) to verify the exact format should be played with.

[CIYAM]

Actually looking further into OP_IF I think we have a problem as what is between it and OP_ELSE won't be executed if what is on the top of the stack is empty (which OP_0 would certainly screw up). You can see it illustrated here: https://webbtc.com/script/2bb5d0ac0eb17f5ebe2d660ec47b4888943b4a4f5433c09bd6514b7a36859a95:0 (scroll down to the Execution Trace and you'll see it isn't even executing the OP_SHA256 or first public key signature check).

I think that the check for the "secret hash" should actually take place before the OP_IF like this:

Code:

OP_SHA256
c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f268646
OP_EQUAL
OP_IF
OP_DROP (to drop the secret which I am guessing is still on the stack)
03d7c6052544bc42eb2bc0d27c884016adb933f15576a1a2d21cd4dd0f2de0c37d
OP_CHECKSIG
OP_ELSE
389900
OP_NOP2
OP_DROP (drops the block number just used for the NOP2/CLTV test)
021844989a2bd7acd127dd7ed51aa2f4d55b32dbb414de6325ae37e05c1067598d
OP_CHECKSIG
OP_ENDIF

Thus assuming that the "secret hash" is matched we then check the signature for the first public key otherwise we do the CLTV test and check the signature for the second public key.

I am not 100% sure of the stack behaviour so it might be necessary to do either an OP_DUP or have an extra OP_DROP to get that correct.

[sonicskye]

I think that the check for the "secret hash" should actually take place before the OP_IF like this:

Code:

OP_SHA256
c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f268646
OP_EQUAL[color=red]VERIFY[/color]
OP_IF
OP_DROP (to drop the secret which I am guessing is still on the stack)
03d7c6052544bc42eb2bc0d27c884016adb933f15576a1a2d21cd4dd0f2de0c37d
OP_CHECKSIG
OP_ELSE
389900
OP_NOP2
OP_DROP (drops the block number just used for the NOP2/CLTV test)
021844989a2bd7acd127dd7ed51aa2f4d55b32dbb414de6325ae37e05c1067598d
OP_CHECKSIG
OP_ENDIF

Thus assuming that the "secret hash" is matched we then check the signature for the first public key otherwise we do the CLTV test and check the signature for the second public key.

I am not 100% sure of the stack behaviour so it might be necessary to do either an OP_DUP or have an extra OP_DROP to get that correct.

That case above you probably need to replace the EQUAL with EQUALVERIFY to eliminate "1" value as the result of EQUAL operation. And your script may probably be translated as "between 2 parties, whoever can provide a secret value which matches a certain hash value can redeem the tx". Is that what you want?


I think there is no right or wrong when it comes to the script. It really depends on what you want to achieve with the script. For example, I quoted this from BIP065

The PayPub protocol makes it possible to pay for information in a trustless way by first proving that an encrypted file contains the desired data, and secondly crafting scriptPubKeys used for payment such that spending them reveals the encryption keys to the data. However the existing implementation has a significant flaw: the publisher can delay the release of the keys indefinitely.

This problem can be solved interactively with the refund transaction technique; with CHECKLOCKTIMEVERIFY the problem can be non-interactively solved using scriptPubKeys of the following form:

    IF
        HASH160 <Hash160(encryption key)> EQUALVERIFY
        <publisher pubkey> CHECKSIG
    ELSE
        <expiry time> CHECKLOCKTIMEVERIFY DROP
        <buyer pubkey> CHECKSIG
    ENDIF

Actually looking further into OP_IF I think we have a problem as what is between it and OP_ELSE won't be executed if what is on the top of the stack is empty (which OP_0 would certainly screw up). You can see it illustrated here: https://webbtc.com/script/2bb5d0ac0eb17f5ebe2d660ec47b4888943b4a4f5433c09bd6514b7a36859a95:0 (scroll down to the Execution Trace and you'll see it isn't even executing the OP_SHA256 or first public key signature check).

Yes, when I read the explanation from the link you provided, OP_0 skips the first block in OP_IF. But I think that's what we want from the sample case above.

[CIYAM]

Yes, when I read the explanation from the link you provided, OP_0 skips the first block in OP_IF. But I think that's what we want from the sample case above.

If we always skip the OP_IF block (in the script as originally shown) then you can never redeem with the "secret" - I guess you could perhaps change OP_0 to OP_1 but from what I understand once it has entered OP_IF then it will never execute the OP_ELSE branch (so if you did that then you'd never be able to redeem as a refund).

Thus OP_IF and OP_ELSE do not work perhaps as might have been expected. You have to have done a test before the OP_IF (whatever happens inside it is not considered as being "the condition").

Unfortunately it appears that the examples that are illustrated for BIP65 do not show correctly how to use OP_IF (perhaps they were not intended to be read as literal tx scripts at all but just as pseudo code which of course is reasonable).

So with the script in my previous post I am pretty sure that you could not just provide the secret because the OP_IF steps would be executed if the secret hash was matched (which then results in the signature check for the first public key and the skipping of the OP_ELSE steps).

From what I gathered OP_IF will remove the item from the stack but I think that is only in the case of it matching (if that is not the case then the refund redeem tx would have to include a dummy extra push).

If the secret hash check fails (which would be the case of course when you don't provide the secret hash which is what the refund tx would do as it would just push the signature onto the stack) then the OP_ELSE steps are executed which would verify the signature against the second public key (after doing the CLTV lock).

It think some careful testing of exactly how this conditional stuff works will be needed - for that I would recommend using "testnet".

Stack based languages like Bitcoin's Script are really not very intuitive to even most programmers.

[sonicskye]

Yes, when I read the explanation from the link you provided, OP_0 skips the first block in OP_IF. But I think that's what we want from the sample case above.

If we always skip the OP_IF block then you can never redeem with the "secret" - I guess you could perhaps change OP_0 to OP_1 but from what I understand once it has entered OP_IF then it will never execute the OP_ELSE branch (so if you did that then you'd never be able to redeem as the refund).

Thus OP_IF and OP_ELSE do not work perhaps as might have been expected. You have to have done a test before the OP_IF (not just inside it).

Unfortunately it appears that the examples that are illustrated for BIP65 do not show correctly how to use OP_IF (perhaps they were not intended to be read as literal tx scripts at all but just as pseudo code which of course is reasonable).

I think the if..else script in Bitcoin does not work in the same manner as the regular programming language. cmiiw.

So with the script in my previous post I am pretty sure that you could not just provide the secret because the OP_IF steps would be executed if the secret hash was matched (which then results in the signature check for the first public key and the skipping of the OP_ELSE steps).

From what I gather OP_IF will remove the item from the stack but I think that is only in the case of it matching (if that is not the case then the refund would either have to include a dummy extra push or an OP_DUP would need to be used at the start of the script along with an extra OP_DROP in the OP_IF steps).

If the secret hash check fails (which would be the case of course when you don't provide the secret hash which is what the refund tx would do as it would just push the signature onto the stack) then the OP_ELSE steps are executed which would verify the signature against the second public key (after doing the CLTV lock).

Yes, because the sample said that there are 2 possible conditions to redeem the tx; either "publisher" or "buyer" can redeem the tx with different condition as expressed in the if..else script.

    IF
        HASH160 <Hash160(encryption key)> EQUALVERIFY
        <publisher pubkey> CHECKSIG
    ELSE
        <expiry time> CHECKLOCKTIMEVERIFY DROP
        <buyer pubkey> CHECKSIG
    ENDIF

From the script above, the publisher can redeem the tx if he/she can provide the encryption key and his/her signature. While the buyer can redeem after <expiry time> with his/her signature.

It think some careful testing of exactly how this conditional stuff works will be needed - for that I would recommend using "testnet".

I tried testnet, and it was harder to push the tx than the mainnet.

[CIYAM]

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).

[sonicskye]

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.

[CIYAM]

Yup - by using OP_1 instead of OP_0 it will now always execute the OP_IF steps (and never the OP_ELSE steps) so I think the way I outlined it is the proper way it should be done (to allow for either redeem case).

Presumably it will require the refund redeem tx to push a dummy value (say OP_1) so that the initial OP_SHA256 has something to work with - or perhaps you could instead do an OP_DUP before the initial test with then an extra OP_DROP in the OP_IF steps. Let me try and illustrate the latter.

For the "secret reveal":

Code:

OP                STACK (top is the left)
--                ----------------------
PUSH <sig>        <sig>
PUSH <secret>     <secret><sig>
(start of P2SH script)
OP_DUP            <secret><secret><sig>
OP_SHA256         <shash><secret><sig>
PUSH <chash>      <chash><shash><secret><sig>
OP_EQUAL          1<secret><sig>
OP_IF             <secret><sig>
OP_DROP           <sig>
PUSH <pkey1>      <pkey1><sig>
OP_CHECKSIG       0 or 1
OP_ENDIF          0 or 1

For the "CLTV refund":

Code:

OP                STACK (top is the left)
--                ----------------------
PUSH <sig>        <sig>
(start of P2SH script)
OP_DUP            <sig><sig>
OP_SHA256         <shash><sig>
PUSH <chash>      <chash><shash><sig>
OP_EQUAL          0<sig>
OP_IF             <sig>
OP_ELSE           <sig>
PUSH <cltv>       <cltv><sig>
OP_NOP2           <sig>
OP_DROP           <sig>
PUSH <pkey2>      <pkey2><sig>
OP_CHECKSIG       0 or 1
OP_ENDIF          0 or 1

Admittedly I have not played around with Bitcoin Script enough to be certain how the stack will behave after each op but I think that should be at least close to correct.

[sonicskye]

Yup - by using OP_1 instead of OP_0 it will now always execute the OP_IF steps (and never the OP_ELSE steps) so I think the way I outlined it is the proper way it should be done (to allow for either redeem case).

Presumably it will require the refund redeem tx to push a dummy value (say OP_1) so that the initial OP_SHA256 has something to work with - or perhaps you could instead do an OP_DUP before the initial test with then an extra OP_DROP in the OP_IF steps. Let me try and illustrate the latter.

For the "secret reveal":

Code:

OP                STACK (top is the left)
--                ----------------------
PUSH <sig>        <sig>
PUSH <secret>     <secret><sig>
(start of P2SH script)
OP_DUP            <secret><secret><sig>
OP_SHA256         <shash><secret><sig>
PUSH <chash>      <chash><shash><secret><sig>
OP_EQUAL          1<secret><sig>
OP_IF             <secret><sig>
OP_DROP           <sig>
PUSH <pkey1>      <pkey1><sig>
OP_CHECKSIG       0 or 1
OP_ENDIF          0 or 1

For the "CLTV refund":

Code:

OP                STACK (top is the left)
--                ----------------------
PUSH <sig>        <sig>
(start of P2SH script)
OP_DUP            <sig><sig>
OP_SHA256         <shash><sig>
PUSH <chash>      <chash><shash><sig>
OP_EQUAL          0<sig>
OP_IF             <sig>
OP_ELSE           <sig>
PUSH <cltv>       <cltv><sig>
OP_NOP2           <sig>
OP_DROP           <sig>
PUSH <pkey2>      <pkey2><sig>
OP_CHECKSIG       0 or 1
OP_ENDIF          0 or 1

Admittedly I have not played around with Bitcoin Script enough to be certain how the stack will behave after each op but I think that should be at least close to correct.

Hi, I created a pair of tx by using your logic https://webbtc.com/script/bd1659576624d937af204f90e153a6be4900650eb8e73d0ca260811435771ed8:0
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.