From: Luke Dashjr <luke@dashjr•org>
To: bitcoin-dev@lists•linuxfoundation.org,
Pieter Wuille <pieter.wuille@gmail•com>
Subject: Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol
Date: Tue, 2 Feb 2016 19:14:17 +0000 [thread overview]
Message-ID: <201602021914.18846.luke@dashjr.org> (raw)
In-Reply-To: <CAPg+sBipDyJC7_UPE8p0oSxaHOC3m5aus562Mc_s=wBkeMh5HQ@mail.gmail.com>
On Tuesday, February 02, 2016 5:16:30 PM Pieter Wuille via bitcoin-dev wrote:
> On Feb 2, 2016 18:04, "Peter Todd via bitcoin-dev" <
>
> bitcoin-dev@lists•linuxfoundation.org> wrote:
> > On Tue, Jan 26, 2016 at 09:44:48AM -0800, Toby Padilla via bitcoin-dev
>
> wrote:
> > > 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.
> >
> > I'll point out that getting a BIP for a feature is *not* a hard
> > requirement for deployment. I'd encourage you to go write up your BIP
> > document, give it a non-numerical name for ease of reference, and lobby
> > wallet vendors to implement it.
> >
> > While I'll refrain from commenting on whether or not I think the feature
> > itself is a good idea, I really don't want people to get the impression
> > that we're gatekeepers for how people choose use Bitcoin.
>
> I'll go further: whatever people have commented here and elsewhere about
> this feature (myself included) are personal opinions on the feature itself,
> in the hope you take the concerns into account.
>
> These comments are not a judgement on whether this should be accepted as a
> BIP. Specifically, the BIP editor should accept a BIP even if he personally
> dislikes the ideas in it, when the criteria are satisfied.
>
> Beyond that, having a BIP accepted does not mean wallets have to implement
> it. That's up to the individual wallet authors/maintainers.
Agree with both Peter and Pieter. Note that BIP 74 was assigned to this
proposal last Friday.
Luke
next prev parent reply other threads:[~2016-02-02 19:14 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
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 [this message]
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=201602021914.18846.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pieter.wuille@gmail$(echo .)com \
/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