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
|
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 <jrn@jrn.me.uk>) id 1YDJfv-0006XK-GQ
for bitcoin-development@lists.sourceforge.net;
Mon, 19 Jan 2015 21:15:55 +0000
X-ACL-Warn:
Received: from hapkido.dreamhost.com ([66.33.216.122])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YDJft-0006Db-W0 for bitcoin-development@lists.sourceforge.net;
Mon, 19 Jan 2015 21:15:55 +0000
Received: from homiemail-a10.g.dreamhost.com (homie.mail.dreamhost.com
[208.97.132.208])
by hapkido.dreamhost.com (Postfix) with ESMTP id B803693954
for <bitcoin-development@lists.sourceforge.net>;
Mon, 19 Jan 2015 12:59:24 -0800 (PST)
Received: from homiemail-a10.g.dreamhost.com (localhost [127.0.0.1])
by homiemail-a10.g.dreamhost.com (Postfix) with ESMTP id 1CA1C28005E
for <bitcoin-development@lists.sourceforge.net>;
Mon, 19 Jan 2015 12:59:19 -0800 (PST)
Received: from [192.168.1.227] (cpc15-sgyl29-2-0-cust655.18-2.cable.virginm.net
[82.39.74.144])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: jrn@jrn.me.uk)
by homiemail-a10.g.dreamhost.com (Postfix) with ESMTPSA id 8CFE028006C
for <bitcoin-development@lists.sourceforge.net>;
Mon, 19 Jan 2015 12:59:18 -0800 (PST)
Message-ID: <54BD7024.5070008@jrn.me.uk>
Date: Mon, 19 Jan 2015 20:59:16 +0000
From: Ross Nicoll <jrn@jrn.me.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CAN5esQJe0uUm0NyctaBa6WH7_JjeE_OLR=FY_XQWnSr50VRDyA@mail.gmail.com> <CAJHLa0OTynX4oiQoyanpRKE2tpAuS4L5X-2j20328725J9RrvQ@mail.gmail.com> <2C7D6208-1921-4DDC-90FE-DB1ABE1D61DB@petertodd.org> <CAN5esQLCV=L0kYxDGhK2F=qZ8OqMxyYS+-Pn17U_M+nV4Sj3Og@mail.gmail.com> <54BD6314.60607@gmail.com>
<CANEZrP3ZdFcQsP+EWgTYQDccFZbrZFTk+xi-YdWPCJzMRH79pA@mail.gmail.com>
In-Reply-To: <CANEZrP3ZdFcQsP+EWgTYQDccFZbrZFTk+xi-YdWPCJzMRH79pA@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------060301050209040606070908"
X-Spam-Score: 0.9 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [66.33.216.122 listed in list.dnswl.org]
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: 1YDJft-0006Db-W0
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 21:15:55 -0000
This is a multi-part message in MIME format.
--------------060301050209040606070908
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
For what it's worth, there was consideration of replacing protocol
buffers when modifying BIP70 to function with the altcoin I work on
(changes were required anyway in eliminate any risk that payment
requests could not be accidentally applied to the wrong blockchain). The
eventual conclusion was that while we might have used JSON or XML if we
were starting from scratch, there's no choice that's clearly better.
While deployed infrastructure for payment protocol is still quite
limited, it seems that the cost to replace at this point is higher than n=
ot.
If there's ever a major reworking of the standard, for example to handle
recurring payments, it's probably worth thinking about then, but
protocol buffers result in a compact data format which is supported by
most major languages (and size is a concern if dealing with Bluetooth or
NFC), and has no major drawbacks I am aware of.
Ross
On 19/01/2015 20:40, Mike Hearn wrote:
>> I'm a bit confused. It's been a long time since I looked at protobuf =
(and
>> will have to dig into it soon), but I seem to recall it doesn't have a=
ny of
>> the determinism properties you guys just said.
>>
> It's not guaranteed no, which is why we store signed sub-messages as by=
te
> arrays instead of typed submessages. In practice though, most
> implementations do seem to serialise things the same way. I recall Pyth=
on
> used to be an odd one out, unsure if it still is.
>
> OK, I guess we can boil this down more simply. BIP 70 uses protocol buf=
fers
> because I designed it and implemented the original prototype (with lots=
of
> input from Gavin and an earlier proposal by sipa). I used protocol buff=
ers
> because, beyond all their nice properties, I used to work at Google and=
so
> was very familiar with them.
>
>
>
> -----------------------------------------------------------------------=
-------
> 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 Ashbur=
n.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant=
=2E
> http://p.sf.net/sfu/gigenet
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------060301050209040606070908
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dwindows-1252"
http-equiv=3D"Content-Type">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
For what it's worth, there was consideration of replacing protocol
buffers when modifying BIP70 to function with the altcoin I work on
(changes were required anyway in eliminate any risk that payment
requests could not be accidentally applied to the wrong blockchain).
The eventual conclusion was that while we might have used JSON or
XML if we were starting from scratch, there's no choice that's
clearly better. While deployed infrastructure for payment protocol
is still quite limited, it seems that the cost to replace at this
point is higher than not.<br>
<br>
If there's ever a major reworking of the standard, for example to
handle recurring payments, it's probably worth thinking about then,
but protocol buffers result in a compact data format which is
supported by most major languages (and size is a concern if dealing
with Bluetooth or NFC), and has no major drawbacks I am aware of.<br>
<br>
Ross<br>
<br>
<div class=3D"moz-cite-prefix">On 19/01/2015 20:40, Mike Hearn wrote:=
<br>
</div>
<blockquote
cite=3D"mid:CANEZrP3ZdFcQsP+EWgTYQDccFZbrZFTk+xi-YdWPCJzMRH79pA@mail.gmai=
l.com"
type=3D"cite">
<blockquote type=3D"cite">
<pre wrap=3D"">
I'm a bit confused. It's been a long time since I looked at protobuf (an=
d
will have to dig into it soon), but I seem to recall it doesn't have any =
of
the determinism properties you guys just said.
</pre>
</blockquote>
<pre wrap=3D"">
It's not guaranteed no, which is why we store signed sub-messages as byte
arrays instead of typed submessages. In practice though, most
implementations do seem to serialise things the same way. I recall Python
used to be an odd one out, unsure if it still is.
OK, I guess we can boil this down more simply. BIP 70 uses protocol buffe=
rs
because I designed it and implemented the original prototype (with lots o=
f
input from Gavin and an earlier proposal by sipa). I used protocol buffer=
s
because, beyond all their nice properties, I used to work at Google and s=
o
was very familiar with them.
</pre>
<br>
<fieldset class=3D"mimeAttachmentHeader"></fieldset>
<br>
<pre wrap=3D"">----------------------------------------------------=
--------------------------
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.
<a class=3D"moz-txt-link-freetext" href=3D"http://p.sf.net/sfu/gigenet">h=
ttp://p.sf.net/sfu/gigenet</a></pre>
<br>
<fieldset class=3D"mimeAttachmentHeader"></fieldset>
<br>
<pre wrap=3D"">_______________________________________________
Bitcoin-development mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:Bitcoin-development@=
lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://lists.sourceforge.net/=
lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/l=
istinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------060301050209040606070908--
|
