txout script criteria (scriptpubkey critieria)

what is the criteria for a txout script to be accepted into a mined block? is there any criteria at all? the reason i ask is that OP_RETURN is regularly used in txout scripts yet it is not spendable:

case OP_RETURN:
{
    return set_error(serror, SCRIPT_ERR_OP_RETURN);
}

and i have also seen transactions which push elements to the stack which are more than MAX_SCRIPT_ELEMENT_SIZE bytes.

i'm guessing that a syntactically incorrect script such as:

05aa
(ie OP_PUSHDATA(5) <aa>)

would not be permitted?

could someone point me to the code which miners use to validate whether a tx will be included or discarded as invalid (due to its txout scripts). i'm guessing it lies in main.cpp, but i would like to know where exactly, thanks.

obviously anybody can mine a block that is set up any way they like, but presumably there are fixed rules for whether it is considered valid or not - so other miners will know whether to use its hash as their prev-header-hash when mining the next block?

mulllhausen

Posted 2015-06-16T05:34:23.567

Reputation: 1 533

Answers

transaction ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767 from the live blockchain contains a lot of syntactically incorrect txout scripts and is useful as a demonstration:

using pybitcointools:

#!/usr/bin/env python2.7                                                        

from bitcoin import *
tx_hex = fetchtx("ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767")
tx_dict = deserialize(tx_hex)
for (txout_num, txout) in enumerate(tx_dict["outs"]):
    script = txout["script"]
    print "raw txout %d script: %s" % (txout_num, script)

output:

raw txout 0 script: 01
raw txout 1 script: 0201
raw txout 2 script: 4c
raw txout 3 script: 4c0201
raw txout 4 script: 4d
raw txout 5 script: 4dffff01
raw txout 6 script: 4e
raw txout 7 script: 4effffffff01

analysing each of these txout scripts:

01 = OP_PUSHDATA0(1)

this fails because it claims it will push 1 byte onto the stack, but then provides no bytes to push onto the stack

0201 = OP_PUSHDATA0(2) <01>

this fails because it claims it will push 2 bytes onto the stack, but then only provides 1 byte to push onto the stack

4c = OP_PUSHDATA1(?)

this fails because it is an incomplete OP_PUSHDATA1 opcode. the 4c byte should be followed by another byte specifying the number of data bytes to push onto the stack, however it is not.

4c0201 = OP_PUSHDATA1(2) <01>

this fails because it claims it will push 2 bytes onto the stack, but then only provides 1 byte to push onto the stack.

etc

its funny that the output scripts in this particular transaction each have a different syntactically incorrect use of the OP_PUSHDATA commands. its almost as if someone had the same question as this and wanted to test if any syntax checking was implemented on scriptpubkeys. i'm glad they did this because its a very conclusive way to demonstrate that absolutely no syntax checking (and therefore no other checks either) are performed on scriptpubkeys before they are spent.

mulllhausen

Posted 2015-06-16T05:34:23.567

Reputation: 1 533

You'll find a lot of scripts like this on testnet3, and a smaller number on the main network. Many of them are attempting (and actually manage in some cases) to break reimplementations using obscure and undocumented behaviors. – Anonymous – 2015-06-18T06:52:19.880

yep! it broke my re-implementation - that's the reason i'm asking :) but i don't see a whole lot of value for validating testnet blocks - people can put anything in there and there is not much hashpower to even guarantee valid blocks.

– mulllhausen – 2015-06-18T08:22:37.687

1You're never going to download a block with invalid contents, because the block would just simply be invalid. The amount of proof of work for this is almost entirely orthogonal. You really shouldn't be reimplementing script, history has shown (bitcoinjs, bitcoin-ruby, btcd) that nobody has the capability to clone the behavior directly, no matter how many millions of dollars are poured into the effort. Unless this is for fun or experience, link to libconsensus and avoid losing piles of money. It's not foolproof, but it means you won't have avoidable mistakes in script execution. – Anonymous – 2015-06-18T08:43:31.730

thanks for the warning but for me its purely educational. you never really know something until you can build it yourself from scratch. – mulllhausen – 2015-06-18T12:09:09.330

i didn't know about libconsensus - that looks really useful! – mulllhausen – 2015-06-18T12:21:40.363

For a learning experience go right ahead reimplementing. Somewhat unexpectedly, that's how some consensus bugs have been found in the past. The warning was mostly born of people reimplementing and then running million dollar companies on top of it without really acknowledging the risk. – Anonymous – 2015-06-18T18:23:25.180

cool. yeah that's another reason for my re-implementation. so far i have always been late to the party - discovering "bugs" well after they have been fixed by bips

– mulllhausen – 2015-06-20T01:44:53.580

Absolutely no consensus validity checks are done on a scriptPubKey. Nodes have soft requirements called IsStandard for what they will relay to their peers as a transaction (a completely junk script or very large OP_RETURN output for example will not pass) but these are not consensus rules. Some miners will mine non-standard transactions into their blocks, but generally to get a transaction to them a transport other than the P2P network needs to be used.

OP_RETURN is a special case refereed to as "provably un-spendable", this is a response to people jamming hashes and other data into PubKeyHash outputs as a way of pegging them in time to the block chain. Due to there being no way of knowing if the output is actually valid or not these outputs must be stored forever in the UTXO pool. An OP_RETURN prefixed output can absolutely never be spent, so nodes can safely forget that they ever existed.

Anonymous

Posted 2015-06-16T05:34:23.567

Reputation: 10 054

thanks for the reply! but surely if someone builds a block with a syntactically incorrect txout script then no other miners will build on top of it? i'm looking for that criteria - ie for building on top of an already mined block – mulllhausen – 2015-06-16T11:05:56.187

i have added a last paragraph to the op explaining a bit better... – mulllhausen – 2015-06-16T11:08:27.703

The output script is never verified in Bitcoin, you can make something that is complete junk (OP_CAT OP_CAT OP_CAT) and that is valid in a block. If there is no way to satisfy the script and spend it again, then the value of the BTC there is simply stuck there forever. This transaction output is similar to your example, it pushes junk onto the stack for no reason. http://webbtc.com/tx/09ca982b6ab313cd7552b9a28e1dabdd37cab5e6ed05bb241579902c5f1e8989 Bonus points if you can work out what it is pushing onto the stack.

– Anonymous – 2015-06-16T11:11:35.030

hmm interesting. i'm guessing it is still syntactically correct though? eg 05aa would fail? if not then it might be possible to use txout scripts for buffer overflow attacks on users... – mulllhausen – 2015-06-16T11:16:24.790

i know they cant be used in EvalScript() - that's not my question. – mulllhausen – 2015-06-16T11:23:16.280

No checks at all, not even on the size of data pushes. It's an array of bytes. – Anonymous – 2015-06-17T06:06:11.533

cool. apparently this transaction does exactly that. i need to have a look at the raw hex but once i have confirmed this i will add it into your answer and mark it as the solution. feel free to get there before me :)

– mulllhausen – 2015-06-17T08:08:36.350

i created a new answer, since the results turned out to be more interesting than i thought! – mulllhausen – 2015-06-18T03:01:38.777