> 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