What im doing wrong? Sinse I found out that Bitcoin is programmable money Im trying to use it potential. Using this site https://improvein.github.io/bitcoin-forge/?#/script/create I’ve created a conditional script that holds 2 time locks for two pub keys.

OP_IF 1694275749 OP_CHECKLOCKTIMEVERIFY OP_DROP 03cd18ace3a339fcd0039fd87d7a7a8377537cd9a9f2afa2a3e76f40e53112a535 OP_CHECKSIG OP_ELSE 1694277749 OP_CHECKLOCKTIMEVERIFY OP_DROP 036bb176ed8fe2e38949a63ff964eed3c5e79fd88ac011cad1eecf22702ea65d23 OP_CHECKSIG OP_ENDIF

Script 63051694275749b1752103cd18ace3a339fcd0039fd87d7a7a8377537cd9a9f2afa2a3e76f40e53112a535ac67051694277749b17521036bb176ed8fe2e38949a63ff964eed3c5e79fd88ac011cad1eecf22702ea65d23ac68

Used this script to create with this tool https://improvein.github.io/bitcoin-forge/?#/address/create Payment to Witness Script Hash address bc1qes2v6ts5ckxuz5mkwdeukcn62hkac05kf97gugc4jnu3kj3wg5as3nes34

Now I’m using bitcoin core cli to sign the input and create raw transaction. And I’m completely stack at this point. How and what to sign and how to put this puzzle for unlocking transaction.

The scope of this script is to give to family member some funds locked in future with ability to be spend it with one of 2 privet keys. If he loose his key, I can spend it with op_else condition. I will provide some data

gettxout 14290ef656c05f8e0c06b6d99a6ae72c77a8809b3a69dd5fb00f07ce9cee1637  vout 133

  "bestblock": "0000000000000000000528fb0e92c1e79378a1b241eb144ca0f97054fdf42dfb",
  "confirmations": 155,
  "value": 0.00007726,
  "scriptPubKey": {
    "asm": "0 cc14cd2e14c58dc153767373cb627a55eddc3e96497c8e231594f91b4a2e453b",
    "desc": "addr(bc1qes2v6ts5ckxuz5mkwdeukcn62hkac05kf97gugc4jnu3kj3wg5as3nes34)#k8s5es0p",
    "hex": "0020cc14cd2e14c58dc153767373cb627a55eddc3e96497c8e231594f91b4a2e453b",
    "address": "bc1qes2v6ts5ckxuz5mkwdeukcn62hkac05kf97gugc4jnu3kj3wg5as3nes34",
    "type": "witness_v0_scripthash"
  "coinbase": false

the locking script

  "asm": "1692429480 OP_CHECKLOCKTIMEVERIFY OP_DROP OP_IF 03cd18ace3a339fcd0039fd87d7a7a8377537cd9a9f2afa2a3e76f40e53112a535 OP_CHECKSIG OP_ELSE 1692602280 OP_CHECKLOCKTIMEVERIFY OP_DROP 036bb176ed8fe2e38949a63ff964eed3c5e79fd88ac011cad1eecf22702ea65d23 OP_CHECKSIG OP_ENDIF",
  "desc": "raw(04a86ce064b175632103cd18ace3a339fcd0039fd87d7a7a8377537cd9a9f2afa2a3e76f40e53112a535ac6704a80fe364b17521036bb176ed8fe2e38949a63ff964eed3c5e79fd88ac011cad1eecf22702ea65d23ac68)#r3dcxvh2",
  "type": "nonstandard",
  "p2sh": "38cTqVJf1jPBDCjg8wKdFx476uHX3qgEaB",
  "segwit": {
    "asm": "0 69672524bb7737429280e9c862b3fdcea0dc22037cbaaa755d6132b4841811e4",
    "desc": "wsh(raw(04a86ce064b175632103cd18ace3a339fcd0039fd87d7a7a8377537cd9a9f2afa2a3e76f40e53112a535ac6704a80fe364b17521036bb176ed8fe2e38949a63ff964eed3c5e79fd88ac011cad1eecf22702ea65d23ac68))#7uzehfsr",
    "hex": "002069672524bb7737429280e9c862b3fdcea0dc22037cbaaa755d6132b4841811e4",
    "address": "bc1qd9nj2f9mwum59y5qa8yx9vlae6sdcgsr0ja25a2avyetfpqcz8jqg69shh",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "3NqDPiKTsbYA18GRWzrsE5wYYxGhH9XS96"

and 2nd question

how segwit time locked script will work considering The "Year 2038 problem" when issue arises because a 32-bit signed integer can represent a maximum value of 2,147,483,647 seconds, which is approximately 68 years. The Unix epoch started on January 1, 1970, so adding 68 years to this date brings us to January 19, 2038. so question is : funds time locked after January 19, 2038 will be spendable same way like today?

1 Answer 1


Regarding 1st question,

I guess your locktime 1694275749 is unix timestamp not little-endian byte(hex). Your script must encode number in little-endian byte(which is a598fc64), not timestamp decimal itself. If you already sent with 1694275749 locktime, it would be interpreted as little-endian byte(hex number), not as decimal, so unspendable as far as I know.

Regarding 2nd question,

BIP65 describes how to handle 2038 problem, which simply allows to accept 5 bytes number exceptionally for utc locktime when it's used with OP_CHECKLOCKTIMEVERIFY.

In BIP65,

If we kept to that limit we'd have a year 2038 problem, even though the nLockTime field in transactions themselves is uint32 which only becomes meaningless after the year 2106. Thus as a special case we tell CScriptNum to accept up to 5-byte bignums, which are good until 2**32-1, the same limit as the nLockTime field itself.

Therefore, OP_CHECKLOCKTIMEVERIFY locktime upper bound for timestamp is same with uint32 nLockTime.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.