Everyone, I want to switch to using Bitcoin addresses instead of OP_RETURN.
The change should be trivial to add (in addition to OP_RETURN, also
checking address outputs).
I'm tired of the bickering and constant switching between standards when
we want to support this feature with CoinJoin working.

-------- Forwarded Message --------
Subject:     Re: [bitcoin] Change the default maximum OP_RETURN size to 80
bytes (#5286)
Date:     Mon, 02 Feb 2015 15:51:29 -0800
From:     Gregory Maxwell <notifications@???>
Reply-To:     bitcoin/bitcoin
<reply+000552facb971d7ea2bcd077cff35afb37ac18e4d3f5b15b92cf0000000110e7cf8192a169ce02ea660a@???>
To:     bitcoin/bitcoin <bitcoin@???>
CC:     genjix <genjix@???>

There is also a matter of driving competent design rather than lazy
first thing that works. E.g. In stealth addresses the early proposals
use highly inefficient single ECDH point per output instead of simply
pooling them. Network behavior is one of the few bits of friction
driving good technical design rather than "move fast, break things, and
force everyone else onto my way of doing thing rather than discussing
the design in public". No one wants to be an outright gatekeeper, but
the network is a shared resource and it's perfectly reasonable node
behavior to be stingy about the perpetual storage impact of the
transactions they're willing to process, especially when it comes to
neutral technical criteria like the amount of network irrelevant data
stuffed in transactions.

There is also a very clear pattern we've seen in the past where people
take anything the system lets them do as strong evidence that they have
a irrevocable right to use the system in that way, and that their only
responsibility-- and if their usage harms the system it's the
responsibility of the system to not permit it. This is especially
concerning since external data that isn't necessary for the operation of
the system comes with a liability that people may try ordering nodes or
miners to censor the data (e.g. when it's being used as a botnet control
channel acting as a high bandwidth channel for "illegal information").
For mitigating these risks it's optimal if transactions seem as uniform
and indistinguishable as reasonably possible.

—
Reply to this email directly or view it on GitHub
<https://github.com/bitcoin/bitcoin/pull/5286#issuecomment-72564175>.