1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
|
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 <jgarzik@bitpay.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CAN5esQJe0uUm0NyctaBa6WH7_JjeE_OLR=FY_XQWnSr50VRDyA@mail.gmail.com>
<2109963.TWzmcrtnFv@crushinator>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Mon, 19 Jan 2015 14:38:23 -0500
Message-ID: <CAJHLa0NVt_X--pOu_ZNPeY+tT6UJDNdNJqiK9k6g4FTY6Z8B3A@mail.gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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 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
<div dir=3D"ltr"><div><div>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.<br><br></div>Google engineers were well aware it existed I'm sure.=
=C2=A0 There are wider considerations beyond the low-level specified format=
.<br><br></div>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.<br><br><br><div><br></div></di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Jan 19,=
2015 at 2:19 PM, Matt Whitlock <span dir=3D"ltr"><<a href=3D"mailto:bip=
@mattwhitlock.name" target=3D"_blank">bip@mattwhitlock.name</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">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.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
On Monday, 19 January 2015, at 7:07 pm, Richard Brady wrote:<br>
> Hi Gavin, Mike and co<br>
><br>
> Is there a strong driver behind the choice of Google Protocol Buffers =
for<br>
> payment request encoding in BIP-0070?<br>
><br>
> Performance doesn't feel that relevant when you think that:<br>
> 1. Payment requests are not broadcast, this is a request / response fl=
ow,<br>
> much more akin to a web request.<br>
> 2. One would be cramming this data into a binary format just so you ca=
n<br>
> then attach it to a no-so-binary format such as HTTP.<br>
><br>
> Some great things about protocols/encodings such as HTTP/JSON/XML are:=
<br>
> 1. They are human readable on-the-wire. No Wireshark plugin required,<=
br>
> tcpdump or ngrep will do.<br>
> 2. There are tons of great open source libraries and API for parsing /=
<br>
> manipulating / generating.<br>
> 3. It's really easy to hand-craft a test message for debugging.<br=
>
> 4. The standards are much easier to read and write. They don't nee=
d to<br>
> contain code like BIP-0070 currently does and they can contain example=
s,<br>
> which BIP70 does not.<br>
> 5. They are thoroughly specified by independent standards bodies such =
as<br>
> the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard.<br>
> 6. They're a family ;-)<br>
><br>
> 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<br>
> and I think that could be a fascinating use case for this protocol whi=
ch<br>
> I'm hoping to do some work on.<br>
><br>
> Best,<br>
> Richard<br>
<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">-----------------------=
-------------------------------------------------------<br>
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.<br>
GigeNET is offering a free month of service with a new server in Ashburn.<b=
r>
Choose from 2 high performing configs, both with 100TB of bandwidth.<br>
Higher redundancy.Lower latency.Increased capacity.Completely compliant.<br=
>
<a href=3D"http://p.sf.net/sfu/gigenet" target=3D"_blank">http://p.sf.net/s=
fu/gigenet</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=
=3D"gmail_signature">Jeff Garzik<br>Bitcoin core developer and open source =
evangelist<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.co=
m/" target=3D"_blank">https://bitpay.com/</a></div>
</div>
--047d7b33c906619f65050d0678c7--
|
