Is there a maximum size of a scriptSig/scriptPubKey?

8

Previous research:

Are there any consensus rules that prohibit scripts from being too large? I know each individual element of a script has to be less than 520 bytes, as shown here, but a script could still have many many individual elements and create an extremely large block.

For example, a malicious miner wants to make the blockchain as big as possible and creates a coinbase transaction with a particular output that has the OP_RETURN opcode followed by enough data to make their block just less than the 1 MB limit. Will the malicious miner's block, in which 99% of the block data is encoded into a dummy OP_RETURN output, be accepted or rejected?

morsecoder

Posted 2015-02-03T21:10:01.350

Reputation: 12 624

stack elements of a txout script need not be less than 520 bytes - there are examples in the live blockchain of stack elements larger than this. however i think that the MAX_SCRIPT_ELEMENT_SIZE criteria you mention will prevent this txout from ever being spent

mulllhausen 2015-06-16T04:36:44.947

Answers

8

David A. Harding

Posted 2015-02-03T21:10:01.350

Reputation: 10 154

It was right under my nose :)morsecoder 2015-02-03T21:52:06.987

2

There are no checks specifically on OP_RETURN. There is a standardness rule, which is that they must embed up to 40 bytes of data. Of course, if you're mining your own blocks, you can ignore standardness rules.

There is a rule against scripts more than 10 kilobytes long, but since there's no limit on the number of outputs you can create, that's not a meaningful restriction.

However, this isn't a very good way to attack the network. It costs roughly $1000 of electricity to make a block. (You recoup some of that from the Bitcoins you get, of course.) It would take 104 years for 10000 nodes storing your block to cost more than mining it costed you in the first place.

Nick ODell

Posted 2015-02-03T21:10:01.350

Reputation: 26 536

1The null data standard tx type is "up to 40 bytes" instead of "less than 40 bytes".David A. Harding 2015-02-03T23:21:49.707