|
Title: Is this BIP65 sample script standard? Post by: CIYAM on December 23, 2015, 02:44:38 AM From the BIP section Trustless Payments for Publishing Data the following script appears:
Code: IF 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? Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 23, 2015, 12:34:31 PM 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.) :( Title: Re: Is this BIP65 sample script standard? Post by: cr1776 on December 23, 2015, 01:07:45 PM 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) Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 23, 2015, 01:15:26 PM 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). Title: Re: Is this BIP65 sample script standard? Post by: var53 on December 23, 2015, 04:18:51 PM 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. http://s23.postimg.org/4s1ciyurv/full_blocks2.jpg 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. Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 26, 2015, 07:39:19 AM 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 :) Title: Re: Is this BIP65 sample script standard? Post by: amaclin on December 26, 2015, 08:16:13 AM Assuming it is standard then if HASH160 was to be changed to say SHA256 would it still be standard? https://gist.github.com/gavinandresen/88be40c141bc67acb247Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 26, 2015, 08:32:49 AM Assuming it is standard then if HASH160 was to be changed to say SHA256 would it still be standard? https://gist.github.com/gavinandresen/88be40c141bc67acb247Yup - 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. Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 26, 2015, 11:42:44 AM 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) 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)? Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 26, 2015, 03:58:42 PM 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. Title: Re: Is this BIP65 sample script standard? Post by: sonicskye on December 27, 2015, 03:49:48 AM 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) 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. Quote 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. Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 27, 2015, 06:53:52 AM Quote 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. Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 27, 2015, 07:52:50 AM 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 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. Title: Re: Is this BIP65 sample script standard? Post by: sonicskye on December 27, 2015, 09:17:05 AM I think that the check for the "secret hash" should actually take place before the OP_IF like this: Code: OP_SHA256 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. 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 Quote 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. Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 27, 2015, 09:23:27 AM 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. :( Title: Re: Is this BIP65 sample script standard? Post by: sonicskye on December 27, 2015, 09:44:09 AM 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. Quote 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.Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 27, 2015, 09:45:59 AM 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). Title: Re: Is this BIP65 sample script standard? Post by: sonicskye on December 27, 2015, 10:41:20 AM 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. Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 27, 2015, 11:18:15 AM 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) For the "CLTV refund": Code: OP STACK (top is the left) 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. Title: Re: Is this BIP65 sample script standard? Post by: sonicskye on December 27, 2015, 01:52:25 PM 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) For the "CLTV refund": Code: OP STACK (top is the left) 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 Quote OP_DUP OP_SHA256 <HASH> OP_EQUAL I have not yet tried redeeming by using the else block, as I think it may work as well.OP_IF OP_DROP <PUBKEY 2> OP_CHECKSIG OP_ELSE <CLTV> OP_NOP2 OP_DROP <PUBKEY 1> OP_CHECKSIG OP_ENDIF 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. Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 27, 2015, 01:58:01 PM The script construction is as follows Quote OP_DUP OP_SHA256 <HASH> OP_EQUAL I have not yet tried redeeming by using the else block, as I think it may work as well.OP_IF OP_DROP <PUBKEY 2> OP_CHECKSIG OP_ELSE <CLTV> OP_NOP2 OP_DROP <PUBKEY 1> OP_CHECKSIG OP_ENDIF 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! :) Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 29, 2015, 10:26:34 AM I think we have basically nutted it out (https://webbtc.com/script/7fec1a377344333496cca3d67b06d418f199702cf4a9f5fcb8fbb38c5de963ca:0) where the P2SH script is as follows:
Code: OP_DUP 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. Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 29, 2015, 12:43:02 PM The one thing that is bothering me (taken from the BIP) is the following:
Code: // Finally the nLockTime feature can be disabled and thus 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? Title: Re: Is this BIP65 sample script standard? Post by: jl777 on December 29, 2015, 05:06:35 PM The one thing that is bothering me (taken from the BIP) is the following: Code: // Finally the nLockTime feature can be disabled and thus 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 Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 29, 2015, 05:25:13 PM 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 Means that it only actually tests the one vin. Title: Re: Is this BIP65 sample script standard? Post by: achow101 on December 29, 2015, 05:36:54 PM 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 Means that it only actually tests the one vin. 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 Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 29, 2015, 05:44:03 PM 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). Title: Re: Is this BIP65 sample script standard? Post by: sniveling on December 29, 2015, 07:57:04 PM 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 Quote 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. Title: Re: Is this BIP65 sample script standard? Post by: fbueller on December 29, 2015, 08:21:30 PM 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. Title: Re: Is this BIP65 sample script standard? Post by: sniveling on December 29, 2015, 08:33:17 PM On the 14th of December Peter Todd tweeted that BIP65 OP_CHECKLOCKTIMEVERIFY can be used in production.
https://twitter.com/petertoddbtc/status/676453190443773954 Quote 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 Quote [–]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 Quote 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 Quote 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> Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 30, 2015, 03:16:38 AM After taking a closer look at the code I found this (scroll down to the bottom):
Code: bool TransactionSignatureChecker::CheckLockTime(const CScriptNum& nLockTime) const 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). Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 30, 2015, 04:27:43 PM 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 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). Title: Re: Is this BIP65 sample script standard? Post by: achow101 on December 30, 2015, 04:30:02 PM What software are yous using to make these transactions? Or are you writing the hex by hand?
Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 30, 2015, 04:33:17 PM 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. Title: Re: Is this BIP65 sample script standard? Post by: sonicskye on December 30, 2015, 08:23:54 PM 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 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? Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 31, 2015, 01:19:15 AM 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 Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 31, 2015, 09:17:37 AM 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: {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? Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 31, 2015, 09:35:13 AM Hmm... I have nearly got there (perhaps):
Code: 0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e8410000000085002103d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4043a6645983a479588ac68000000000140420f00000000001976a9148a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b88ac00000000 When I decode this I am seeing the following (which I think looks fine): Code: {But unfortunately if I try and sign it I get this output: Code: {Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 31, 2015, 10:33:01 AM 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? Title: Re: Is this BIP65 sample script standard? Post by: sniveling on December 31, 2015, 10:40:28 AM 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 Title: Re: Is this BIP65 sample script standard? Post by: sonicskye on December 31, 2015, 12:08:37 PM 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 Hi, many thanks for the clue. I managed to construct the following structure Quote OP_IF The structure probably is the first few steps of Gmaxwell's Coinswap. I am not sure whether this can be called as atomic. Basically the tx can be redemed by 3 different ways:OP_IF OP_DUP OP_SHA256 <HASH> OP_EQUAL OP_DROP OP_DUP OP_HASH160 <pubkeyhash2> OP_EQUALVERIFY OP_CHECKSIG OP_ELSE <cltv> OP_NOP2 OP_DROP OP_DUP OP_HASH160 <pubkeyhash1> OP_EQUALVERIFY OP_CHECKSIG OP_ENDIF OP_ELSE 2 <pubkey 1> <pubkey 2> 2 OP_CHECKMULTISIG OP_ENDIF - secret value + sig2 - sig1 + pubkey1 after certain CLTV - sig1 + sig2 (in 2-of-2 multisig) Title: Re: Is this BIP65 sample script standard? Post by: sonicskye on December 31, 2015, 12:11:27 PM 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. Last time I checked, it is still buggy. This one https://webbtc.com/script is one of the best so far, despite it does not work lately. Title: Re: Is this BIP65 sample script standard? Post by: sonicskye on December 31, 2015, 12:17:33 PM Hmm... I have nearly got there (perhaps): Code: 0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e8410000000085002103d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd7594c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4043a6645983a479588ac68000000000140420f00000000001976a9148a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b88ac00000000 When I decode this I am seeing the following (which I think looks fine): Code: {But unfortunately if I try and sign it I get this output: Code: {Are you trying to redeem the CLTV block? BX decodes the tx as follows. Quote transaction { hash b6ae7d90587b27adef7c36571cc1fdf4fbe04c77d2a3113a2239188285f581cf inputs { input { previous_output { hash 41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb index 0 } script "zero [ 03d30f361b0d5dacba61a56db0903fe32244b5616f950cac1081694e81148dd759 ] [ 76a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a 91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774 de8c88d0b7a4043a6645983a479588ac68 ]" sequence 0 } } lock_time 0 outputs { output { address mt9EHSSeERgWKNqYfdmkpa4Mjb4EXr4QY2 script "dup hash160 [ 8a7dd4d0e29f50f989dd2b97d463d706a7ef0c7b ] equalverify checksig" value 1000000 } } version 1 } I wonder why there is a zero there. Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 31, 2015, 12:36:23 PM Yes - I am trying to do the CLTV redeem (but without a sig it will never work of course).
I wonder why there is a zero there. That is where the sig should end up (except that it won't sign the tx for me). My understanding is that you can leave a zero as a place-marker in the raw tx to later replace with the signature (assuming it would agree to sign the tx for me which it won't). You can omit the zero with this version: Code: 0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e84100000000842102d1570ab314b7b32ffe76f31232805a727d05119958d14b0b8aff9df5709676884c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a91401d7295f243a3a6d26516b54e4e6f51278d376b588ac6703ac9a09b17576a914b6a7c89a6774de8c88d0b7a4043a6645983a479588ac68000000000140420f00000000001976a9145817f2d63208327c21da272a3bb037c3d9ec026988ac00000000 But without being able to sign the tx it doesn't really help me. So using that version if I try signrawtransaction I get the following output: Code: {I am going to try this with "-regtest" next (but that might have to wait until tomorrow). Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 31, 2015, 02:45:04 PM Shit - just realised I was running 0.11.1 not 0.11.2.
After downloading and re-running I now get this: Code: {I think if I fix up my nLockTime now then we might have a winner. Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 31, 2015, 02:57:58 PM Unfortunately no such luck:
Code: {using the version with the extra 00 at the start of the inputs produces this: Code: {Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on December 31, 2015, 03:02:50 PM I am guessing if I can work out the format that is suitable for signing (which will have that 00 and I think requires another 01000000 to be added at the end of the inputs from memory) then I can manually sign it and then try and send the tx.
Anyone can for sure tell me the hex input for signing? Title: Re: Is this BIP65 sample script standard? Post by: sonicskye on December 31, 2015, 09:23:54 PM I am guessing if I can work out the format that is suitable for signing (which will have that 00 and I think requires another 01000000 to be added at the end of the inputs from memory) then I can manually sign it and then try and send the tx. Anyone can for sure tell me the hex input for signing? I don't really understand the question. Do you mean you cannot produce a valid signature by using your tool? I checked the rawtx you created and indeed the problem is within the signature. webbtc verifies this as well. Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on January 01, 2016, 03:43:46 AM I don't really understand the question. Do you mean you cannot produce a valid signature by using your tool? I checked the rawtx you created and indeed the problem is within the signature. webbtc verifies this as well. I have written code that signs "standard P2PKH" transactions here: https://github.com/ciyam/ciyam/blob/master/src/crypto_keys.cpp#L805 and if you look closely you'll see c_empty_sig_script (which is "00") being placed where the sig later goes (why I was mucking around with the extra 00 above) and also this: Code: signing_info_suffix += c_hash_code_type_all; which appends "01000000" (only to what is signed rather than what is actually the raw tx). Basically to manually do a sig I'll need to apply the same approach to non-standard txs (nothing too hard - just some modifications really). I was actually hoping to just use bitcoin-cli rather than to have to write code though but it's beginning to look like signrawtransaction is not able to do what I am wanting it to. Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on January 01, 2016, 02:21:18 PM I think I basically have the correct raw tx but still Bitcoin won't allow me to send it.
Code: 0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e84100000000cc47304402204d5c2b9a9a5a9e467a77d87c0de310c1fa1be7 the decoded version of this: Code: {You can also debug it here: https://webbtc.com/script if you copy and paste this into the Input Script: Code: 3045022100922dd91ae97909ee6cfa19976e3d072d24521e0e3717d6c1634e190d43131922022064b992db3588651c717777d579c74787daf5d24b3b9651ea4cb38544ff50604501 and the following into the Output Script: Code: OP_HASH160 5817f2d63208327c21da272a3bb037c3d9ec0269 OP_EQUAL The error I'm getting when trying to send this raw transaction is as follows: Code: error: {"code":-26,"message":"16: mandatory-script-verify-flag-failed (Script evaluated without error but finished with a false/empty top stack element)"}Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on January 01, 2016, 02:39:14 PM Hmm... I wonder if the problem is the CLTV value itself:
Code: ["ac9a09"] What block number is that (am a bit tired and really starting to hate Satoshi for using little-endian)? Title: Re: Is this BIP65 sample script standard? Post by: achow101 on January 01, 2016, 04:24:27 PM Hmm... I wonder if the problem is the CLTV value itself: That looks like it is block number 629420.Code: ["ac9a09"] What block number is that (am a bit tired and really starting to hate Satoshi for using little-endian)? Title: Re: Is this BIP65 sample script standard? Post by: cr1776 on January 01, 2016, 04:26:13 PM Hmm... I wonder if the problem is the CLTV value itself: Code: ["ac9a09"] What block number is that (am a bit tired and really starting to hate Satoshi for using little-endian)? Looks like 629420 to me too. Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on January 01, 2016, 04:27:13 PM Looks like 629420 to me too. So if the block number isn't the issue then is the sig invalid? (current testnet3 block is 629899 and that raw tx's nLockTime is 629888) Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on January 01, 2016, 04:43:15 PM If I issue a signrawtransaction with (basically) the same tx I see this:
Code: {The question is whether the complete being false is due to an invalid sig or due to the script eval error. Title: Re: Is this BIP65 sample script standard? Post by: sonicskye on January 02, 2016, 05:47:28 AM If I issue a signrawtransaction with (basically) the same tx I see this: Code: {The question is whether the complete being false is due to an invalid sig or due to the script eval error. I crafted a tx pair similar to yours (same cltv block and same locktime) in testnet, I think it is correct but it won't be sent to the network. This is the rawtx Code: 0100000001de320e8cc248e7fe8fc7e57ec70b0d1bf3a44122f634bf443a2a8fceb39b63c001000000cc473044022026d86fa3239733e866bc4187e6a13813e7db68cb39aceb3837054f7340a1a62002200f5fd9f7c6a0a9d92b4233faac4bb9642584818da737dd51cae4951e01d7839501210260274c034ffc8dc6a2ceb1ff5f31031c593d7005bd286f03c9cadb1bc662961b4c6076a820c775e7b757ede630cd0aa1113bd102661ab38829ca52a6422ab782862f26864687637576a9149d8fe65f4bccb39d510c45ae3bcf9cf0a3a22b0e88ac6703ac9a09b17576a9147abb3052f7090c5379d2af382c84eeab0658488188ac68010000000180c3c901000000001976a9147abb3052f7090c5379d2af382c84eeab0658488188ac289c0900 I wonder if the CLTV is not deployed in testnet yet Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on January 02, 2016, 07:13:53 AM I wonder if the CLTV is not deployed in testnet yet It could well be that not enough of the testnet peers have upgraded - I think the next step is to play with -regtest rather than -testnet (so you are mining your own blocks). Title: Re: Is this BIP65 sample script standard? Post by: sonicskye on January 02, 2016, 07:36:24 AM I wonder if the CLTV is not deployed in testnet yet It could well be that not enough of the testnet peers have upgraded - I think the next step is to play with -regtest rather than -testnet (so you are mining your own blocks). That's why I quitted using testnet (and people do not stop asking me why I do the tests in mainnet). I emailed Josh Cincinnati from blockcypher.com and he said it would be better to run the test in our own testnet, or we can also use their testnet. https://medium.com/blockcypher-blog/testnet-is-not-for-testing-5afa78b1394 Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on January 02, 2016, 10:12:28 AM Well - I've tried doing this with regtest but unfortunately there seems to be a problem.
Raw tx is as follows: Code: 010000000194fb5e28b96182167b73934863fdc6cc23502f2574fdca8230b187fcc768171400000000cb4830450221008854a06bb9fd2fc81e9fe01666481e0fc297 and decoded: Code: {I can even issue a "signrawtransaction" and I get this: Code: {which all looks fine - but when I attempt to send it I get this: Code: error: {"code":-26,"message":"16: mandatory-script-verify-flag-failed (Non-canonical DER signature)"}:( Title: Re: Is this BIP65 sample script standard? Post by: sniveling on January 03, 2016, 05:02:15 AM I cut and pasted your transaction from here into the webbtc page for relaying transactions to testnet3. The page said there was an error because the transaction context was invalid, and rule "prev_out" failed to validate.
I think I basically have the correct raw tx but still Bitcoin won't allow me to send it. Code: 0100000001bbc6c76fd91bee5badfb0746204adba70efceb04f21a270de566827dbc34e84100000000cc47304402204d5c2b9a9a5a9e467a77d87c0de310c1fa1be7 This is the transaction relaying page link, and the error message. https://test.webbtc.com/relay_tx Quote Error: Transaction context invalid. Rule "prev_out" failed to validate: Prev out 41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb:0 not found. Although I searched webbtc for 41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb it couldn't find it. Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on January 03, 2016, 05:23:29 AM Strange as the tx 41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb can be found on other testnet3 block explorers.
I am starting to agree that "testnet" is actually not at all useful for testing. :( The trouble I'm having with "regtest" is the initial P2SH payment. I am sending to what I think should be a valid testnet/regtest P2SH address 2MyPZMFn1fbyo3udjFQwvutmMheV3t2S1GQ but the payment tx to it looks like this: Code: {So instead of this: OP_HASH160 <hash> OP_EQUAL it has done this: 02f0d1b577793c518bf5c3b94f6c0a14637b3d883da7e5f80c6511167e1825bdd1 OP_CHECKSIG WTF? Title: Re: Is this BIP65 sample script standard? Post by: sniveling on January 03, 2016, 05:48:49 AM I sometimes get this error message from webbtc when attempting to use its testnet3 script pages. It seemed to be the most reliable script tool available, but I don't trust it anymore. After you suggested trying alternatives I found 41e834bc7d8266e50d271af204ebfc0ea7db4a204607fbad5bee1bd96fc7c6bb on other testnet3 block explorers.
http://s7.postimg.org/67bz69spn/error.jpg Title: Re: Is this BIP65 sample script standard? Post by: amaclin on January 03, 2016, 08:02:17 AM I am starting to agree that "testnet" is actually not at all useful for testing. :( testnet on https://test.webbtc.com/ is not synchronized.the last block is 2015-11-10 07:21 Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on January 03, 2016, 08:48:54 AM Finally I got the regtest version to work!!
Code: {And this is the redeem tx (using CLTV): Code: {The P2SH redeem script is as follows: Code: OP_DUP The two address hashes were intentionally made the same to simplify testing - for practical usage they would be different (one for Alice and one for Bob). Title: Re: Is this BIP65 sample script standard? Post by: CIYAM on January 04, 2016, 08:23:55 AM The following tx uses the "secret reveal" method which doesn't use the CLTV op so it can be issued as soon as the P2SH address is funded (hence locktime is zero).
Code: { |
