<div dir="ltr"><span style="font-size:12.8px">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).</span><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Here's the blocking code:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><a href="https://github.com/bitcoin/bitcoin/blob/master/src/qt/paymentserver.cpp#L584" target="_blank">https://github.com/bitcoin/bitcoin/blob/master/src/qt/paymentserver.cpp#L584</a><br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I agree that this should be made more clear in my BIP though, I'll clean up the language.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 26, 2016 at 6:37 AM, Andreas Schildbach via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Discussion about reasoning of OP_RETURN aside, I think your<br>
specification needs to be more precise/less ambiguous.<br>
<br>
Here is what BIP70 currently says about PaymentDetails.outputs:<br>
<br>
"one or more outputs where Bitcoins are to be sent. If the sum of<br>
outputs.amount is zero, the customer will be asked how much to pay, and<br>
the bitcoin client may choose any or all of the Outputs (if there are<br>
more than one) for payment. If the sum of outputs.amount is non-zero,<br>
then the customer will be asked to pay the sum, and the payment shall be<br>
split among the Outputs with non-zero amounts (if there are more than<br>
one; Outputs with zero amounts shall be ignored)."<br>
<br>
As you can see, zero outputs are not ignored at all. They are used as an<br>
indication to allow the user to set an amount. So if you'd come up with<br>
one zero-amount OP_RETURN output, it would pop up an amount dialog.<br>
Certainly not what you want, right?<br>
<span class=""><br>
<br>
On 01/26/2016 03:54 AM, Toby Padilla via bitcoin-dev wrote:<br>
> It looks like my draft hasn't been approved by the mailing list so if<br>
> anyone would like to read it it's also on Gist:<br>
><br>
> <a href="https://gist.github.com/toby/9e71811d387923a71a53" rel="noreferrer" target="_blank">https://gist.github.com/toby/9e71811d387923a71a53</a><br>
><br>
> Luke - As stated in the Github thread, I totally understand where you're<br>
> coming from but the fact is people *will* encode data on the blockchain<br>
> using worse methods. For all of the reasons that OP_RETURN was a good<br>
> idea in the first place, it's a good idea to support it in PaymentRequests.<br>
><br>
> As for keyless - there's no way (that I know of) to construct a<br>
> transaction with a zero value OP_RETURN in an environment without keys<br>
> since the Payment Protocol is what defines the method for getting a<br>
> transaction from a server to a wallet. You can make a custom transaction<br>
> and execute it in the same application but without Payments there's no<br>
> way to move transactions between two applications. You need to build the<br>
> transaction where you execute it and thus need a key.<br>
><br>
><br>
><br>
> On Mon, Jan 25, 2016 at 6:24 PM, Luke Dashjr <<a href="mailto:luke@dashjr.org">luke@dashjr.org</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:luke@dashjr.org">luke@dashjr.org</a>>> wrote:<br>
><br>
> This is a bad idea. OP_RETURN attachments are tolerated (not<br>
> encouraged!) for<br>
> the sake of the network, since the spam cannot be outright stopped.<br>
> If it<br>
> could be outright stopped, it would not be reasonable to allow<br>
> OP_RETURN. When<br>
> it comes to the payment protocol, however, changing the current<br>
> behaviour has<br>
> literally no benefit to the network at all, and the changes proposed<br>
> herein<br>
> are clearly detrimental since it would both encourage spam, and<br>
> potentially<br>
> make users unwilling (maybe even unaware) participants in it. For these<br>
> reasons, *I highly advise against publishing or implementing this<br>
> BIP, even if<br>
> the later mentioned issues are fixed.*<br>
><br>
> On Tuesday, January 26, 2016 1:02:44 AM Toby Padilla wrote:<br>
> > An example might be a merchant that adds the hash of a plain text invoice<br>
> > to the checkout transaction. The merchant could construct the<br>
> > PaymentRequest with the invoice hash in an OP_RETURN and pass it to the<br>
> > customer's wallet. The wallet could then submit the transaction, including<br>
> > the invoice hash from the PaymentRequest. The wallet will have encoded a<br>
> > proof of purchase to the blockchain without the wallet developer having to<br>
> > coordinate with the merchant software or add features beyond this BIP.<br>
><br>
> Such a "proof" is useless without wallet support. Even if you argue<br>
> it could<br>
> be implemented later on, it stands to reason that a scammer will<br>
> simply encode<br>
> garbage if the wallet is not checking the proof-of-purchase upfront.<br>
> To check<br>
> it, you would also need further protocol extensions which are not<br>
> included in<br>
> this draft.<br>
><br>
> > Merchants and Bitcoin application developers benefit from this BIP because<br>
> > they can now construct transactions that include OP_RETURN data in a<br>
> > keyless environment. Again, prior to this BIP, transactions that used<br>
> > OP_RETURN (with zero value) needed to be constructed and executed in the<br>
> > same software. By separating the two concerns, this BIP allows merchant<br>
> > software to create transactions with OP_RETURN metadata on a server without<br>
> > storing public or private Bitcoin keys. This greatly enhances security<br>
> > where OP_RETURN applications currently need access to a private key to sign<br>
> > transactions.<br>
><br>
> I don't see how this has any relevance to keys at all...<br>
><br>
> > ## Specification<br>
> ><br>
> > The specification for this BIP is straightforward. BIP70 should be fully<br>
> > implemented with two changes:<br>
> ><br>
> > 1. Outputs where the script is an OP_RETURN and the value is zero should be<br>
> > accepted by the wallet.<br>
> > 2. Outputs where the script is an OP_RETURN and the value is greater than<br>
> > zero should be rejected.<br>
> ><br>
> > This is a change from the BIP70 requirement that all zero value outputs be<br>
> > ignored.<br>
><br>
> This does not appear to be backward nor even forward compatible. Old<br>
> clients<br>
> will continue to use the previous behaviour and transparently omit any<br>
> commitments. New clients on the other hand will fail to include<br>
> commitments<br>
> produced by old servers. In other words, it is impossible to produce<br>
> software<br>
> compatible with both BIP 70 and this draft, and implementing either<br>
> would<br>
> result in severe consequences.<br>
><br>
> > As it exists today, BIP70 allows for OP_RETURN data storage at the expense<br>
> > of permanently destroyed Bitcoin.<br>
><br>
> It is better for the spammers to lose burned bitcoins, than have a<br>
> way to<br>
> avoid them.<br>
><br>
> Luke<br>
><br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
><br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>