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 < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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? > > > On 01/26/2016 03:54 AM, Toby Padilla via bitcoin-dev wrote: > > 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. > > > > > > > > On Mon, Jan 25, 2016 at 6:24 PM, Luke Dashjr > > wrote: > > > > 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.* > > > > On Tuesday, January 26, 2016 1:02:44 AM Toby Padilla wrote: > > > 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 > > > implemented with two changes: > > > > > > 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 > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >