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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@bitpay.com>) id 1YGV7R-0002CA-4m
for bitcoin-development@lists.sourceforge.net;
Wed, 28 Jan 2015 16:05:29 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bitpay.com
designates 209.85.214.178 as permitted sender)
client-ip=209.85.214.178; envelope-from=jgarzik@bitpay.com;
helo=mail-ob0-f178.google.com;
Received: from mail-ob0-f178.google.com ([209.85.214.178])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YGV7L-0006gV-ID
for bitcoin-development@lists.sourceforge.net;
Wed, 28 Jan 2015 16:05:29 +0000
Received: by mail-ob0-f178.google.com with SMTP id uz6so2064552obc.9
for <bitcoin-development@lists.sourceforge.net>;
Wed, 28 Jan 2015 08:05:19 -0800 (PST)
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:from:date
:message-id:subject:to:cc:content-type;
bh=7WI7ou73J3WVVKDOr/WnaiZvyc7nZSiZVA68RaluFLU=;
b=Qt5UQAslBrNL68M1gAdmxAQBbboY2HPKj5RAboN6lKr74WOCP7b/hAonUV7BkpRXkU
yk5Y8/90URKenBZQz7zuOxhFfMd+T9eY95dqXwQwrjDjXn3AOQzwLYA4fWOKYYpfVXmS
IFIX21AGWB7ge0PUivnoAXNLP7hAlknMqykz6TzjZQS8ZjqSnXNuSHB9oGcx5LHeLSXC
8WhN2QekaRcxfYgAn1/PWf6y8XEWk4LEVhm7CU+THQXOPHuqqrnK5iF52hmSEOa/q6G3
jU3FaQpr2674wFjxQgo7iup15BOh2Nl7Ss2Bm1Gvt4gcjmwJr0RL6R4pm2/UC4MEpZcT
HdTw==
X-Gm-Message-State: ALoCoQnwxkvqcLh+ZC6S0t1sQlVA0Czvvq/FO1g1xr5UMJEzLoOI/cWdTFNAjbsBiix2nbLhXn98
X-Received: by 10.60.50.234 with SMTP id f10mr2561112oeo.23.1422461119082;
Wed, 28 Jan 2015 08:05:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.202.219.196 with HTTP; Wed, 28 Jan 2015 08:04:58 -0800 (PST)
In-Reply-To: <CANEZrP3PCHaTO3-HA3GHFxwuJJpW2dbvPuV4R1sFPcFW49uGgw@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>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Wed, 28 Jan 2015 11:04:58 -0500
Message-ID: <CAJHLa0Mu3Mjn=N-fTQ_fjwp+NUpfBqpdnXZiHoKz1s3tcZa+Cg@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a11c303dab5c51f050db889e3
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 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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
X-Headers-End: 1YGV7L-0006gV-ID
Cc: Nicolas DORIER <nicolas.dorier@gmail.com>,
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:05:29 -0000
--001a11c303dab5c51f050db889e3
Content-Type: text/plain; charset=UTF-8
Not to mention the tiresome and error-prone task of writing your own
JSON-to-schema marshalling code -- or something equivalent to the protobufs
compiler and libs for JSON.
protobufs -- and its modern competitors such as msgpack -- natively provide
type support in a way that must be hacked into JSON or XML.
The protobuf/msgpack design is engineered to avoid bugs routinely found in
JSON parsing code; due to the amount of code & effort involved in JSON
input sanity checking, bugs and inconsistencies inevitable arise. We have
seen this in bitcoind with JSON-RPC.
On Wed, Jan 28, 2015 at 10:42 AM, Mike Hearn <mike@plan99.net> wrote:
> On the other hand, if you charge the developer (and not the plateform) to
>> check certificate validity, it means that you have to develop a different
>> codebase for all plateform you are targeting, because each plateform store
>> trusted root certificate in a different manner with different APIs, and
>> also have different types representing a X509 Certificate.
>>
>
> That's what cross-platform abstraction libraries are for. Both Java and Qt
> provide a key store library that can load from either the OS root store or
> a custom one. If your chosen app platform doesn't, OK, then you'll have to
> make or find one yourself. Perhaps contribute it upstream or make it a
> library. But that's not a limitation of BIP70.
>
> Just as a reminder, there is no obligation to use the OS root store. You
> can (and quite possibly should) take a snapshot of the Mozilla/Apple/MSFT
> etc stores and load it in your app. We do this in bitcoinj by default to
> avoid cases where BIP70 requests work on some platforms and not others,
> although the developer can easily override this and use the OS root store
> instead.
>
> Of all possible solutions, using a third party service to convert things
> to JSON is one of the least obvious and highest effort. I don't know anyone
> else who arrived at such a conclusion and respectfully disagree that this
> is a problem with the design choices in BIP70. It sounds like a bizarre
> hack around lack of features in whatever runtime you're using.
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
--001a11c303dab5c51f050db889e3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>Not to mention the tiresome and error-prone task=
of writing your own JSON-to-schema marshalling code -- or something equiva=
lent to the protobufs compiler and libs for JSON.<br><br></div>protobufs --=
and its modern competitors such as msgpack -- natively provide type suppor=
t in a way that must be hacked into JSON or XML.<br><br></div>The protobuf/=
msgpack design is engineered to avoid bugs routinely found in JSON parsing =
code; due to the amount of code & effort involved in JSON input sanity =
checking, bugs and inconsistencies inevitable arise.=C2=A0 We have seen thi=
s in bitcoind with JSON-RPC.<br><br><div><br></div></div><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote">On Wed, Jan 28, 2015 at 10:42 AM, M=
ike Hearn <span dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=
=3D"_blank">mike@plan99.net</a>></span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<div>On the other hand, if you charge the
developer (and not the plateform) to check certificate validity, it=20
means that you have to develop a different codebase for all plateform=20
you are targeting, because each plateform store trusted root certificate
in a different manner with different APIs, and also have different=20
types representing a X509 Certificate.<br></div></div></div></blockquote><d=
iv><br></div></span><div>That's what cross-platform abstraction librari=
es are for. Both Java and Qt provide a key store library that can load from=
either the OS root store or a custom one. If your chosen app platform does=
n't, OK, then you'll have to make or find one yourself. Perhaps con=
tribute it upstream or make it a library. But that's not a limitation o=
f BIP70.</div><div><br></div><div>Just as a reminder, there is no obligatio=
n to use the OS root store. You can (and quite possibly should) take a snap=
shot of the Mozilla/Apple/MSFT etc stores and load it in your app. We do th=
is in bitcoinj by default to avoid cases where BIP70 requests work on some =
platforms and not others, although the developer can easily override this a=
nd use the OS root store instead.</div><div>=C2=A0</div><div>Of all possibl=
e solutions, using a third party service to convert things to JSON is one o=
f the least obvious and highest effort. I don't know anyone else who ar=
rived at such a conclusion and respectfully disagree that this is a problem=
with the design choices in BIP70. It sounds like a bizarre hack around lac=
k of features in whatever runtime you're using.</div><div><br></div></d=
iv></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
Dive into the World of Parallel Programming. The Go Parallel Website,<br>
sponsored by Intel and developed in partnership with Slashdot Media, is you=
r<br>
hub for all things parallel software development, from weekly thought<br>
leadership blogs to news, videos, case studies, tutorials and more. Take a<=
br>
look and join the conversation now. <a href=3D"http://goparallel.sourceforg=
e.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>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail=
_signature">Jeff Garzik<br>Bitcoin core developer and open source evangelis=
t<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.com/" targe=
t=3D"_blank">https://bitpay.com/</a></div>
</div>
--001a11c303dab5c51f050db889e3--
|
