path: root/15/ced305bab7a133bb382b3f82e272d8a74893f4

Return-Path: <tobypadilla@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CC944D1F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 26 Jan 2016 02:54:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com
	[209.85.213.45])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9EA6563
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 26 Jan 2016 02:54:17 +0000 (UTC)
Received: by mail-vk0-f45.google.com with SMTP id e185so84694246vkb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 25 Jan 2016 18:54:17 -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:to
	:cc:content-type;
	bh=Y/UPTplrc18onJUam6UTe+o2Vmt27zMqa+YeRwAQ8nQ=;
	b=Jkme6gGvpOkXazwiE9FsjWOtWqO/Y1KFmqR+BjcgAy+ZyomUzCajsFAG/A6GtRpPG6
	0kTQGHduD+IX5a+/ljGwthM58NeqaT3aWP6o2C3YpJEuJn+4XYsfXevee951dWqMWwvs
	PU+v2r4TscdmQIvwlw9o1gPjtynenYB3QBHQPk3s7ac32Ej47A/T2TVnZIUfRyhY8gzn
	fxtdcoWXbyyBKdE5pouDVOMWhFT1wP/8OHkm6Q7GAis1oeKPozdx+muxbM22RizjgCnM
	QyQdEYq1AxjZHsB27GvjOiFBzsEWc/hX9tNGfC2ae/TzA16uCHD4lXuk6L4Oud0X9Iv6
	svlg==
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:to:cc:content-type;
	bh=Y/UPTplrc18onJUam6UTe+o2Vmt27zMqa+YeRwAQ8nQ=;
	b=BNCpdWcDe0tUCmxrsN7MV3psP55XVuZaJQGMiEjR6DUnjV7oIQdZ6z9I+FUv0qAiLJ
	nUXkQsXWEPOCsOAT/marglUGjIJ/W7zYcktCQ0UNMhmolZHocnGLFxyHW/NizK8DvTrq
	yCfUMdvV7ix+LgPIZh/nGRsT0/mjyNU3oiQIEygK5eoUqM4u8D2XE/pkdHg1v9iKgfXf
	3anX0zw+gclaQrjctyZx4bqcaAP6yIcEu1jUiY0baykoFxhyMwu9Q7y/osHcZZh6fULg
	wjjEiEnHCWQcjErEINmSe5qhqsG+OwkT04QGcgBQyk7ERZBkG/O4CbeYKa4xs5g/rBRc
	9A1g==
X-Gm-Message-State: AG10YOTo3ly7mLRLCrnpkjqPnTUw95HVCG215EWIAvH36/oyoRZhBFZZwoFc/sRuWBwE5ykEJs7XgXaS+RLsZQ==
MIME-Version: 1.0
X-Received: by 10.31.9.72 with SMTP id 69mr11474245vkj.126.1453776856642; Mon,
	25 Jan 2016 18:54:16 -0800 (PST)
Received: by 10.31.96.85 with HTTP; Mon, 25 Jan 2016 18:54:16 -0800 (PST)
In-Reply-To: <201601260224.16917.luke@dashjr.org>
References: <CAGcHOzzde_T3xJwJL2Ehyw7U1FgxEEBJR30VBLdSZMj=W49hSg@mail.gmail.com>
	<201601260224.16917.luke@dashjr.org>
Date: Mon, 25 Jan 2016 18:54:16 -0800
Message-ID: <CAGcHOzziBsF6DhX=TrgDJdYiOLHT-zwwX3FAUUkvfi1_4OmPKw@mail.gmail.com>
From: Toby Padilla <tobypadilla@gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=001a11440dfa1f7c1a052a33cd65
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW, URIBL_SBL autolearn=ham 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 02:56:25 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2016 02:54:18 -0000

--001a11440dfa1f7c1a052a33cd65
Content-Type: text/plain; charset=UTF-8

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

--001a11440dfa1f7c1a052a33cd65
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It looks like my draft hasn&#39;t been approved by the mai=
ling list so if anyone would like to read it it&#39;s also on Gist:<div><br=
></div><div><a href=3D"https://gist.github.com/toby/9e71811d387923a71a53">h=
ttps://gist.github.com/toby/9e71811d387923a71a53</a><br></div><div><br></di=
v><div>Luke - As stated in the Github thread, I totally understand where yo=
u&#39;re coming from but the fact is people *will* encode data on the block=
chain using worse methods. For all of the reasons that OP_RETURN was a good=
 idea in the first place, it&#39;s a good idea to support it in PaymentRequ=
ests.</div><div><br></div><div>As for keyless - there&#39;s no way (that I =
know of) to construct a transaction with a zero value OP_RETURN in an envir=
onment without keys since the Payment Protocol is what defines the method f=
or getting a transaction from a server to a wallet. You can make a custom t=
ransaction and execute it in the same application but without Payments ther=
e&#39;s no way to move transactions between two applications. You need to b=
uild the transaction where you execute it and thus need a key.</div><div><b=
r></div><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Mon, Jan 25, 2016 at 6:24 PM, Luke Dashjr <span dir=3D"ltr">=
&lt;<a href=3D"mailto:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is a bad idea. O=
P_RETURN attachments are tolerated (not encouraged!) for<br>
the sake of the network, since the spam cannot be outright stopped. If it<b=
r>
could be outright stopped, it would not be reasonable to allow OP_RETURN. W=
hen<br>
it comes to the payment protocol, however, changing the current behaviour h=
as<br>
literally no benefit to the network at all, and the changes proposed herein=
<br>
are clearly detrimental since it would both encourage spam, and potentially=
<br>
make users unwilling (maybe even unaware) participants in it. For these<br>
reasons, *I highly advise against publishing or implementing this BIP, even=
 if<br>
the later mentioned issues are fixed.*<br>
<span class=3D""><br>
On Tuesday, January 26, 2016 1:02:44 AM Toby Padilla wrote:<br>
&gt; An example might be a merchant that adds the hash of a plain text invo=
ice<br>
&gt; to the checkout transaction. The merchant could construct the<br>
&gt; PaymentRequest with the invoice hash in an OP_RETURN and pass it to th=
e<br>
&gt; customer&#39;s wallet. The wallet could then submit the transaction, i=
ncluding<br>
&gt; the invoice hash from the PaymentRequest. The wallet will have encoded=
 a<br>
&gt; proof of purchase to the blockchain without the wallet developer havin=
g to<br>
&gt; coordinate with the merchant software or add features beyond this BIP.=
<br>
<br>
</span>Such a &quot;proof&quot; is useless without wallet support. Even if =
you argue it could<br>
be implemented later on, it stands to reason that a scammer will simply enc=
ode<br>
garbage if the wallet is not checking the proof-of-purchase upfront. To che=
ck<br>
it, you would also need further protocol extensions which are not included =
in<br>
this draft.<br>
<span class=3D""><br>
&gt; Merchants and Bitcoin application developers benefit from this BIP bec=
ause<br>
&gt; they can now construct transactions that include OP_RETURN data in a<b=
r>
&gt; keyless environment. Again, prior to this BIP, transactions that used<=
br>
&gt; OP_RETURN (with zero value) needed to be constructed and executed in t=
he<br>
&gt; same software. By separating the two concerns, this BIP allows merchan=
t<br>
&gt; software to create transactions with OP_RETURN metadata on a server wi=
thout<br>
&gt; storing public or private Bitcoin keys. This greatly enhances security=
<br>
&gt; where OP_RETURN applications currently need access to a private key to=
 sign<br>
&gt; transactions.<br>
<br>
</span>I don&#39;t see how this has any relevance to keys at all...<br>
<span class=3D""><br>
&gt; ## Specification<br>
&gt;<br>
&gt; The specification for this BIP is straightforward. BIP70 should be ful=
ly<br>
&gt; implemented with two changes:<br>
&gt;<br>
&gt; 1. Outputs where the script is an OP_RETURN and the value is zero shou=
ld be<br>
&gt; accepted by the wallet.<br>
&gt; 2. Outputs where the script is an OP_RETURN and the value is greater t=
han<br>
&gt; zero should be rejected.<br>
&gt;<br>
&gt; This is a change from the BIP70 requirement that all zero value output=
s be<br>
&gt; ignored.<br>
<br>
</span>This does not appear to be backward nor even forward compatible. Old=
 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 commitments=
<br>
produced by old servers. In other words, it is impossible to produce softwa=
re<br>
compatible with both BIP 70 and this draft, and implementing either would<b=
r>
result in severe consequences.<br>
<span class=3D""><br>
&gt; As it exists today, BIP70 allows for OP_RETURN data storage at the exp=
ense<br>
&gt; of permanently destroyed Bitcoin.<br>
<br>
</span>It is better for the spammers to lose burned bitcoins, than have a w=
ay to<br>
avoid them.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Luke<br>
</font></span></blockquote></div><br></div>

--001a11440dfa1f7c1a052a33cd65--