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

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

> I don't see any benefit to
changing that. It is better that coins are burned.

I think this is our fundamental disagreement. People will burn coins to
encode data, why allow this when there's a better alternative?

> You *always* need a key, to redeem inputs... regardless of values.

Correct, but with BIP70 that key is in the user's wallet and you can
construct transactions on another machine (thus not needing a key during
construction). Right now there's no way to do the transaction construction
on another machine with zero value OP_RETURNs.

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

> On Tuesday, January 26, 2016 3:01:13 AM Toby Padilla wrote:
> > > 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.
>
> OP_RETURN can be used, but you need to burn coins. I don't see any benefit
> to
> changing that. It is better that coins are burned.
>
> > > 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.
>
> You *always* need a key, to redeem inputs... regardless of values.
>
> Luke
>

--001a114409de0710c5052a33fd25
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">I don&#39;t see=
 any benefit to</span><br style=3D"font-size:12.8px"><span style=3D"font-si=
ze:12.8px">changing that. It is better that coins are burned.</span><div><s=
pan style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-si=
ze:12.8px">I think this is our=C2=A0fundamental=C2=A0disagreement. People w=
ill burn coins to encode data, why allow this when there&#39;s a better alt=
ernative?</span></div><div><span style=3D"font-size:12.8px"><br></span></di=
v><div><span style=3D"font-size:12.8px">&gt;=C2=A0</span><span style=3D"fon=
t-size:12.8px">You *always* need a key, to redeem inputs... regardless of v=
alues.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><=
div><span style=3D"font-size:12.8px">Correct, but with BIP70 that key is in=
 the user&#39;s wallet and you can construct transactions on another machin=
e (thus not needing a key during construction). Right now there&#39;s no wa=
y to do the transaction construction on another machine with zero value OP_=
RETURNs.</span></div></div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Mon, Jan 25, 2016 at 7:04 PM, Luke Dashjr <span dir=3D"ltr">&l=
t;<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"><span class=3D"">On Tue=
sday, January 26, 2016 3:01:13 AM Toby Padilla wrote:<br>
&gt; &gt; As I explained, none of those reasons apply to PaymentRequests.<b=
r>
&gt;<br>
&gt; As they exist today PaymentRequests allow for essentially the same typ=
es of<br>
&gt; transactions as non-PaymentRequest based transactions with the limitat=
ion<br>
&gt; that OP_RETURN values must be greater. In that sense they&#39;re basic=
ally a<br>
&gt; pre-OP_RETURN environment. OP_RETURN serves a purpose and it can&#39;t=
 be used<br>
&gt; with PaymentRequest transactions.<br>
<br>
</span>OP_RETURN can be used, but you need to burn coins. I don&#39;t see a=
ny benefit to<br>
changing that. It is better that coins are burned.<br>
<span class=3D""><br>
&gt; &gt; I have no idea what you are trying to say here.<br>
&gt;<br>
&gt; I think if you think through how you would create an OP_RETURN transac=
tion<br>
&gt; today without this BIP you&#39;ll see you need a key at some point if =
you want<br>
&gt; a zero value.<br>
<br>
</span>You *always* need a key, to redeem inputs... regardless of values.<b=
r>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Luke<br>
</font></span></blockquote></div><br></div>

--001a114409de0710c5052a33fd25--