<p>Your transaction, although not invalid, is non-standard. Since it is non-standard, it will not be propagated and will be rejected for being non-standard. However this does not mean that it cannot be included in a block; it can. It only requires that the miner and all of the nodes between you and that miner must be running some software that accepts and relays non-standard transactions. However not many nodes actually do, so you may have a hard time getting good propagation of your transaction.</p>

CC BY-SA 3.0
2017-06-23T20:32:56.000Z
Non-standard for a segwit node or a non-segwit node? If segwit nodes consider such a transaction non-standard, where is that stated in the documentation?
Rich Apodaca
CC BY-SA 3.0
2017-06-23T20:36:16.543Z
Segwit is constructed in such a way that *every* SegWit spend is non-standard to non-segwit nodes.
Pieter Wuille
CC BY-SA 3.0
2017-06-23T21:08:25.550Z
@PieterWuille, of course. But how would a segwit node that only understands V0 witness programs respond to my attack?
Rich Apodaca
CC BY-SA 3.0
2017-06-23T21:10:02.153Z
Future witness versions are non-standard by policy in Bitcoin Core for precisely the reason you point out. This is generic: all constructions that exist which are intended for future extensibility are treated as non-standard (for example, also the OP_NOPx opcodes).
Pieter Wuille
CC BY-SA 3.0
2017-06-23T21:14:10.563Z
@RichApodaca standardness for outputs is defined by this function here: https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L72. The solver function that is called will end up at this if block: https://github.com/bitcoin/bitcoin/blob/master/src/script/standard.cpp#L71. From that code, you can see that any non v0 witness output will return false in the solver which then causes IsStandard to return false too, indicating that non v0 witness outputs are non-standard. The same happens here for inputs https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L161
Ava Chow
CC BY-SA 3.0
2017-06-23T21:32:58.817Z
Thanks @PieterWuille. It looks like what I was missing is that all upgradeable behavior is marked as non-standard implicitly, so there's no need to document this in the SegWit BIPs.
Rich Apodaca
CC BY-SA 3.0
2017-06-23T19:52:57.127Z
2017-06-23T19:52:57.127Z
Ava Chow
<p>Let's say I want to encode the text of the King James version of the Bible into the block chain, one piece at a time (replace this with any zany idea to consume copious quantities of block space). OP_RETURN is impractical because I can only work with 80-byte chunks.</p>

<p>I notice that SegWit allows much more data to be stored - up to 3 MB/block - in witness data.</p>

<p>Clearly, I can't use a V0 witness program because my witness data must take the form</p>

<pre><code>&lt;signature&gt; &lt;pubkey&gt;
</code></pre>

<p>However, I believe I can use a V1 witness program. Scripts with that version won't be supported immediately after SegWit deployment, but I notice this in <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="nofollow noreferrer">BIP-141</a>:</p>

<blockquote>
  <p>If the version byte is 1 to 16, no further interpretation of the witness program or witness stack happens, and there is no size restriction for the witness stack. These versions are reserved for future extensions.</p>
</blockquote>

<p>So here's my plan. I'm going to create an output script of the form:</p>

<pre><code>&lt;0x01&gt; &lt;0x0000&gt;
</code></pre>

<p>This is a V1 witness program. According to BIP-141, the witness program is not to be interpreted, and the subsequent witness stack will have no size restriction.</p>

<p>Then I'm going to spend that output with a witness transaction input. The witness of my transaction encodes a thousand bytes of text.</p>

<p>When I publish this spending transaction, it will be propagated by nodes. They can't reject it as invalid because that would break forward compatibility when V1 scripts are introduced. BIP-141 says nothing about whether or not such transactions should be relayed (nor does BIP-144), so I assume they will be.</p>

<p>As long as I pay a sufficiently high fee, my transaction should eventually be mined. I even get a 75% discount over using OP_RETURN because my text is encoded in the witness.</p>

<p>And there's nothing the protocol will do to stop me. Or is there?</p>

<p>Edit: to make things simple, assume SegWit has been widely-deployed and that most nodes understand V0 witness programs. Clearly, non-SegWit nodes will not relay a witness transaction because it will be considered non-standard. I'm interested in the behavior of SegWit nodes.</p>

CC BY-SA 4.0
2022-11-08T10:41:55.897Z
How did this age after SegWit adoption?
CSᵠ
CC BY-SA 4.0
2024-02-26T18:48:46.547Z
@CSᵠ see ordinals...
Tobias Kienzler
<segregated-witness><op-return><witness-data>
Segwit: Arbitrary data storage in witness?
Rich Apodaca
# Segwit: Arbitrary data storage in witness?

(Asked by: username_0 on 2017-06-23)

Let's say I want to encode the text of the King James version of the Bible into the block chain, one piece at a time (replace this with any zany idea to consume copious quantities of block space). OP\_RETURN is impractical because I can only work with 80-byte chunks.

I notice that SegWit allows much more data to be stored - up to 3 MB/block - in witness data.

Clearly, I can't use a V0 witness program because my witness data must take the form

```
<signature> <pubkey>

```

However, I believe I can use a V1 witness program. Scripts with that version won't be supported immediately after SegWit deployment, but I notice this in [BIP-141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki):

> If the version byte is 1 to 16, no further interpretation of the witness program or witness stack happens, and there is no size restriction for the witness stack. These versions are reserved for future extensions.

So here's my plan. I'm going to create an output script of the form:

```
<0x01> <0x0000>

```

This is a V1 witness program. According to BIP-141, the witness program is not to be interpreted, and the subsequent witness stack will have no size restriction.

Then I'm going to spend that output with a witness transaction input. The witness of my transaction encodes a thousand bytes of text.

When I publish this spending transaction, it will be propagated by nodes. They can't reject it as invalid because that would break forward compatibility when V1 scripts are introduced. BIP-141 says nothing about whether or not such transactions should be relayed (nor does BIP-144), so I assume they will be.

As long as I pay a sufficiently high fee, my transaction should eventually be mined. I even get a 75% discount over using OP\_RETURN because my text is encoded in the witness.

And there's nothing the protocol will do to stop me. Or is there?

Edit: to make things simple, assume SegWit has been widely-deployed and that most nodes understand V0 witness programs. Clearly, non-SegWit nodes will not relay a witness transaction because it will be considered non-standard. I'm interested in the behavior of SegWit nodes.

**Tags:** segregated-witness, op-return, witness-data

> **Comments:**
> **username_1**: How did this age after SegWit adoption?  
> **username_2**: @username_1 see ordinals...  

---

## 1 answers

### Answer by username_3 on 2017-06-23. Score: 5 | Accepted answer

Your transaction, although not invalid, is non-standard. Since it is non-standard, it will not be propagated and will be rejected for being non-standard. However this does not mean that it cannot be included in a block; it can. It only requires that the miner and all of the nodes between you and that miner must be running some software that accepts and relays non-standard transactions. However not many nodes actually do, so you may have a hard time getting good propagation of your transaction.

> **Comments:**
> **username_0**: Non-standard for a segwit node or a non-segwit node? If segwit nodes consider such a transaction non-standard, where is that stated in the documentation?  
> **username_4**: Segwit is constructed in such a way that *every* SegWit spend is non-standard to non-segwit nodes.  
> **username_0**: @username_4, of course. But how would a segwit node that only understands V0 witness programs respond to my attack?  
> **username_4**: Future witness versions are non-standard by policy in Bitcoin Core for precisely the reason you point out. This is generic: all constructions that exist which are intended for future extensibility are treated as non-standard (for example, also the OP_NOPx opcodes).  
> **username_3**: @username_0 standardness for outputs is defined by this function here: https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L72. The solver function that is called will end up at this if block: https://github.com/bitcoin/bitcoin/blob/master/src/script/standard.cpp#L71. From that code, you can see that any non v0 witness output will return false in the solver which then causes IsStandard to return false too, indicating that non v0 witness outputs are non-standard. The same happens here for inputs https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L161  
> **username_0**: Thanks @username_4. It looks like what I was missing is that all upgradeable behavior is marked as non-standard implicitly, so there's no need to document this in the SegWit BIPs.  

---

