From: Thomas Kerin <thomas.kerin@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol
Date: Tue, 26 Jan 2016 16:19:18 +0000 [thread overview]
Message-ID: <56A79C86.1030902@gmail.com> (raw)
In-Reply-To: <CAGcHOzwec-eoG-uZzXY2pb=VzQ98EvnijvxrcsrFYgKi2HQ_uw@mail.gmail.com>
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.
next prev parent reply other threads:[~2016-01-26 16:19 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-26 1:02 Toby Padilla
2016-01-26 2:24 ` Luke Dashjr
2016-01-26 2:54 ` Toby Padilla
2016-01-26 2:56 ` Luke Dashjr
2016-01-26 3:01 ` Toby Padilla
2016-01-26 3:04 ` Luke Dashjr
2016-01-26 3:07 ` Toby Padilla
2016-01-26 3:12 ` Luke Dashjr
2016-01-26 3:17 ` Toby Padilla
2016-01-26 3:23 ` Luke Dashjr
2016-01-26 3:30 ` Toby Padilla
2016-01-26 16:19 ` Thomas Kerin [this message]
2016-01-26 17:44 ` Toby Padilla
2016-02-02 17:03 ` Peter Todd
2016-02-02 17:16 ` Pieter Wuille
2016-02-02 17:27 ` Toby Padilla
2016-02-02 17:38 ` Peter Todd
2016-02-02 17:41 ` Toby Padilla
2016-02-02 19:12 ` Peter Todd
2016-02-02 19:22 ` Toby Padilla
2016-02-02 19:14 ` Luke Dashjr
2016-01-26 14:37 ` Andreas Schildbach
2016-01-26 17:41 ` Toby Padilla
2016-02-02 17:07 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56A79C86.1030902@gmail.com \
--to=thomas.kerin@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox