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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <nicolas.dorier@gmail.com>) id 1YGTAl-00012h-Sd
for bitcoin-development@lists.sourceforge.net;
Wed, 28 Jan 2015 14:00:47 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.49 as permitted sender)
client-ip=74.125.82.49; envelope-from=nicolas.dorier@gmail.com;
helo=mail-wg0-f49.google.com;
Received: from mail-wg0-f49.google.com ([74.125.82.49])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YGTAk-00063P-2d
for bitcoin-development@lists.sourceforge.net;
Wed, 28 Jan 2015 14:00:47 +0000
Received: by mail-wg0-f49.google.com with SMTP id k14so20743894wgh.8
for <bitcoin-development@lists.sourceforge.net>;
Wed, 28 Jan 2015 06:00:41 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.175.102 with SMTP id bz6mr7537182wjc.120.1422453641021;
Wed, 28 Jan 2015 06:00:41 -0800 (PST)
Sender: slashene@gmail.com
X-Google-Sender-Delegation: slashene@gmail.com
Received: by 10.194.92.112 with HTTP; Wed, 28 Jan 2015 06:00:40 -0800 (PST)
In-Reply-To: <alpine.DEB.2.10.1501281419110.21680@nzrgulfg.ivfhpber.pbz>
References: <CALYO6Xt-jTYwpywUaH-s4YPYyGUp1_BLSEswscnwX+Vu166Lcw@mail.gmail.com>
<alpine.DEB.2.10.1501281419110.21680@nzrgulfg.ivfhpber.pbz>
Date: Wed, 28 Jan 2015 15:00:40 +0100
X-Google-Sender-Auth: dmebrGXFyK24UA2gbN5GScjpU4M
Message-ID: <CALYO6Xv=k+Ztvke90SDB91StFBL7C0U49ufMD-WjG91uHLshFg@mail.gmail.com>
From: Nicolas DORIER <nicolas.dorier@gmail.com>
To: Wladimir <laanwj@gmail.com>
Content-Type: multipart/alternative; boundary=089e0149365afb8d2d050db6cb6c
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
(nicolas.dorier[at]gmail.com)
-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: 1YGTAk-00063P-2d
Cc: 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 14:00:48 -0000
--089e0149365afb8d2d050db6cb6c
Content-Type: text/plain; charset=UTF-8
Sure I know that x509 is international standard. And that HTTPS uses TLS.
This is not my point, my point is that when we use HTTPS the developer
delegates certificates verification to the plateform he is running on, so
developer don't have to bother about it, making the implementation safer
and easier.
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.
So, let's say I want to target IOS + WP + Android + WinRT + desktop win, I
need to develop 4 times chain verification and certificate parsing.
(Because I can't verify a certificate if it is not in the specific type of
the underlying plateform)
And since it would take too much time to do that, I end up delegating
parsing and trust verification to a third party service.
2015-01-28 14:32 GMT+01:00 Wladimir <laanwj@gmail.com>:
>
> On Wed, 28 Jan 2015, Nicolas DORIER wrote:
>
> I agree that the use protocol buffer and x509 by BIP70 is a poor choice.
>>
>
> Well x509 is an international standard in common use, you can't do much
> better with regard to portability. Your suggestion about HTTPS makes little
> sense, you do know what TLS uses x509 internally as well?
>
> Re: protocol buffers, I don't know if it's the best possible one, but one
> serialization method had to be picked. If it weren't, we could still have
> still been discussing which one to use by now. Just like for JSON there are
> bindings for many languages.
>
> Though JSON parsers are much more diverse, which people using Bitcoin
> Core's RPC have bumped into e.g. some have some problems handling large
> numbers. Something you wouldn't expect using a straightforward binary
> format. There's no obvious best choice.
>
> Wladimir
>
--089e0149365afb8d2d050db6cb6c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>Sure I know that x509 is international stan=
dard. And that HTTPS uses TLS.<br></div>This
is not my point, my point is that when we use HTTPS the developer=20
delegates certificates verification to the plateform he is running on,=20
so developer don't have to bother about it, making the implementation=
=20
safer and easier.<br></div><div><br>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><br></div><div>So, let's say =
I
want to target IOS + WP + Android + WinRT + desktop win, I need to=20
develop 4 times chain verification and certificate parsing. (Because I=20
can't verify a certificate if it is not in the specific type of the=20
underlying plateform)<br><br></div>And since it would take too much time to=
do that, I end up delegating parsing and trust verification to a third par=
ty service.<br></div></div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">2015-01-28 14:32 GMT+01:00 Wladimir <span dir=3D"ltr"><<a href=
=3D"mailto:laanwj@gmail.com" target=3D"_blank">laanwj@gmail.com</a>></sp=
an>:<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 Wed, 28 Jan 2015, Nicolas DORIER wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I agree that the use protocol buffer and x509 by BIP70 is a poor choice.<br=
>
</blockquote>
<br></span>
Well x509 is an international standard in common use, you can't do much=
better with regard to portability. Your suggestion about HTTPS makes littl=
e sense, you do know what TLS uses x509 internally as well?<br>
<br>
Re: protocol buffers, I don't know if it's the best possible one, b=
ut one serialization method had to be picked. If it weren't, we could s=
till have still been discussing which one to use by now. Just like for JSON=
there are bindings for many languages.<br>
<br>
Though JSON parsers are much more diverse, which people using Bitcoin Core&=
#39;s RPC have bumped into e.g. some have some problems handling large numb=
ers. Something you wouldn't expect using a straightforward binary forma=
t. There's no obvious best choice.<span class=3D"HOEnZb"><font color=3D=
"#888888"><br>
<br>
Wladimir<br>
</font></span></blockquote></div><br></div>
--089e0149365afb8d2d050db6cb6c--
|
