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
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
|
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 258D6E9E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jan 2016 17:44:50 +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 40E46129
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jan 2016 17:44:49 +0000 (UTC)
Received: by mail-vk0-f53.google.com with SMTP id e185so96024083vkb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jan 2016 09:44:49 -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:cc
:content-type; bh=InfDDaJYCGAzNsV56BM9FIS/fwJDp4Uhw+7tuvDMSss=;
b=tbU91w48TkQCICLjj/ks1jurakwjtdm00XON3OsHSBXWdueGJZ9o22161umr09xjAW
wBtaWGR4p8ftzwNu/X48eXcyMaebR62qv2hGzMRTArJc5l7bGcEKbigf4/8viSlBasIK
fqrrRJmieA1g+lReA5swckjUX2VNRdECs1CcheYHUI2O94q0cSFPPKnpyR9AwQqOyxIQ
7FnztW3U4PFW0WVsmum+P52mLKAzLcfiAvuRX8vWPffGBU+rrYtKW7To1kCEhSyMMYjx
pqc8C/Zj3Y8AGpRaK4Ed0wjJc7boN903tPu9P8x7Go27PB5jSNvOqEH2Vy4d0Mw7jONO
6O1Q==
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:cc:content-type;
bh=InfDDaJYCGAzNsV56BM9FIS/fwJDp4Uhw+7tuvDMSss=;
b=jXoANHDGJObs99w0jvjGR485ZVf3p6p5A6b39mjXGaFSuHFzXf0pRmXpEzy7U/NO8b
zvnizEJaSn/e1/xZ9UgGobIktO6ra6w8iPlEPiujkgDMzuIE8XvvxQrvuWGcdDB4WSti
kOIUXP16fnzkVeX57UEdj0gYpLrVQ3kfwc978fc/is3GUD5YsodChPlZjX/y1Ys2MuRu
b3WOLg8qs7OXw98HPLQ3He+8jXg73S8O0Qzw3r2hGo1dnDqVnxix6mM9JNRsDFoC6OOY
TjDh6FnqJ0k7QuKtDONAYAaCjwwzxFnFwjsXKuYY9Al9S3HKbIFyGi9NVwzauO97OPl4
NzNw==
X-Gm-Message-State: AG10YOS0/ioBiyDNvftowax7Vko0zJ380pj2hvUxcU9bFOL4NHYLAjIyZZJrE087ivK6/0otmsi8JM7KCZuneQ==
MIME-Version: 1.0
X-Received: by 10.31.0.136 with SMTP id 130mr14050426vka.139.1453830288391;
Tue, 26 Jan 2016 09:44:48 -0800 (PST)
Received: by 10.31.96.85 with HTTP; Tue, 26 Jan 2016 09:44:48 -0800 (PST)
In-Reply-To: <56A79C86.1030902@gmail.com>
References: <CAGcHOzzde_T3xJwJL2Ehyw7U1FgxEEBJR30VBLdSZMj=W49hSg@mail.gmail.com>
<201601260312.25248.luke@dashjr.org>
<CAGcHOzw88za1m6uJY9MBO2X=3psNk667FyBOHz2XCPO3ABbcRw@mail.gmail.com>
<201601260323.14993.luke@dashjr.org>
<CAGcHOzwec-eoG-uZzXY2pb=VzQ98EvnijvxrcsrFYgKi2HQ_uw@mail.gmail.com>
<56A79C86.1030902@gmail.com>
Date: Tue, 26 Jan 2016 09:44:48 -0800
Message-ID: <CAGcHOzybd3fgmdZwdMjq36O4-dXUMcdpdV0+jovTSiAtzFdGUg@mail.gmail.com>
From: Toby Padilla <tobypadilla@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a113d9ccae7428f052a403d5e
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 27 Jan 2016 00:49:29 +0000
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 17:44:50 -0000
--001a113d9ccae7428f052a403d5e
Content-Type: text/plain; charset=UTF-8
OP_RETURN was not part of isStandard? from day one. Once it was supported
by Core it became necessary to actually support it, not try to support it
in one part of the software and not in others. The whole reason it was
supported is because without it people will use more heinous methods to
encode data on the blockchain. There's no way to stop people from doing
that, so this compromise seemed best for everyone.
I think we should actually define "spam". To me a valid transaction someone
willing pays for is never spam. Also PaymentRequests would be a very
inefficient way to spam. It would be much easier to write a script to
automatically create and submit transactions yourself. With PaymentRequests
customers have to initiate the transaction and submit/pay for it one by
one.
What is actually the worst case scenario that those opposed to this are
concerned about? That this takes off like wild fire and all of the sudden
millions of people are using PaymentRequests and creating small
transactions? That seems like a win for Bitcoin. It will help spread
support for the Payment protocol and IF it becomes a problem it's because
so many people are using it. In which case there's a very valid use case
for Bitcoin that people are obviously excited about.
I really don't like the idea of policing other people's use of the
protocol. If a transaction pays its fee and has a greater than dust value,
it makes no sense to object to it.
On Tue, Jan 26, 2016 at 8:19 AM, Thomas Kerin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On 26/01/16 03:30, Toby Padilla via bitcoin-dev wrote:
> > There are already valid use cases for OP_RETURN, it only makes sense
> > to fully support the feature. The only reason it's not supported now
> > is because the Payments protocol came before OP_RETURN.
> >
> You keep saying OP_RETURN is new, but it has been there from day one.
> It's purpose is causing script execution to end if encountered.
>
> Since then, we have tolerated putting pushdata's after it, and even
> raised the limit for the size of this data. It still doesn't mean every
> proposal has to be rewritten to cater for a new allowance we give
> OP_RETURN.
>
>
> > I've also been exploring this area with key.run
> > (https://git.playgrub.com/toby/keyrun) and want the functionality for
> > voting based on aggregate OP_RETURN value. *Not* to store data on the
> > blockchain, but to associate content pointers with transactions.
> >
> > I think that since OP_RETURN has already been approved and supported
> > it doesn't make much sense for me to have to re-defend it from scratch
> > here.
>
> I'd generally agree with Luke. Removing the cost of this hurts bitcoin,
> and ironically, your application to a certain degree. Just because you
> can do a thing one way, it doesn't mean you should. Especially if your
> applications success depends on people spamming OP_RETURN hashes of
> every torrent they like.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113d9ccae7428f052a403d5e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-size:12.8px">OP_RETURN was not part of=
isStandard? from day one. Once it was supported by Core it became necessar=
y to actually support it, not try to support it in one part of the software=
and not in others. The whole reason it was supported is because without it=
people will use more heinous methods to encode data on the blockchain. The=
re's no way to stop people from doing that, so this compromise seemed b=
est for everyone.</span><div style=3D"font-size:12.8px"><br></div><div styl=
e=3D"font-size:12.8px">I think we should actually define "spam". =
To me a valid transaction someone willing pays for is never spam. Also Paym=
entRequests would be a very inefficient way to spam. It would be much easie=
r to write a script to automatically create and submit transactions yoursel=
f. With PaymentRequests =C2=A0customers have to initiate the transaction an=
d submit/pay for it one by one.</div><div style=3D"font-size:12.8px"><br></=
div><div style=3D"font-size:12.8px">What is actually the worst case scenari=
o that those opposed to this are concerned about? That this takes off like =
wild fire and all of the sudden millions of people are using PaymentRequest=
s and creating small transactions? That seems like a win for Bitcoin. It wi=
ll help spread support for the Payment protocol and IF it becomes a problem=
it's because so many people are using it. In which case there's a =
very valid use case for Bitcoin that people are obviously excited about.</d=
iv><div style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px=
">I really don't like the idea of policing other people's use of th=
e protocol. If a transaction pays its fee and has a greater than dust value=
, it makes no sense to object to it.</div><div class=3D"gmail_extra"><br><d=
iv class=3D"gmail_quote">On Tue, Jan 26, 2016 at 8:19 AM, Thomas Kerin via =
bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>=
></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""><br>
On 26/01/16 03:30, Toby Padilla via bitcoin-dev wrote:<br>
> There are already valid use cases for OP_RETURN, it only makes sense<b=
r>
> to fully support the feature. The only reason it's not supported n=
ow<br>
> is because the Payments protocol came before OP_RETURN.<br>
><br>
</span>You keep saying OP_RETURN is new, but it has been there from day one=
.<br>
It's purpose is causing script execution to end if encountered.<br>
<br>
Since then, we have tolerated putting pushdata's after it, and even<br>
raised the limit for the size of this data. It still doesn't mean every=
<br>
proposal has to be rewritten to cater for a new allowance we give<br>
OP_RETURN.<br>
<span class=3D""><br>
<br>
> I've also been exploring this area with key.run<br>
> (<a href=3D"https://git.playgrub.com/toby/keyrun" rel=3D"noreferrer" t=
arget=3D"_blank">https://git.playgrub.com/toby/keyrun</a>) and want the fun=
ctionality for<br>
> voting based on aggregate OP_RETURN value. *Not* to store data on the<=
br>
> blockchain, but to associate content pointers with transactions.<br>
><br>
> I think that since OP_RETURN has already been approved and supported<b=
r>
> it doesn't make much sense for me to have to re-defend it from scr=
atch<br>
> here.<br>
<br>
</span>I'd generally agree with Luke. Removing the cost of this hurts b=
itcoin,<br>
and ironically, your application to a certain degree. Just because you<br>
can do a thing one way, it doesn't mean you should. Especially if your<=
br>
applications success depends on people spamming OP_RETURN hashes of<br>
every torrent they like.<br>
<div class=3D"HOEnZb"><div class=3D"h5">___________________________________=
____________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div></div>
--001a113d9ccae7428f052a403d5e--
|
