From: Ross Nicoll <jrn@jrn.me.uk>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
Date: Mon, 19 Jan 2015 20:59:16 +0000 [thread overview]
Message-ID: <54BD7024.5070008@jrn.me.uk> (raw)
In-Reply-To: <CANEZrP3ZdFcQsP+EWgTYQDccFZbrZFTk+xi-YdWPCJzMRH79pA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2414 bytes --]
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 (and
>> 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 buffers
> because I designed it and implemented the original prototype (with lots of
> input from Gavin and an earlier proposal by sipa). I used protocol buffers
> 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 Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 3425 bytes --]
next prev parent reply other threads:[~2015-01-19 21:15 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-19 19:07 [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding? 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 [this message]
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
2015-01-28 12:45 Nicolas DORIER
2015-01-28 13:32 ` Wladimir
2015-01-28 14:00 ` Nicolas DORIER
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
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=54BD7024.5070008@jrn.me.uk \
--to=jrn@jrn.me.uk \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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