Nevermind, I found the answer. Yes, they are activated!
Topic: Double check my relative locktime script (Read 1122 times)
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!
Nevermind, I found the answer. Yes, they are activated!
How do these scripts look?
much better.try to use them on testnet.
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-endianso, 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
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-endianso, the second byte in your redeem script will be 03 or 04, but not greater than 05
...which I believe translates into the redeem script hex of:
634e...
63 = OP_IF, correct634e...
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, correct634d...
4D = OP_PUSHDATA2 - WTF??
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.
...which I believe translates into the redeem script hex of:
634e...
63 = OP_IF, correct634e...
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, correct634d...
4D = OP_PUSHDATA2 - WTF??
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.
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:
My understanding of the RLT BIP is that 2 weeks would translate to 0x40093a. So the script I came up with is:
which I believe translates into the redeem script hex of:
for the address 3B6X5FyVdm3qS8J2CNbX2n8M2JyzXhQw8L.
Alternatively, I changed the relative locktime to be 2016 blocks instead of two weeks, for a redeem script of:
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:
or alternatively
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?
The keys are:
Code:
020dd847d245216d27fad46c99ea490b8b9dbae87e144fc1f0c9427b041e4acf90
0346cbb9b74d786560a7e69a1013ddb6af6931d939f9dbba8311aab55de4fb772f
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
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?
Jump to: