Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol

[Toby Padilla <tobypadilla@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3126 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4243 bytes --]