summaryrefslogtreecommitdiff
path: root/bd/faf2e0ff5f0368598dcdf3bd46ad0a886a8d19
blob: 50c5c2e6767767ccfa09b2630ef4617a55548726 (plain)
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
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 <roy@gnomon.org.uk>) id 1Tfeon-00037C-Dl
	for bitcoin-development@lists.sourceforge.net;
	Mon, 03 Dec 2012 22:48:53 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gnomon.org.uk
	designates 93.93.131.22 as permitted sender)
	client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk;
	helo=darla.gnomon.org.uk; 
Received: from darla.gnomon.org.uk ([93.93.131.22])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1Tfeol-0008WB-HR
	for bitcoin-development@lists.sourceforge.net;
	Mon, 03 Dec 2012 22:48:53 +0000
Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1])
	by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id qB3MmQ61028141
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 3 Dec 2012 22:48:31 GMT (envelope-from roy@darla.gnomon.org.uk)
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.95.3 at darla.gnomon.org.uk
Received: (from roy@localhost)
	by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id qB3MmQYx028140;
	Mon, 3 Dec 2012 17:48:26 -0500 (EST) (envelope-from roy)
Date: Mon, 3 Dec 2012 17:48:26 -0500
From: Roy Badami <roy@gnomon.org.uk>
To: Jeff Garzik <jgarzik@exmulti.com>
Message-ID: <20121203224825.GL6368@giles.gnomon.org.uk>
References: <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>
	<CANEZrP3sU9-J0O9UcP7z0tDRDOwajiH+OWMnPaNL3WKnYa9F9w@mail.gmail.com>
	<20121203222629.GK6368@giles.gnomon.org.uk>
	<CA+8xBpdc2jcNVJk6+CChfGObDb0Mj9dhZjzQ4G1goCVx1Yy-8A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+8xBpdc2jcNVJk6+CChfGObDb0Mj9dhZjzQ4G1goCVx1Yy-8A@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
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 SPF_HELO_PASS          SPF: HELO matches SPF record
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain
X-Headers-End: 1Tfeol-0008WB-HR
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 22:48:53 -0000

On Mon, Dec 03, 2012 at 05:34:12PM -0500, Jeff Garzik wrote:
> You shouldn't need to escape and unescape data that is not being
> interpreted in any way.

Funilly enough pretty much all low-level links that make up the
Internet use either bit-stuffing or byte-stuffing to escape a
particular bit sequence or byte that terminates an HDLC frame.

I'm not particularly agreeing or disagreeing with you on the
suitability for the case at hand, but as an absolute your statement
doesn't hold water.  The use of a terminator for a variable-length
data structure rather than a length prefix is a design desicion that
has little-to-nothing to do with the debate of text-versus-binary.

Anyone remember Holerith constants?

roy