The consequence of previous ECDH address proposals "not designing around
current software" is a sustained ~70% of transactions reusing addresses, as
you saw in my Reddit post recently.

If you have a fear that an inferior proposal will gain popularity, you can
always propose a superior one. If it's *actually* superior, it will win out.

On Thu, Oct 22, 2015 at 4:43 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thursday, October 22, 2015 2:55:14 PM Justus Ranvier wrote:
> > On 22/10/15 00:53, Luke Dashjr wrote:
> > > Sorry for the late review. I'm concerned with the "notification
> address"
> > > requirement, which entails address reuse and blockchain spam. Since it
> > > entails address reuse, the recipient is forced to either leave them
> > > unspent forever (bloating the UTXO set), or spend it which potentially
> > > compromises the private key, and (combined with the payment code)
> > > possibly as much as the entire wallet.
> > >
> > > Instead, I suggest making it a single zero-value OP_RETURN output with
> > > two pushes: 1) a hash of the recipient's payment code, and 2) the
> > > encrypted payment code. This can be searched with standard bloom
> > > filters, or indexed with whatever other optimised algorithms are
> > > desired. At the same time, it never uses any space in the UTXO set, and
> > > never needs to be
> > > spent/mixed/dusted.
> >
> > The notification transaction portion is my least-favorite portion of the
> > spec, but I don't see any alternatives that provide an unambiguous
> > improvement, including your suggestion.
> >
> > One of the most highly-weighted goals of this proposal is to be usable
> > on as many mobile/light wallets as possible.
> >
> > I know for sure that all existing platforms for balance querying index
> > by address. Support for bloom filters or other querying methods is less
> > comprehensive, meaning the set of wallets that can support payment codes
> > would be smaller.
>
> No, they just need to improve their software, and only to support receiving
> with payment codes (not sending to them). BIPs should in general not be
> designed around current software, especially in this case where there is no
> benefit to doing so (since it requires software upgrades anyway).
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>