<div dir="ltr">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.<div><br></div><div>I give one example use case in the BIP. I agree that special wallet support would make the feature even better, but if someone tried to use Core the transaction would at least not be rejected. </div><div><br></div><div>I've also been exploring this area with key.run (<a href="https://git.playgrub.com/toby/keyrun">https://git.playgrub.com/toby/keyrun</a>) 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.</div><div><br></div><div>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. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 25, 2016 at 7:23 PM, Luke Dashjr <span dir="ltr"><<a href="mailto:luke@dashjr.org" target="_blank">luke@dashjr.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="">On Tuesday, January 26, 2016 3:17:12 AM Toby Padilla wrote:<br>
> I don't think every application of OP_RETURN could be classified as "spam".<br>
<br>
</span>Perhaps not, but in this context I cannot think of any non-spam use cases.<br>
Use cases should come before changes to support them.<br>
<span class=""><br>
> I also don't think burning the value is going to dissuade anyone from going<br>
> down that route. I don't think lost value is better for anyone.<br>
<br>
</span>Lost value is better because it has a cost to the spammer, and deflates the<br>
rest of the bitcoins.<br>
<span class="HOEnZb"><font color="#888888"><br>
Luke<br>
</font></span></blockquote></div><br></div>