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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <melvincarvalho@gmail.com>) id 1TkYnS-0004Wd-1J
for bitcoin-development@lists.sourceforge.net;
Mon, 17 Dec 2012 11:23:46 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.175 as permitted sender)
client-ip=209.85.223.175; envelope-from=melvincarvalho@gmail.com;
helo=mail-ie0-f175.google.com;
Received: from mail-ie0-f175.google.com ([209.85.223.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TkYnO-0005he-MS
for bitcoin-development@lists.sourceforge.net;
Mon, 17 Dec 2012 11:23:45 +0000
Received: by mail-ie0-f175.google.com with SMTP id qd14so8547112ieb.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 17 Dec 2012 03:23:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.179.99 with SMTP id df3mr8624497igc.20.1355743417425; Mon,
17 Dec 2012 03:23:37 -0800 (PST)
Received: by 10.42.61.203 with HTTP; Mon, 17 Dec 2012 03:23:37 -0800 (PST)
In-Reply-To: <CANEZrP1v9E1S1VA2p-pCzrobp8ueWZTf0r0stZ3JyJ==u_Zgxg@mail.gmail.com>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
<20121128233619.GA6368@giles.gnomon.org.uk>
<CABsx9T09FYf2RTaMpmujt3qwTFc2JgnREH_7Hyk2mnCgb3CvAw@mail.gmail.com>
<20121129170713.GD6368@giles.gnomon.org.uk>
<CANEZrP233CytLs3PWBQ1TyuBTMv4sLGJkEMeGWYq5xRi+iLKew@mail.gmail.com>
<20121129185330.GE6368@giles.gnomon.org.uk>
<CABsx9T35qD_xJEVw002eAhJ1kr6x5aMU7RpD+U84XEOZXmXcYw@mail.gmail.com>
<CAErK2ChjAm-Zf11YXuBQeTQvahOEJNGiPSZaD-CQ=OU9K6HtZA@mail.gmail.com>
<CAKaEYh+OUD4kfxwSNQBCJXmj6Kwb8jy9Au=Mfrqr2sKv7SuHpg@mail.gmail.com>
<CA+8xBpeya92UR60_ba+xYycjONOOvYUcW4Fe+SNdWwpg7aWEHw@mail.gmail.com>
<CAKaEYh+jJn0dPsGn_RnOy3NmWMc0F12Dffx2jYBUA=z+W45fWA@mail.gmail.com>
<CANEZrP1v9E1S1VA2p-pCzrobp8ueWZTf0r0stZ3JyJ==u_Zgxg@mail.gmail.com>
Date: Mon, 17 Dec 2012 12:23:37 +0100
Message-ID: <CAKaEYhLbeBfJeLtBJTkX6S-MbqdWuQrcpNKpY2Czhhk3T6frmA@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=14dae9340347cd60fa04d10a9ca3
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
(melvincarvalho[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: 1TkYnO-0005he-MS
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
Invoices/Payments/Receipts
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, 17 Dec 2012 11:23:46 -0000
--14dae9340347cd60fa04d10a9ca3
Content-Type: text/plain; charset=ISO-8859-1
On 17 December 2012 10:19, Mike Hearn <mike@plan99.net> wrote:
> Can we please drop the binary vs text issue? We have been around it
> millions of times already. There are no compelling arguments to use
> text here and several obvious problems with it. If you think you've
> found a good argument to use JSON, please research protocol buffers
> more thoroughly and see if it changes your mind.
>
Hi Mike, thanks you for the pointer. I have read up on Protocol Buffers.
If the decision has already been made, then let's go with that, but if not
perhaps I can offer some comments.
Looking at:
http://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats
And -- "Canonically, Protocol Buffers are serialized into a binary wire
format which is compact, forwards-compatible, backwards-compatible, but not
self-describing"
I can see there are advantages in this approach in that you can send
messages quickly and with low bandwidth. However the non self describing
data means that it's significantly harder to convert from one format to
another. Also references are important, and can be achieved in JSON.
Yet in my opinion there is great advantage to growing the bitcoin ecosystem
to interoperate with the whole net, kind of creating a complete web
economy. The way to do this is to foster interoperability. Having looked
at and worked with standards for the past 5-10 years that is the great
challenge. Every system works in an island, and few talk to any others.
However, a market based economy grows exponentially more valuable with
extra liquidity.
Inventing yet another format may lead to balkanization. If history is a
judge, the chances are high. A self describing JSON format, however is
much more likely to interop.
I can understand the hesitation with JOSE. However, if you get a moment,
please look at :
http://payswarm.com/specs/source/web-keys/
This should provide some of the tools that you need.
As I said above, if the matter is closed, that's fine and thanks for taking
the time to read.
Can I at least propose to make it mandatory for the binary format to have a
translation script to a self describing JSON format and back again. I
would love to see the bitcoin ecosystem become a major part of the
infrastructure of the web itself (leading to even nice things like a proper
web of trust), as well as an awesome P2P system in its own right.
--14dae9340347cd60fa04d10a9ca3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br><div class=3D"gmail_quote">On 17 December 2012 10:19, Mike Hearn <s=
pan dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mi=
ke@plan99.net</a>></span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Can we please drop the binary vs text issue? We have been around it<br>
millions of times already. There are no compelling arguments to use<br>
text here and several obvious problems with it. If you think you've<br>
found a good argument to use JSON, please research protocol buffers<br>
more thoroughly and see if it changes your mind. <br></blockquote><div><br>=
Hi Mike, thanks you for the pointer.=A0 I have read up on Protocol Buffers.=
<br><br>If the decision has already been made, then let's go with that,=
but if not perhaps I can offer some comments.<br>
<br>Looking at:<br><br><a href=3D"http://en.wikipedia.org/wiki/Comparison_o=
f_data_serialization_formats">http://en.wikipedia.org/wiki/Comparison_of_da=
ta_serialization_formats</a><br><br>And -- "Canonically, Protocol Buff=
ers are serialized into a binary wire format=20
which is compact, forwards-compatible, backwards-compatible, but not=20
self-describing"<br><br>I can see there are advantages in this approac=
h in that you can send messages quickly and with low bandwidth.=A0 However =
the non self describing data means that it's significantly harder to co=
nvert from one format to another.=A0 Also references are important, and can=
be achieved in JSON.<br>
<br>Yet in my opinion there is great advantage to growing the bitcoin ecosy=
stem to interoperate with the whole net, kind of creating a complete web ec=
onomy.=A0 The way to do this is to foster interoperability.=A0 Having looke=
d at and worked with standards for the past 5-10 years that is the great ch=
allenge.=A0 Every system works in an island, and few talk to any others.=A0=
However, a market based economy grows exponentially more valuable with ext=
ra liquidity.<br>
=A0<br></div></div>Inventing yet another format may lead to balkanization.=
=A0 If history is a judge, the chances are high.=A0 A self describing JSON =
format, however is much more likely to interop.=A0 <br><br>I can understand=
the hesitation with JOSE.=A0 However, if you get a moment, please look at =
:<br>
<br><a href=3D"http://payswarm.com/specs/source/web-keys/">http://payswarm.=
com/specs/source/web-keys/</a><br><br>This should provide some of the tools=
that you need.<br><br>As I said above, if the matter is closed, that's=
fine and thanks for taking the time to read.=A0 <br>
<br>Can I at least propose to make it mandatory for the binary format to ha=
ve a translation script to a self describing JSON format and back again.=A0=
I would love to see the bitcoin ecosystem become a major part of the infra=
structure of the web itself (leading to even nice things like a proper web =
of trust), as well as an awesome P2P system in its own right.<br>
--14dae9340347cd60fa04d10a9ca3--
|
