1

A few hours ago I've sent a transaction which is not being added to a block, and on blockchain.info it flagged as "non-standard input".

I've used pybitcointools to create the TX.

What is wrong with the TX?

  • 1
    Where do you see "non-standard input" ? – amaclin Jun 15 '16 at 13:30
  • @amaclin there was an exclamation/warning mark in the screen, i was about to take a screenshot but the transaction was finally confirmed – reiven Jun 16 '16 at 0:26
  • Finally the transaction was confirmed on block blockchain.info/block-index/1114778 Thanks for you answers/comments! – reiven Jun 16 '16 at 0:29
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 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, 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.

| improve this answer | |
  • OP_CHECKMULTISIG pops one item too much from the stack, requiring the scriptSig to contain an extra push. – Pieter Wuille Jun 15 '16 at 19:28
  • 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 Jun 15 '16 at 19:32
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.

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

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.