Bitcoin Forum
December 09, 2024, 03:52:34 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Big endinan code problems  (Read 8256 times)
chromicant (OP)
Newbie
*
Offline Offline

Activity: 40
Merit: 0


View Profile
August 14, 2010, 10:08:00 PM
 #1

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...
teknohog
Sr. Member
****
Offline Offline

Activity: 520
Merit: 253


555


View Profile WWW
August 14, 2010, 11:07:54 PM
 #2

I also have a couple of G4 machines, but I think this issue is about much more than getting these old(ish) machines to good use. It is something like the Y2038 problem that some people are already discussing; will everyone keep using x86 all those decades, or should we drop the assumption of that particular architecture?

It is a nice fact that bitcoin happens to compile and run on ARM, one of the most serious contenders of the x86 monopoly, at least in the mobile and embedded space. Nevertheless, a digital currency is too important to be limited in computing architectures. Don't banks tend to use big iron?

world famous math art | masternodes are bad, mmmkay?
Every sha(sha(sha(sha()))), every ho-o-o-old, still shines
MoonShadow
Legendary
*
Offline Offline

Activity: 1708
Merit: 1010



View Profile
August 15, 2010, 12:10:04 AM
 #3

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...

Do you think that you might have replaced them sometime in the next 28 years?

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
teknohog
Sr. Member
****
Offline Offline

Activity: 520
Merit: 253


555


View Profile WWW
August 28, 2010, 06:10:50 PM
 #4

I have been thinking about an interim solution, inspired by the fact that many architectures can run in either endianness. AFAIK, Virtual PC used this feature of the PowerPC to run Windows on a Mac. Apparently, Linux also supports running little-endian PPC binaries on an otherwise big-endian system.

It will not be as simple as compiling with -mlittle-endian, as the libraries should likely have the same endianness. It might be possible to cross-compile a little-endian system, compile a static binary in the chroot, and run the resulting binary in the usual big-endian system. Or it could be running in the chroot, if that is easier to accomplish.

So far, I have not managed to build such a system, but it might be possible with a suitable cross-compiler. I already use Gentoo and Crossdev for such things, but I have not found a suitable target machine type for this.

world famous math art | masternodes are bad, mmmkay?
Every sha(sha(sha(sha()))), every ho-o-o-old, still shines
Gespenster
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
August 29, 2010, 11:35:19 AM
 #5

The ByteReverse macro should probably be skipped before doing SHA-256 transforms.
lfm
Full Member
***
Offline Offline

Activity: 196
Merit: 104



View Profile
August 29, 2010, 04:41:10 PM
 #6

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.

Gespenster
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
August 29, 2010, 05:18:16 PM
 #7

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.
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364
Merit: 7424


View Profile
August 29, 2010, 10:14:36 PM
 #8

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.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!