How to redeem Non-standard script Tx (testnet instance)

Question

Th testnet TxID 8d897ca91774a7fafa086a3275e679248d6bffee015d3b2efefd5dab00df152d has the following scriptPubKey:

scriptPubKey: "OP_DUP OP_HASH160 5f1426c2ce4a8e1abaa9dbe819b6303eb8a25a26 OP_EQUALVERIFY OP_CHECKSIGVERIFY OP_IF OP_DUP OP_HASH160 6c7ceafe76c56843c9d2868f616fdc9370355eb9 OP_EQUALVERIFY OP_CHECKSIG OP_ELSE OP_HASH256 644d79d87e0907833e888e272e5d7b925deb261a8499a65cbc0bf26797a15e8e OP_EQUAL OP_ENDIF"

Looking at the script of the redeeming Tx (TxID: 2d0daa01da8294a54178f8111eb2a02010c425fd15957d8baee8717edcfbe105) we see:

7e 10 3ceb50edd0282cd99dc59351f513dcdf 00 der sig

So I can see essentially that because sha256(sha256(3ceb50edd0282cd99dc59351f513dcdf)) = 644d79d87e0907833e888e272e5d7b925deb261a8499a65cbc0bf26797a15e8e the script is validated as True.

I'm attempting to understand how this is working but am consistently getting an error code 26 (OP_EQUALVERIFY failure) for this attempt at sendrawtransaction:

01000000013261e80001cbcc53101036792dcc8edc6802940b81a06e6e38f34765a4a5e4e5000000008b483045022100fe3890cfe091789b8300e563bbad402421a8dc07096ba04bcaaa4dd3537e7ce302204a1d7d1d33b6101599385f74164d95fdd8c00f62062a339e6d4907334b17df5f0141042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9ffffffff0220402c00000000001976a914dd6cce9f255a8cc17bda8ba0373df8e861cb866e88ac20402c00000000005876a914e900510876cb689f1db6fa982376c301362b740c88ad6376a914dd6cce9f255a8cc17bda8ba0373df8e861cb866e88ac67aa20644d79d87e0907833e888e272e5d7b925deb261a8499a65cbc0bf26797a15e8e876800000000

Where exactly is this problem occurring?

Also, in general, if one needs to push data onto the stack before the der signature, how is it done? Is the data added to the scriptSig field then signed, or signed, then added to the scriptSig? (I'm having trouble visualising the stack even with this interactive scenario at webbtc)

Answer 1

The first redeeming transaction has a scriptSig in the form:

<value to be double hashed> 0 <signature> <public key>

That 7e is a red herring - it's the size of the scriptSig. Similarly, the 10 is the size of the data to be hashed.

The second transaction appears to be attempting to spend a standard output. It appears to be trying to spend this using a key that doesn't hash to the right value.

You can see this by pasting the following script into Bitcoin Script IDE:

042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9 OP_DUP OP_HASH160 e900510876cb689f1db6fa982376c301362b740c OP_EQUALVERIFY OP_CHECKSIG