Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.180 as permitted sender)
	client-ip=209.85.212.180; envelope-from=laanwj@gmail.com;
	helo=mail-wi0-f180.google.com; 
Date: Wed, 28 Jan 2015 14:32:40 +0100 (CET)
From: Wladimir <laanwj@gmail.com>
To: Nicolas DORIER <nicolas.dorier@gmail.com>
In-Reply-To: <CALYO6Xt-jTYwpywUaH-s4YPYyGUp1_BLSEswscnwX+Vu166Lcw@mail.gmail.com>
Message-ID: <alpine.DEB.2.10.1501281419110.21680@nzrgulfg.ivfhpber.pbz>
References: <CALYO6Xt-jTYwpywUaH-s4YPYyGUp1_BLSEswscnwX+Vu166Lcw@mail.gmail.com>
User-Agent: Alpine 2.10 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for
 encoding?
Precedence: list


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