From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YDJfv-0006XK-GQ for bitcoin-development@lists.sourceforge.net; Mon, 19 Jan 2015 21:15:55 +0000 X-ACL-Warn: Received: from hapkido.dreamhost.com ([66.33.216.122]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YDJft-0006Db-W0 for bitcoin-development@lists.sourceforge.net; Mon, 19 Jan 2015 21:15:55 +0000 Received: from homiemail-a10.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by hapkido.dreamhost.com (Postfix) with ESMTP id B803693954 for ; Mon, 19 Jan 2015 12:59:24 -0800 (PST) Received: from homiemail-a10.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTP id 1CA1C28005E for ; Mon, 19 Jan 2015 12:59:19 -0800 (PST) Received: from [192.168.1.227] (cpc15-sgyl29-2-0-cust655.18-2.cable.virginm.net [82.39.74.144]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jrn@jrn.me.uk) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTPSA id 8CFE028006C for ; Mon, 19 Jan 2015 12:59:18 -0800 (PST) Message-ID: <54BD7024.5070008@jrn.me.uk> Date: Mon, 19 Jan 2015 20:59:16 +0000 From: Ross Nicoll User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <2C7D6208-1921-4DDC-90FE-DB1ABE1D61DB@petertodd.org> <54BD6314.60607@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060301050209040606070908" X-Spam-Score: 0.9 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [66.33.216.122 listed in list.dnswl.org] 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: 1YDJft-0006Db-W0 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: Mon, 19 Jan 2015 21:15:55 -0000 This is a multi-part message in MIME format. --------------060301050209040606070908 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable For what it's worth, there was consideration of replacing protocol buffers when modifying BIP70 to function with the altcoin I work on (changes were required anyway in eliminate any risk that payment requests could not be accidentally applied to the wrong blockchain). The eventual conclusion was that while we might have used JSON or XML if we were starting from scratch, there's no choice that's clearly better. While deployed infrastructure for payment protocol is still quite limited, it seems that the cost to replace at this point is higher than n= ot. If there's ever a major reworking of the standard, for example to handle recurring payments, it's probably worth thinking about then, but protocol buffers result in a compact data format which is supported by most major languages (and size is a concern if dealing with Bluetooth or NFC), and has no major drawbacks I am aware of. Ross On 19/01/2015 20:40, Mike Hearn wrote: >> I'm a bit confused. It's been a long time since I looked at protobuf = (and >> will have to dig into it soon), but I seem to recall it doesn't have a= ny of >> the determinism properties you guys just said. >> > It's not guaranteed no, which is why we store signed sub-messages as by= te > arrays instead of typed submessages. In practice though, most > implementations do seem to serialise things the same way. I recall Pyth= on > used to be an odd one out, unsure if it still is. > > OK, I guess we can boil this down more simply. BIP 70 uses protocol buf= fers > because I designed it and implemented the original prototype (with lots= of > input from Gavin and an earlier proposal by sipa). I used protocol buff= ers > because, beyond all their nice properties, I used to work at Google and= so > was very familiar with them. > > > > -----------------------------------------------------------------------= ------- > New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in Ashbur= n. > Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely compliant= =2E > http://p.sf.net/sfu/gigenet > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --------------060301050209040606070908 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable For what it's worth, there was consideration of replacing protocol buffers when modifying BIP70 to function with the altcoin I work on (changes were required anyway in eliminate any risk that payment requests could not be accidentally applied to the wrong blockchain). The eventual conclusion was that while we might have used JSON or XML if we were starting from scratch, there's no choice that's clearly better. While deployed infrastructure for payment protocol is still quite limited, it seems that the cost to replace at this point is higher than not.

If there's ever a major reworking of the standard, for example to handle recurring payments, it's probably worth thinking about then, but protocol buffers result in a compact data format which is supported by most major languages (and size is a concern if dealing with Bluetooth or NFC), and has no major drawbacks I am aware of.

Ross

On 19/01/2015 20:40, Mike Hearn wrote:= 
I'm a bit confused.  It's been a long time since I looked at protobuf (an=
d
will have to dig into it soon), but I seem to recall it doesn't have any =
of
the determinism properties you guys just said.


It's not guaranteed no, which is why we store signed sub-messages as byte
arrays instead of typed submessages. In practice though, most
implementations do seem to serialise things the same way. I recall Python
used to be an odd one out, unsure if it still is.

OK, I guess we can boil this down more simply. BIP 70 uses protocol buffe=
rs
because I designed it and implemented the original prototype (with lots o=
f
input from Gavin and an earlier proposal by sipa). I used protocol buffer=
s
because, beyond all their nice properties, I used to work at Google and s=
o
was very familiar with them.




----------------------------------------------------=
--------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
h=
ttp://p.sf.net/sfu/gigenet


_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/l=
istinfo/bitcoin-development

--------------060301050209040606070908--