public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Toby Padilla <tobypadilla@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol
Date: Tue, 26 Jan 2016 09:41:01 -0800	[thread overview]
Message-ID: <CAGcHOzyQ4d_oPey=7bMcm8mA4QWAcBrkCu3CY=_BVjrbbd03Sw@mail.gmail.com> (raw)
In-Reply-To: <n880a6$i5v$1@ger.gmane.org>

[-- 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 --]

  reply	other threads:[~2016-01-26 17:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-26  1:02 [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol Toby Padilla
2016-01-26  2:24 ` Luke Dashjr
2016-01-26  2:54   ` Toby Padilla
2016-01-26  2:56     ` Luke Dashjr
2016-01-26  3:01       ` Toby Padilla
2016-01-26  3:04         ` Luke Dashjr
2016-01-26  3:07           ` Toby Padilla
2016-01-26  3:12             ` Luke Dashjr
2016-01-26  3:17               ` Toby Padilla
2016-01-26  3:23                 ` Luke Dashjr
2016-01-26  3:30                   ` Toby Padilla
2016-01-26 16:19                     ` Thomas Kerin
2016-01-26 17:44                       ` Toby Padilla
2016-02-02 17:03                         ` Peter Todd
2016-02-02 17:16                           ` Pieter Wuille
2016-02-02 17:27                             ` Toby Padilla
2016-02-02 17:38                               ` Peter Todd
2016-02-02 17:41                                 ` Toby Padilla
2016-02-02 19:12                                   ` Peter Todd
2016-02-02 19:22                                     ` Toby Padilla
2016-02-02 19:14                             ` Luke Dashjr
2016-01-26 14:37     ` Andreas Schildbach
2016-01-26 17:41       ` Toby Padilla [this message]
2016-02-02 17:07         ` Peter Todd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGcHOzyQ4d_oPey=7bMcm8mA4QWAcBrkCu3CY=_BVjrbbd03Sw@mail.gmail.com' \
    --to=tobypadilla@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox