<p>The limitation is a relay standard, but not a consensus rule. This can be modified on a per-node basis with <code>$ bicoind -datacarriersize</code> flag. The consensus rule that would limit this is the max block size, if I'm not mistaken. So, presumably, miners connected to the node that accepted that non-standard transaction mined that block, thus it was non-standard, but still valid.</p>

<h2>Standards</h2>

<p>These rules are enforced during mempool acceptance. Each node can decide to implement different rules, provided they follow consensus rules, but many just accept the Bitcoin-core defaults upon installation. In this case 80 bytes is the default setting for <code>OP_RETURN data size.</code></p>

<h2>Consensus Rules</h2>

<p>These rules are enforced at the block validation phase. These cannot be different between nodes or it would be considered a hard fork and the chains would diverge.</p>

CC BY-SA 4.0
2018-08-24T16:56:49.533Z
`presumably, miners connected to the node that accepted that non-standard transaction mined that block, thus it was non-standard, but still valid`: why a miner would accept to do such a thing? In order to gain its fee (0.008 in this case)?
robermann
CC BY-SA 4.0
2018-08-24T16:57:58.750Z
Possibly, or maybe the person mining is the same person running the node, and they wanted to post that data.
JBaczuk
CC BY-SA 4.0
2018-08-24T17:02:01.817Z
Yes, it was in 2013, probably the mining task was not such difficult as today, and a developer could afford mining himself.
robermann
CC BY-SA 4.0
2018-08-24T13:35:31.157Z
2018-08-24T13:35:31.157Z
JBaczuk
<p>I've read that an OP_RETURN opcode allows up to 80 arbitrary bytes to be used in an unspendable transaction.
My question is, how is it possible that in this famous transaction (<a href="https://bitcoinsays.com/d29c9c0e8e4d2a9790922af73f0b8d51f0bd4bb19940d9cf910ead8fbe85bc9b" rel="noreferrer">d29c9c0e8e4d2a9790922af73f0b8d51f0bd4bb19940d9cf910ead8fbe85bc9b</a>) are being pushed 983 bytes?</p>

<p>In detail:</p>

<pre><code> Push data having size of 893 bytes. OP_CODES:

     6a             4d                    d7 03 
 OP_RETURN    OP_PUSHDATA2    (03d7 = 983 following bytes)
</code></pre>

<op-return>
OP_RETURN max bytes clarification
robermann
# OP_RETURN max bytes clarification

(Asked by: username_0 on 2018-08-24)

I've read that an OP_RETURN opcode allows up to 80 arbitrary bytes to be used in an unspendable transaction.
My question is, how is it possible that in this famous transaction (d29c9c0e8e4d2a9790922af73f0b8d51f0bd4bb19940d9cf910ead8fbe85bc9b) are being pushed 983 bytes?
In detail:
 Push data having size of 893 bytes. OP_CODES:

     6a             4d                    d7 03 
 OP_RETURN    OP_PUSHDATA2    (03d7 = 983 following bytes)

**Tags:** op-return


---

## 1 answers

### Answer by username_1 on 2018-08-24. Score: 6 | Accepted answer

The limitation is a relay standard, but not a consensus rule. This can be modified on a per-node basis with `$ bicoind -datacarriersize` flag. The consensus rule that would limit this is the max block size, if I'm not mistaken. So, presumably, miners connected to the node that accepted that non-standard transaction mined that block, thus it was non-standard, but still valid.

## Standards

These rules are enforced during mempool acceptance. Each node can decide to implement different rules, provided they follow consensus rules, but many just accept the Bitcoin-core defaults upon installation. In this case 80 bytes is the default setting for `OP_RETURN data size.`

## Consensus Rules

These rules are enforced at the block validation phase. These cannot be different between nodes or it would be considered a hard fork and the chains would diverge.

> **Comments:**
> **username_0**: `presumably, miners connected to the node that accepted that non-standard transaction mined that block, thus it was non-standard, but still valid`: why a miner would accept to do such a thing? In order to gain its fee (0.008 in this case)?  
> **username_1**: Possibly, or maybe the person mining is the same person running the node, and they wanted to post that data.  
> **username_0**: Yes, it was in 2013, probably the mining task was not such difficult as today, and a developer could afford mining himself.  

---

