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
|
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 E23CCF8C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jan 2016 03:01:14 +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 3D89B63
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jan 2016 03:01:14 +0000 (UTC)
Received: by mail-vk0-f49.google.com with SMTP id n1so84823925vkb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 25 Jan 2016 19:01:14 -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=B47Zy3Kjx6cutT49iKWJ2dz705gEJNIQJcIWbv7iVds=;
b=PwbLPcQfRMHrZWylecRDRtLqclXDHkk80cA+gBXzeYGhj3jlvHXdZrzDa5htkQJNev
nAbHFZmlZLEGSlPJ2PlOmpD4zK1w6fh9AC9TNzG+n1V1gCcei0OvhiqDKM77L4UFr09Z
z8ncy9awTetuMFMjUya7lhV3e3kGq+hPB2kOZij60o75PtA0t+4NbVO1p10ZyPOxzp7f
GP7y5RosIvKnzenRLM5LVJyjvrFkaTHfTs7FA+TCw3oxd3315ItA/T1z+WkngZzoZXTA
mjELnm6BNb8p162aQsD90CjmjbtT5AdulRDFOAyNjLPc8j0DZSRnppFnhtwruZZpJ8yz
FW/w==
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=B47Zy3Kjx6cutT49iKWJ2dz705gEJNIQJcIWbv7iVds=;
b=Q22m/YSKPU3eQyF5o2gmxf+EgjQZHBwI8bPHlARlFuUkKso2ni8ldJDskEzuI02jNM
/4Vnixx6JN5flKpb+mfxpPnQbb24friN4CWKQ+E7kLNguY+pTS1RglmSKASwBYwAEugL
Gw/vdb+gFKdKJKu/2o2gfq4siHGUs4creOcuWfFC2hS/j4zztxYJvnIH6A0xSTp0MeX7
bB0MLYrhZw7PMsY/5cMgd8u8V09I468fSpLdIdCLDM1/Usl9RgGV2sk8TyikbcztWdEv
Gn/ouO8PL9Hc6gvirGWiagMXe205oj6EGCsEl/w4gNfyt6aUUDNtwZlJyr0i5U3QjUX+
4iFA==
X-Gm-Message-State: AG10YORSgbzkuQsTxYsNR/bsLPUVtWQVGtxfiLe6PNoSJDxOfDqxp9VfOkEcU3gOT0Fz2nxlhl6xqcaS9knezg==
MIME-Version: 1.0
X-Received: by 10.31.52.73 with SMTP id b70mr11572895vka.16.1453777273326;
Mon, 25 Jan 2016 19:01:13 -0800 (PST)
Received: by 10.31.96.85 with HTTP; Mon, 25 Jan 2016 19:01:13 -0800 (PST)
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
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:47 +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:01:15 -0000
--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">>=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're basically a =
pre-OP_RETURN environment. OP_RETURN serves a purpose and it can'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">> </=
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'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"><<a href=3D"mailto:luke@=
dashjr.org" target=3D"_blank">luke@dashjr.org</a>></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>
> Luke - As stated in the Github thread, I totally understand where you&=
#39;re<br>
> coming from but the fact is people *will* encode data on the blockchai=
n<br>
> using worse methods. For all of the reasons that OP_RETURN was a good =
idea<br>
> in the first place, it'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>
> As for keyless - there's no way (that I know of) to construct a tr=
ansaction<br>
> with a zero value OP_RETURN in an environment without keys since the<b=
r>
> Payment Protocol is what defines the method for getting a transaction =
from<br>
> a server to a wallet. You can make a custom transaction and execute it=
in<br>
> the same application but without Payments there's no way to move<b=
r>
> transactions between two applications. You need to build the transacti=
on<br>
> 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--
|
