Big endinan code problems

I’ve seen a lot of messages about some big-endian “issues” (ok, no worky) with the bitcoin client. Before I sit and try to analyze all the source code, are there any known “bad bits” of the code that assume LE?

I have some idle G4 and Sparc machines that can happily be put to use…plus an old decrepit Alpha that needs to be tested to see if it still boots…

The ByteReverse macro should probably be skipped before doing SHA-256 transforms.

The ByteReverse macro should probably be skipped before doing SHA-256 transforms.

before and after? theres several ByteReverse calls that probably need removal for the nonce ant the timestamp also.

in fact you may be able to do away completely with the temp block header thats mostly just there so it can be ByteReversed.

Quote from: Gespenster on August 29, 2010, 2:35:19 AM UTC

The ByteReverse macro should probably be skipped before doing SHA-256 transforms.

before and after? theres several ByteReverse calls that probably need removal for the nonce ant the timestamp also.

in fact you may be able to do away completely with the temp block header thats mostly just there so it can be ByteReversed.

I think all of them can go away since SHA-256 expects it’s bytestream to be big-endian. The fastest way to find out I think is to run the code through a debugger on both a BE and LE machine at the same time and compare results at every step.

The code assumes little-endian throughout and was written with the intention of never being ported to big-endian.  Every integer that is sent over the network would have to be byte swapped, in addition to many dozens of other places in code.  It would not be worth the extra sourcecode bloat.

Big-endian is on its way out anyway.