chromicant (OP)
Newbie
 Offline
Activity: 40
Merit: 0
|
 |
August 14, 2010, 10:08:00 PM |
|
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...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, but full nodes are more resource-heavy, and they must do a lengthy initial syncing process. As a result, lightweight clients with somewhat less security are commonly used.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
teknohog
|
|
August 14, 2010, 11:07:54 PM |
|
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?
|
|
|
|
MoonShadow
Legendary
Offline
Activity: 1708
Merit: 1007
|
|
August 15, 2010, 12:10:04 AM |
|
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
|
|
August 28, 2010, 06:10:50 PM |
|
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.
|
|
|
|
Gespenster
Newbie
Offline
Activity: 15
Merit: 0
|
|
August 29, 2010, 11:35:19 AM |
|
The ByteReverse macro should probably be skipped before doing SHA-256 transforms.
|
|
|
|
|
|
lfm
|
|
August 29, 2010, 04:41:10 PM |
|
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
Activity: 15
Merit: 0
|
|
August 29, 2010, 05:18:16 PM |
|
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
Offline
Activity: 364
Merit: 6723
|
|
August 29, 2010, 10:14:36 PM |
|
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.
|
|
|
|
|
|
