From: Jeff Garzik <jgarzik@bitpay•com>
To: Richard Brady <rnbrady@gmail•com>
Cc: Bitcoin <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?
Date: Mon, 19 Jan 2015 14:34:18 -0500 [thread overview]
Message-ID: <CAJHLa0MCv8kCZLJ2PkBdkDuPZBv4GTosYq-sfqjgri=bG65AMw@mail.gmail.com> (raw)
In-Reply-To: <CAN5esQJK4UnkQC=y6aT15txFekpptv32+5n4CbyR=6G6J7HF4A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2942 bytes --]
None of those listed were in the context of performance. Parsing of binary
or text is quite fast these days, and is not really a consideration versus
other needs such as a predictable encoding for a single data
representation. XML and JSON both can represent the same post-evaluation
user data a million different ways, which is awful for anything you are
signing and hashing. Text formats also transit binary data very poorly,
leading to unnecessary wrapping and unwrappiing (a programmatic, visibility
& bug; again performance not a primary concern).
This is evident because both XML and JSON have standards efforts under way
to correct some of these problems and make them more deterministic.
However, such standards are not field deployed and widely supported by
parsers and generators alike.
On Mon, Jan 19, 2015 at 2:16 PM, Richard Brady <rnbrady@gmail•com> wrote:
> Fair points, although for me the line is blurred between which of those
> are security considerations vs performance considerations.
>
> Richard
>
> On 19 January 2015 at 19:09, Jeff Garzik <jgarzik@bitpay•com> wrote:
>
>> Text formats such as XML or JSON are far less deterministic, are more
>> loosely specified, have wide variance in parsing, are not very hash-able,
>> the list goes on.
>>
>>
>> On Mon, Jan 19, 2015 at 2:07 PM, Richard Brady <rnbrady@gmail•com> wrote:
>>
>>> Hi Gavin, Mike and co
>>>
>>> Is there a strong driver behind the choice of Google Protocol Buffers
>>> for payment request encoding in BIP-0070?
>>>
>>> Performance doesn't feel that relevant when you think that:
>>> 1. Payment requests are not broadcast, this is a request / response
>>> flow, much more akin to a web request.
>>> 2. One would be cramming this data into a binary format just so you can
>>> then attach it to a no-so-binary format such as HTTP.
>>>
>>> Some great things about protocols/encodings such as HTTP/JSON/XML are:
>>> 1. They are human readable on-the-wire. No Wireshark plugin required,
>>> tcpdump or ngrep will do.
>>> 2. There are tons of great open source libraries and API for parsing /
>>> manipulating / generating.
>>> 3. It's really easy to hand-craft a test message for debugging.
>>> 4. The standards are much easier to read and write. They don't need to
>>> contain code like BIP-0070 currently does and they can contain examples,
>>> which BIP70 does not.
>>> 5. They are thoroughly specified by independent standards bodies such as
>>> the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard.
>>> 6. They're a family ;-)
>>>
>>> Keen to hear your thoughts on this and very keen to watch the payment
>>> protocol grow regardless of encoding choice! My background is SIP / VoIP
>>> and I think that could be a fascinating use case for this protocol which
>>> I'm hoping to do some work on.
>>>
>>> Best,
>>> Richard
>>>
>>>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
[-- Attachment #2: Type: text/html, Size: 4317 bytes --]
next prev parent reply other threads:[~2015-01-19 19:34 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
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='CAJHLa0MCv8kCZLJ2PkBdkDuPZBv4GTosYq-sfqjgri=bG65AMw@mail.gmail.com' \
--to=jgarzik@bitpay$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=rnbrady@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