From: Toby Padilla <tobypadilla@gmail•com>
To: Luke Dashjr <luke@dashjr•org>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol
Date: Mon, 25 Jan 2016 19:30:38 -0800 [thread overview]
Message-ID: <CAGcHOzwec-eoG-uZzXY2pb=VzQ98EvnijvxrcsrFYgKi2HQ_uw@mail.gmail.com> (raw)
In-Reply-To: <201601260323.14993.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]
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.
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.
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.
On Mon, Jan 25, 2016 at 7:23 PM, Luke Dashjr <luke@dashjr•org> wrote:
> On Tuesday, January 26, 2016 3:17:12 AM Toby Padilla wrote:
> > I don't think every application of OP_RETURN could be classified as
> "spam".
>
> Perhaps not, but in this context I cannot think of any non-spam use cases.
> Use cases should come before changes to support them.
>
> > I also don't think burning the value is going to dissuade anyone from
> going
> > down that route. I don't think lost value is better for anyone.
>
> Lost value is better because it has a cost to the spammer, and deflates the
> rest of the bitcoins.
>
> Luke
>
[-- Attachment #2: Type: text/html, Size: 2005 bytes --]
next prev parent reply other threads:[~2016-01-26 3:30 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 [this message]
2016-01-26 16:19 ` Thomas Kerin
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='CAGcHOzwec-eoG-uZzXY2pb=VzQ98EvnijvxrcsrFYgKi2HQ_uw@mail.gmail.com' \
--to=tobypadilla@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)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