<p>The <a href="http://test.webbtc.com/tx/2d0daa01da8294a54178f8111eb2a02010c425fd15957d8baee8717edcfbe105.json" rel="nofollow">first redeeming transaction</a> has a scriptSig in the form:</p>

<pre><code>&lt;value to be double hashed&gt; 0 &lt;signature&gt; &lt;public key&gt;
</code></pre>

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

<p>The second transaction appears to be attempting to spend <a href="http://blockexplorer.com/testnet/tx/e5e4a5a46547f3386e6ea0810b940268dc8ecc2d7936101053cccb0100e86132" rel="nofollow">a standard output</a>. It appears to be trying to spend this using a key that doesn't hash to the right value.</p>

<p>You can see this by pasting the following script into <a href="http://www.cs.princeton.edu/~tongbinw/bitcoinIDE/build/editor.html" rel="nofollow">Bitcoin Script IDE</a>:</p>

<pre><code>042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9 OP_DUP OP_HASH160 e900510876cb689f1db6fa982376c301362b740c OP_EQUALVERIFY OP_CHECKSIG
</code></pre>

CC BY-SA 3.0
2015-03-18T11:36:34.633Z
re: Bitcoin Script IDE: I have been looking for something like this EVERYWHERE.
Wizard Of Ozzie
CC BY-SA 3.0
2015-03-23T07:07:52.057Z
Is the virtual asm fully tested? I'm getting inconsistent OP_HASH160 values than expected
Wizard Of Ozzie
CC BY-SA 3.0
2015-03-23T08:25:05.347Z
@WizardOfOzzie Hmm, odd. I'm getting the same issue on known-good values from network transactions. It might be a bug with this IDE. Lemme check with python-bitcoinlib.
Nick ODell
CC BY-SA 3.0
2015-03-18T10:39:28.187Z
2015-03-18T10:39:28.187Z
Nick ODell
<p>Th testnet <a href="http://test.webbtc.com/tx/8d897ca91774a7fafa086a3275e679248d6bffee015d3b2efefd5dab00df152d.json" rel="nofollow">TxID 8d897ca91774a7fafa086a3275e679248d6bffee015d3b2efefd5dab00df152d</a> has the following <strong>scriptPubKey</strong>:</p>

<blockquote>
  <p>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"</p>
</blockquote>

<p><a href="http://test.webbtc.com/script/2d0daa01da8294a54178f8111eb2a02010c425fd15957d8baee8717edcfbe105:0" rel="nofollow">Looking at the script</a> of the redeeming Tx (<a href="http://test.webbtc.com/tx/2d0daa01da8294a54178f8111eb2a02010c425fd15957d8baee8717edcfbe105.json" rel="nofollow">TxID: 2d0daa01da8294a54178f8111eb2a02010c425fd15957d8baee8717edcfbe105</a>) we see:</p>

<p><code>7e</code> <code>10</code> <code>3ceb50edd0282cd99dc59351f513dcdf</code> <code>00</code> <code>der sig</code></p>

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

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

<pre><code>01000000013261e80001cbcc53101036792dcc8edc6802940b81a06e6e38f34765a4a5e4e5000000008b483045022100fe3890cfe091789b8300e563bbad402421a8dc07096ba04bcaaa4dd3537e7ce302204a1d7d1d33b6101599385f74164d95fdd8c00f62062a339e6d4907334b17df5f0141042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9ffffffff0220402c00000000001976a914dd6cce9f255a8cc17bda8ba0373df8e861cb866e88ac20402c00000000005876a914e900510876cb689f1db6fa982376c301362b740c88ad6376a914dd6cce9f255a8cc17bda8ba0373df8e861cb866e88ac67aa20644d79d87e0907833e888e272e5d7b925deb261a8499a65cbc0bf26797a15e8e876800000000
</code></pre>

<p>Where exactly is this problem occurring?</p>

<p>Also, <em>in general</em>, if one needs to push data onto the stack <em>before the der signature</em>, 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 <a href="http://test.webbtc.com/script/2d0daa01da8294a54178f8111eb2a02010c425fd15957d8baee8717edcfbe105:0" rel="nofollow">this interactive scenario at webbtc</a>)</p>

<raw-transaction>
How to redeem Non-standard script Tx (testnet instance)
Wizard Of Ozzie
# How to redeem Non-standard script Tx (testnet instance)

(Asked by: username_0 on 2015-03-18)

Th testnet [TxID 8d897ca91774a7fafa086a3275e679248d6bffee015d3b2efefd5dab00df152d](http://test.webbtc.com/tx/8d897ca91774a7fafa086a3275e679248d6bffee015d3b2efefd5dab00df152d.json) 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](http://test.webbtc.com/script/2d0daa01da8294a54178f8111eb2a02010c425fd15957d8baee8717edcfbe105:0) of the redeeming Tx ([TxID: 2d0daa01da8294a54178f8111eb2a02010c425fd15957d8baee8717edcfbe105](http://test.webbtc.com/tx/2d0daa01da8294a54178f8111eb2a02010c425fd15957d8baee8717edcfbe105.json)) 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](http://test.webbtc.com/script/2d0daa01da8294a54178f8111eb2a02010c425fd15957d8baee8717edcfbe105:0))

**Tags:** raw-transaction


---

## 1 answers

### Answer by username_1 on 2015-03-18. Score: 1

The [first redeeming transaction](http://test.webbtc.com/tx/2d0daa01da8294a54178f8111eb2a02010c425fd15957d8baee8717edcfbe105.json) 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](http://blockexplorer.com/testnet/tx/e5e4a5a46547f3386e6ea0810b940268dc8ecc2d7936101053cccb0100e86132). 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](http://www.cs.princeton.edu/~tongbinw/bitcoinIDE/build/editor.html):

```
042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9 OP_DUP OP_HASH160 e900510876cb689f1db6fa982376c301362b740c OP_EQUALVERIFY OP_CHECKSIG

```

> **Comments:**
> **username_0**: re: Bitcoin Script IDE: I have been looking for something like this EVERYWHERE.  
> **username_0**: Is the virtual asm fully tested? I'm getting inconsistent OP_HASH160 values than expected  
> **username_1**: @username_0 Hmm, odd. I'm getting the same issue on known-good values from network transactions. It might be a bug with this IDE. Lemme check with python-bitcoinlib.  

---

