summaryrefslogtreecommitdiff
path: root/23/33618c0365aa38503bf37778c913ed1de3d8d9
blob: db19385d017baf8e4a92db60194dd1e1621498a1 (plain)
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
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <will.yager@gmail.com>) id 1WzVww-0001Uy-R3
	for bitcoin-development@lists.sourceforge.net;
	Tue, 24 Jun 2014 19:00:10 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.44 as permitted sender)
	client-ip=209.85.192.44; envelope-from=will.yager@gmail.com;
	helo=mail-qg0-f44.google.com; 
Received: from mail-qg0-f44.google.com ([209.85.192.44])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WzVwv-0002Fs-3W
	for bitcoin-development@lists.sourceforge.net;
	Tue, 24 Jun 2014 19:00:10 +0000
Received: by mail-qg0-f44.google.com with SMTP id j107so701838qga.31
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 24 Jun 2014 12:00:03 -0700 (PDT)
X-Received: by 10.140.82.113 with SMTP id g104mr4511364qgd.55.1403636403506;
	Tue, 24 Jun 2014 12:00:03 -0700 (PDT)
Received: from [10.255.130.128] ([65.115.226.29])
	by mx.google.com with ESMTPSA id u4sm1770872qab.1.2014.06.24.12.00.02
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 24 Jun 2014 12:00:02 -0700 (PDT)
Content-Type: multipart/signed;
	boundary=Apple-Mail-ADD7CE9F-8B5E-424C-886C-D8E9DCE67E6E;
	protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (1.0)
From: Gmail <will.yager@gmail.com>
X-Mailer: iPhone Mail (11D201)
In-Reply-To: <CAJHLa0PYfuJg3daPvzPFZpFz7ezH2RHpJ8zyz2g1NDKppM7rWA@mail.gmail.com>
Date: Tue, 24 Jun 2014 15:00:02 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <BBF86C9B-6B3D-4A03-AC7B-35619C47091F@gmail.com>
References: <CANEZrP3iyQ9zQ+hDnooxrjdBO+_Fj+nAkK1Skgk+Gb4gkidPhQ@mail.gmail.com>
	<CAJHLa0Omiz+UhGjSKgYU7+b2YY7aN23w7o8CQntqMePFs7LkjA@mail.gmail.com>
	<CANEZrP06gk-JhKaNpvYUTfjFq9AGnCay9=pjUGpVMjMSuX3_ew@mail.gmail.com>
	<CAJna-HhX8HOci0KMe4ZScr4QW792S3n5twvU0QhbQe1N_3q7_w@mail.gmail.com>
	<6E6F88E9-5698-419B-927C-F65A5FCABBE9@gmail.com>
	<CAJHLa0PYfuJg3daPvzPFZpFz7ezH2RHpJ8zyz2g1NDKppM7rWA@mail.gmail.com>
To: Jeff Garzik <jgarzik@bitpay.com>
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(will.yager[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [209.85.192.44 listed in list.dnswl.org]
X-Headers-End: 1WzVwv-0002Fs-3W
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed BIP 70 extension
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 24 Jun 2014 19:00:11 -0000


--Apple-Mail-ADD7CE9F-8B5E-424C-886C-D8E9DCE67E6E
Content-Type: multipart/alternative;
	boundary=Apple-Mail-3D033F15-7563-4A23-AE8D-F44F07B66109
Content-Transfer-Encoding: 7bit


--Apple-Mail-3D033F15-7563-4A23-AE8D-F44F07B66109
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Ok, wanting structured data is a decent argument, but why this random arbitr=
ary case in particular? There are hundreds of fields like this that people m=
ight want to use.=20

If we're going to support one random cosmetic field, we might as well suppor=
t them all with a generic structured data format.=20

I'd rather we just didn't have this essentially pointless "feature" at all. L=
et's try and keep as much cruft as possible out of the payment protocol. The=
 textual memo field is already more than sufficient.=20

> On Jun 24, 2014, at 11:48, Jeff Garzik <jgarzik@bitpay.com> wrote:
>=20
> I think there is nothing wrong with having a numeric memo field, which
> is effectively what this is.  Structured rather than unstructured
> data.

--Apple-Mail-3D033F15-7563-4A23-AE8D-F44F07B66109
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>Ok, wanting structured data is a decen=
t argument, but why this random arbitrary case in particular? There are hund=
reds of fields like this that people might want to use.&nbsp;</div><div><br>=
</div><div>If we're going to support one random cosmetic field, we might as w=
ell support them all with a generic structured data format.&nbsp;</div><div>=
<br></div><div>I'd rather we just didn't have this essentially pointless "fe=
ature" at all. Let's try and keep as much cruft as possible <i>out </i>of th=
e payment protocol. The textual memo field is already more than sufficient.&=
nbsp;</div><div><br>On Jun 24, 2014, at 11:48, Jeff Garzik &lt;<a href=3D"ma=
ilto:jgarzik@bitpay.com">jgarzik@bitpay.com</a>&gt; wrote:<br><br></div><blo=
ckquote type=3D"cite"><span>I think there is nothing wrong with having a num=
eric memo field, which</span><br><span>is effectively what this is. &nbsp;St=
ructured rather than unstructured</span><br><span>data.</span></blockquote><=
/body></html>=

--Apple-Mail-3D033F15-7563-4A23-AE8D-F44F07B66109--

--Apple-Mail-ADD7CE9F-8B5E-424C-886C-D8E9DCE67E6E
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDYjCCA14w
ggJGoAMCAQICAQEwCwYJKoZIhvcNAQELMEoxFjAUBgNVBAMMDVdpbGxpYW0gWWFnZXIxCzAJBgNV
BAYTAlVTMSMwIQYJKoZIhvcNAQkBFhR3aWxsLnlhZ2VyQGdtYWlsLmNvbTAeFw0xMzExMTMyMzQ0
MDlaFw0xNDExMTMyMzQ0MDlaMEoxFjAUBgNVBAMMDVdpbGxpYW0gWWFnZXIxCzAJBgNVBAYTAlVT
MSMwIQYJKoZIhvcNAQkBFhR3aWxsLnlhZ2VyQGdtYWlsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAK+DkBdyRq8raiByDg9lye6EyMxmVstEg7/+Tw+BFyvoiPsIlmMzhJ3o8Vhl
8m3rn5JVun5h+BrWW5Efb4i+n7/3zmX0JHeR27Fl2r7KiyZnmeVUWGefiqTr1UmP+jN+wd2qZA5C
N4EzHlV4AkGGD/+lYxJqj9VXCRMoguV16G5LaUlNIsrsSiMeQ5htXS2LgTMzl/+KDuQ28yKrFfE/
puBtg33IRM4t0LV/X5ePfHY6UirDLdg/0E9QkkNeFyfegftRNNqsxpR00727C3iZd1R2/0r5ePdo
ZZ26i6ccnCTlAd3cw2KONnoYIXauTYu9ZltrdTil//jARFjdvw0MEQECAwEAAaNRME8wDgYDVR0P
AQH/BAQDAgL8MBwGA1UdJQEB/wQSMBAGCCsGAQUFBwMEBgRVHSUAMB8GA1UdEQQYMBaBFHdpbGwu
eWFnZXJAZ21haWwuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQCEFtUaBk/T6t7Z7LiNsWbWxYaV+e5I
Sv1Xgcf+HUveHF2pNPy1dESKm4SwFgzeXRbFrJoR9iAUn5Sp4BW7BK36HAgi4R4nTPPlnDOuwuhg
PayrIjP4hxJs56sxeloeakgXhryON0OmQDBCTsStZo1yJQ2ThGXrvlhJVCYu5q781QvLdO+FrNkT
v/G+SNsPf+rZviqiUdw645x8fbfvEXMKgYWvyvXlCGGMNNi2/DzqNqY+oBaLeX4GJTdgly//FcNm
U0SAH/9VM6UubDnqf1zcPMbTNDrBWvq82Oj1ABRuDCZ3N+A4Wbe/z5Y6C1E47QdIu1Ubecxh0/hF
oBQbvkQjMYICmTCCApUCAQEwTzBKMRYwFAYDVQQDDA1XaWxsaWFtIFlhZ2VyMQswCQYDVQQGEwJV
UzEjMCEGCSqGSIb3DQEJARYUd2lsbC55YWdlckBnbWFpbC5jb20CAQEwCQYFKw4DAhoFAKCCAR8w
GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNjI0MTkwMDAzWjAj
BgkqhkiG9w0BCQQxFgQUcBJtPZMzdSuPxlJkSPANiw1yR6EwXgYJKwYBBAGCNxAEMVEwTzBKMRYw
FAYDVQQDDA1XaWxsaWFtIFlhZ2VyMQswCQYDVQQGEwJVUzEjMCEGCSqGSIb3DQEJARYUd2lsbC55
YWdlckBnbWFpbC5jb20CAQEwYAYLKoZIhvcNAQkQAgsxUaBPMEoxFjAUBgNVBAMMDVdpbGxpYW0g
WWFnZXIxCzAJBgNVBAYTAlVTMSMwIQYJKoZIhvcNAQkBFhR3aWxsLnlhZ2VyQGdtYWlsLmNvbQIB
ATANBgkqhkiG9w0BAQEFAASCAQAnUtuNmQXTnDKBL+BH7/rRRQsgJDWu4PthGAd6/6lD4TC9FLJR
lohAfQfepyw+CeuMAPJn0Og3aybXsQoDVMZrQ6QdbfUjHnUyNyINiUmK5cyIx07KlPX52z/2ZDCs
NfKqEwWNMeF43lewXtmW1FaPBDHpd3ncRPBnvYd3DLyAjdSLeH884oITrFHgq5xZHHlVk1nRpwxb
sjSX+3n/obFtt4i4ZPznR517OHSk3FGkboWALqHhwHd6/9RLOH1NHQKFhNU+1OUtw3Lt9AxAcrDN
RI9beKKECA/maLl9khsByIleEN3uSQP7rE9DPhYXYjtL+LrswN6iya91m7foTtqGAAAAAAAA
--Apple-Mail-ADD7CE9F-8B5E-424C-886C-D8E9DCE67E6E--