Payments: Allow zero value OP_RETURN in PaymentRequests #7376

PaymentRequests currently support any valid script serialized in the PaymentDetails protocol buffer. Zero value outputs are ignored and not included in the transaction. This means that OP_RETURN scripts are currently supported but they must have a > zero value, effectively destroying the value assigned to that output.

This patch allows zero value PaymentRequest outputs ONLY if the script is an OP_RETURN. It also requires that all OP_RETURN outputs be zero value to address the value destruction issue.

This needs a BIP, especially for a Motivation section... ie, what's the use case?

I was wondering if I needed to add one :)

I address the use case in a message I sent to the dev list:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011874.html

I can certainly go into more detail in a BIP draft if that would be helpful.

I was hoping it wouldn't need a BIP (although I can't see it hurting) since allowing non-zero OP_RETURNs seems like a bug that's worth fixing ASAP. For example, here is a transaction that was created with a PaymentRequest where value was forever lost:

https://blockchain.info/tx/5d5ec1c999022ae16a728ed4abfc8882d067b519e28eac51baecbf2b8b49b860

Hi all. I've been working on a new publication platform based on Bitcoin

So it's a spamming service. Not something we'd want to support.

I was hoping it wouldn't need a BIP (although I can't see it hurting) since allowing non-zero OP_RETURNs seems like a bug that's worth fixing ASAP.

Allowing non-zero outputs would be a bug as it stands, since BIP 70 explicitly states: "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)."

So it's a spamming service. Not something we'd want to support.

It's an exploration into grouping transactions by OP_RETURN value, not meant for spamming :) Regardless, there are other use cases that would benefit from this. Essentially anything that uses OP_RETURN is currently incompatible with Payments. I'm happy to write up a BIP if this has any chance of going through.

Allowing non-zero outputs would be a bug as it stands, since BIP 70 explicitly states: "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)."

It currently works as specified. If you give an OP_RETURN a > dust value, Bitcoin Core will process it (how I created that transaction on blockinfo). I can't imagine why this would be supported since it destroys value.

The two potential fixes are:

1. Allow only zero value OP_RETURN in PaymentDetails as I suggest.
2. Don't allow any OP_RETURN scripts.

Right now we have a situation where only OP_RETURNs with value are supported which seems like the worst of all options.

For example, here is a PaymentRequest with a 6000 Satoshi value on an OP_RETURN output:

bitcoin:?r=http%3A%2F%2Fkey.run%2Fkr%2Fmessage%2Fpayreq%3Fmessage%3Dd295285dd45fd0c9a0e86095d8fe31ddb6a07dcb

Bitcoin Core will currently open and process this transaction resulting in 6000 lost Satoshi.

I think it makes sense to support OP_RETURN with zero value outputs. We've had the spamming discussion multiple times, at least OP_RETURN is the least harmful (from the point of the UTXO set) of doing so. That's the reason it was added to IsStandard in the first place. It's perfectly possible to spam in other ways, but at least these outputs can be pruned.

But I do agree that it needs a BIP. Bitcoin Core is not the only software implementing PaymentRequests, so a change in this functionality needs to be signaled to a wider audience.

@laanwj There's quite a difference between passively tolerating some spam to avoid unintentionally tolerating worse spam, and actively enabling it. In this case, there is no worse-spam being prevented at all, and the user may not even be aware he is participating in spam!

@laanwj that sounds great! I will write up a BIP draft. @luke-jr hopefully the BIP will help. There are definitely non-spam applications for this. Also, this fixes non-zero value OP_RETURNs which are currently allowed. I doubt the user ever wants to destroy Bitcoin but BIP-70 allows for that.

and the user may not even be aware he is participating in spam!

Right - the software should at least show that it is happening, so that it doesn't go behind the user's back.

Right - the software should at least show that it is happening, so that it doesn't go behind the user's back.

I totally agree here as well. The OP_RETURN data should be displayed to the user when present. I would propose to do that in a second pull request though. This patch will plug the value destruction hole and introduce the BIP (where I was planning on recommending the OP_RETURN data be displayed in the UI when there is a UI).

There could then be a second PR for any UI work if this one gets merged. What do you think?

I still think it should be rejected in every way possible. At least without an established legitimate use case. (Also note OP_RETURN data especially should never be ASCII content... so what exactly do you plan to display to the user?)

@luke-jr here's an example of why you might want an ASCII OP_RETURN:

Imagine including a hash of the invoice or contract that went along with the transaction into the OP_RETURN of that transaction. It would be a way to verify and prove what that transaction was for.

There are many potential use cases for OP_RETURN, some of which are yet to be invented and will help Bitcoin. Since it's already been decided that OP_RETURN is standard it seems odd to not offer support for it (or offer broken support as BIP-70 currently does). I had honestly thought this discussion had already been settled.

@toby So you'd display the preimage of the OP_RETURN'd hash?

Note also, that it is possible to include the hash in the signature itself, without increasing the data required, something I hope to see in future versions (mainly waiting on libsecp256k1 to add the special sign function needed).

Since it's already been decided that OP_RETURN is standard it seems odd to not offer support for it

OP_RETURN is not standard in any way. It is simply tolerated by Core's IsStandard function.

So you'd display the preimage of the OP_RETURN'd hash?

Since Bitcoin Core is a "generic" client I would just show the hash itself, much like how blockchain.info renders OP_RETURN values. I imagine more specialized clients could also display the preimage of whatever made sense in their domain.

OP_RETURN is not standard in any way. It is simply tolerated by Core's IsStandard function.

I would say in an open source, p2p project that's as standard as you can get :) Seriously though, I thought the whole point of OP_RETURN is that it's provably unspendable and can be trimmed from the UTXO pool. Additionally if someone wants to "spam" (certainly not the only use of OP_RETURN), they still have to pay transaction fees. I think all of these arguments were made when OP_RETURN was introduced.

Again, there is a significant difference in relaying them when there is no way to effectively filter them, vs generating them ourselves in a situation where there is no way presently to avoid destroying dust. Adding support for 0-value OP_RETURN in payment requests literally has no benefit, and (at least lacking a legitimate use case) encourages abuse.

(and when/if there is a legitimate use case, it makes more sense to figure out if there's a specialised way to add that only without enabling abuse)

Adding support for 0-value OP_RETURN in payment requests literally has no benefit

So you're fine supporting OP_RETURN now because it doesn't work with zero value and you think that will discourage people from using it? It seems better to take away support altogether than offer broken support.

encourages abuse.

I'm not comfortable classifying other people's use cases as "abuse". As @laanwj said, there are other ways to encode data on the blockchain that are far less elegant. People will use them. OP_RETURN was a good solution for all parties involved.

So you're fine supporting OP_RETURN now because it doesn't work with zero value and you think that will discourage people from using it? It seems better to take away support altogether than offer broken support.

If OP_RETURN doesn't work, they could just encode the spam in p2pkh. But in this case, they can't, because of the dust rule. (Actually, maybe this is also true of the relayed transactions?? Hmm)

I'm not comfortable classifying other people's use cases as "abuse".

Bitcoin cannot possibly work without such a classification.

As @laanwj said, there are other ways to encode data on the blockchain that are far less elegant. People will use them.

Not using payment protocol, there aren't...?

OP_RETURN was a way to allow people to store data in the chain that did not hurt as much as other mechanisms. I wish we could have done it in a way that didn't make it look like it was encouraged behaviour.

Anyway, reality is that it exists now, and without it, abuse woukd be much worse.

I'd like to understand your use case, though.

@sipa my particular use case was to use the OP_RETURN for voting. On http://key.run I'm aggregating transactions sent to a particular address based on OP_RETURN value then displaying the OP_RETURNs that got the most Bitcoin sent to them.

I probably looks like spam because I haven't built anything useful with it yet and the amounts are super low because I've been testing with it. You could imagine real value flowing through a system like this though.

I don't think this is the only use case for OP_RETURN but it's the one I have right now. In general it seems like a great way (at the expense of a prunable 40 bytes) to encourage emergent behavior within Bitcoin. I imagine any killer consumer app based on Bitcoin will be leveraging OP_RETURN. @luke-jr did you open the PaymentRequest I linked to up thread? Today you can "spam" the block chain with OP_RETURN values using the payment protocol. All my change does it make sure value isn't lost in the process.

My point is that it is better to require the value be lost in the process, in this scenario.

My point is that it is better to require the value be lost in the process, in this scenario.

I appreciate your sentiment and motivation but I strongly disagree. Features that exist need to be properly supported. It's not good to offer broken support just to discourage use, it would be far better to not support OP_RETURN at all.

You're missing the point. OP_RETURN is not supported for the sake of people who wish to spam. It is tolerated for the sake of people harmed by said spam. Making it cheaper increases the harm, so it goes against the purpose of tolerating OP_RETURN.

@luke-jr I understand your point but I think you're not quite seeing what is going to motivate people to use this anyway...

OP_RETURN was created because people were encoding data on the blockchain using ad hoc methods that weren't efficient. Even though some people (like yourself) would rather no data be encoded on the blockchain, OP_RETURN gave people a less damaging way to do what they were going to do anyway.

Now with zero value payments the situation is the same. I could shutdown key.run and call it a day since destroying value is suboptimal. Or I could just burn 6,000 satoshi per transaction and keep moving forward.

Also, from a pure design perspective I would say it's definitely a smell to have such broken functionality live.

I see no benefit to the users harmed, to avoid the burning of 6,000sat/tx.

There shouldn't even be a way to burn Bitcoin. It's bad for everyone.

You can't prevent voluntary burning. Someone can always send to a non-existing address.

@sipa correct, but this is an additional way to burn value that can be prevented and even worse, value must be burned to fulfill a use case.

Not using payment protocol, there aren't...?

Sure, by voluntary burning to a non-existent address that encodes data.

I've written a BIP draft.

Live copy: https://gist.github.com/toby/9e71811d387923a71a53 Mailing list: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012283.html

NACK. 6,000sat/tx is even too cheap to do what you want. If I were you I would encourage your users to burn even more. You said "(...) It's bad for everyone." - Actually, it is the opposite: burn bitcoin is good for everyone as Satoshi said: "Lost coins only make everyone else’s coins worth slightly more. Think of it as a donation to everyone."

@felipelalli I believe you should provide a reason for your NACK. As it stands I don't understand why you're objecting.

I've updated the BIP specification section with feedback from the list re: multiple outputs that sum to zero value:

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

This pull request doesn't address this case since Core doesn't fully implement BIP70 when there are multiple zero value outputs. Core currently alerts the user saying that values must be greater than zero instead of prompting for an amount to distribute over all outputs.

I would make the case that update should be addressed in a separate PR.

NACK: a payment request is a request for a payment. requesting someone to send 0 money doesn't make sense.

OP_RETURN helps for some cases where you need messages to travel along with transactions, where no other communication channel is available. However, in the specific case of the Payment Protocol, such a channel already exists (you're directly communicating with the receiver, so why not use that instead of burdening the whole world with it?).

@sipa as proposed in the BIP you would need to include more than just the OP_RETURN and the end value of the transaction will have to be greater than zero so I think it is a request for payment in that sense.

EDIT: I made this more clear in the BIP specification:

Payment requests also must contain at least one payable output (i.e. no payment requests with just a zero value OP_RETURN).

I see OP_RETURN as a way for metadata to stay with a transaction forever. That's why it's important to put it on the blockchain. As a merchant, you could message your user outside of the protocol but the message would be temporal, would rely on a great deal of trust that the values stick around and never change and generally encourage centralized behavior (to broadcast and store the messages). By allowing OP_RETURN you open the door for distributed applications that can't be built by removing the data from the Bitcoin protocol and handling it on another channel.

To go back to my particular use case, you could fire up your own copy of key.run on your machine right now and the db would be reconstituted from the blockchain. I could be hit by a bus and the service would continue uninterrupted (if anyone was using it :).

@sipa Transaction metadata can be used to create an unambiguous link between the payment and the invoice (PaymentRequest).

PaymentRequest is signed by the merchant, but multiple conflicting signed PaymentRequests can exist.

Non-repudiation properties can be strengthened through secure timestamping, and here we have a timestamping mechanism which requires less than 13% space overhead and requires no 3rd party services. So why not allow it?

I've updated the PR and BIP to support all values (zero or greater) for OP_RETURN. Multiple people have pointed out that it would be best for backward compatibility, and I agree. I've also been making the case that the Payment protocol should work in a manner consistent with non-Payment protocol transactions and this change is in line with that.

It's still not backward compatible, because you need old BIP70 clients to reject your new format.

Regardless of whether you address that problem or not, I maintain a NACK on supporting such a BIP in Core.

@luke-jr good point, I'll address that in the BIP.

What is the state of this?

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

and the commits need a squash?

I maintain that this BIP is a bad idea and should not be supported.

Here we have a timestamping mechanism which requires no 3rd party services.

Can one of the admins verify this patch?

So the BIP is there; looks like this needs rebase, and update of doc/bips.md

The fact that he's made a BIP does not change the fact that it should not be supported.

Personally I don't see any harm in supporting this. OP_RETURN with zero-value outputs is standard, after all, so why should users be prevented from sending them through the payment protocol?

Then again, closing this, this is probably not worth the fight...