diff options
| author | Melvin Carvalho <melvincarvalho@gmail.com> | 2012-12-17 12:23:37 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2012-12-17 11:23:46 +0000 |
| commit | dedcd39977bf8487cfdea76468ffd7f6ab93313a (patch) | |
| tree | be15b9f664aed6d663c4727a47ff0eb171eb4f37 | |
| parent | 1075ded839349fada0e7e4dda776e79ad576cc3f (diff) | |
| download | pi-bitcoindev-dedcd39977bf8487cfdea76468ffd7f6ab93313a.tar.gz pi-bitcoindev-dedcd39977bf8487cfdea76468ffd7f6ab93313a.zip | |
Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
| -rw-r--r-- | 42/38007f6e61c1435af635c41e03091d29401bf0 | 180 |
1 files changed, 180 insertions, 0 deletions
diff --git a/42/38007f6e61c1435af635c41e03091d29401bf0 b/42/38007f6e61c1435af635c41e03091d29401bf0 new file mode 100644 index 000000000..392e168d6 --- /dev/null +++ b/42/38007f6e61c1435af635c41e03091d29401bf0 @@ -0,0 +1,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-- + + |