From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Date: Mon, 17 Dec 2012 12:23:37 +0100 [thread overview]
Message-ID: <CAKaEYhLbeBfJeLtBJTkX6S-MbqdWuQrcpNKpY2Czhhk3T6frmA@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP1v9E1S1VA2p-pCzrobp8ueWZTf0r0stZ3JyJ==u_Zgxg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2388 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2918 bytes --]
next prev parent reply other threads:[~2012-12-17 11:23 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-26 22:37 [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts Gavin Andresen
2012-11-26 23:02 ` Mike Hearn
2012-11-26 23:13 ` Luke-Jr
2012-11-26 23:16 ` Mike Hearn
2012-11-26 23:19 ` Luke-Jr
2012-11-26 23:27 ` Mike Hearn
2012-11-26 23:32 ` Gregory Maxwell
2012-11-26 23:44 ` Luke-Jr
2012-11-27 0:16 ` Gregory Maxwell
2012-11-27 0:26 ` Mike Hearn
2012-11-27 0:45 ` Rick Wesson
2012-11-27 1:09 ` Gavin
2012-11-27 8:44 ` Mike Hearn
2012-11-27 0:44 ` Luke-Jr
2012-11-26 23:38 ` Rick Wesson
2012-11-26 23:52 ` Jeff Garzik
2012-11-27 0:02 ` Rick Wesson
2012-11-27 0:31 ` Luke-Jr
2012-11-27 0:37 ` Rick Wesson
2012-11-27 2:16 ` Walter Stanish
2012-11-27 2:47 ` Gregory Maxwell
2012-11-27 3:16 ` Walter Stanish
2012-11-27 3:29 ` Rick Wesson
2012-11-27 3:31 ` Walter Stanish
2012-11-27 3:54 ` Rick Wesson
2012-11-27 4:17 ` Walter Stanish
2012-11-27 8:43 ` Michael Gronager
2012-11-27 10:23 ` Mike Hearn
2012-11-27 10:42 ` Michael Gronager
2012-11-27 11:36 ` Pieter Wuille
2012-11-27 11:46 ` Michael Gronager
2012-11-27 12:03 ` Mike Hearn
2012-11-27 12:39 ` Michael Gronager
2012-11-27 14:05 ` Gavin Andresen
2012-11-27 14:26 ` Gavin Andresen
2012-11-28 13:55 ` Walter Stanish
2012-11-27 17:03 ` Andy Parkins
2012-11-27 17:14 ` Mike Hearn
2012-11-27 17:26 ` Andy Parkins
2012-11-27 18:16 ` Mike Hearn
2012-11-27 21:39 ` Gavin Andresen
2012-11-28 10:43 ` Mike Hearn
2012-11-28 12:57 ` Peter Todd
2012-11-28 14:09 ` Gavin Andresen
2012-11-28 8:33 ` Peter Todd
2012-11-28 23:36 ` Roy Badami
2012-11-29 0:30 ` Watson Ladd
2012-11-29 8:16 ` slush
2012-11-29 16:11 ` Gavin Andresen
2012-11-29 17:07 ` Roy Badami
2012-11-29 17:30 ` Gavin Andresen
2012-11-29 17:31 ` Mike Hearn
2012-11-29 18:53 ` Roy Badami
2012-12-01 19:25 ` Gavin Andresen
2012-12-03 19:35 ` Mike Koss
2012-12-03 20:59 ` Gavin Andresen
2012-12-03 21:28 ` Mike Hearn
2012-12-03 22:26 ` Roy Badami
2012-12-03 22:34 ` Jeff Garzik
2012-12-03 22:48 ` Roy Badami
2012-12-16 21:15 ` Melvin Carvalho
2012-12-17 2:18 ` Jeff Garzik
2012-12-17 8:24 ` Melvin Carvalho
2012-12-17 9:19 ` Mike Hearn
2012-12-17 9:31 ` Gary Rowe
2012-12-17 11:23 ` Melvin Carvalho [this message]
2012-12-17 17:57 ` Gavin Andresen
2012-12-20 16:53 ` Stephen Pair
2012-12-20 17:43 ` Mike Hearn
2012-12-20 19:32 ` Stephen Pair
2012-12-21 17:05 ` Stephen Pair
2012-12-24 0:38 ` Elden Tyrell
2012-12-04 17:06 ` Mike Hearn
2012-12-05 19:34 ` Gavin Andresen
2012-12-06 6:31 ` Andreas Petersson
2012-12-06 8:53 ` Mike Hearn
2012-12-06 16:56 ` Gavin Andresen
2012-12-06 17:55 ` Mike Hearn
2012-12-06 19:13 ` Gavin Andresen
2012-12-07 10:45 ` Mike Hearn
2012-12-07 11:01 ` Mike Hearn
2012-12-07 16:19 ` Gavin Andresen
2012-12-07 16:27 ` Mike Hearn
2012-12-06 18:13 ` Alan Reiner
[not found] ` <CALf2ePx5jS@mail.gmail.com>
2014-09-17 19:28 ` Vezalke
2012-12-03 21:42 ` Gregory Maxwell
2012-12-23 2:33 ` Mark Friedenbach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKaEYhLbeBfJeLtBJTkX6S-MbqdWuQrcpNKpY2Czhhk3T6frmA@mail.gmail.com \
--to=melvincarvalho@gmail.com \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=mike@plan99.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox