5

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)
robermann
  • 175
  • 1
  • 6

1 Answers1

6

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.

JBaczuk
  • 7,388
  • 1
  • 13
  • 34
  • 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 Aug 24 '18 at 16:56
  • 1
    Possibly, or maybe the person mining is the same person running the node, and they wanted to post that data. – JBaczuk Aug 24 '18 at 16:57
  • Yes, it was in 2013, probably the mining task was not such difficult as today, and a developer could afford mining himself. – robermann Aug 24 '18 at 17:02