<p>Yes, both encodings are valid. Of course, using just the length byte (sometimes called OP_PUSHBYTES_x) requires one fewer byte of space, so it's usually done that way.</p>

CC BY-SA 4.0
2023-01-25T15:55:25.123Z
It's also nonstandard to use the non-minimal one. However, standardness rules don't apply to coinbase transactions as those are created by miners (and obviously miners aren't subject to standardness).
Pieter Wuille
CC BY-SA 4.0
2023-01-25T10:05:01.307Z
2023-01-25T10:05:01.307Z
Vojtěch Strnad
<p>According to <a href="https://en.bitcoin.it/wiki/Script#Constants" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Script#Constants</a>, for data between 1-75 bytes, the length byte is directly appended to the data, without any OP_PUSHDATA op-codes.</p>
<p>However, I noticed that in many coinbase transactions, there exists OP_PUSHDATA1 for data less than 76 bytes.</p>
<p>Are both ways of encoding data between 1~75 bytes correct, with and without OP_PUSHDATA1?</p>
<p>For example, in the last output of transaction 2c1f1797e05d0b16c0a0aa03985a47920275ffb080439614ef08b7ee019b9511,
the 41 (0x29) bytes data 52534b424c4f434b3a4cf1e3f3539bb748501d706ad13227e5eb123b2f226f03d735001321004c43f7 was encoded as:</p>
<pre><code>6a4c2952534b424c4f434b3a4cf1e3f3539bb748501d706ad13227e5eb123b2f226f03d735001321004c43f7
</code></pre>
<p>instead of</p>
<pre><code>6a2952534b424c4f434b3a4cf1e3f3539bb748501d706ad13227e5eb123b2f226f03d735001321004c43f7
</code></pre>
<p>Below is the Bitcoin transaction in question:</p>
<pre><code>{
  &quot;txid&quot;: &quot;2c1f1797e05d0b16c0a0aa03985a47920275ffb080439614ef08b7ee019b9511&quot;,
  &quot;hash&quot;: &quot;fe33cf3518e858f5301edb792e6d48e7176a35eebdb6c64aba3641dc291c5874&quot;,
  &quot;version&quot;: 1,
  &quot;size&quot;: 368,
  &quot;vsize&quot;: 341,
  &quot;weight&quot;: 1364,
  &quot;locktime&quot;: 1060266043,
  &quot;vin&quot;: [
    {
      &quot;coinbase&quot;: &quot;0382cd0b2cfabe6d6d559a043760d4418ea56a139ecc10c2f02618b68354d662d18e42972da7159a8210000000f09f909f092f4632506f6f6c2f660000000000000000000000000000000000000000000000000000000000000000000000050068000000&quot;,
      &quot;txinwitness&quot;: [
        &quot;0000000000000000000000000000000000000000000000000000000000000000&quot;
      ],
      &quot;sequence&quot;: 0
    }
  ],
  &quot;vout&quot;: [
    {
      &quot;value&quot;: 6.26354634,
      &quot;n&quot;: 0,
      &quot;scriptPubKey&quot;: {
        &quot;asm&quot;: &quot;OP_DUP OP_HASH160 c825a1ecf2a6830c4401620c3a16f1995057c2ab OP_EQUALVERIFY OP_CHECKSIG&quot;,
        &quot;desc&quot;: &quot;addr(1KFHE7w8BhaENAswwryaoccDb6qcT6DbYY)#flw9lhul&quot;,
        &quot;hex&quot;: &quot;76a914c825a1ecf2a6830c4401620c3a16f1995057c2ab88ac&quot;,
        &quot;address&quot;: &quot;1KFHE7w8BhaENAswwryaoccDb6qcT6DbYY&quot;,
        &quot;type&quot;: &quot;pubkeyhash&quot;
      }
    },
    {
      &quot;value&quot;: 0.00000000,
      &quot;n&quot;: 1,
      &quot;scriptPubKey&quot;: {
        &quot;asm&quot;: &quot;OP_RETURN aa21a9ed306308136280f52cb5206de82c5e143c4661a14833bfb4be86bb4f3bfb050e20&quot;,
        &quot;desc&quot;: &quot;raw(6a24aa21a9ed306308136280f52cb5206de82c5e143c4661a14833bfb4be86bb4f3bfb050e20)#zxjkvxlz&quot;,
        &quot;hex&quot;: &quot;6a24aa21a9ed306308136280f52cb5206de82c5e143c4661a14833bfb4be86bb4f3bfb050e20&quot;,
        &quot;type&quot;: &quot;nulldata&quot;
      }
    },
    {
      &quot;value&quot;: 0.00000000,
      &quot;n&quot;: 2,
      &quot;scriptPubKey&quot;: {
        &quot;asm&quot;: &quot;OP_RETURN 48617468c01245061cd08921f42aa661cd788e70ac71022b06ad6ea4a6017cd1a2a81f63&quot;,
        &quot;desc&quot;: &quot;raw(6a2448617468c01245061cd08921f42aa661cd788e70ac71022b06ad6ea4a6017cd1a2a81f63)#jndu367m&quot;,
        &quot;hex&quot;: &quot;6a2448617468c01245061cd08921f42aa661cd788e70ac71022b06ad6ea4a6017cd1a2a81f63&quot;,
        &quot;type&quot;: &quot;nulldata&quot;
      }
    },
    {
      &quot;value&quot;: 0.00000000,
      &quot;n&quot;: 3,
      &quot;scriptPubKey&quot;: {
        &quot;asm&quot;: &quot;OP_RETURN 52534b424c4f434b3a4cf1e3f3539bb748501d706ad13227e5eb123b2f226f03d735001321004c43f7&quot;,
        &quot;desc&quot;: &quot;raw(6a4c2952534b424c4f434b3a4cf1e3f3539bb748501d706ad13227e5eb123b2f226f03d735001321004c43f7)#akullk9c&quot;,
        &quot;hex&quot;: &quot;6a4c2952534b424c4f434b3a4cf1e3f3539bb748501d706ad13227e5eb123b2f226f03d735001321004c43f7&quot;,
        &quot;type&quot;: &quot;nulldata&quot;
      }
    }
  ]
}
</code></pre>

<script><non-standard-transaction><op-pushdata>
Is it correct to use OP_PUSHDATA1 to encode data less than 76 bytes?
Simon L
# Is it correct to use OP_PUSHDATA1 to encode data less than 76 bytes?

(Asked by: username_0 on 2023-01-25)

According to <https://en.bitcoin.it/wiki/Script#Constants>, for data between 1-75 bytes, the length byte is directly appended to the data, without any OP\_PUSHDATA op-codes.

However, I noticed that in many coinbase transactions, there exists OP\_PUSHDATA1 for data less than 76 bytes.

Are both ways of encoding data between 1~75 bytes correct, with and without OP\_PUSHDATA1?

For example, in the last output of transaction 2c1f1797e05d0b16c0a0aa03985a47920275ffb080439614ef08b7ee019b9511,
the 41 (0x29) bytes data 52534b424c4f434b3a4cf1e3f3539bb748501d706ad13227e5eb123b2f226f03d735001321004c43f7 was encoded as:

```
6a4c2952534b424c4f434b3a4cf1e3f3539bb748501d706ad13227e5eb123b2f226f03d735001321004c43f7

```

instead of

```
6a2952534b424c4f434b3a4cf1e3f3539bb748501d706ad13227e5eb123b2f226f03d735001321004c43f7

```

Below is the Bitcoin transaction in question:

```
{
  "txid": "2c1f1797e05d0b16c0a0aa03985a47920275ffb080439614ef08b7ee019b9511",
  "hash": "fe33cf3518e858f5301edb792e6d48e7176a35eebdb6c64aba3641dc291c5874",
  "version": 1,
  "size": 368,
  "vsize": 341,
  "weight": 1364,
  "locktime": 1060266043,
  "vin": [
    {
      "coinbase": "0382cd0b2cfabe6d6d559a043760d4418ea56a139ecc10c2f02618b68354d662d18e42972da7159a8210000000f09f909f092f4632506f6f6c2f660000000000000000000000000000000000000000000000000000000000000000000000050068000000",
      "txinwitness": [
        "0000000000000000000000000000000000000000000000000000000000000000"
      ],
      "sequence": 0
    }
  ],
  "vout": [
    {
      "value": 6.26354634,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 c825a1ecf2a6830c4401620c3a16f1995057c2ab OP_EQUALVERIFY OP_CHECKSIG",
        "desc": "addr(1KFHE7w8BhaENAswwryaoccDb6qcT6DbYY)#flw9lhul",
        "hex": "76a914c825a1ecf2a6830c4401620c3a16f1995057c2ab88ac",
        "address": "1KFHE7w8BhaENAswwryaoccDb6qcT6DbYY",
        "type": "pubkeyhash"
      }
    },
    {
      "value": 0.00000000,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_RETURN aa21a9ed306308136280f52cb5206de82c5e143c4661a14833bfb4be86bb4f3bfb050e20",
        "desc": "raw(6a24aa21a9ed306308136280f52cb5206de82c5e143c4661a14833bfb4be86bb4f3bfb050e20)#zxjkvxlz",
        "hex": "6a24aa21a9ed306308136280f52cb5206de82c5e143c4661a14833bfb4be86bb4f3bfb050e20",
        "type": "nulldata"
      }
    },
    {
      "value": 0.00000000,
      "n": 2,
      "scriptPubKey": {
        "asm": "OP_RETURN 48617468c01245061cd08921f42aa661cd788e70ac71022b06ad6ea4a6017cd1a2a81f63",
        "desc": "raw(6a2448617468c01245061cd08921f42aa661cd788e70ac71022b06ad6ea4a6017cd1a2a81f63)#jndu367m",
        "hex": "6a2448617468c01245061cd08921f42aa661cd788e70ac71022b06ad6ea4a6017cd1a2a81f63",
        "type": "nulldata"
      }
    },
    {
      "value": 0.00000000,
      "n": 3,
      "scriptPubKey": {
        "asm": "OP_RETURN 52534b424c4f434b3a4cf1e3f3539bb748501d706ad13227e5eb123b2f226f03d735001321004c43f7",
        "desc": "raw(6a4c2952534b424c4f434b3a4cf1e3f3539bb748501d706ad13227e5eb123b2f226f03d735001321004c43f7)#akullk9c",
        "hex": "6a4c2952534b424c4f434b3a4cf1e3f3539bb748501d706ad13227e5eb123b2f226f03d735001321004c43f7",
        "type": "nulldata"
      }
    }
  ]
}

```

**Tags:** script, non-standard-transaction, op-pushdata


---

## 1 answers

### Answer by username_1 on 2023-01-25. Score: 1

Yes, both encodings are valid. Of course, using just the length byte (sometimes called OP\_PUSHBYTES\_x) requires one fewer byte of space, so it's usually done that way.

> **Comments:**
> **username_2**: It's also nonstandard to use the non-minimal one. However, standardness rules don't apply to coinbase transactions as those are created by miners (and obviously miners aren't subject to standardness).  

---

