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

[Toby Padilla <tobypadilla@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6954 bytes --]

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 <luke@dashjr.org
> > <mailto:luke@dashjr.org>> 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
>

[-- Attachment #2: Type: text/html, Size: 9290 bytes --]