<blockquote>
  <p>What use is a transaction that is never relayed?</p>
</blockquote>

<p>None, unless it is generated by the same person who mines it into a block. But it is not the case that non-standard transactions are never relayed. There are nodes that relay non-standard transactions and miners who include them.</p>

<blockquote>
  <p>How did the transaction make it into a block in the first place if it cannot be relayed? Did this transaction come directly from a client? Was it created at an origin node and put in a block somehow by that node?</p>
</blockquote>

<p>Nobody said it "cannot be relayed", merely that this particular piece of software does not, by default, relay it.</p>

<blockquote>
  <p>What does it mean that the script is "accepted" if it's "in a block"? (I'm aware of the script evaluation process, but the sense of the word "accepted" here doesn't seem to be the same as the standard "evaluate to true" verification process.)</p>
</blockquote>

<p>It means that the client cannot reject it or otherwise ignore it. If it gets into a block, it's officially done and its outputs are spendable if the transaction script rules say si.</p>

<blockquote>
  <p>Perhaps most importantly: What good is all this wonderful scripting capability if interesting transactions are not relayed? Won't this cripple the scripting capability for more complex transaction types?</p>
</blockquote>

<p>That's a good question.</p>

CC BY-SA 3.0
2014-11-21T06:06:54.307Z
+1. I really don't understand why we even have this whole IsStandard funny business then. Why are non-standard transactions not propagated in the core client implementation? Who would it hurt by propagating them?
morsecoder
CC BY-SA 3.0
2014-11-21T06:08:58.337Z
Is it because the bitcoin core devs are worried there might be some way to manipulate the stack so that UTXOs are spent when they shouldn't have been allowed to? I feel like that is already done by making sure the `scriptSig` only pushes data, though...
morsecoder
CC BY-SA 3.0
2013-12-13T02:44:55.100Z
2013-12-13T02:44:55.100Z
David Schwartz
<p>The following statement appears on the "Script" page in the <a href="https://en.bitcoin.it/wiki/Script" rel="nofollow">wiki</a>: </p>

<blockquote>
  <p>Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.</p>
</blockquote>

<p>This begs a lot of questions:</p>

<ul>
<li>What use is a transaction that is never relayed?</li>
<li>How did the transaction make it into a block in the first place if it cannot be relayed? Did this transaction come directly from a client? Was it created at an origin node and put in a block somehow by that node?</li>
<li>What does it mean that the script is "accepted" if it's "in a block"? (I'm aware of the script evaluation process, but the sense of the word "accepted" here doesn't seem to be the same as the standard "evaluate to true" verification process.)</li>
<li>Perhaps most importantly: What good is all this wonderful scripting capability if interesting transactions are not relayed? Won't this cripple the scripting capability for more complex transaction types?</li>
</ul>

<protocol><academic-research><non-standard-transaction>
Not relaying non-standard transactions
Will Nelson
# Not relaying non-standard transactions

(Asked by: username_0 on 2013-12-13)

The following statement appears on the "Script" page in the [wiki](https://en.bitcoin.it/wiki/Script):

> Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes username_0 not relay them.

This begs a lot of questions:

* What use is a transaction that is never relayed?
* How did the transaction make it into a block in the first place if it cannot be relayed? Did this transaction come directly from a client? Was it created at an origin node and put in a block somehow by that node?
* What does it mean that the script is "accepted" if it's "in a block"? (I'm aware of the script evaluation process, but the sense of the word "accepted" here doesn't seem to be the same as the standard "evaluate to true" verification process.)
* Perhaps most importantly: What good is all this wonderful scripting capability if interesting transactions are not relayed? Won't this cripple the scripting capability for more complex transaction types?

**Tags:** protocol, academic-research, non-standard-transaction


---

## 1 answers

### Answer by username_1 on 2013-12-13. Score: 5

> What use is a transaction that is never relayed?

None, unless it is generated by the same person who mines it into a block. But it is not the case that non-standard transactions are never relayed. There are nodes that relay non-standard transactions and miners who include them.

> How did the transaction make it into a block in the first place if it cannot be relayed? Did this transaction come directly from a client? Was it created at an origin node and put in a block somehow by that node?

Nobody said it "cannot be relayed", merely that this particular piece of software does not, by default, relay it.

> What does it mean that the script is "accepted" if it's "in a block"? (I'm aware of the script evaluation process, but the sense of the word "accepted" here doesn't seem to be the same as the standard "evaluate to true" verification process.)

It means that the client cannot reject it or otherwise ignore it. If it gets into a block, it's officially done and its outputs are spendable if the transaction script rules say si.

> Perhaps most importantly: What good is all this wonderful scripting capability if interesting transactions are not relayed? Won't this cripple the scripting capability for more complex transaction types?

That's a good question.

> **Comments:**
> **username_2**: +1. I really don't understand why we even have this whole IsStandard funny business then. Why are non-standard transactions not propagated in the core client implementation? Who would it hurt by propagating them?  
> **username_2**: Is it because the bitcoin core devs are worried there might be some way to manipulate the stack so that UTXOs are spent when they shouldn't have been allowed to? I feel like that is already done by making sure the `scriptSig` only pushes data, though...  

---

