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 1YDI61-0006dm-8Z for bitcoin-development@lists.sourceforge.net; Mon, 19 Jan 2015 19:34:45 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.214.175 as permitted sender) client-ip=209.85.214.175; envelope-from=jgarzik@bitpay.com; helo=mail-ob0-f175.google.com; Received: from mail-ob0-f175.google.com ([209.85.214.175]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YDI5z-00087i-TG for bitcoin-development@lists.sourceforge.net; Mon, 19 Jan 2015 19:34:45 +0000 Received: by mail-ob0-f175.google.com with SMTP id wp4so9382022obc.6 for ; Mon, 19 Jan 2015 11:34:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=P6JZmaz2mB7uQ8q1QDjdwKOrOoTmJWuJg68PrNVUIjU=; b=mXkfJC6umyqjHDswTlt6hSzefIjSnRyjD94J5TWvQUuWJwW+vOyu+l1nOplMBj9NrY /gOAFpFP3vX5w9nUfLAzyLgkqycUaMXTOwpUDJq1uoHfZQ3xWDD+ufZBo5GMGcmPkkRp t9GkAUrxz0WPxuLTaKWarM77npRii1feFK2C8MlFZVTyoBRNhAEL9+OD3Y2bphtETycf M0jqOUwKblo78zCyf/+jFpHmOILDfNVM20i3wyO4RNSc5fZu6kFDLLYEZLqBWB5+m9K2 U515Wi/4eQTIjhCLPH1YyfIzctlmA5tt2nxAuTeN/10eGCWCqZX8AkBMoFqGv7w0Rrd7 8QXg== X-Gm-Message-State: ALoCoQlOktc9aEjfIa19sCdnly2rTcF5LwupjBlVNOiEdwDIFU1zY8UOdjEcGyEgT7XxEk93BPe+ X-Received: by 10.202.86.85 with SMTP id k82mr4810557oib.42.1421696078477; Mon, 19 Jan 2015 11:34:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.219.196 with HTTP; Mon, 19 Jan 2015 11:34:18 -0800 (PST) In-Reply-To: References: From: Jeff Garzik Date: Mon, 19 Jan 2015 14:34:18 -0500 Message-ID: To: Richard Brady Content-Type: multipart/alternative; boundary=001a113df0ecbc93cb050d06694c 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 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: 1YDI5z-00087i-TG Cc: Bitcoin 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 19:34:45 -0000 --001a113df0ecbc93cb050d06694c Content-Type: text/plain; charset=UTF-8 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 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 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 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/ --001a113df0ecbc93cb050d06694c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
None of those listed were in the context of performan= ce.=C2=A0 Parsing of binary or text is quite fast these days, and is not re= ally a consideration versus other needs such as a predictable encoding for = a single data representation.=C2=A0 XML and JSON both can represent the sam= e post-evaluation user data a million different ways, which is awful for an= ything you are signing and hashing.=C2=A0 Text formats also transit binary = data very poorly, leading to unnecessary wrapping and unwrappiing (a progra= mmatic, 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 deterministi= c.=C2=A0 However, such standards are not field deployed and widely supporte= d by parsers and generators alike.




On Mon, Jan 19, 2015 at 2= :16 PM, Richard Brady <rnbrady@gmail.com> wrote:
Fair poi= nts, although for me the line is blurred between which of those are securit= y 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 les= s 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 Go= ogle Protocol Buffers for payment request encoding in BIP-0070?
<= br>
Performance doesn't feel that relevant when you think tha= t:
1. Payment requests are not broadcast, this is a request / res= ponse flow, much more akin to a web request.
2. One would be cram= ming this data into a binary format just so you can then attach it to a no-= so-binary format such as HTTP.=C2=A0

Some great th= ings about protocols/encodings such as HTTP/JSON/XML are:
1. They= are human readable on-the-wire. No Wireshark plugin required, tcpdump or n= grep will do.
2. There are tons of great open source libraries an= d API for parsing / manipulating / generating.
3. It's really= easy to hand-craft a test message for debugging.
4. The stan= dards are much easier to read and write. They don't need to contain cod= e like BIP-0070 currently does and they can contain examples, which BIP70 d= oes not.=C2=A0
5. They are thoroughly specified by independent st= andards 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 prot= ocol 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 evangelistBitPay, Inc. =C2=A0 =C2=A0 =C2=A0https://bitpay.com/
--001a113df0ecbc93cb050d06694c--