Quote from: BitcoinTangibleTrust on March 21, 2014, 07:04:11 AM

Thanks for engaging with us Luke-Jr. Will you be able to elaborate on how this opt-in basis would work

Merged mining, and/or hopefully soon bitcoin side-chains.

Quote from: BitcoinTangibleTrust on March 21, 2014, 07:04:11 AM

and why reducing OP_RETURN from the proposed 80 bytes was better for bitcoin?

Because:

Too many people were getting the impression that OP_RETURN was a feature, meant to be used. It was never intended as such, only a way to "leave the windows unlocked so we don't need to replace the glass when someone breaks in". That is, to reduce the damage caused by people abusing Bitcoin.
40 bytes is more than sufficient for all legitimate needs for tying data to a transaction: you get 32 bytes for a hash, plus 8 bytes for some kind of unique identifier (which really isn't necessary either!).
The original 80 byte proposal was intended to be for 512-bit hashes, but this was determined to be unnecessary.

Quote from: BitcoinTangibleTrust on March 21, 2014, 07:04:11 AM

It seems that the 40byte reduction might be the first step in a slippery slope to zero bytes in the future by the bitcoin core devs.

Zero bytes is exactly how it's intended to be.
Note the OP_RETURN change by the development team is only a change in default relay policy.
Miners are, as always, expected to make their own policy decisions, and never rely on merely the default Bitcoin Core mining code.
Hopefully as mining returns to being decentralised, we will see less toleration of abusive/spam transactions whether the OP_RETURN variant or otherwise.
Now, if someone has a valid, necessary use case for actually storing hashes with transactions, obviously that's a case miners should seriously consider mining.