From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5488DF3F for ; Tue, 26 Jan 2016 17:41:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com [209.85.213.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 30256129 for ; Tue, 26 Jan 2016 17:41:02 +0000 (UTC) Received: by mail-vk0-f49.google.com with SMTP id e64so96973432vkg.0 for ; Tue, 26 Jan 2016 09:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=sJlTzxfRZT6GseIjWSpRXcxnFEr+BIH/6MaK4RQTbCE=; b=lYkz98nkuZplx9IMpxa3TLjBVpqRouDCC9MKa+hHiJGa/5DgwL2ZDcOwnKCledbJUG TMqPTKGjOT/vjFfJzysTLasLkMIKpQqfWxEpUgHWUtI1ZVYW8NYbhIM0/3rOUSoRQZ0B 5O2V2xuG1c/SDQqJbyuidCVIlE6yNhduOQCi2eEv5+WbJIkXu6niUcMZLdw0AFaUPTPo VBpSd7fLLmBSLh+rMmUmNpDSTObMFIpTWC9G1ptkDHUtEOWhZbJyBSYrVLKK6JLciuyr 3ZiNXaO4jAuhfRgmjQ/p1fbrN1klgk9GA6jlGTNSMjbxzw/OXf7M2AneM8wiUd629dRR Q2aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc:content-type; bh=sJlTzxfRZT6GseIjWSpRXcxnFEr+BIH/6MaK4RQTbCE=; b=idjwq9JpocWLRhhv1vwwAIcNMAY8xnV3dOWIW48eJnmva4SePNHWV9FvhY5/vQr0E8 jh5ptd5G9k2yKFyq2ZRnHWya6ww2Gvl8weWhagQ43x2S9i6CNSPABjqpw8c+S/XOzxgO PkcJckFVyIAUospbPVOCuBs0Vw10yMMUPZPLA14cByox4MJkfMgjnHuTcOJTCo/eSeYm 4tPdH9xgskvQ45fZYTYEePepzL/0HxUyCPXCJHObzBoT9Gc7wJ5snKIYG8yiqpwdD5DI rWDrI7NaDDjTNDgIWUfDnE+Tir8gRaECl4mld8Z0krxHxzJS0eDSzQUjg3FLericujvK vYeQ== X-Gm-Message-State: AG10YOQLQrJ0HZ3XMXiiVqZ6QMf2fyPycV6VJg9E/Gjh3iXWPZC2p4rBpZIka8gF3deW+Hqx+BYafpobQ1YpGA== MIME-Version: 1.0 X-Received: by 10.31.52.73 with SMTP id b70mr13805984vka.16.1453830061258; Tue, 26 Jan 2016 09:41:01 -0800 (PST) Received: by 10.31.96.85 with HTTP; Tue, 26 Jan 2016 09:41:01 -0800 (PST) In-Reply-To: References: <201601260224.16917.luke@dashjr.org> Date: Tue, 26 Jan 2016 09:41:01 -0800 Message-ID: From: Toby Padilla Cc: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a1143fa4c5d7c6b052a40309a X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS, RCVD_IN_DNSWL_LOW,URIBL_SBL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 26 Jan 2016 17:43:31 +0000 Subject: Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment Protocol X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2016 17:41:03 -0000 --001a1143fa4c5d7c6b052a40309a Content-Type: text/plain; charset=UTF-8 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 > --001a1143fa4c5d7c6b052a40309a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The wording is a little s= trange and I think it *should* work as you state, but Bitcoin Core will act= ually 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:


I agree that this should b= e made more clear in my BIP though, I'll clean up the language.

On Tue, Jan 2= 6, 2016 at 6:37 AM, Andreas Schildbach via bitcoin-dev &l= t;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/9e71811d387923a71= a53
>
> Luke - As stated in the Github thread, I totally understand where you&= #39;re
> coming from but the fact is people *will* encode data on the blockchai= n
> 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 Payment= Requests.
>
> 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 transacti= on
> and execute it in the same application but without Payments there'= s no
> way to move transactions between two applications. You need to build t= he
> 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:
>
>=C2=A0 =C2=A0 =C2=A0This is a bad idea. OP_RETURN attachments are toler= ated (not
>=C2=A0 =C2=A0 =C2=A0encouraged!) for
>=C2=A0 =C2=A0 =C2=A0the sake of the network, since the spam cannot be o= utright stopped.
>=C2=A0 =C2=A0 =C2=A0If it
>=C2=A0 =C2=A0 =C2=A0could be outright stopped, it would not be reasonab= le to allow
>=C2=A0 =C2=A0 =C2=A0OP_RETURN. When
>=C2=A0 =C2=A0 =C2=A0it comes to the payment protocol, however, changing= the current
>=C2=A0 =C2=A0 =C2=A0behaviour has
>=C2=A0 =C2=A0 =C2=A0literally no benefit to the network at all, and the= changes proposed
>=C2=A0 =C2=A0 =C2=A0herein
>=C2=A0 =C2=A0 =C2=A0are clearly detrimental since it would both encoura= ge spam, and
>=C2=A0 =C2=A0 =C2=A0potentially
>=C2=A0 =C2=A0 =C2=A0make users unwilling (maybe even unaware) participa= nts in it. For these
>=C2=A0 =C2=A0 =C2=A0reasons, *I highly advise against publishing or imp= lementing this
>=C2=A0 =C2=A0 =C2=A0BIP, even if
>=C2=A0 =C2=A0 =C2=A0the later mentioned issues are fixed.*
>
>=C2=A0 =C2=A0 =C2=A0On Tuesday, January 26, 2016 1:02:44 AM Toby Padill= a wrote:
>=C2=A0 =C2=A0 =C2=A0> An example might be a merchant that adds the h= ash of a plain text invoice
>=C2=A0 =C2=A0 =C2=A0> to the checkout transaction. The merchant coul= d construct the
>=C2=A0 =C2=A0 =C2=A0> PaymentRequest with the invoice hash in an OP_= RETURN and pass it to the
>=C2=A0 =C2=A0 =C2=A0> customer's wallet. The wallet could then s= ubmit the transaction, including
>=C2=A0 =C2=A0 =C2=A0> the invoice hash from the PaymentRequest. The = wallet will have encoded a
>=C2=A0 =C2=A0 =C2=A0> proof of purchase to the blockchain without th= e wallet developer having to
>=C2=A0 =C2=A0 =C2=A0> coordinate with the merchant software or add f= eatures beyond this BIP.
>
>=C2=A0 =C2=A0 =C2=A0Such a "proof" is useless without wallet = support. Even if you argue
>=C2=A0 =C2=A0 =C2=A0it could
>=C2=A0 =C2=A0 =C2=A0be implemented later on, it stands to reason that a= scammer will
>=C2=A0 =C2=A0 =C2=A0simply encode
>=C2=A0 =C2=A0 =C2=A0garbage if the wallet is not checking the proof-of-= purchase upfront.
>=C2=A0 =C2=A0 =C2=A0To check
>=C2=A0 =C2=A0 =C2=A0it, you would also need further protocol extensions= which are not
>=C2=A0 =C2=A0 =C2=A0included in
>=C2=A0 =C2=A0 =C2=A0this draft.
>
>=C2=A0 =C2=A0 =C2=A0> Merchants and Bitcoin application developers b= enefit from this BIP because
>=C2=A0 =C2=A0 =C2=A0> they can now construct transactions that inclu= de OP_RETURN data in a
>=C2=A0 =C2=A0 =C2=A0> keyless environment. Again, prior to this BIP,= transactions that used
>=C2=A0 =C2=A0 =C2=A0> OP_RETURN (with zero value) needed to be const= ructed and executed in the
>=C2=A0 =C2=A0 =C2=A0> same software. By separating the two concerns,= this BIP allows merchant
>=C2=A0 =C2=A0 =C2=A0> software to create transactions with OP_RETURN= metadata on a server without
>=C2=A0 =C2=A0 =C2=A0> storing public or private Bitcoin keys. This g= reatly enhances security
>=C2=A0 =C2=A0 =C2=A0> where OP_RETURN applications currently need ac= cess to a private key to sign
>=C2=A0 =C2=A0 =C2=A0> transactions.
>
>=C2=A0 =C2=A0 =C2=A0I don't see how this has any relevance to keys = at all...
>
>=C2=A0 =C2=A0 =C2=A0> ## Specification
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The specification for this BIP is straightforw= ard. BIP70 should be fully
>=C2=A0 =C2=A0 =C2=A0> implemented with two changes:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> 1. Outputs where the script is an OP_RETURN an= d the value is zero should be
>=C2=A0 =C2=A0 =C2=A0> accepted by the wallet.
>=C2=A0 =C2=A0 =C2=A0> 2. Outputs where the script is an OP_RETURN an= d the value is greater than
>=C2=A0 =C2=A0 =C2=A0> zero should be rejected.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> This is a change from the BIP70 requirement th= at all zero value outputs be
>=C2=A0 =C2=A0 =C2=A0> ignored.
>
>=C2=A0 =C2=A0 =C2=A0This does not appear to be backward nor even forwar= d compatible. Old
>=C2=A0 =C2=A0 =C2=A0clients
>=C2=A0 =C2=A0 =C2=A0will continue to use the previous behaviour and tra= nsparently omit any
>=C2=A0 =C2=A0 =C2=A0commitments. New clients on the other hand will fai= l to include
>=C2=A0 =C2=A0 =C2=A0commitments
>=C2=A0 =C2=A0 =C2=A0produced by old servers. In other words, it is impo= ssible to produce
>=C2=A0 =C2=A0 =C2=A0software
>=C2=A0 =C2=A0 =C2=A0compatible with both BIP 70 and this draft, and imp= lementing either
>=C2=A0 =C2=A0 =C2=A0would
>=C2=A0 =C2=A0 =C2=A0result in severe consequences.
>
>=C2=A0 =C2=A0 =C2=A0> As it exists today, BIP70 allows for OP_RETURN= data storage at the expense
>=C2=A0 =C2=A0 =C2=A0> of permanently destroyed Bitcoin.
>
>=C2=A0 =C2=A0 =C2=A0It is better for the spammers to lose burned bitcoi= ns, than have a
>=C2=A0 =C2=A0 =C2=A0way to
>=C2=A0 =C2=A0 =C2=A0avoid them.
>
>=C2=A0 =C2=A0 =C2=A0Luke
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
>


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a1143fa4c5d7c6b052a40309a--