<p>There's really no reason inscriptions couldn't have been done with SegWit v0. The only difference would be that large inscriptions would have to be split across multiple inputs, making the construction slightly more expensive. Pre-SegWit you'd have to use a different transaction field for inscriptions and you couldn't use the witness discount, but methods of embedding arbitrary data in the chain have existed basically since the beginning of Bitcoin.</p>
<p>The lifting of that 10,000 byte script size limit, coupled with the fact that the currently used inscription standard requires that Taproot be used, is the likely reason it's associated with (and sometimes wrongly blamed for) inscriptions.</p>

CC BY-SA 4.0
2023-05-09T18:30:50.363Z
2023-05-12T07:43:11.550Z
2023-05-12T07:43:11.550Z
Vojtěch Strnad
<blockquote>
<p>With P2WSH, one could seemingly use the same script structure (&quot;envelope&quot;) OP_FALSE OP_IF  OP_ENDIF to store up to ~10Kb of data in witness</p>
</blockquote>
<p>This is incorrect. The <a href="https://github.com/bitcoin/bitcoin/blob/fc06881f13495154c888a64a38c7d538baf00435/src/policy/policy.h#L46-L47" rel="nofollow noreferrer">maximum standard witness script size for P2WSH is <code>3600</code></a> bytes.</p>

CC BY-SA 4.0
2023-05-09T16:12:50.860Z
Thanks for your answer. Where is that limit specified (code or bip)?
DeLorean88
CC BY-SA 4.0
2023-05-09T16:14:03.633Z
Follow the link. :) Note this is a standardness rule specific to Bitcoin Core, not a Bitcoin consensus rule.
Antoine Poinsot
CC BY-SA 4.0
2023-05-09T16:18:12.050Z
Aw... GPT-4 strikes again...
https://i.postimg.cc/pX8YR9C1/Screenshot-2023-05-09-181726.png‍♂️
DeLorean88
CC BY-SA 4.0
2023-05-09T16:21:33.943Z
Haha. I wonder why people keep using a tool with such a high false positive rate. It's literally even worse than sub-optimal search engines: you won't find what you're looking for but at least they'll admit it instead of making something up.
Antoine Poinsot
CC BY-SA 4.0
2023-05-09T16:10:41.283Z
2023-05-09T16:10:41.283Z
Antoine Poinsot
<p>In 2017 SegWit soft fork introduced consensus limit on script size <code>MAX_STANDARD_P2WSH_SCRIPT_SIZE=10000</code>. With P2WSH, one could seemingly use the same script structure (&quot;envelope&quot;) <code>OP_FALSE OP_IF &lt;data&gt; OP_ENDIF</code> to store up to ~10Kb of data in witness. Even though taproot removed the 10Kb restriction, the vast majority of inscriptions are under that limit currently. Why did they become popular now and why the popularity is commonly associated with taproot?</p>

CC BY-SA 4.0
2023-05-10T06:30:33.673Z
@Poseidon OP_RETURN is a different storage solution and has 80 bytes limit
DeLorean88
<segregated-witness><taproot><p2wsh><ordinals>
Inscriptions with size less than 10Kb were seemingly possible before taproot, why did they become popular only now?
DeLorean88
# Inscriptions with size less than 10Kb were seemingly possible before taproot, why did they become popular only now?

(Asked by: username_0 on 2023-05-09)

In 2017 SegWit soft fork introduced consensus limit on script size `MAX_STANDARD_P2WSH_SCRIPT_SIZE=10000`. With P2WSH, one could seemingly use the same script structure ("envelope") `OP_FALSE OP_IF <data> OP_ENDIF` to store up to ~10Kb of data in witness. Even though taproot removed the 10Kb restriction, the vast majority of inscriptions are under that limit currently. Why did they become popular now and why the popularity is commonly associated with taproot?

**Tags:** segregated-witness, taproot, p2wsh, ordinals

> **Comments:**
> **username_0**: @Poseidon OP_RETURN is a different storage solution and has 80 bytes limit  

---

## 2 answers

### Answer by username_1 on 2023-05-09. Score: 2

There's really no reason inscriptions couldn't have been done with SegWit v0. The only difference would be that large inscriptions would have to be split across multiple inputs, making the construction slightly more expensive. Pre-SegWit you'd have to use a different transaction field for inscriptions and you couldn't use the witness discount, but methods of embedding arbitrary data in the chain have existed basically since the beginning of Bitcoin.

The lifting of that 10,000 byte script size limit, coupled with the fact that the currently used inscription standard requires that Taproot be used, is the likely reason it's associated with (and sometimes wrongly blamed for) inscriptions.


---

### Answer by username_2 on 2023-05-09. Score: 2

> With P2WSH, one could seemingly use the same script structure ("envelope") OP\_FALSE OP\_IF OP\_ENDIF to store up to ~10Kb of data in witness

This is incorrect. The [maximum standard witness script size for P2WSH is `3600`](https://github.com/bitcoin/bitcoin/blob/fc06881f13495154c888a64a38c7d538baf00435/src/policy/policy.h#L46-L47) bytes.

> **Comments:**
> **username_0**: Thanks for your answer. Where is that limit specified (code or bip)?  
> **username_2**: Follow the link. :) Note this is a standardness rule specific to Bitcoin Core, not a Bitcoin consensus rule.  
> **username_0**: Aw... GPT-4 strikes again... https://i.postimg.cc/pX8YR9C1/Screenshot-2023-05-09-181726.png‍♂️  
> **username_2**: Haha. I wonder why people keep using a tool with such a high false positive rate. It's literally even worse than sub-optimal search engines: you won't find what you're looking for but at least they'll admit it instead of making something up.  

---

