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; 
MIME-Version: 1.0
Sender: slashene@gmail.com
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
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
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for
	encoding?
Precedence: list

--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&#39;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&#39;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&#39;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">&lt;<a href=
=3D"mailto:laanwj@gmail.com" target=3D"_blank">laanwj@gmail.com</a>&gt;</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&#39;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&#39;t know if it&#39;s the best possible one, b=
ut one serialization method had to be picked. If it weren&#39;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&#39;t expect using a straightforward binary forma=
t. There&#39;s no obvious best choice.<span class=3D"HOEnZb"><font color=3D=
"#888888"><br>
<br>
Wladimir<br>
</font></span></blockquote></div><br></div>

--089e0149365afb8d2d050db6cb6c--