> As I explained, none of those reasons apply to PaymentRequests.

As they exist today PaymentRequests allow for essentially the same types of
transactions as non-PaymentRequest based transactions with the limitation
that OP_RETURN values must be greater. In that sense they're basically a
pre-OP_RETURN environment. OP_RETURN serves a purpose and it can't be used
with PaymentRequest transactions.

> I have no idea what you are trying to say here.

I think if you think through how you would create an OP_RETURN transaction
today without this BIP you'll see you need a key at some point if you want
a zero value.

On Mon, Jan 25, 2016 at 6:56 PM, Luke Dashjr <luke@dashjr.org> wrote:

> On Tuesday, January 26, 2016 2:54:16 AM Toby Padilla wrote:
> > Luke - As stated in the Github thread, I totally understand where you're
> > coming from but the fact is people *will* encode data on the blockchain
> > using worse methods. For all of the reasons that OP_RETURN was a good
> idea
> > in the first place, it's a good idea to support it in PaymentRequests.
>
> As I explained, none of those reasons apply to PaymentRequests.
>
> > As for keyless - there's no way (that I know of) to construct a
> transaction
> > with a zero value OP_RETURN in an environment without keys since the
> > Payment Protocol is what defines the method for getting a transaction
> from
> > a server to a wallet. You can make a custom transaction and execute it in
> > the same application but without Payments there's no way to move
> > transactions between two applications. You need to build the transaction
> > where you execute it and thus need a key.
>
> I have no idea what you are trying to say here.
>
> Luke
>