[bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol

[Luke Dashjr via bitcoin-dev]

This is a bad idea. OP_RETURN attachments are tolerated (not encouraged!) for
the sake of the network, since the spam cannot be outright stopped. If it
could be outright stopped, it would not be reasonable to allow OP_RETURN. When
it comes to the payment protocol, however, changing the current behaviour has
literally no benefit to the network at all, and the changes proposed herein
are clearly detrimental since it would both encourage spam, and potentially
make users unwilling (maybe even unaware) participants in it. For these
reasons, *I highly advise against publishing or implementing this BIP, even if
the later mentioned issues are fixed.*

An example might be a merchant that adds the hash of a plain text invoice
to the checkout transaction. The merchant could construct the
PaymentRequest with the invoice hash in an OP_RETURN and pass it to the
customer's wallet. The wallet could then submit the transaction, including
the invoice hash from the PaymentRequest. The wallet will have encoded a
proof of purchase to the blockchain without the wallet developer having to
coordinate with the merchant software or add features beyond this BIP.

Such a "proof" is useless without wallet support. Even if you argue it could
be implemented later on, it stands to reason that a scammer will simply encode
garbage if the wallet is not checking the proof-of-purchase upfront. To check
it, you would also need further protocol extensions which are not included in
this draft.

Merchants and Bitcoin application developers benefit from this BIP because
they can now construct transactions that include OP_RETURN data in a
keyless environment. Again, prior to this BIP, transactions that used
OP_RETURN (with zero value) needed to be constructed and executed in the
same software. By separating the two concerns, this BIP allows merchant
software to create transactions with OP_RETURN metadata on a server without
storing public or private Bitcoin keys. This greatly enhances security
where OP_RETURN applications currently need access to a private key to sign
transactions.

I don't see how this has any relevance to keys at all...

## Specification
The specification for this BIP is straightforward. BIP70 should be fully
1. Outputs where the script is an OP_RETURN and the value is zero should be
accepted by the wallet.
2. Outputs where the script is an OP_RETURN and the value is greater than
zero should be rejected.
This is a change from the BIP70 requirement that all zero value outputs be
ignored.

This does not appear to be backward nor even forward compatible. Old clients
will continue to use the previous behaviour and transparently omit any
commitments. New clients on the other hand will fail to include commitments
produced by old servers. In other words, it is impossible to produce software
compatible with both BIP 70 and this draft, and implementing either would
result in severe consequences.

As it exists today, BIP70 allows for OP_RETURN data storage at the expense
of permanently destroyed Bitcoin.

It is better for the spammers to lose burned bitcoins, than have a way to
avoid them.

Luke

[Toby Padilla via bitcoin-dev]

It looks like my draft hasn't been approved by the mailing list so if
anyone would like to read it it's also on Gist:

https://gist.github.com/toby/9e71811d387923a71a53

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 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.

Post by Luke Dashjr via bitcoin-dev
This is a bad idea. OP_RETURN attachments are tolerated (not encouraged!) for
the sake of the network, since the spam cannot be outright stopped. If it
could be outright stopped, it would not be reasonable to allow OP_RETURN. When
it comes to the payment protocol, however, changing the current behaviour has
literally no benefit to the network at all, and the changes proposed herein
are clearly detrimental since it would both encourage spam, and potentially
make users unwilling (maybe even unaware) participants in it. For these
reasons, *I highly advise against publishing or implementing this BIP, even if
the later mentioned issues are fixed.*

An example might be a merchant that adds the hash of a plain text invoice
to the checkout transaction. The merchant could construct the
PaymentRequest with the invoice hash in an OP_RETURN and pass it to the
customer's wallet. The wallet could then submit the transaction,

including

the invoice hash from the PaymentRequest. The wallet will have encoded a
proof of purchase to the blockchain without the wallet developer having

to

coordinate with the merchant software or add features beyond this BIP.

Such a "proof" is useless without wallet support. Even if you argue it could
be implemented later on, it stands to reason that a scammer will simply encode
garbage if the wallet is not checking the proof-of-purchase upfront. To check
it, you would also need further protocol extensions which are not included in
this draft.

Merchants and Bitcoin application developers benefit from this BIP

because

they can now construct transactions that include OP_RETURN data in a
keyless environment. Again, prior to this BIP, transactions that used
OP_RETURN (with zero value) needed to be constructed and executed in the
same software. By separating the two concerns, this BIP allows merchant
software to create transactions with OP_RETURN metadata on a server

without

storing public or private Bitcoin keys. This greatly enhances security
where OP_RETURN applications currently need access to a private key to

sign

transactions.

I don't see how this has any relevance to keys at all...

## Specification
The specification for this BIP is straightforward. BIP70 should be fully
1. Outputs where the script is an OP_RETURN and the value is zero should

be

accepted by the wallet.
2. Outputs where the script is an OP_RETURN and the value is greater than
zero should be rejected.
This is a change from the BIP70 requirement that all zero value outputs

be

ignored.

This does not appear to be backward nor even forward compatible. Old clients
will continue to use the previous behaviour and transparently omit any
commitments. New clients on the other hand will fail to include commitments
produced by old servers. In other words, it is impossible to produce software
compatible with both BIP 70 and this draft, and implementing either would
result in severe consequences.

As it exists today, BIP70 allows for OP_RETURN data storage at the

expense

of permanently destroyed Bitcoin.

It is better for the spammers to lose burned bitcoins, than have a way to
avoid them.
Luke

[Luke Dashjr via bitcoin-dev]

Post by Toby Padilla via bitcoin-dev
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.

Post by Toby Padilla via bitcoin-dev
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

[Luke Dashjr via bitcoin-dev]

Post by Luke Dashjr via bitcoin-dev
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.

OP_RETURN can be used, but you need to burn coins. I don't see any benefit to
changing that. It is better that coins are burned.

Post by Luke Dashjr via bitcoin-dev
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.

You *always* need a key, to redeem inputs... regardless of values.

Luke

[Luke Dashjr via bitcoin-dev]

I don't see any benefit to changing that. It is better that coins are
burned.

I think this is our fundamental disagreement. People will burn coins to
encode data, why allow this when there's a better alternative?

My point is that there isn't a better alternative. The coins being burned, is
strictly better than it being gratis.

You *always* need a key, to redeem inputs... regardless of values.

Correct, but with BIP70 that key is in the user's wallet and you can
construct transactions on another machine (thus not needing a key during
construction). Right now there's no way to do the transaction construction
on another machine with zero value OP_RETURNs.

This is also a good thing. Spam should not be made easier or cheaper.

Luke

[Luke Dashjr via bitcoin-dev]

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

[Toby Padilla via bitcoin-dev]

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.

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

[Thomas Kerin via bitcoin-dev]

Post by Toby Padilla via bitcoin-dev
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.

Post by Toby Padilla via bitcoin-dev
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.

[Toby Padilla via bitcoin-dev]

OP_RETURN was not part of isStandard? from day one. Once it was supported
by Core it became necessary to actually support it, not try to support it
in one part of the software and not in others. The whole reason it was
supported is because without it people will use more heinous methods to
encode data on the blockchain. There's no way to stop people from doing
that, so this compromise seemed best for everyone.

I think we should actually define "spam". To me a valid transaction someone
willing pays for is never spam. Also PaymentRequests would be a very
inefficient way to spam. It would be much easier to write a script to
automatically create and submit transactions yourself. With PaymentRequests
customers have to initiate the transaction and submit/pay for it one by
one.

What is actually the worst case scenario that those opposed to this are
concerned about? That this takes off like wild fire and all of the sudden
millions of people are using PaymentRequests and creating small
transactions? That seems like a win for Bitcoin. It will help spread
support for the Payment protocol and IF it becomes a problem it's because
so many people are using it. In which case there's a very valid use case
for Bitcoin that people are obviously excited about.

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.

On Tue, Jan 26, 2016 at 8:19 AM, Thomas Kerin via bitcoin-dev <

Post by Thomas Kerin via bitcoin-dev

Post by Toby Padilla via bitcoin-dev
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.

Post by Toby Padilla via bitcoin-dev
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.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Peter Todd via bitcoin-dev]

Post by Toby Padilla via bitcoin-dev
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.

[Pieter Wuille via bitcoin-dev]

On Feb 2, 2016 18:04, "Peter Todd via bitcoin-dev" <

Post by Peter Todd via bitcoin-dev

Post by Toby Padilla via bitcoin-dev
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.

[Toby Padilla via bitcoin-dev]

My BIP was ultimately accepted, it's number 74

https://github.com/bitcoin/bips/blob/master/bip-0074.mediawiki

The editor did not agree with it, and I suspect would comment against it
with his new proposed BIP :)

I really appreciated that despite his vehement disagreement, he assigned
the BIP. It seems like the process worked great. There was deep vetting,
lots of back and forth and the editor put aside his personal opinions to
accept the BIP.

That being said...

The mailing list is a problem. I'm still on moderation only. I have no idea
if this message will go through and when it will go through. I totally
understand the desire to keep the conversation level high, but when people
who *are* whitelisted can quickly post multiple heated arguments against
you (publicly) and you can't respond, then that starts to look very
centralized and discouraging.

I would agree with Gavin on the other thread about the proposed BIP
commenting BIP. Putting more decision power behind a moderated mailing list
and wiki doesn't seem like a good idea.

Post by Pieter Wuille via bitcoin-dev
On Feb 2, 2016 18:04, "Peter Todd via bitcoin-dev" <

On Tue, Jan 26, 2016 at 09:44:48AM -0800, Toby Padilla via bitcoin-dev

Post by Toby Padilla via bitcoin-dev
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,

Post by Toby Padilla via bitcoin-dev
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.
--
Pieter

[Peter Todd via bitcoin-dev]

Post by Toby Padilla via bitcoin-dev
The mailing list is a problem. I'm still on moderation only. I have no idea
if this message will go through and when it will go through. I totally
understand the desire to keep the conversation level high, but when people
who *are* whitelisted can quickly post multiple heated arguments against
you (publicly) and you can't respond, then that starts to look very
centralized and discouraging.

Everyone is on moderation only in this mailing list, myself included.

[Toby Padilla via bitcoin-dev]

Then the moderation is being unevenly applied. Luke commented against my
BIP multiple times right after it was published but it took hours for my
responses to go through and I had to track people down on IRC to ask about
it:

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/thread.html

Post by Toby Padilla via bitcoin-dev

Post by Toby Padilla via bitcoin-dev
The mailing list is a problem. I'm still on moderation only. I have no

idea

Post by Toby Padilla via bitcoin-dev
if this message will go through and when it will go through. I totally
understand the desire to keep the conversation level high, but when

people

Post by Toby Padilla via bitcoin-dev
who *are* whitelisted can quickly post multiple heated arguments against
you (publicly) and you can't respond, then that starts to look very
centralized and discouraging.

Everyone is on moderation only in this mailing list, myself included.
--
000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698

[Peter Todd via bitcoin-dev]

Post by Toby Padilla via bitcoin-dev
Then the moderation is being unevenly applied. Luke commented against my
BIP multiple times right after it was published but it took hours for my
responses to go through and I had to track people down on IRC to ask about
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/thread.html

Keep in mind that actual human beings need to hit the approve button on
your posts; quite likely Luke happened to respond when those humans were
available, and you didn't. I personally had to do the exact same thing
the other day with one of my posts.

Moderation is an unfortunate thing to need, but this list is read by
literally hundreds of busy people, many of whome have had to unsubscribe
at various points in the past due to a lack of moderation. I wish we had
a better solution, but that's what we have. We're also not along in
using fairly agressive moderation, for example the
***@metzdowd.com mailing list where Bitcoin was originally
announced uses manual approval moderation on all messages as well;
there's also an unmoderated offshoot of it, ***@randombit.net

(and feel free to start an unmoderated version of bitcoin-dev!)

[Toby Padilla via bitcoin-dev]

I think it would be helpful to clarify this in the list documentation.
Right now there's a bunch of conflicting information.

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev states:

"*Greylisting Notice*
Your first post to this list may be delayed by 5+ minutes due to Greylisting
<https://en.wikipedia.org/wiki/Greylisting>. Subsequent posts should go
through without delay."

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011591.html
states:

"Everyone starts moderated, and the mod bit gets cleared as they post. It
gets set again if someone notices or reports a violation."

Post by Toby Padilla via bitcoin-dev

Post by Toby Padilla via bitcoin-dev
Then the moderation is being unevenly applied. Luke commented against my
BIP multiple times right after it was published but it took hours for my
responses to go through and I had to track people down on IRC to ask

about
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/thread.html
Keep in mind that actual human beings need to hit the approve button on
your posts; quite likely Luke happened to respond when those humans were
available, and you didn't. I personally had to do the exact same thing
the other day with one of my posts.
Moderation is an unfortunate thing to need, but this list is read by
literally hundreds of busy people, many of whome have had to unsubscribe
at various points in the past due to a lack of moderation. I wish we had
a better solution, but that's what we have. We're also not along in
using fairly agressive moderation, for example the
announced uses manual approval moderation on all messages as well;
(and feel free to start an unmoderated version of bitcoin-dev!)
--
000000000000000008320874843f282f554aa2436290642fcfa81e5a01d78698

[Luke Dashjr via bitcoin-dev]

Post by Pieter Wuille via bitcoin-dev
On Feb 2, 2016 18:04, "Peter Todd via bitcoin-dev" <

On Tue, Jan 26, 2016 at 09:44:48AM -0800, Toby Padilla via bitcoin-dev

Post by Toby Padilla via bitcoin-dev
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,

Post by Toby Padilla via bitcoin-dev
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

[Andreas Schildbach via bitcoin-dev]

Discussion about reasoning of OP_RETURN aside, I think your
specification needs to be more precise/less ambiguous.

Here is what BIP70 currently says about PaymentDetails.outputs:

"one or more outputs where Bitcoins are to be sent. If the sum of
outputs.amount is zero, the customer will be asked how much to pay, and
the bitcoin client may choose any or all of the Outputs (if there are
more than one) for payment. If the sum of outputs.amount is non-zero,
then the customer will be asked to pay the sum, and the payment shall be
split among the Outputs with non-zero amounts (if there are more than
one; Outputs with zero amounts shall be ignored)."

As you can see, zero outputs are not ignored at all. They are used as an
indication to allow the user to set an amount. So if you'd come up with
one zero-amount OP_RETURN output, it would pop up an amount dialog.
Certainly not what you want, right?

Post by Toby Padilla via bitcoin-dev
It looks like my draft hasn't been approved by the mailing list so if
https://gist.github.com/toby/9e71811d387923a71a53
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 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.
This is a bad idea. OP_RETURN attachments are tolerated (not encouraged!) for
the sake of the network, since the spam cannot be outright stopped. If it
could be outright stopped, it would not be reasonable to allow OP_RETURN. When
it comes to the payment protocol, however, changing the current behaviour has
literally no benefit to the network at all, and the changes proposed herein
are clearly detrimental since it would both encourage spam, and potentially
make users unwilling (maybe even unaware) participants in it. For these
reasons, *I highly advise against publishing or implementing this BIP, even if
the later mentioned issues are fixed.*

An example might be a merchant that adds the hash of a plain text invoice
to the checkout transaction. The merchant could construct the
PaymentRequest with the invoice hash in an OP_RETURN and pass it to the
customer's wallet. The wallet could then submit the transaction, including
the invoice hash from the PaymentRequest. The wallet will have encoded a
proof of purchase to the blockchain without the wallet developer having to
coordinate with the merchant software or add features beyond this BIP.

Such a "proof" is useless without wallet support. Even if you argue it could
be implemented later on, it stands to reason that a scammer will simply encode
garbage if the wallet is not checking the proof-of-purchase upfront. To check
it, you would also need further protocol extensions which are not included in
this draft.

Merchants and Bitcoin application developers benefit from this BIP because
they can now construct transactions that include OP_RETURN data in a
keyless environment. Again, prior to this BIP, transactions that used
OP_RETURN (with zero value) needed to be constructed and executed in the
same software. By separating the two concerns, this BIP allows merchant
software to create transactions with OP_RETURN metadata on a server without
storing public or private Bitcoin keys. This greatly enhances security
where OP_RETURN applications currently need access to a private key to sign
transactions.

I don't see how this has any relevance to keys at all...

## Specification
The specification for this BIP is straightforward. BIP70 should be fully
1. Outputs where the script is an OP_RETURN and the value is zero should be
accepted by the wallet.
2. Outputs where the script is an OP_RETURN and the value is greater than
zero should be rejected.
This is a change from the BIP70 requirement that all zero value outputs be
ignored.

This does not appear to be backward nor even forward compatible. Old clients
will continue to use the previous behaviour and transparently omit any
commitments. New clients on the other hand will fail to include commitments
produced by old servers. In other words, it is impossible to produce software
compatible with both BIP 70 and this draft, and implementing either would
result in severe consequences.

As it exists today, BIP70 allows for OP_RETURN data storage at the expense
of permanently destroyed Bitcoin.

It is better for the spammers to lose burned bitcoins, than have a way to
avoid them.
Luke
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Toby Padilla via bitcoin-dev]

The wording is a little strange and I think it *should* work as you state,
but Bitcoin Core will actually reject any output that has zero value (even
a single OP_RETURN output -- I just tested again to make sure).

Here's the blocking code:

https://github.com/bitcoin/bitcoin/blob/master/src/qt/paymentserver.cpp#L584

I agree that this should be made more clear in my BIP though, I'll clean up
the language.

On Tue, Jan 26, 2016 at 6:37 AM, Andreas Schildbach via bitcoin-dev <

Post by Andreas Schildbach via bitcoin-dev
Discussion about reasoning of OP_RETURN aside, I think your
specification needs to be more precise/less ambiguous.
"one or more outputs where Bitcoins are to be sent. If the sum of
outputs.amount is zero, the customer will be asked how much to pay, and
the bitcoin client may choose any or all of the Outputs (if there are
more than one) for payment. If the sum of outputs.amount is non-zero,
then the customer will be asked to pay the sum, and the payment shall be
split among the Outputs with non-zero amounts (if there are more than
one; Outputs with zero amounts shall be ignored)."
As you can see, zero outputs are not ignored at all. They are used as an
indication to allow the user to set an amount. So if you'd come up with
one zero-amount OP_RETURN output, it would pop up an amount dialog.
Certainly not what you want, right?

Post by Toby Padilla via bitcoin-dev
It looks like my draft hasn't been approved by the mailing list so if
https://gist.github.com/toby/9e71811d387923a71a53
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.

Post by Toby Padilla via bitcoin-dev
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.
This is a bad idea. OP_RETURN attachments are tolerated (not encouraged!) for
the sake of the network, since the spam cannot be outright stopped. If it
could be outright stopped, it would not be reasonable to allow OP_RETURN. When
it comes to the payment protocol, however, changing the current behaviour has
literally no benefit to the network at all, and the changes proposed herein
are clearly detrimental since it would both encourage spam, and potentially
make users unwilling (maybe even unaware) participants in it. For

these

Post by Toby Padilla via bitcoin-dev
reasons, *I highly advise against publishing or implementing this BIP, even if
the later mentioned issues are fixed.*

An example might be a merchant that adds the hash of a plain text

invoice

Post by Toby Padilla via bitcoin-dev

to the checkout transaction. The merchant could construct the
PaymentRequest with the invoice hash in an OP_RETURN and pass it

to the

Post by Toby Padilla via bitcoin-dev

customer's wallet. The wallet could then submit the transaction,

including

Post by Toby Padilla via bitcoin-dev

the invoice hash from the PaymentRequest. The wallet will have

encoded a

Post by Toby Padilla via bitcoin-dev

proof of purchase to the blockchain without the wallet developer

having to

Post by Toby Padilla via bitcoin-dev

coordinate with the merchant software or add features beyond this

BIP.

Post by Toby Padilla via bitcoin-dev
Such a "proof" is useless without wallet support. Even if you argue it could
be implemented later on, it stands to reason that a scammer will simply encode
garbage if the wallet is not checking the proof-of-purchase upfront. To check
it, you would also need further protocol extensions which are not included in
this draft.

Merchants and Bitcoin application developers benefit from this BIP

because

Post by Toby Padilla via bitcoin-dev

they can now construct transactions that include OP_RETURN data in

a

Post by Toby Padilla via bitcoin-dev

keyless environment. Again, prior to this BIP, transactions that

used

Post by Toby Padilla via bitcoin-dev

OP_RETURN (with zero value) needed to be constructed and executed

in the

Post by Toby Padilla via bitcoin-dev

same software. By separating the two concerns, this BIP allows

merchant

Post by Toby Padilla via bitcoin-dev

software to create transactions with OP_RETURN metadata on a

server without

Post by Toby Padilla via bitcoin-dev

storing public or private Bitcoin keys. This greatly enhances

security

Post by Toby Padilla via bitcoin-dev

where OP_RETURN applications currently need access to a private

key to sign

Post by Toby Padilla via bitcoin-dev

transactions.

I don't see how this has any relevance to keys at all...

## Specification
The specification for this BIP is straightforward. BIP70 should be

fully

Post by Toby Padilla via bitcoin-dev

1. Outputs where the script is an OP_RETURN and the value is zero

should be

Post by Toby Padilla via bitcoin-dev

accepted by the wallet.
2. Outputs where the script is an OP_RETURN and the value is

greater than

Post by Toby Padilla via bitcoin-dev

zero should be rejected.
This is a change from the BIP70 requirement that all zero value

outputs be

Post by Toby Padilla via bitcoin-dev

ignored.

This does not appear to be backward nor even forward compatible. Old clients
will continue to use the previous behaviour and transparently omit

any

Post by Toby Padilla via bitcoin-dev
commitments. New clients on the other hand will fail to include commitments
produced by old servers. In other words, it is impossible to produce software
compatible with both BIP 70 and this draft, and implementing either would
result in severe consequences.

As it exists today, BIP70 allows for OP_RETURN data storage at the

expense

Post by Toby Padilla via bitcoin-dev

of permanently destroyed Bitcoin.

It is better for the spammers to lose burned bitcoins, than have a way to
avoid them.
Luke
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Peter Todd via bitcoin-dev]

Post by Toby Padilla via bitcoin-dev
The wording is a little strange and I think it *should* work as you state,
but Bitcoin Core will actually reject any output that has zero value (even
a single OP_RETURN output -- I just tested again to make sure).
https://github.com/bitcoin/bitcoin/blob/master/src/qt/paymentserver.cpp#L584
I agree that this should be made more clear in my BIP though, I'll clean up
the language.

Note that because the dust limit is ignored completely for OP_RETURN
outputs, you can work around this by setting the OP_RETURN outputs to 1
satoshi instead.