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.
Show Posts
