Double check my relative locktime script

[luv2drnkbr]

I just want to make sure I am writing the script correctly, and was hoping somebody could point out my errors or let me know it's correct.  I have 2 keys, and I want to require both keys' signatures or wait 2 weeks after inclusion in a block and require 1 signature.

The keys are:

Code:

020dd847d245216d27fad46c99ea490b8b9dbae87e144fc1f0c9427b041e4acf90
0346cbb9b74d786560a7e69a1013ddb6af6931d939f9dbba8311aab55de4fb772f

My understanding of the RLT BIP is that 2 weeks would translate to 0x40093a.  So the script I came up with is:

Code:

OP_IF
    0x40093a OP_CHECKSEQUENCEVERIFY OP_DROP
    1
OP_ELSE
    2
OP_ENDIF
020dd847d245216d27fad46c99ea490b8b9dbae87e144fc1f0c9427b041e4acf90
0346cbb9b74d786560a7e69a1013ddb6af6931d939f9dbba8311aab55de4fb772f
2
OP_CHECKMULTISIG

which I believe translates into the redeem script hex of:

Code:

634e3a094000b2755167526821020dd847d245216d27fad46c99ea490b8b9dbae87e144fc1f0c9427b041e4acf90210346cbb9b74d786560a7e69a1013ddb6af6931d939f9dbba8311aab55de4fb772f52ae

for the address 3B6X5FyVdm3qS8J2CNbX2n8M2JyzXhQw8L.

Alternatively, I changed the relative locktime to be 2016 blocks instead of two weeks, for a redeem script of:

Code:

634de007b2755167526821020dd847d245216d27fad46c99ea490b8b9dbae87e144fc1f0c9427b041e4acf90210346cbb9b74d786560a7e69a1013ddb6af6931d939f9dbba8311aab55de4fb772f52ae

and the address 3DDPMrpPeL81WEb4u8cVgRAGZyGanVCVVp.

Are those redeem scripts correct?  And to spend from them, I would need to set the sequence of the input to match what's in the redeem script (but filled to all 4 bytes in the case of the 2016 block example).. is that correct?  And the scriptsig would look like this:

Code:

0 sig 1

or alternatively

Code:

0 sig1 sig2 0

Do I have everything correct?

Please don't send money for me to test.  (Not that anybody was going to.)  Those keys are NOT the actual keys involved!  I made them up for the purposes of posting here.

Thanks for the help!

Edit: Random thought... Could I remove the OP_DROP and the 1 from the OP_IF and use the OP_TRUE stack item produced by OP_CHECKSEQUENCEVERIFY as the OP_1 for the multisig m-keys-required?

[achow101]

I can't verify your script since I am not sure on the behavior of OP_IF. However, there are some things that I can point out.

My understanding of the RLT BIP is that 2 weeks would translate to 0x40093a.  So the script I came up with is:

No. It has to be in Little Endian, so swap the bytes. It should be 0x3a0940.

Edit: Random thought... Could I remove the OP_DROP and the 1 from the OP_IF and use the OP_TRUE stack item produced by OP_CHECKSEQUENCEVERIFY as the OP_1 for the multisig m-keys-required?

No you cannot remove them. OP_CSV does not return an OP_TRUE, it acts as either a OP_NOP or it terminates the script execution with an error. If it passes, then nothing happens and it needs to be removed from the stack with OP_DROP. If it fails, then the transaction fails and is rejected.

Edit: Figured it out. Besides for the endianness, it all looks good.

[amaclin]

...which I believe translates into the redeem script hex of:
634e...

63 = OP_IF, correct
4E = OP_PUSHDATA4 - WTF??

Alternatively, I changed the relative locktime to be 2016 blocks instead of two weeks, for a redeem script of:
634d...

63 = OP_IF, correct
4D = OP_PUSHDATA2 - WTF??

[luv2drnkbr]

...which I believe translates into the redeem script hex of:
634e...

63 = OP_IF, correct
4E = OP_PUSHDATA4 - WTF??

Alternatively, I changed the relative locktime to be 2016 blocks instead of two weeks, for a redeem script of:
634d...

63 = OP_IF, correct
4D = OP_PUSHDATA2 - WTF??

Yeah, how else am I pushing the sequence number I want to compare for OP_CHECKSEQUENCEVERIFY?  Is it a varint?  The BIP is confusing and there's no easy to read developer documentation.  That's why I'm posting here asking for help.

I'm assuming by your reaction that it's supposed to be a varint..??

Edit:  Wait, no, that's not how var_int's are used.  They are only ever used to denote the length of scripts.  So how exactly am I supposed to push the number preceding OP_CHECKSEQUENCEVERIFY??

Edit 2:  Nevermind, I'm an idiot.  See posts below.

No. It has to be in Little Endian, so swap the bytes. It should be 0x3a0940.

Right.  I didn't write it in the script example, but I did do that in the redeem script.  Thanks for looking out though.

No you cannot remove them. OP_CSV does not return an OP_TRUE, it acts as either a OP_NOP or it terminates the script execution with an error. If it passes, then nothing happens and it needs to be removed from the stack with OP_DROP. If it fails, then the transaction fails and is rejected.

Yes, you're absolutely right.  That was just a brain fart on my end.  Thanks again.

[amaclin]

Yeah, how else am I pushing the sequence number I want to compare for OP_CHECKSEQUENCEVERIFY?

int32 should be pushed as an array of 3 or 4 bytes (or even 5?) in lo-endian
so, the second byte in your redeem script will be 03 or 04, but not greater than 05

[luv2drnkbr]

Yeah, how else am I pushing the sequence number I want to compare for OP_CHECKSEQUENCEVERIFY?

int32 should be pushed as an array of 3 or 4 bytes (or even 5?) in lo-endian
so, the second byte in your redeem script will be 03 or 04, but not greater than 05

Yeah I just realized the fuckup and was coming to edit my post.  Pushdata bytes are the number of bytes to push, not the data itself.  I know that.  That was just another brain fart.

How do these scripts look?

Code:

63033a0940b2755167526821020dd847d245216d27fad46c99ea490b8b9dbae87e144fc1f0c9427b041e4acf90210346cbb9b74d786560a7e69a1013ddb6af6931d939f9dbba8311aab55de4fb772f52ae

Code:

6302e007b2755167526821020dd847d245216d27fad46c99ea490b8b9dbae87e144fc1f0c9427b041e4acf90210346cbb9b74d786560a7e69a1013ddb6af6931d939f9dbba8311aab55de4fb772f52ae

[amaclin]

How do these scripts look?

much better.
try to use them on testnet.

[luv2drnkbr]

Awesome.  Thank you.

Assuming it works correctly, do you know if BIPs 68, 112, and 113 been activated for mainnet yet?  I haven't been keeping up with news the past month or so, and can't seem to find the answer on google.

Nevermind, I found the answer.  Yes, they are activated!