summaryrefslogtreecommitdiff
path: root/d7/d5af6fe5530658cfc5131fede5650235ca659b
blob: ae78afa7048bb27868b54ef53b188af5956261b1 (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
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gmaxwell@gmail.com>) id 1V1qMc-0005fB-1c
	for bitcoin-development@lists.sourceforge.net;
	Wed, 24 Jul 2013 04:07:46 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.173 as permitted sender)
	client-ip=209.85.217.173; envelope-from=gmaxwell@gmail.com;
	helo=mail-lb0-f173.google.com; 
Received: from mail-lb0-f173.google.com ([209.85.217.173])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1V1qMa-0003qt-0n
	for bitcoin-development@lists.sourceforge.net;
	Wed, 24 Jul 2013 04:07:46 +0000
Received: by mail-lb0-f173.google.com with SMTP id v1so103889lbd.4
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 23 Jul 2013 21:07:37 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.45.65 with SMTP id k1mr16036645lam.78.1374638857201;
	Tue, 23 Jul 2013 21:07:37 -0700 (PDT)
Received: by 10.112.160.104 with HTTP; Tue, 23 Jul 2013 21:07:37 -0700 (PDT)
In-Reply-To: <10A07C03-7BAF-4312-9D43-827D03034EAE@grabhive.com>
References: <CANEZrP2GvgZP_1z3EoSs3p+db7tZB6JfEVAewLpGE5eRpGgR3w@mail.gmail.com>
	<CANg8-dAzc2ENivTpr6S=zoUkfGyBM6j=OUb8-_wLTFQqLRmnzw@mail.gmail.com>
	<8A6BD408-352F-4346-AF81-3C63BD0ED93B@jrbobdobbs.org>
	<10A07C03-7BAF-4312-9D43-827D03034EAE@grabhive.com>
Date: Tue, 23 Jul 2013 21:07:37 -0700
Message-ID: <CAAS2fgTxJTbOiUE1ueA8HD7fFimTx-QgWD2yLmbH1Y41i_Hp4g@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Wendell <w@grabhive.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.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
	(gmaxwell[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-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: 1V1qMa-0003qt-0n
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Endianness (was: Linux packaging letter)
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: Wed, 24 Jul 2013 04:07:46 -0000

On Tue, Jul 23, 2013 at 8:54 PM, Wendell <w@grabhive.com> wrote:
> Forking for curiosity's sake:
> Is there a substantial barrier to endian independence in the Bitcoin code=
base?

Not really. The software was originally written to write out memory
order to and from the wire, which is part of why the protocol is LE
everywhere, so fixing that much is pretty typical endianness fixes.
There is an extra kink in that almost everything Bitcoin sends and
receives is an authenticated data structure=E2=80=94 the stuff gets hashed =
for
authentication.  So that simply swizzling the byte order on
immediately on input isn't enough because sometimes you'll go on to
hash that data and it can't be in memory order for that.

Luke gave an initial crack at it a long time ago:
http://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin/commits/endian
But it wasn't enough yet.

Seems like its just enough of an undertaking that absent a really good
reason to care about it no real progress in fixing it is happening.