<p>UPDATE: The first version of this answer suggested using two data pushes, updated to use OP_PUSHDATA1.</p>
<p>Further research has clarified the issue:</p>
<ul>
<li>OP_RETURN max data length is 80 bytes, however</li>
<li>Maximum bytes in one push data is 75 bytes.</li>
<li>Therefore data of sizes between 76 to 80 need to be encoded with OP_PUSHDATA1!</li>
</ul>
<p>The script in this transaction is in fact invalid, <code>6a 4d 53 57</code> should be interpreted as <code>OP_RETURN OP_PUSHDATA2 53 57</code>, after which 22355 (0x5753) bytes are expected.</p>
<p>Correct encoding would be to use <code>OP_PUSHDATA1</code> for data of length 76 to 80 bytes.</p>
<p><code>50 6a 4c 4d &lt;77 bytes&gt;</code>
<code>OP_RETURN OP_PUSHDATA1 4d &lt;77 bytes&gt;</code></p>

CC BY-SA 4.0
2022-11-22T14:00:48.080Z
Can't you use the 2-byte push OP, e.g. `6a 4c 4e data_78_bytes` ?
bca-0353f40e
CC BY-SA 4.0
2022-11-22T14:05:44.417Z
So full output serialization would be: `0000000000000000516A4C4E{your_data_78_raw_bytes}`
bca-0353f40e
CC BY-SA 4.0
2022-11-22T14:26:34.500Z
Another solution is to use OP_PUSHDATA1 with 1-byte length:
OP_RETURN OP_PUSHDATA1 4f <...>
OptOut
CC BY-SA 4.0
2022-11-22T14:27:50.093Z
Right, probably the correct solution is to use OP_PUSHDATA1. This is probably better than 2 separate pushes.
OP_PUSHDATA2 is not supposed to be used with len<256 (I've removed my previous misleading comment).
OptOut
CC BY-SA 4.0
2022-11-22T21:59:15.817Z
Sample tx with 80-byte OP_RETURN as one data push (testnet):

https://mempool.space/testnet/tx/d06b4c6f7c3bcf56ec98b7109729a2d20b540aa2b0bdfe8681281f8c99dfbd93
OptOut
CC BY-SA 4.0
2022-11-23T05:43:22.827Z
Looks like the block explorer has a bug, it's assuming a 1-byte push op and decoding the length byte as the 1st character of your message :) Here's how it should look like:

`6a 4c 50 4d 454d4f5f35363738395f3132333435363738395f3132333435363738395f3132333435363738395f3132333435363738395f3132333435363738395f3132333435363738395f313233343536373839` == OP_RETURN
OP_PUSHDATA1 0x4e "EMO_56789_123456789_123456789_123456789_123456789_123456789_123456789_123456789"
bca-0353f40e
CC BY-SA 4.0
2022-11-23T10:13:22.893Z
I think in this case it shows correctly. 4c is OP_PUSHDATA1, 50 is length (=80), and 4d (=M) is the first character of the data. I don't know of other explorers supporting testnet.
OptOut
CC BY-SA 4.0
2022-11-23T10:15:40.263Z
Here is a sample TX on mainnet (80 bytes). Mempool shows correctly, blockchair does not -- it takes the length as part of the data.
https://mempool.space/tx/62096a361bc7f142f82d82762a090a1e57ea347d2650e6c5431a6544dd29e786
https://blockchair.com/bitcoin/transaction/62096a361bc7f142f82d82762a090a1e57ea347d2650e6c5431a6544dd29e786
OptOut
CC BY-SA 4.0
2022-11-24T09:26:15.047Z
You're right, sorry for the confusion, I had read it wrong and thought I saw an error while it was actually correct, the message is "MEMO..." I mixed up the "M" for the length. Yeah I noticed this with blockchair - it decodes the push op to ASCII, too.
bca-0353f40e
CC BY-SA 4.0
2022-11-22T13:48:43.263Z
2022-11-22T14:58:14.523Z
2022-11-22T14:58:14.523Z
OptOut
<p>A transaction with a 77 bytes OP_RETURN is refused, but with shorter data (e.g. 74 bytes) is accepted, although up to 80 bytes should work.</p>
<p>What is the safe limit to be used?</p>
<p>Per these references the maximum length is 80 bytes (83 for whole script) (since v 0.11):</p>
<p><a href="https://stackoverflow.com/questions/24845429/maximum-size-of-data-bitcoin-op-return-tx-can-handle">https://stackoverflow.com/questions/24845429/maximum-size-of-data-bitcoin-op-return-tx-can-handle</a>
<a href="https://developer.bitcoin.org/devguide/transactions.html#null-data" rel="nofollow noreferrer">https://developer.bitcoin.org/devguide/transactions.html#null-data</a></p>
<p>The below transaction produces error: <code>{&quot;error&quot;:&quot;-26: scriptpubkey&quot;}</code>.
Similar transactions with slightly shorter OP_RETURN are fine.</p>
<pre><code>01000000000102ae5c4a7139f0f47cf4bf431d99f110e73d2cd7e03faae56d56d7c09db3ee3c400100000000fbffffffc8ab005126b7b871d7c9621789de87282f4cd13e851fd286b0e5aae02e21c0b90000000000faffffff0350c30000000000001600146f26d2633d5307d9c4b1ca5b4c282201bae4ab144e15000000000000160014bb5bb9b9a07718bd0bfeef385f6a184787b584da00000000000000004f6a4d535741503a424e422e425553443a626e62317368366e757a7474336463657679346e676d7a746b7061706e76787179376a653074307564723a3635383137323831393a74656d7963683a3330300247304402200ca03ef0f249471dbee806b0961892c7141339460a5890479fdbebd3ec06ce8d02201a2275d54849f660ba01cd2799c0ac57a4bfca6d21115ddeecf63ebfd71898df0121034df96f5dacf5e22fb8611e6863e48f6777c7e96064c81196e23dcefd35017d0e02483045022100987199ff71731d44520bc1ed3704a6a66725ea890479ea5078b6b89ebb854d8402202dd52791a28c9d28c1672785765aab811b1549a1ec031f7c15a4ee472e70c4200121034df96f5dacf5e22fb8611e6863e48f6777c7e96064c81196e23dcefd35017d0e00000000

{
    &quot;data_hex&quot;: &quot;535741503a ...&quot;,
    &quot;script&quot;: &quot;6a4d535741503a ...&quot;,
    &quot;script_type&quot;: &quot;null-data&quot;,
    &quot;value&quot;: 0
}
</code></pre>
<p>Note: use case is client for thorswap.finance cross-chain DEX.</p>

CC BY-SA 4.0
2022-11-22T10:20:10.690Z
This OP_RETURN contains 78 bytes in one push, however, it seems the max length for a push is 75 bytes.  See https://en.bitcoin.it/wiki/Script .
Therefore this is in fact an invalid script, the byte 78 following OP_RETURN in fact is interpreted as OP_PUSHDATA4, not as length 78.
OptOut
<op-return><op-pushdata>
Tx with OP_RETURN with 77 bytes of data refused by node
OptOut
# Tx with OP_RETURN with 77 bytes of data refused by node

(Asked by: username_0 on 2022-11-22)

A transaction with a 77 bytes OP\_RETURN is refused, but with shorter data (e.g. 74 bytes) is accepted, although up to 80 bytes should work.

What is the safe limit to be used?

Per these references the maximum length is 80 bytes (83 for whole script) (since v 0.11):

<https://stackoverflow.com/questions/24845429/maximum-size-of-data-bitcoin-op-return-tx-can-handle>
<https://developer.bitcoin.org/devguide/transactions.html#null-data>

The below transaction produces error: `{"error":"-26: scriptpubkey"}`.
Similar transactions with slightly shorter OP\_RETURN are fine.

```
01000000000102ae5c4a7139f0f47cf4bf431d99f110e73d2cd7e03faae56d56d7c09db3ee3c400100000000fbffffffc8ab005126b7b871d7c9621789de87282f4cd13e851fd286b0e5aae02e21c0b90000000000faffffff0350c30000000000001600146f26d2633d5307d9c4b1ca5b4c282201bae4ab144e15000000000000160014bb5bb9b9a07718bd0bfeef385f6a184787b584da00000000000000004f6a4d535741503a424e422e425553443a626e62317368366e757a7474336463657679346e676d7a746b7061706e76787179376a653074307564723a3635383137323831393a74656d7963683a3330300247304402200ca03ef0f249471dbee806b0961892c7141339460a5890479fdbebd3ec06ce8d02201a2275d54849f660ba01cd2799c0ac57a4bfca6d21115ddeecf63ebfd71898df0121034df96f5dacf5e22fb8611e6863e48f6777c7e96064c81196e23dcefd35017d0e02483045022100987199ff71731d44520bc1ed3704a6a66725ea890479ea5078b6b89ebb854d8402202dd52791a28c9d28c1672785765aab811b1549a1ec031f7c15a4ee472e70c4200121034df96f5dacf5e22fb8611e6863e48f6777c7e96064c81196e23dcefd35017d0e00000000

{
    "data_hex": "535741503a ...",
    "script": "6a4d535741503a ...",
    "script_type": "null-data",
    "value": 0
}

```

Note: use case is client for thorswap.finance cross-chain DEX.

**Tags:** op-return, op-pushdata

> **Comments:**
> **username_0**: This OP_RETURN contains 78 bytes in one push, however, it seems the max length for a push is 75 bytes.  See https://en.bitcoin.it/wiki/Script . Therefore this is in fact an invalid script, the byte 78 following OP_RETURN in fact is interpreted as OP_PUSHDATA4, not as length 78.  

---

## 1 answers

### Answer by username_0 on 2022-11-22. Score: 4

UPDATE: The first version of this answer suggested using two data pushes, updated to use OP\_PUSHDATA1.

Further research has clarified the issue:

* OP\_RETURN max data length is 80 bytes, however
* Maximum bytes in one push data is 75 bytes.
* Therefore data of sizes between 76 to 80 need to be encoded with OP\_PUSHDATA1!

The script in this transaction is in fact invalid, `6a 4d 53 57` should be interpreted as `OP_RETURN OP_PUSHDATA2 53 57`, after which 22355 (0x5753) bytes are expected.

Correct encoding would be to use `OP_PUSHDATA1` for data of length 76 to 80 bytes.

`50 6a 4c 4d <77 bytes>`
`OP_RETURN OP_PUSHDATA1 4d <77 bytes>`

> **Comments:**
> **username_1**: Can't you use the 2-byte push OP, e.g. `6a 4c 4e data_78_bytes` ?  
> **username_1**: So full output serialization would be: `0000000000000000516A4C4E{your_data_78_raw_bytes}`  
> **username_0**: Another solution is to use OP_PUSHDATA1 with 1-byte length: OP_RETURN OP_PUSHDATA1 4f <...>  
> **username_0**: Right, probably the correct solution is to use OP_PUSHDATA1. This is probably better than 2 separate pushes. OP_PUSHDATA2 is not supposed to be used with len<256 (I've removed my previous misleading comment).  
> **username_0**: Sample tx with 80-byte OP_RETURN as one data push (testnet):  https://mempool.space/testnet/tx/d06b4c6f7c3bcf56ec98b7109729a2d20b540aa2b0bdfe8681281f8c99dfbd93  
> **username_1**: Looks like the block explorer has a bug, it's assuming a 1-byte push op and decoding the length byte as the 1st character of your message :) Here's how it should look like:  `6a 4c 50 4d 454d4f5f35363738395f3132333435363738395f3132333435363738395f3132333435363738395f3132333435363738395f3132333435363738395f3132333435363738395f313233343536373839` == OP_RETURN OP_PUSHDATA1 0x4e "EMO_56789_123456789_123456789_123456789_123456789_123456789_123456789_123456789"  
> **username_0**: I think in this case it shows correctly. 4c is OP_PUSHDATA1, 50 is length (=80), and 4d (=M) is the first character of the data. I don't know of other explorers supporting testnet.  
> **username_0**: Here is a sample TX on mainnet (80 bytes). Mempool shows correctly, blockchair does not -- it takes the length as part of the data. https://mempool.space/tx/62096a361bc7f142f82d82762a090a1e57ea347d2650e6c5431a6544dd29e786 https://blockchair.com/bitcoin/transaction/62096a361bc7f142f82d82762a090a1e57ea347d2650e6c5431a6544dd29e786  
> **username_1**: You're right, sorry for the confusion, I had read it wrong and thought I saw an error while it was actually correct, the message is "MEMO..." I mixed up the "M" for the length. Yeah I noticed this with blockchair - it decodes the push op to ASCII, too.  

---

