From: Nicolas DORIER <nicolas.dorier@gmail•com>
To: Wladimir <laanwj@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
Date: Wed, 28 Jan 2015 15:00:40 +0100 [thread overview]
Message-ID: <CALYO6Xv=k+Ztvke90SDB91StFBL7C0U49ufMD-WjG91uHLshFg@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1501281419110.21680@nzrgulfg.ivfhpber.pbz>
[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 2627 bytes --]
next prev parent reply other threads:[~2015-01-28 14:00 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-28 12:45 Nicolas DORIER
2015-01-28 13:32 ` Wladimir
2015-01-28 14:00 ` Nicolas DORIER [this message]
2015-01-28 15:42 ` Mike Hearn
2015-01-28 16:04 ` Jeff Garzik
2015-01-28 16:52 ` Nicolas DORIER
2015-01-28 17:29 ` Jeff Garzik
2015-01-28 17:45 ` Mike Hearn
2015-01-28 16:19 ` Giuseppe Mazzotta
2015-01-28 16:51 ` Matt Whitlock
2015-01-28 17:02 ` Mike Hearn
2015-01-28 16:34 ` Nicolas DORIER
2015-01-28 16:55 ` Mike Hearn
2015-01-28 17:04 ` Nicolas Dorier
2015-01-28 17:14 ` Mike Hearn
2015-01-28 17:17 ` Angel Leon
2015-01-28 17:27 ` Nicolas DORIER
-- strict thread matches above, loose matches on Subject: below --
2015-01-19 19:07 Richard Brady
2015-01-19 19:09 ` Jeff Garzik
2015-01-19 19:16 ` Richard Brady
2015-01-19 19:34 ` Jeff Garzik
2015-01-19 19:48 ` Peter Todd
2015-01-19 19:57 ` Richard Brady
2015-01-19 20:03 ` Alan Reiner
2015-01-19 20:06 ` Peter Todd
2015-01-19 20:40 ` Mike Hearn
2015-01-19 20:56 ` Gavin Andresen
2015-01-19 21:22 ` Brian Hoffman
2015-01-19 20:59 ` Ross Nicoll
2015-01-24 13:19 ` Isidor Zeuner
2015-01-25 22:59 ` Ross Nicoll
2015-03-14 15:58 ` Isidor Zeuner
2015-03-24 12:08 ` Jorge Timón
2015-01-19 21:21 ` Jeff Garzik
2015-01-19 19:19 ` Matt Whitlock
2015-01-19 19:37 ` Mike Hearn
2015-01-19 19:38 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALYO6Xv=k+Ztvke90SDB91StFBL7C0U49ufMD-WjG91uHLshFg@mail.gmail.com' \
--to=nicolas.dorier@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=laanwj@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox