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?
-
1Where do you see "non-standard input" ?– amaclinJun 15, 2016 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– reivenJun 16, 2016 at 0:26
-
Finally the transaction was confirmed on block blockchain.info/block-index/1114778 Thanks for you answers/comments!– reivenJun 16, 2016 at 0:29
Add a comment
|
2 Answers
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.
-
OP_CHECKMULTISIG pops one item too much from the stack, requiring the scriptSig to contain an extra push. Jun 15, 2016 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.– JestinJun 15, 2016 at 19:32
there are 4 possible reasons for the bad-txns-nonstandard-inputs error:
- the previous transaction's output script fails a Solver() check.
- the redeem script you made for that output script fails an EvalScript() check.
- the stack is empty after the previous EvalScript() run.
- the
subscript.GetSigOpCount(true) > MAX_P2SH_SIGOPStest 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.
