MIME-Version: 1.0
In-Reply-To: <201601260256.55378.luke@dashjr.org>
References: <CAGcHOzzde_T3xJwJL2Ehyw7U1FgxEEBJR30VBLdSZMj=W49hSg@mail.gmail.com>
	<201601260224.16917.luke@dashjr.org>
	<CAGcHOzziBsF6DhX=TrgDJdYiOLHT-zwwX3FAUUkvfi1_4OmPKw@mail.gmail.com>
	<201601260256.55378.luke@dashjr.org>
Date: Mon, 25 Jan 2016 19:01:13 -0800
Message-ID: <CAGcHOzwpcCdgJ1VcBrnZ+D8dfZFBJYLs_A9Z4Nz-FJokdkcuyQ@mail.gmail.com>
From: Toby Padilla <tobypadilla@gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=001a1143fa4cf5937b052a33e51c
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] [BIP Draft] Allow zero value OP_RETURN in Payment
	Protocol
Precedence: list

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

> As I explained, none of those reasons apply to PaymentRequests.

As they exist today PaymentRequests allow for essentially the same types of
transactions as non-PaymentRequest based transactions with the limitation
that OP_RETURN values must be greater. In that sense they're basically a
pre-OP_RETURN environment. OP_RETURN serves a purpose and it can't be used
with PaymentRequest transactions.

> I have no idea what you are trying to say here.

I think if you think through how you would create an OP_RETURN transaction
today without this BIP you'll see you need a key at some point if you want
a zero value.

On Mon, Jan 25, 2016 at 6:56 PM, Luke Dashjr <luke@dashjr.org> wrote:

> On Tuesday, January 26, 2016 2:54:16 AM Toby Padilla wrote:
> > 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 I explained, none of those reasons apply to 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.
>
> I have no idea what you are trying to say here.
>
> Luke
>

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

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"font-size:12.8px">As I explained,=
 none of those reasons apply to PaymentRequests.</span><div><span style=3D"=
font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">As=
 they exist today PaymentRequests allow for essentially the same types of t=
ransactions as non-PaymentRequest based transactions with the limitation th=
at OP_RETURN values must be greater. In that sense they&#39;re basically a =
pre-OP_RETURN environment. OP_RETURN serves a purpose and it can&#39;t be u=
sed with PaymentRequest transactions.</span></div><div><span style=3D"font-=
size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">&gt; </=
span><span style=3D"font-size:12.8px">I have no idea what you are trying to=
 say here.</span></div><div><span style=3D"font-size:12.8px"><br></span></d=
iv><div><span style=3D"font-size:12.8px">I think if you think through how y=
ou would create an OP_RETURN transaction today without this BIP you&#39;ll =
see you need a key at some point if you want a zero value.</span></div></di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Jan 25,=
 2016 at 6:56 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><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><span class=3D"">On Tuesday, January 26, 2016 2:=
54:16 AM Toby Padilla wrote:<br>
&gt; Luke - As stated in the Github thread, I totally understand where you&=
#39;re<br>
&gt; coming from but the fact is people *will* encode data on the blockchai=
n<br>
&gt; using worse methods. For all of the reasons that OP_RETURN was a good =
idea<br>
&gt; in the first place, it&#39;s a good idea to support it in PaymentReque=
sts.<br>
<br>
</span>As I explained, none of those reasons apply to PaymentRequests.<br>
<span class=3D""><br>
&gt; As for keyless - there&#39;s no way (that I know of) to construct a tr=
ansaction<br>
&gt; with a zero value OP_RETURN in an environment without keys since the<b=
r>
&gt; Payment Protocol is what defines the method for getting a transaction =
from<br>
&gt; a server to a wallet. You can make a custom transaction and execute it=
 in<br>
&gt; the same application but without Payments there&#39;s no way to move<b=
r>
&gt; transactions between two applications. You need to build the transacti=
on<br>
&gt; where you execute it and thus need a key.<br>
<br>
</span>I have no idea what you are trying to say here.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Luke<br>
</font></span></blockquote></div><br></div>

--001a1143fa4cf5937b052a33e51c--