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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YGVuE-0002fj-Gv
for bitcoin-development@lists.sourceforge.net;
Wed, 28 Jan 2015 16:55:54 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.169 as permitted sender)
client-ip=209.85.212.169; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f169.google.com;
Received: from mail-wi0-f169.google.com ([209.85.212.169])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YGVu8-0003yb-Cq
for bitcoin-development@lists.sourceforge.net;
Wed, 28 Jan 2015 16:55:54 +0000
Received: by mail-wi0-f169.google.com with SMTP id h11so10246529wiw.0
for <bitcoin-development@lists.sourceforge.net>;
Wed, 28 Jan 2015 08:55:43 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.206.47 with SMTP id ll15mr9156208wic.34.1422464143349;
Wed, 28 Jan 2015 08:55:43 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.194.188.9 with HTTP; Wed, 28 Jan 2015 08:55:43 -0800 (PST)
In-Reply-To: <CALYO6Xucf7xqE_4ykJqFyS_AEAT0X-1aGvYmA0WXzX7By0c0uQ@mail.gmail.com>
References: <CALYO6Xt-jTYwpywUaH-s4YPYyGUp1_BLSEswscnwX+Vu166Lcw@mail.gmail.com>
<alpine.DEB.2.10.1501281419110.21680@nzrgulfg.ivfhpber.pbz>
<CALYO6Xv=k+Ztvke90SDB91StFBL7C0U49ufMD-WjG91uHLshFg@mail.gmail.com>
<CANEZrP3PCHaTO3-HA3GHFxwuJJpW2dbvPuV4R1sFPcFW49uGgw@mail.gmail.com>
<CALYO6Xucf7xqE_4ykJqFyS_AEAT0X-1aGvYmA0WXzX7By0c0uQ@mail.gmail.com>
Date: Wed, 28 Jan 2015 17:55:43 +0100
X-Google-Sender-Auth: tHmEMN0xla8LAagyOwvVnqnp-ww
Message-ID: <CANEZrP1N4nwATG2FNJwc8jHZg3HfjSxHOL0u84jTi7Tx0+d9dQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Nicolas DORIER <nicolas.dorier@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c25c20f8796c050db93d91
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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
X-Headers-End: 1YGVu8-0003yb-Cq
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for
encoding?
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: Wed, 28 Jan 2015 16:55:54 -0000
--001a11c25c20f8796c050db93d91
Content-Type: text/plain; charset=UTF-8
>
> My point is not that there is a limitation in BIP70. My point is that you
> put the burden of certificate verification on developer's shoulder when we
> can just leverage built in HTTPS support of the platform.
>
Platforms that support HTTPS but not certificate handling are rare - I know
HTML5 is such a platform but such apps are inherently dependent on the
server anyway and the server can just do the parsing and validation work
itself. If WinRT is such a platform, OK, too bad.
The embedding of the certificates is not arbitrary or pointless, by the
way. It's there for a very good reason - it makes the signed payment
request verifiable by third parties. Effectively you can store the signed
message and present it later to someone else, it's undeniable. Combined
with the transactions and merkle branches linking them to the block chain,
what you have is a form of digital receipt ... a proof of purchase that can
be automatically verified as legitimate. This has all kinds of use cases.
Because of how HTTPS works, you can't easily prove to a third party that a
server gave you a piece of data. Doing so requires staggeringly complex
hacks (see tls notary) and when we designed BIP70, those hacks didn't even
exist. So we'd lose the benefit of having a digitally signed request.
Additionally, doing things this way means BIP70 requests can be signed by
things which are not HTTPS servers. For example you can sign with an email
address cert, an EV certificate i.e. a company, a certificate issued by
some user forum, whatever else we end up wanting. Not every payment
recipient can be identified by a domain name + dynamic session.
> However, if you want to use your plateform's store, then you are toasted
>
That's a bit melodramatic. BitcoinJ is able to use the Android, JRE,
Windows and Mac certificate stores all using the same code or very minor
variants on it (e.g. on Mac you have to specify you want the system store
but it's a one-liner).
Yes, that's not *every* platform. Some will require custom binding glue and
it depends what abstractions and languages you are using.
> Have you tried to do that on windows RT and IOS ? I tried, and I quickly
> stopped doing that since it is not worth the effort. (Frankly I am not even
> sure you can on win rt, since the API is a stripped down version of windows)
>
There is code to do iOS using the Apple APIs here:
https://github.com/voisine/breadwallet/blob/master/BreadWallet/BRPaymentProtocol.m#L391
> Why have you not heard about the problem ? (until now, because I have this
> problem because I need to have the same codebase on
> winrt/win/android/ios/tablets)
>
WinRT is a minority platform in the extreme, and all the other platforms
you mentioned have the necessary APIs. Java abstracts you from them. So I
think you are encountering this problem because you desire to target WinRT
and other platforms with a single codebase. That's an unusual constraint.
AFAIK the only other people who encountered this are BitPay, because they
want to do everything in Javascript which doesn't really provide any major
APIs.
> Also, you bundle mozilla's store in bitcoinj, what happen when the store
> change and your customer have not intent to use bitcoinj new version ? by
> leveraging the plateform you benefit from automatic updates.
>
Yes, there are pros and cons to bundling a custom root store.
> Also, does java stores deals with certificate revocations ? sure you can
> theorically code that too... or just let the plateform deals with it.
>
It can do OCSP checks, yes, although I believe no wallets currently do so.
A better solution would be to implement an OCSP stapling extension to BIP70
though.
--001a11c25c20f8796c050db93d91
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div><div><div><div><div><div><div>My point i=
s not that there is a limitation in BIP70. My point is that you put the bur=
den of certificate verification on developer's shoulder when we can jus=
t leverage built in HTTPS support of the platform.<br></div></div></div></d=
iv></div></div></div></div></blockquote><div><br></div><div>Platforms that =
support HTTPS but not certificate handling are rare - I know HTML5 is such =
a platform but such apps are inherently dependent on the server anyway and =
the server can just do the parsing and validation work itself. If WinRT is =
such a platform, OK, too bad.</div><div><br></div><div>The embedding of the=
certificates is not arbitrary or pointless, by the way. It's there for=
a very good reason - it makes the signed payment request verifiable by thi=
rd parties. Effectively you can store the signed message and present it lat=
er to someone else, it's undeniable. Combined with the transactions and=
merkle branches linking them to the block chain, what you have is a form o=
f digital receipt ... a proof of purchase that can be automatically verifie=
d as legitimate. This has all kinds of use cases.=C2=A0</div><div><br></div=
><div>Because of how HTTPS works, you can't easily prove to a third par=
ty that a server gave you a piece of data. Doing so requires staggeringly c=
omplex hacks (see tls notary) and when we designed BIP70, those hacks didn&=
#39;t even exist. So we'd lose the benefit of having a digitally signed=
request.</div><div><br></div><div>Additionally, doing things this way mean=
s BIP70 requests can be signed by things which are not HTTPS servers. For e=
xample you can sign with an email address cert, an EV certificate i.e. a co=
mpany, a certificate issued by some user forum, whatever else we end up wan=
ting. Not every payment recipient can be identified by a domain name + dyna=
mic session.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<div><div><div><div><div><div></div></div></div>However, if you want to use=
your plateform's store, then you are toasted</div></div></div></div></=
div></blockquote><div><br></div><div>That's a bit melodramatic. Bitcoin=
J is able to use the Android, JRE, Windows and Mac certificate stores all u=
sing the same code or very minor variants on it (e.g. on Mac you have to sp=
ecify you want the system store but it's a one-liner).=C2=A0</div><div>=
<br></div><div>Yes, that's not <i>every</i>=C2=A0platform. Some will re=
quire custom binding glue and it depends what abstractions and languages yo=
u are using.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<div><div><div>Have you tried to do that on windows RT and IOS ? I tried, a=
nd I quickly stopped doing that since it is not worth the effort. (Frankly =
I am not even sure you can on win rt, since the API is a stripped down vers=
ion of windows)<br></div></div></div></div></div></blockquote><div><br></di=
v><div>There is code to do iOS using the Apple APIs here:</div><div><br></d=
iv><div><a href=3D"https://github.com/voisine/breadwallet/blob/master/Bread=
Wallet/BRPaymentProtocol.m#L391">https://github.com/voisine/breadwallet/blo=
b/master/BreadWallet/BRPaymentProtocol.m#L391</a><br></div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex"><div dir=3D"ltr"><div><div><div><div></div></div>Why have=
you not heard about the problem ? (until now, because I have this problem =
because I need to have the same codebase on winrt/win/android/ios/tablets)<=
br></div></div></div></blockquote><div><br></div><div>WinRT is a minority p=
latform in the extreme, and all the other platforms you mentioned have the =
necessary APIs. Java abstracts you from them. So I think you are encounteri=
ng this problem because you desire to target WinRT and other platforms with=
a single codebase. That's an unusual constraint.</div><div><br></div><=
div><div>AFAIK the only other people who encountered this are BitPay, becau=
se they want to do everything in Javascript which doesn't really provid=
e any major APIs.</div></div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"=
ltr"><div><div></div></div><div>Also, you bundle mozilla's store in bit=
coinj, what happen when the store change and your customer have not intent =
to use bitcoinj new version ? by leveraging the plateform you benefit from =
automatic updates.<br></div></div></blockquote><div><br></div><div>Yes, the=
re are pros and cons to bundling a custom root store.</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex"><div dir=3D"ltr"><div></div><div>Also, does java stores d=
eals with certificate revocations ? sure you can theorically code that too.=
.. or just let the plateform deals with it.<br></div></div></blockquote><di=
v><br></div><div>It can do OCSP checks, yes, although I believe no wallets =
currently do so. A better solution would be to implement an OCSP stapling e=
xtension to BIP70 though.</div></div></div></div>
--001a11c25c20f8796c050db93d91--
|
