<p>there are 4 possible reasons for the <code>bad-txns-nonstandard-inputs</code> error:</p>

<ol>
<li>the previous transaction's output script fails a Solver() check.</li>
<li>the redeem script you made for that output script fails an EvalScript() check.</li>
<li>the stack is empty after the previous EvalScript() run.</li>
<li>the <code>subscript.GetSigOpCount(true) &gt; MAX_P2SH_SIGOPS</code> test fails.</li>
</ol>

<p>you can find the checks in <code>src/policy/policy.cpp</code>, and make it log more verbosely the reasons by applying <a href="https://pastebin.com/CGg3mREX" rel="nofollow noreferrer">this patch</a>.</p>

<p>I discovered this while attempting to <a href="https://pastebin.com/zx1sh9jD" rel="nofollow noreferrer">harvest about .6 BTC</a> from the 182 transactions whose script actually, when compiled, spells "script". here is a <a href="https://pastebin.com/x5Unpseq" rel="nofollow noreferrer">sample</a>. I suspect this was a programming error on the part of the miner: a USD6000+ error which he now very likely regrets.</p>

CC BY-SA 3.0
2018-01-27T22:29:54.383Z
2018-01-27T22:29:54.383Z
jcomeau_ictx
<p>I believe it is non-standard because you include an OP code in your input script, specifically, <code>OP_FALSE</code>.  It should not be necessary to include OP codes in input scripts; only literals.  The only way input scripts (scriptSig's) intereact with the output scripts they are spending (scriptPubKey's) is by placing values on the stack.  Therefore, there is never any need to run an operation, since you could simply place the values on the stack.</p>

<p>From the <a href="https://en.bitcoin.it/wiki/Script" rel="nofollow">docs</a> for <code>OP_FALSE</code>:</p>

<blockquote>
  <p>An empty array of bytes is pushed onto the stack. (This is not a
  no-op: an item is added to the stack.)</p>
</blockquote>

<p>Becasue there is an operation and not just a literals in your script, it is non-standard.</p>

<p>That said, I'm not sure how to write an input script that places an empty array of bytes on the stack without using <code>OP_FALSE</code>.  I don't know why such a thing would be necessary for redeeming an output.</p>

<p>EDIT:  I just realized that you are using a standard Multisig input script (which I forgot is an exception to the "no op codes in input scripts" rule) to redeem a standard P2SH output script.  Technically, your redeem script is standard, because it matches one of the <a href="https://bitcoin.org/en/developer-guide#standard-transactions" rel="nofollow">standard transactions</a>, but it doesn't match the output script it is spending.  Your redeem script should probably be in the form of <code>&lt;sig&gt; [sig] [sig...] &lt;redeemScript&gt;</code> if it is going to spend an output script that looks like <code>OP_HASH160 &lt;Hash160(redeemScript)&gt; OP_EQUAL</code>.</p>

CC BY-SA 3.0
2016-06-15T19:28:16.917Z
OP_CHECKMULTISIG pops one item too much from the stack, requiring the scriptSig to contain an extra push.
Pieter Wuille
CC BY-SA 3.0
2016-06-15T19:32:12.647Z
Yeah, I just read about that.  Feels like a weird quirk, but I understand how we're stuck with it.  Good thing P2SH is making that issue less relevant.
Jestin
CC BY-SA 3.0
2016-06-15T14:40:35.377Z
2016-06-15T15:17:24.360Z
2016-06-15T15:17:24.360Z
Jestin
<p>A few hours ago I've sent a transaction which is not being added to a block, and on <a href="https://blockchain.info/tx/d1eb7de1d356e3c7defb8dcdb7afd48572b4113b100410489135c26bfb7c0816" rel="nofollow">blockchain.info</a> it flagged as "non-standard input".</p>

<p>I've used <a href="https://github.com/vbuterin/pybitcointools" rel="nofollow">pybitcointools</a> to create the TX.</p>

<p>What is wrong with the TX?</p>

CC BY-SA 3.0
2016-06-15T13:30:02.337Z
Where do you see "non-standard input" ?
amaclin
CC BY-SA 3.0
2016-06-16T00:26:33.160Z
@amaclin there was an exclamation/warning mark in the screen, i was about to take a screenshot but the transaction was finally confirmed
reiven
CC BY-SA 3.0
2016-06-16T00:29:05.770Z
Finally the transaction was confirmed on block https://blockchain.info/block-index/1114778 Thanks for you answers/comments!
reiven
<transactions><unconfirmed-transactions><non-standard-transaction>
Transaction flagged as having a non-standard input
reiven
# Transaction flagged as having a non-standard input

(Asked by: username_0 on 2016-06-14)

A few hours ago I've sent a transaction which is not being added to a block, and on [blockchain.info](https://blockchain.info/tx/d1eb7de1d356e3c7defb8dcdb7afd48572b4113b100410489135c26bfb7c0816) it flagged as "non-standard input".

I've used [pybitcointools](https://github.com/vbuterin/pybitcointools) to create the TX.

What is wrong with the TX?

**Tags:** transactions, unconfirmed-transactions, non-standard-transaction

> **Comments:**
> **username_1**: Where do you see "non-standard input" ?  
> **username_0**: @username_1 there was an exclamation/warning mark in the screen, i was about to take a screenshot but the transaction was finally confirmed  
> **username_0**: Finally the transaction was confirmed on block https://blockchain.info/block-index/1114778 Thanks for you answers/comments!  

---

## 2 answers

### Answer by username_2 on 2018-01-27. Score: 1

there are 4 possible reasons for the `bad-txns-nonstandard-inputs` error:

1. the previous transaction's output script fails a Solver() check.
2. the redeem script you made for that output script fails an EvalScript() check.
3. the stack is empty after the previous EvalScript() run.
4. the `subscript.GetSigOpCount(true) > MAX_P2SH_SIGOPS` test fails.

you can find the checks in `src/policy/policy.cpp`, and make it log more verbosely the reasons by applying [this patch](https://pastebin.com/CGg3mREX).

I discovered this while attempting to [harvest about .6 BTC](https://pastebin.com/zx1sh9jD) from the 182 transactions whose script actually, when compiled, spells "script". here is a [sample](https://pastebin.com/x5Unpseq). I suspect this was a programming error on the part of the miner: a USD6000+ error which he now very likely regrets.


---

### Answer by username_3 on 2016-06-15. Score: 1

I believe it is non-standard because you include an OP code in your input script, specifically, `OP_FALSE`. It should not be necessary to include OP codes in input scripts; only literals. The only way input scripts (scriptSig's) intereact with the output scripts they are spending (scriptPubKey's) is by placing values on the stack. Therefore, there is never any need to run an operation, since you could simply place the values on the stack.

From the [docs](https://en.bitcoin.it/wiki/Script) for `OP_FALSE`:

> An empty array of bytes is pushed onto the stack. (This is not a
> no-op: an item is added to the stack.)

Becasue there is an operation and not just a literals in your script, it is non-standard.

That said, I'm not sure how to write an input script that places an empty array of bytes on the stack without using `OP_FALSE`. I don't know why such a thing would be necessary for redeeming an output.

EDIT: I just realized that you are using a standard Multisig input script (which I forgot is an exception to the "no op codes in input scripts" rule) to redeem a standard P2SH output script. Technically, your redeem script is standard, because it matches one of the [standard transactions](https://bitcoin.org/en/developer-guide#standard-transactions), but it doesn't match the output script it is spending. Your redeem script should probably be in the form of `<sig> [sig] [sig...] <redeemScript>` if it is going to spend an output script that looks like `OP_HASH160 <Hash160(redeemScript)> OP_EQUAL`.

> **Comments:**
> **username_4**: OP_CHECKMULTISIG pops one item too much from the stack, requiring the scriptSig to contain an extra push.  
> **username_3**: Yeah, I just read about that.  Feels like a weird quirk, but I understand how we're stuck with it.  Good thing P2SH is making that issue less relevant.  

---

