<p>Due to the nature of of how redeem scripts are used, there is never any reason for a redeem script to contain anything more than simple constant values.  When an output is redeemed, the redeem script is pre-pended to the encumbrance script, and run as a single script.  Consider a transaction output that is encumbered by a script that says (in pseudo code):</p>

<p><code>+ 3 == 5</code></p>

<p>This output could be redeemed by by any script that leaves a <code>2</code> on the stack after executing.  That means it could be redeemed by scripts like <code>3 - 1</code> or <code>8 / 4</code>.  However, there is no reason for the additional calculation.  Since  a redeem script only need to leave <code>2</code> on the stack, we can simply use a script that just puts <code>2</code> on the stack.</p>

<p>This means that any redeem script that performs calculations rather than just placing constants on the stack serves no purpose, and was probably broadcast as an attempt at a denial of service.  These scripts can be disallowed without having any negative effect on the utility of the Bitcoin network.</p>

<p>By contrast, limiting the variability of encumbrance scripts limits what the Bitcoin network can be used for.  This is a topic that has been hotly debated, but in general, the community does not wish to limit Bitcoin's usefulness for future applications.</p>

CC BY-SA 3.0
2016-04-11T21:21:43.337Z
What about a redeem script that wants to do something like check lock time verify, they aren't just pushing data on the stack and are still considered valid?
Ronald Smith
CC BY-SA 3.0
2016-04-11T21:47:57.177Z
Let's make sure we have our terms right.  When I say "encumbrance script", I'm referring to `scriptPubKey` (https://bitcoin.org/en/glossary/pubkey-script), which is the part of a transaction output that locks coins on the blockchain.  When I say "redeem script", I'm referring to `scriptSig` (https://bitcoin.org/en/glossary/signature-script), which is part of a transaction input.  OP_CHECKLOCKTIMEVERIFY only needs to be used on `scriptPubKey`, even though the conditions set by it will be evaluated at the time of redemption.
Jestin
CC BY-SA 3.0
2016-04-12T01:37:01.257Z
However if OP_CHECKLOCKTIMEVERIFY is used in scriptPubKey, the transaction will be non-standard. But if using p2sh it can be moved to the scriptSig, and then be marked as standard
Ronald Smith
CC BY-SA 3.0
2016-04-11T14:06:51.093Z
2016-04-11T14:06:51.093Z
Jestin
<p>As I understand it, only transactions with pubkey scripts conforming to a certain pattern are considered "standard" and are relayed, however a script is also considered standard regardless of its redeem script.</p>

<p>If the limitation on standard transactions is to prevent abuse, wouldn't using it as a redeem script be equally bad?</p>

<transactions><relay>
Why are all redeem scripts standard, but only a few pubkey scripts?
Ronald Smith
# Why are all redeem scripts standard, but only a few pubkey scripts?

(Asked by: username_0 on 2016-04-10)

As I understand it, only transactions with pubkey scripts conforming to a certain pattern are considered "standard" and are relayed, however a script is also considered standard regardless of its redeem script.

If the limitation on standard transactions is to prevent abuse, wouldn't using it as a redeem script be equally bad?

**Tags:** transactions, relay


---

## 1 answers

### Answer by username_1 on 2016-04-11. Score: 2

Due to the nature of of how redeem scripts are used, there is never any reason for a redeem script to contain anything more than simple constant values. When an output is redeemed, the redeem script is pre-pended to the encumbrance script, and run as a single script. Consider a transaction output that is encumbered by a script that says (in pseudo code):

`+ 3 == 5`

This output could be redeemed by by any script that leaves a `2` on the stack after executing. That means it could be redeemed by scripts like `3 - 1` or `8 / 4`. However, there is no reason for the additional calculation. Since a redeem script only need to leave `2` on the stack, we can simply use a script that just puts `2` on the stack.

This means that any redeem script that performs calculations rather than just placing constants on the stack serves no purpose, and was probably broadcast as an attempt at a denial of service. These scripts can be disallowed without having any negative effect on the utility of the Bitcoin network.

By contrast, limiting the variability of encumbrance scripts limits what the Bitcoin network can be used for. This is a topic that has been hotly debated, but in general, the community does not wish to limit Bitcoin's usefulness for future applications.

> **Comments:**
> **username_0**: What about a redeem script that wants to do something like check lock time verify, they aren't just pushing data on the stack and are still considered valid?  
> **username_1**: Let's make sure we have our terms right.  When I say "encumbrance script", I'm referring to `scriptPubKey` (https://bitcoin.org/en/glossary/pubkey-script), which is the part of a transaction output that locks coins on the blockchain.  When I say "redeem script", I'm referring to `scriptSig` (https://bitcoin.org/en/glossary/signature-script), which is part of a transaction input.  OP_CHECKLOCKTIMEVERIFY only needs to be used on `scriptPubKey`, even though the conditions set by it will be evaluated at the time of redemption.  
> **username_0**: However if OP_CHECKLOCKTIMEVERIFY is used in scriptPubKey, the transaction will be non-standard. But if using p2sh it can be moved to the scriptSig, and then be marked as standard  

---

