OP_RETURN and non-standard transactions

[locksley]

I have an idea that uses OP_RETURN. However, the wiki states that "Note that this mechanism is not yet a standard transaction type, and thus will not be relayed by nodes on mainnet."

If it doesn't get relayed by nodes (and rather only included if you've mined that block), then how did this particular transaction get in there?

https://blockchain.info/tx/eb31ca1a4cbd97c2770983164d7560d2d03276ae1aee26f12d7c2c6424252f29

Also, I was wondering what is meant by this in the IsStandard() method?

Code:

    // only one OP_RETURN txout is permitted
    if (nDataOut > 1) {
        reason = "mucho-data";
        return false;
    }

See here https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L408-412

[locksley]

Answering my own question, but I eventually found this https://bitcoinfoundation.org/blog/?p=290

Summary: In 0.9, OP_RETURN data TxOut will become a standard transaction type. However, this is controversial, and some miners may just reject OP_RETURNs with data junk.

[maaku]

The answer to your question as stated is that if you connect directly to a miner which accepts that transaction type, then you can get those transactions in their blocks. Just because some nodes won't relay doesn't mean other nodes won't include it in their blocks.

[loquitus_of_borg]

The answer to your question as stated is that if you connect directly to a miner which accepts that transaction type, then you can get those transactions in their blocks. Just because some nodes won't relay doesn't mean other nodes won't include it in their blocks.

Given we know this tx did get relayed, if we want to send out OP_RETURN tx's, is there a way to do so? I have figured out how to construct such a message properly, but it seems to be impossible so far to send it out, as expected. The typical "entry points" to send the raw tx (such as blockchain.info's push or bitcoind's sendrawtransaction) tend to fail. The latter fails client-side, I think and does not even bother talking to the network.

Perhaps the IP of the node that relayed this example tx successfully is a miner that does accept such tx's?

[dexX7]

It's possible, you should try to push the transactions via Eligius: http://eligius.st/~wizkid057/newstats/pushtxn.php

Could take a while, if you're unlucky though. (1-4 hours)

[loquitus_of_borg]

Interesting!

I tried and got the following:

Trying to send...
array(3) {
  ["result"]=>
  string(64) "<XXX>"
  ["error"]=>
  NULL
  ["id"]=>
  string(1) "1"
}
Response = 0

<XXX> replaces what appears to be a hex string that is the same length as a tx hash.

What does this mean?

Also, when you say it could take a while, do you mean the confirmation time?

It's possible, you should try to push the transactions via Eligius: http://eligius.st/~wizkid057/newstats/pushtxn.php

Could take a while, if you're unlucky though. (1-4 hours)

[maaku]

Eligius does not accept OP_RETURN outputs.

[TierNolan]

Eligius does not accept OP_RETURN outputs.

Is that a policy thing, or they haven't updated?

[maaku]

Policy.

[TierNolan]

Policy.

Is their reasoning that people shouldn't be spamming the blockchain with data unrelated to bitcoin?  If so, how do they propose to stop it?

[loquitus_of_borg]

It is a matter of opinion if it is spamming. You can argue it both ways. Frankly, miners can always choose to reject your TX if they want to, based on what fee you provide. So ultimately, the miners could just process such TX's with a high enough fee that justifies it. Sort of alleviates a mass-spam issue and now, people are paying to store data.

Policy.

Is their reasoning that people shouldn't be spamming the blockchain with data unrelated to bitcoin?  If so, how do they propose to stop it?

[maaku]

Or, like Eligius, they can reason that spamming the network with data is uniformity bad for everyone and an externalized cost that is not properly accounted for, and reject all data transactions on principle, for the health of the network.

[TierNolan]

Or, like Eligius, they can reason that spamming the network with data is uniformity bad for everyone and an externalized cost that is not properly accounted for, and reject all data transactions on principle, for the health of the network.

Well, if people are going to do it anyway, the OP_RETURN system means that it is does less damage (disk block rather than RAM bloat).

[dexX7]

Eligius does not accept OP_RETURN outputs.

I was pretty sure that I sent those two transactions via Eligius, but after looking at it again, it shows another transmitter:

https://blockchain.info/en/tx/ac960e5ae5e574f95de11eabf5671f7bec30c964377f643c8358d0ca0728e385
https://blockchain.info/en/tx/4feb2528d2b262099e03add25a76221078f53c919fdcbb509b3161e2eb8d5e86

Anyway, loquitus_of_borg: try to look up the txid in a few hours. If it worked, awesome, otherwise I guess I was indeed wrong. Sorry then.

[genjix]

Eligius does not accept OP_RETURN outputs.

yes they do.

[maaku]

Well, it's not *supposed* to, and Luke-Jr considers it a bug if it does.

[09:09:16] <maaku> Luke-Jr: does Eligius accept OP_RETURN data outputs?
[09:10:23] <Luke-Jr> maaku: not intentionally.
[09:11:01] <maaku> you've fixed it right, so it no longer does?
[09:11:08] <Luke-Jr> not sure
[09:13:40] <Luke-Jr> maaku: if it works right now, hopefully we will fix that soon

[genjix]

Well, it's not *supposed* to, and Luke-Jr considers it a bug if it does.

[09:09:16] <maaku> Luke-Jr: does Eligius accept OP_RETURN data outputs?
[09:10:23] <Luke-Jr> maaku: not intentionally.
[09:11:01] <maaku> you've fixed it right, so it no longer does?
[09:11:08] <Luke-Jr> not sure
[09:13:40] <Luke-Jr> maaku: if it works right now, hopefully we will fix that soon

ok thanks for clarifying

[gidgreen]

This site shows all recent OP_RETURNs in the bitcoin blockchain:

http://coinsecrets.org/

Might be helpful for debugging purposes.