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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1TfdYs-0006ax-Fw
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Dec 2012 21:28:22 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.47 as permitted sender)
client-ip=209.85.219.47; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f47.google.com;
Received: from mail-oa0-f47.google.com ([209.85.219.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TfdYo-0003Y6-MK
for bitcoin-development@lists.sourceforge.net;
Mon, 03 Dec 2012 21:28:22 +0000
Received: by mail-oa0-f47.google.com with SMTP id h1so3416574oag.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 03 Dec 2012 13:28:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.32.73 with SMTP id g9mr3554682oei.134.1354570093358; Mon,
03 Dec 2012 13:28:13 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.128.139 with HTTP; Mon, 3 Dec 2012 13:28:13 -0800 (PST)
In-Reply-To: <CAErK2ChjAm-Zf11YXuBQeTQvahOEJNGiPSZaD-CQ=OU9K6HtZA@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>
Date: Mon, 3 Dec 2012 22:28:13 +0100
X-Google-Sender-Auth: 2PPdcLRZmVdStecze_K-1oZ1czw
Message-ID: <CANEZrP3sU9-J0O9UcP7z0tDRDOwajiH+OWMnPaNL3WKnYa9F9w@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Mike Koss <mike@coinlab.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.5 (-)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: 1TfdYo-0003Y6-MK
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, 03 Dec 2012 21:28:22 -0000
> It would also be really nice to migrate to textual representations of data
> structures as opposed to binary ones. The most successful internet
> standards are based on text.
There are lots of successful binary protocols: TCP, IP, PNG, JPEG,
MP3, DNS, SSH, SSL, the Bitcoin protocol itself. What's more some
other protocols that are text based have suffered serious problems due
to that choice. Witness the absurd design of SMTP that means you can't
start a paragraph with the word From because that's a new-message
marker! Or the fact that file attachments grow by 33% when you send
them. Or the various exploits that can exist in web servers thanks to
header splitting attacks.
Trying to represent something binary as text doesn't make any sense.
If you look at these data structures they consist of keys, signatures,
hashes, certificates and other fundamentally binary things. You'd just
end up base64 encoding everything anyway, at which point all you've
done is design an inefficient binary protocol that masquerades as
text. The disadvantages of both with the advantages of neither.
Protocol buffers have a text form that you can print to and parse
from, if you so wish, though I only normally see people use that
support for debug prints and sometimes because they want to load
hand-written config files directly into protobuf generated objects.
|
