5

http://blockexplorer.com/block/000000000000051b42fd09195c75da7a084df7593f47ad18139cdc9cd83a112e

The last three tx have a inputs with script_sig "1". This is invalid right?

According to protocol rules https://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messages it seems like the block (even if mined) should have been rejected by peers.

16.1.4: "Verify crypto signatures for each input; reject if any are bad"

What am I missing? Thanks!

Improve this question
7

The script page of the bitcoin wiki tells us that:

  • A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero)

To validate a transaction's input, first the input's scriptSig is run, then the scriptPubKey of the output it's trying to spend is run.

The transactions in question have a scriptSig of '1' and the outputs they're spending have a scriptPubKey of OP_DUP OP_DUP OP_DUP. Running these will cause a '1' to be put onto the stack, and then for the '1' to be copied three times, ending up with a stack of: [1, 1, 1, 1]. The top stack item is non-zero, so it's fine.

To address your question about crypto signatures, while it's true that any OP_CHECKSIG in either script has to pass there was none in these scripts, so none of them were bad.

The current version of the client rejects "non standard" scriptPubKey scripts in the individual transactions that it receives from the network, and refuses to pass them on, but doesn't appear to do the same for transactions in already-mined blocks that it receives. So this block was likely mined by the person who made this transaction, using custom software.

Anybody seeing those outputs could have immediately claimed them. Note however that these easily-redeemed outputs were created and redeemed in the same block, leaving no risk of someone else redeeming them.

Improve this answer
4
  • 1
    Non-standard scripts aren't rejected. The default client just doesn't mine or relay them. Whoever mined this block modified his client. Probably he created this strange transaction, too: both the "OP_DUP..." transactions and the "1" transactions that spend them are in this one block. – theymos Mar 15 '12 at 5:55
  • Thanks Chris! This makes sense now since the outputs were non standard as well (no OP_CHECKSIG) it makes sense why it passed. I appreciate the help! – Brian Armstrong Mar 15 '12 at 8:09
  • I don't think inputs are checked for being 'standard' like outputs are. If the input script makes the output script work, then it's fine, just so long as (1) it's not longer than 500 bytes and (2) it only contains "push" operations (OP_0 through OP_16). – Chris Moore Mar 15 '12 at 9:00
  • Before BIP16, an input was standard if its script only contained pushes. With BIP16, another rule is added: an input can only be standard if it spends a standard output. – Pieter Wuille Mar 16 '12 at 0:22

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.