OP_RETURN was not part of isStandard? from day one. Once it was supported by Core it became necessary to actually support it, not try to support it in one part of the software and not in others. The whole reason it was supported is because without it people will use more heinous methods to encode data on the blockchain. There's no way to stop people from doing that, so this compromise seemed best for everyone.

I think we should actually define "spam". To me a valid transaction someone willing pays for is never spam. Also PaymentRequests would be a very inefficient way to spam. It would be much easier to write a script to automatically create and submit transactions yourself. With PaymentRequests  customers have to initiate the transaction and submit/pay for it one by one.

What is actually the worst case scenario that those opposed to this are concerned about? That this takes off like wild fire and all of the sudden millions of people are using PaymentRequests and creating small transactions? That seems like a win for Bitcoin. It will help spread support for the Payment protocol and IF it becomes a problem it's because so many people are using it. In which case there's a very valid use case for Bitcoin that people are obviously excited about.

I really don't like the idea of policing other people's use of the protocol. If a transaction pays its fee and has a greater than dust value, it makes no sense to object to it.

On Tue, Jan 26, 2016 at 8:19 AM, Thomas Kerin via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

On 26/01/16 03:30, Toby Padilla via bitcoin-dev wrote:
> There are already valid use cases for OP_RETURN, it only makes sense
> to fully support the feature. The only reason it's not supported now
> is because the Payments protocol came before OP_RETURN.
>
You keep saying OP_RETURN is new, but it has been there from day one.
It's purpose is causing script execution to end if encountered.

Since then, we have tolerated putting pushdata's after it, and even
raised the limit for the size of this data. It still doesn't mean every
proposal has to be rewritten to cater for a new allowance we give
OP_RETURN.


> I've also been exploring this area with key.run
> (https://git.playgrub.com/toby/keyrun) and want the functionality for
> voting based on aggregate OP_RETURN value. *Not* to store data on the
> blockchain, but to associate content pointers with transactions.
>
> I think that since OP_RETURN has already been approved and supported
> it doesn't make much sense for me to have to re-defend it from scratch
> here.

I'd generally agree with Luke. Removing the cost of this hurts bitcoin,
and ironically, your application to a certain degree. Just because you
can do a thing one way, it doesn't mean you should. Especially if your
applications success depends on people spamming OP_RETURN hashes of
every torrent they like.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev