<div dir="ltr"><span style="font-size:12.8px">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.</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 26, 2016 at 8:19 AM, Thomas Kerin via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On 26/01/16 03:30, Toby Padilla via bitcoin-dev wrote:<br>
> There are already valid use cases for OP_RETURN, it only makes sense<br>
> to fully support the feature. The only reason it's not supported now<br>
> is because the Payments protocol came before OP_RETURN.<br>
><br>
</span>You keep saying OP_RETURN is new, but it has been there from day one.<br>
It's purpose is causing script execution to end if encountered.<br>
<br>
Since then, we have tolerated putting pushdata's after it, and even<br>
raised the limit for the size of this data. It still doesn't mean every<br>
proposal has to be rewritten to cater for a new allowance we give<br>
OP_RETURN.<br>
<span class=""><br>
<br>
> I've also been exploring this area with key.run<br>
> (<a href="https://git.playgrub.com/toby/keyrun" rel="noreferrer" target="_blank">https://git.playgrub.com/toby/keyrun</a>) and want the functionality for<br>
> voting based on aggregate OP_RETURN value. *Not* to store data on the<br>
> blockchain, but to associate content pointers with transactions.<br>
><br>
> I think that since OP_RETURN has already been approved and supported<br>
> it doesn't make much sense for me to have to re-defend it from scratch<br>
> here.<br>
<br>
</span>I'd generally agree with Luke. Removing the cost of this hurts bitcoin,<br>
and ironically, your application to a certain degree. Just because you<br>
can do a thing one way, it doesn't mean you should. Especially if your<br>
applications success depends on people spamming OP_RETURN hashes of<br>
every torrent they like.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div></div>