From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: Date: Wed, 28 Jan 2015 15:00:40 +0100 X-Google-Sender-Auth: dmebrGXFyK24UA2gbN5GScjpU4M Message-ID: From: Nicolas DORIER To: Wladimir 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 : > > 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
Sure I know that x509 is international stan= dard. And that HTTPS uses TLS.
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.

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.

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)

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.

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 littl= e 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, 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.

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.

Wladimir

--089e0149365afb8d2d050db6cb6c--