From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YDI9z-0007Vx-Ek for bitcoin-development@lists.sourceforge.net; Mon, 19 Jan 2015 19:38:51 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.218.43 as permitted sender) client-ip=209.85.218.43; envelope-from=jgarzik@bitpay.com; helo=mail-oi0-f43.google.com; Received: from mail-oi0-f43.google.com ([209.85.218.43]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YDI9x-0005ec-LF for bitcoin-development@lists.sourceforge.net; Mon, 19 Jan 2015 19:38:51 +0000 Received: by mail-oi0-f43.google.com with SMTP id z81so456736oif.2 for ; Mon, 19 Jan 2015 11:38:44 -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=Q/OSj3pJqYdnV3BHsHKrrXZAy7/MOtlztsowxaVz3Ic=; b=YtJBI60/ijMCW6+Xho8LACwZOBT3gfIM4m3hMuhgrL792pPLSCZ8GhM1O+g1r9mZiY mRSM4UW/W+S7Nn2YR5pzgYPEZ5QI4soXTHXuwEqNxi539MW7gZdAsqWR5q7KGt1TIeof UTAjg7mbARQ3zwJSaQAn1VulQEnBtWL76QPs9mHOqQvSJCyM7AtYIEb0yTmW8RMk9ya5 kvcJv7DQ81An5U01EpQ/gbNC5pGENK8XrRb/uk4r0SuRdKXB5++heUyMzFOpit/0eaE9 QpUAASf9Wi2nPFQN32nwxyYKHQIAEzuucFXCe/P6vMlLBftGMXunRSL/LKBt7MUCfTXx QYKA== X-Gm-Message-State: ALoCoQlWSwyF2dZesP+9W4qX1TQQEozsjRfmM2hLaE6z78xr8ZIDypn7u6VZNZ6EayvSYCXEDjT8 X-Received: by 10.60.125.130 with SMTP id mq2mr19495976oeb.50.1421696324176; Mon, 19 Jan 2015 11:38:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.219.196 with HTTP; Mon, 19 Jan 2015 11:38:23 -0800 (PST) In-Reply-To: <2109963.TWzmcrtnFv@crushinator> References: <2109963.TWzmcrtnFv@crushinator> From: Jeff Garzik Date: Mon, 19 Jan 2015 14:38:23 -0500 Message-ID: To: Matt Whitlock Content-Type: multipart/alternative; boundary=047d7b33c906619f65050d0678c7 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: 1YDI9x-0005ec-LF Cc: Bitcoin Dev 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:38:51 -0000 --047d7b33c906619f65050d0678c7 Content-Type: text/plain; charset=UTF-8 ASN.1 is not nearly as flexible when it comes to well-supported libraries, generators, and the ecosystem that surrounds the actual encoding. You don't see ASN.1 compilers + language support packages for [all popular programming languages], as you do with protobufs. Google engineers were well aware it existed I'm sure. There are wider considerations beyond the low-level specified format. Protobufs have their problems and aren't perfect, but ASN.1 ecosystem is far less developed in the programming ecosystem, far less approachable for programmers. BIP70 wouldn't have been as easily and widely adopted if ASN.1 had been chosen. On Mon, Jan 19, 2015 at 2:19 PM, Matt Whitlock wrote: > Even if a compact binary encoding is a high priority, there are more > "standard" choices than Google Protocol Buffers. For example, ASN.1 is a > very rigorously defined standard that has been around for decades, and > ASN.1 even has an XML encoding (XER) that is directly convertible to/from > the binary encoding (BER/DER), given the schema. In practice, I'm mostly > agnostic about what encoding is actually used in BIP70, and I wouldn't > fault BIP70 for choosing Google Protocol Buffers, but the very existence of > Protobuf perplexes me, as it apparently re-solves a problem that was solved > 40 years ago by ASN.1. It's as though the engineers at Google weren't aware > that ASN.1 existed. > > > On Monday, 19 January 2015, at 7: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 > > > ------------------------------------------------------------------------------ > 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 > -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ --047d7b33c906619f65050d0678c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
ASN.1 is not nearly as flexible when it comes to= well-supported libraries, generators, and the ecosystem that surrounds the= actual encoding.=C2=A0 You don't see ASN.1 compilers + language suppor= t packages for [all popular programming languages], as you do with protobuf= s.

Google engineers were well aware it existed I'm sure.= =C2=A0 There are wider considerations beyond the low-level specified format= .

Protobufs have their problems and aren't perfect, but AS= N.1 ecosystem is far less developed in the programming ecosystem, far less = approachable for programmers.=C2=A0 BIP70 wouldn't have been as easily = and widely adopted if ASN.1 had been chosen.




On Mon, Jan 19,= 2015 at 2:19 PM, Matt Whitlock <bip@mattwhitlock.name> = wrote:
Even if a compact binary encoding = is a high priority, there are more "standard" choices than Google= Protocol Buffers. For example, ASN.1 is a very rigorously defined standard= that has been around for decades, and ASN.1 even has an XML encoding (XER)= that is directly convertible to/from the binary encoding (BER/DER), given = the schema. In practice, I'm mostly agnostic about what encoding is act= ually used in BIP70, and I wouldn't fault BIP70 for choosing Google Pro= tocol Buffers, but the very existence of Protobuf perplexes me, as it appar= ently re-solves a problem that was solved 40 years ago by ASN.1. It's a= s though the engineers at Google weren't aware that ASN.1 existed.


On Monday, 19 January 2015, at 7: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 fl= ow,
> much more akin to a web request.
> 2. One would be cramming this data into a binary format just so you ca= n
> 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,<= br> > 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 nee= d to
> contain code like BIP-0070 currently does and they can contain example= s,
> 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<= br> > protocol grow regardless of encoding choice! My background is SIP / Vo= IP
> and I think that could be a fascinating use case for this protocol whi= ch
> I'm hoping to do some work on.
>
> Best,
> Richard

-----------------------= -------------------------------------------------------
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/s= fu/gigenet
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment



--
Jeff Garzik
Bitcoin core developer and open source = evangelist
BitPay, Inc. =C2=A0 =C2=A0 =C2=A0https://bitpay.com/
--047d7b33c906619f65050d0678c7--