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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <rnbrady@gmail.com>) id 1YDHou-0005EK-03
for bitcoin-development@lists.sourceforge.net;
Mon, 19 Jan 2015 19:17:04 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.218.49 as permitted sender)
client-ip=209.85.218.49; envelope-from=rnbrady@gmail.com;
helo=mail-oi0-f49.google.com;
Received: from mail-oi0-f49.google.com ([209.85.218.49])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YDHop-000486-Sz
for bitcoin-development@lists.sourceforge.net;
Mon, 19 Jan 2015 19:17:03 +0000
Received: by mail-oi0-f49.google.com with SMTP id a3so4447903oib.8
for <bitcoin-development@lists.sourceforge.net>;
Mon, 19 Jan 2015 11:16:54 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.227.161 with SMTP id sb1mr19408252obc.80.1421695014515;
Mon, 19 Jan 2015 11:16:54 -0800 (PST)
Received: by 10.76.153.164 with HTTP; Mon, 19 Jan 2015 11:16:54 -0800 (PST)
In-Reply-To: <CAJHLa0OTynX4oiQoyanpRKE2tpAuS4L5X-2j20328725J9RrvQ@mail.gmail.com>
References: <CAN5esQJe0uUm0NyctaBa6WH7_JjeE_OLR=FY_XQWnSr50VRDyA@mail.gmail.com>
<CAJHLa0OTynX4oiQoyanpRKE2tpAuS4L5X-2j20328725J9RrvQ@mail.gmail.com>
Date: Mon, 19 Jan 2015 19:16:54 +0000
Message-ID: <CAN5esQJK4UnkQC=y6aT15txFekpptv32+5n4CbyR=6G6J7HF4A@mail.gmail.com>
From: Richard Brady <rnbrady@gmail.com>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: multipart/alternative; boundary=001a11c3581251c220050d062ab2
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(rnbrady[at]gmail.com)
-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: 1YDHop-000486-Sz
Cc: Bitcoin <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:17:04 -0000
--001a11c3581251c220050d062ab2
Content-Type: text/plain; charset=UTF-8
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
>>
>>
--001a11c3581251c220050d062ab2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">Fair points, although for me th=
e line is blurred between which of those are security considerations vs per=
formance considerations.</div><div class=3D"gmail_extra"><br></div><div cla=
ss=3D"gmail_extra">Richard</div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On 19 January 2015 at 19:09, Jeff Garzik <span dir=3D"ltr"=
><<a href=3D"mailto:jgarzik@bitpay.com" target=3D"_blank">jgarzik@bitpay=
.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">Text formats such as XML or JSON are far less deterministic, are more lo=
osely specified, have wide variance in parsing, are not very hash-able, the=
list goes on.<br><br></div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote"><div><div>On Mon, Jan 19, 2015 at 2:07 PM, Richard Brady <span d=
ir=3D"ltr"><<a href=3D"mailto:rnbrady@gmail.com" target=3D"_blank">rnbra=
dy@gmail.com</a>></span> wrote:<br></div></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div><div><div dir=3D"ltr">Hi Gavin, Mike and co<div><br></div><div>I=
s there a strong driver behind the choice of Google Protocol Buffers for pa=
yment request encoding in BIP-0070?</div><div><br></div><div>Performance do=
esn't feel that relevant when you think that:</div><div>1. Payment requ=
ests are not broadcast, this is a request / response flow, much more akin t=
o a web request.</div><div>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 HTT=
P.=C2=A0</div><div><br></div><div>Some great things about protocols/encodin=
gs such as HTTP/JSON/XML are:</div><div>1. They are human readable on-the-w=
ire. No Wireshark plugin required, tcpdump or ngrep will do.</div><div>2. T=
here are tons of great open source libraries and API for parsing / manipula=
ting / generating.</div><div>3. It's really easy to hand-craft a test m=
essage for debugging.<br></div><div>4. The standards are much easier to rea=
d and write. They don't need to contain code like BIP-0070 currently do=
es and they can contain examples, which BIP70 does not.=C2=A0</div><div>5. =
They are thoroughly specified by independent standards bodies such as the I=
ETF. Gotta love a bit of MUST / SHOULD / MAY in a standard.</div><div>6. Th=
ey're a family ;-)</div><div><br></div><div>Keen to hear your thoughts =
on this and very keen to watch the payment protocol grow regardless of enco=
ding choice! My background is SIP / VoIP and I think that could be a fascin=
ating use case for this protocol which I'm hoping to do some work on.</=
div><div><br></div><div>Best,</div><div>Richard</div><div><br></div></div><=
/div></div></blockquote></div></div></blockquote></div></div></div>
--001a11c3581251c220050d062ab2--
|
