Bitcoin Forum
September 26, 2016, 08:49:19 AM *
News: Due to DDoS attacks, there may be periodic downtime.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Big endinan code problems  (Read 1542 times)
chromicant
Jr. Member
*
Offline Offline

Activity: 40


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

1474879759
Hero Member
*
Offline Offline

Posts: 1474879759

View Profile Personal Message (Offline)

Ignore
1474879759
Reply with quote  #2

1474879759
Report to moderator
1474879759
Hero Member
*
Offline Offline

Posts: 1474879759

View Profile Personal Message (Offline)

Ignore
1474879759
Reply with quote  #2

1474879759
Report to moderator
Each block is stacked on top of the previous one. Adding another block to the top makes all lower blocks more difficult to remove: there is more "weight" above each block. A transaction in a block 6 blocks deep (6 confirmations) will be very difficult to remove.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1474879759
Hero Member
*
Offline Offline

Posts: 1474879759

View Profile Personal Message (Offline)

Ignore
1474879759
Reply with quote  #2

1474879759
Report to moderator
1474879759
Hero Member
*
Offline Offline

Posts: 1474879759

View Profile Personal Message (Offline)

Ignore
1474879759
Reply with quote  #2

1474879759
Report to moderator
1474879759
Hero Member
*
Offline Offline

Posts: 1474879759

View Profile Personal Message (Offline)

Ignore
1474879759
Reply with quote  #2

1474879759
Report to moderator
teknohog
Sr. Member
****
Offline Offline

Activity: 410


minor developer


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?

MoonShadow
Legendary
*
Offline Offline

Activity: 1666



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: 410


minor developer


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.

Gespenster
Newbie
*
Offline Offline

Activity: 15


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



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


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


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:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!