<p>The <a href="https://en.bitcoin.it/wiki/Script">script page</a> of the <a href="https://en.bitcoin.it/wiki/Main_Page">bitcoin wiki</a> tells us that:</p>

<ul>
<li>A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero)</li>
</ul>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>Anybody seeing those outputs could have immediately claimed them.  Note however that these easily-redeemed outputs were created and redeemed in <a href="http://blockexplorer.com/b/168910">the same block</a>, leaving no risk of someone else redeeming them.</p>

CC BY-SA 3.0
2012-03-15T05:55:38.857Z
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
CC BY-SA 3.0
2012-03-15T08:09:44.137Z
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
CC BY-SA 3.0
2012-03-15T09:00:11.997Z
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
CC BY-SA 3.0
2012-03-16T00:22:09.227Z
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
CC BY-SA 3.0
2012-03-15T05:43:06.220Z
2012-03-15T06:02:55.180Z
2012-03-15T06:02:55.180Z
Chris Moore
<p><a href="http://blockexplorer.com/block/000000000000051b42fd09195c75da7a084df7593f47ad18139cdc9cd83a112e">http://blockexplorer.com/block/000000000000051b42fd09195c75da7a084df7593f47ad18139cdc9cd83a112e</a></p>

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

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

<blockquote>
  <p>16.1.4: "Verify crypto signatures for each input; reject if any are bad"</p>
</blockquote>

<p>What am I missing?  Thanks!</p>

<blockchain><script><signature>
How did these 3 tx make it into a block in the main chain?
Brian Armstrong
# How did these 3 tx make it into a block in the main chain?

(Asked by: username_0 on 2012-03-15)

<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!

**Tags:** blockchain, script, signature


---

## 1 answers

### Answer by username_1 on 2012-03-15. Score: 7 | Accepted answer

The [script page](https://en.bitcoin.it/wiki/Script) of the [bitcoin wiki](https://en.bitcoin.it/wiki/Main_Page) 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](http://blockexplorer.com/b/168910), leaving no risk of someone else redeeming them.

> **Comments:**
> **username_2**: 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.  
> **username_0**: Thanks username_1!  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!  
> **username_1**: 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).  
> **username_3**: 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.  

---

