1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
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 F2CD01013
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jan 2016 03:07:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com
[209.85.213.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 57DB163
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jan 2016 03:07:41 +0000 (UTC)
Received: by mail-vk0-f53.google.com with SMTP id k1so84959188vkb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Jan 2016 19:07:41 -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=oBJw7CL3H9zML32Z0iEgEc3V4kmQpGMUfC9DZNd0tQA=;
b=xbpzF/lgNul9BzuXW+Y/z+L7mWlCrCrE93zqiQIWaxJg6pfy+lSTEEqyUFNS+14gVF
1+Q06kxqnVBBqtnmLOX0FGJaZgSSuXOAV7WabglCnaN2eB4jD/S4fDXwcGN5/ErKV+2L
ltWQmNf7ZiT+nNrypZCb0bMpYHUV9ch1d9ECDqAkbQRvLRGIZR30y3ngZ36270XOtvD7
jrlhPs3ysWpYcqc/ZksGtoTNb3Ue6q9tFC82QwGlgrdy3QI/YID7ceIT/DocrnJTy3HQ
H1c+kfIFu5ftyFoAWuM0XjC8Wo1DRRac11nZcB08zarTkRpZeZUsD8rCrZkcXpSPVm1b
5Dnw==
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=oBJw7CL3H9zML32Z0iEgEc3V4kmQpGMUfC9DZNd0tQA=;
b=bMF5Jp8UKjfm0J/n3l63SPNYpMugD0vVpk635bT4M4v0qNTt1C77ZdCT17W0N2ia8B
OE3aKhUi6syg5PJF3omsB/uFqethKuXqQE0ai4+w9RagzCaB6QXY9afnPYiHPMWhjNZZ
Q6br/ohLGJc7HCz/q+8OYoAsqQ4NXXZ0Ac3CFBNqizuDR3XguE6yUwyKUW70PkfmMedN
FcAwtRjULYA0kwT3xULFzDVWHv3dy8ezRRknWncJfrb9Ay/SJimyiNZvWsvr1q16krFW
73Hwx+HqjWSRoP5uMgEte2TIyVeACJZj2QFlvdL5+4r/lLMNkotMzgcHAotTIFAg4jK3
SiDQ==
X-Gm-Message-State: AG10YOQgiXi5S1KHPiTPSxwi7gHsmm/E3CCyQav6DJzEukFv6C03ZAiIWJRh6EnwhDWshsUZbIcbE6KFQqhgbQ==
MIME-Version: 1.0
X-Received: by 10.31.56.202 with SMTP id f193mr13209576vka.134.1453777660348;
Mon, 25 Jan 2016 19:07:40 -0800 (PST)
Received: by 10.31.96.85 with HTTP; Mon, 25 Jan 2016 19:07:40 -0800 (PST)
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
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 03:14:55 +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 03:07:42 -0000
--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">>=C2=A0<span style=3D"font-size:12.8px">I don'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'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">>=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's wallet and you can construct transactions on another machin=
e (thus not needing a key during construction). Right now there'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>
> > As I explained, none of those reasons apply to PaymentRequests.<b=
r>
><br>
> As they exist today PaymentRequests allow for essentially the same typ=
es of<br>
> transactions as non-PaymentRequest based transactions with the limitat=
ion<br>
> that OP_RETURN values must be greater. In that sense they're basic=
ally a<br>
> pre-OP_RETURN environment. OP_RETURN serves a purpose and it can't=
be used<br>
> with PaymentRequest transactions.<br>
<br>
</span>OP_RETURN can be used, but you need to burn coins. I don't see a=
ny benefit to<br>
changing that. It is better that coins are burned.<br>
<span class=3D""><br>
> > I have no idea what you are trying to say here.<br>
><br>
> I think if you think through how you would create an OP_RETURN transac=
tion<br>
> today without this BIP you'll see you need a key at some point if =
you want<br>
> 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--
|
