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
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mike@coinlab.com>) id 1TfcAY-00071T-1k
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Dec 2012 19:59:10 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of coinlab.com
designates 209.85.214.175 as permitted sender)
client-ip=209.85.214.175; envelope-from=mike@coinlab.com;
helo=mail-ob0-f175.google.com;
Received: from mail-ob0-f175.google.com ([209.85.214.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TfcAV-0004M8-PM
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Dec 2012 19:59:09 +0000
Received: by mail-ob0-f175.google.com with SMTP id vb8so3084874obc.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 03 Dec 2012 11:59:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type:x-gm-message-state;
bh=sA2uzYBqKSa6rkfg84SGsiCXO2z3bIkMQK71fIE14+w=;
b=IAM40mNOYYKiac6A012QJ70jLJvkNkwuahoA8HvtDw5nmprOv/CrtLtJpGbbCQFkWB
OnDNGSkzl08is9ni8aMDsSBdL5hrfAtQHr1S46shk0PKd3tfMELI5OJpYPW9s0fzNZxD
lVkV71/b0d+WOtTqpnkl7aGfaFmP7c68KEfLPGSap+5ccuyBo1Q5ruMml+aWTxNl7+Oj
cp1QoGMvwi5rlUlEtMh2c7rAfC7nMeXYJPWUh/qSqO3/1PbKWWh7g35hS7ocYq+O0i9R
czWVy1tAm0VFLTRIqBlx90m1xVBjbMKK/+rgt9pbQixbVYBqDKf+9UjA5e9elT6T/iyI
BFzA==
MIME-Version: 1.0
Received: by 10.60.24.161 with SMTP id v1mr8924996oef.115.1354563313387; Mon,
03 Dec 2012 11:35:13 -0800 (PST)
Received: by 10.76.33.130 with HTTP; Mon, 3 Dec 2012 11:35:13 -0800 (PST)
In-Reply-To: <CABsx9T35qD_xJEVw002eAhJ1kr6x5aMU7RpD+U84XEOZXmXcYw@mail.gmail.com>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
<20121128233619.GA6368@giles.gnomon.org.uk>
<CABsx9T09FYf2RTaMpmujt3qwTFc2JgnREH_7Hyk2mnCgb3CvAw@mail.gmail.com>
<20121129170713.GD6368@giles.gnomon.org.uk>
<CANEZrP233CytLs3PWBQ1TyuBTMv4sLGJkEMeGWYq5xRi+iLKew@mail.gmail.com>
<20121129185330.GE6368@giles.gnomon.org.uk>
<CABsx9T35qD_xJEVw002eAhJ1kr6x5aMU7RpD+U84XEOZXmXcYw@mail.gmail.com>
Date: Mon, 3 Dec 2012 11:35:13 -0800
Message-ID: <CAErK2ChjAm-Zf11YXuBQeTQvahOEJNGiPSZaD-CQ=OU9K6HtZA@mail.gmail.com>
From: Mike Koss <mike@coinlab.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8fb204461ec83504cff7d93e
X-Gm-Message-State: ALoCoQlJ2lhomoWaMBKI5WJQk8MYxT2nX4C1Z0sBGU0r+xlTJ1mv+RcsCvBVs1XOcypEzIhPDtZ4
X-Spam-Score: -0.5 (/)
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 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1TfcAV-0004M8-PM
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
Invoices/Payments/Receipts
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: Mon, 03 Dec 2012 19:59:10 -0000
--e89a8fb204461ec83504cff7d93e
Content-Type: text/plain; charset=ISO-8859-1
The thing that bugged me most about the original spec was the sole reliance
on X.509 - glad to see you've made that optional. I think many people will
balk at deferring our identity trust to the existing CA's. I think it's a
fine bootstrap method, but I'd really like to see another option that
allows for out-of-band trust (based on ECDSA, probably).
It would also be really nice to migrate to textual representations of data
structures as opposed to binary ones. The most successful internet
standards are based on text, making them that much more accessible for
developers to deal with them. JSON would be my preferred candidate.
Why don't we sign the text representation of a (utf8) JSON, rather than
some complex encoding standard of JSON? That way the signatures are simple
- and you need only retain the original textual representation of a message
to validate the signature (as well as the decoded version, if you don't
want to alway re-parse the message when writing programs that use it).
On Sat, Dec 1, 2012 at 11:25 AM, Gavin Andresen <gavinandresen@gmail.com>wrote:
> Spec updated: https://gist.github.com/4120476
>
> Changes are:
>
> Version numbers: a couple of people asked privately about adding
> version numbers to the messages. In general, Protocol Buffers don't
> need version numbers if later versions add only optional fields.
>
> And best-practice is to know what version of something you're
> expecting BEFORE you start parsing that something.
>
> So, if a bitcoin client is getting Invoice messages via email or from
> a web server, the version will be specified as part of the MIME type;
> for example:
> Content-Type: application/x-bitcoin-invoice; version=1
> The version= syntax is part of the MIME standard.
>
> Following that best-practice of knowing what you're parsing before you
> parse it, I added an invoice_version field to the SignedInvoice
> message. It is now:
>
> message SignedInvoice {
> required bytes pki_data = 1;
> required string pki_type = 2 [default = "x509"];
> required bytes serialized_invoice = 3;
> required uint32 invoice_version = 4 [default = 1];
> required bytes signature = 5;
> }
>
>
> Handling of receiptURI errors:
>
> Following discussion here, I changed the spec to say:
>
> "Clients may handle errors communicating with the receiptURI server
> however they like, but should assume that if they cannot communicate
> at all with the server then the Payment should either be retried later
> or immediately rejected."
>
> and under Receipt added:
>
> "The Bitcoin client must be prepared to handle the case of an evil
> merchant that returns accepted=false but broadcasts the transactions
> anyway."
>
>
> I also added a TODO "Test Vectors" section with base64-encoded
> examples of everything.
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> INSIGHTS What's next for parallel hardware, programming and related areas?
> Interviews and blogs by thought leaders keep you ahead of the curve.
> http://goparallel.sourceforge.net
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)
A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf> - What you need
to know about Bitcoins.
--e89a8fb204461ec83504cff7d93e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
The thing that bugged me most about the original spec was the sole reliance=
on X.509 -=A0glad=A0to see you've made that optional. =A0I think many =
people will balk at deferring our identity trust to the existing CA's. =
=A0I think it's a fine bootstrap method, but I'd really like to see=
another option that allows for out-of-band trust (based on ECDSA, probably=
).<div>
<br></div><div>It would also be really nice to migrate to textual represent=
ations of data structures as opposed to binary ones. =A0The most successful=
internet standards are based on text, making them that much more accessibl=
e for developers to deal with them. =A0 JSON would be my preferred candidat=
e.</div>
<div><br></div><div>Why don't we sign the text representation of a (utf=
8) JSON, rather than some complex encoding standard of JSON? =A0That way th=
e signatures are simple - and you need only retain the original textual rep=
resentation of a message to validate the signature (as well as the decoded =
version, if you don't want to alway re-parse the message when writing p=
rograms that use it).</div>
<br><div class=3D"gmail_quote">On Sat, Dec 1, 2012 at 11:25 AM, Gavin Andre=
sen <span dir=3D"ltr"><<a href=3D"mailto:gavinandresen@gmail.com" target=
=3D"_blank">gavinandresen@gmail.com</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
Spec updated: <a href=3D"https://gist.github.com/4120476" target=3D"_blank"=
>https://gist.github.com/4120476</a><br>
<br>
Changes are:<br>
<br>
Version numbers: =A0a couple of people asked privately about adding<br>
version numbers to the messages. In general, Protocol Buffers don't<br>
need version numbers if later versions add only optional fields.<br>
<br>
And best-practice is to know what version of something you're<br>
expecting BEFORE you start parsing that something.<br>
<br>
So, if a bitcoin client is getting Invoice messages via email or from<br>
a web server, the version will be specified as part of the MIME type;<br>
for example:<br>
=A0 =A0Content-Type: application/x-bitcoin-invoice; version=3D1<br>
The version=3D syntax is part of the MIME standard.<br>
<br>
Following that best-practice of knowing what you're parsing before you<=
br>
parse it, I added an invoice_version field to the SignedInvoice<br>
message. It is now:<br>
<br>
message SignedInvoice {<br>
=A0 =A0 required bytes pki_data =3D 1;<br>
=A0 =A0 required string pki_type =3D 2 [default =3D "x509"];<br>
=A0 =A0 required bytes serialized_invoice =3D 3;<br>
=A0 =A0 required uint32 invoice_version =3D 4 [default =3D 1];<br>
=A0 =A0 required bytes signature =3D 5;<br>
}<br>
<br>
<br>
Handling of receiptURI errors:<br>
<br>
Following discussion here, I changed the spec to say:<br>
<br>
"Clients may handle errors communicating with the receiptURI server<br=
>
however they like, but should assume that if they cannot communicate<br>
at all with the server then the Payment should either be retried later<br>
or immediately rejected."<br>
<br>
and under Receipt added:<br>
<br>
"The Bitcoin client must be prepared to handle the case of an evil<br>
merchant that returns accepted=3Dfalse but broadcasts the transactions<br>
anyway."<br>
<br>
<br>
I also added a TODO "Test Vectors" section with base64-encoded<br=
>
examples of everything.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
--<br>
Gavin Andresen<br>
</font></span><div class=3D"im HOEnZb"><br>
---------------------------------------------------------------------------=
---<br>
Keep yourself connected to Go Parallel:<br>
</div><div class=3D"im HOEnZb">INSIGHTS What's next for parallel hardwa=
re, programming and related areas?<br>
Interviews and blogs by thought leaders keep you ahead of the curve.<br>
</div><div class=3D"HOEnZb"><div class=3D"h5"><a href=3D"http://goparallel.=
sourceforge.net" target=3D"_blank">http://goparallel.sourceforge.net</a><br=
>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
Mike Koss<div>CTO, CoinLab</div><div>(425) 246-7701 (m)</div><div><br></div=
><div><a href=3D"http://coinlab.com/a-bitcoin-primer.pdf" target=3D"_blank"=
>A Bitcoin Primer</a>=A0- What you need to know about Bitcoins.</div>
<br>
--e89a8fb204461ec83504cff7d93e--
|
