2
3
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)
4
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.
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.
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.
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 – 2018-08-24T16:56:49.5331Possibly, or maybe the person mining is the same person running the node, and they wanted to post that data. – JBaczuk – 2018-08-24T16:57:58.750
Yes, it was in 2013, probably the mining task was not such difficult as today, and a developer could afford mining himself. – robermann – 2018-08-24T17:02:01.817