Bitcoin Forum
December 05, 2016, 10:53:38 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: bitcoin generation broken in 0.3.8? (64-bit)  (Read 4326 times)
knightmb
Sr. Member
****
Offline Offline

Activity: 308


Timekoin - Save Electricity, Don't Waste It!


View Profile WWW
August 08, 2010, 06:27:50 PM
 #21

After testing the 32bit and 64bit builds, the problem I can confirm what was already posted here, it just affects the 64bit builds. When I go back and trace what's being produced, it's the 64bit Linux machines (the 64bit windows machines don't appear to have this problem) that aren't producing any coin since the latest releases. All of the 32bit builds (stock or custom) appear to be just fine.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480935218
Hero Member
*
Offline Offline

Posts: 1480935218

View Profile Personal Message (Offline)

Ignore
1480935218
Reply with quote  #2

1480935218
Report to moderator
1480935218
Hero Member
*
Offline Offline

Posts: 1480935218

View Profile Personal Message (Offline)

Ignore
1480935218
Reply with quote  #2

1480935218
Report to moderator
1480935218
Hero Member
*
Offline Offline

Posts: 1480935218

View Profile Personal Message (Offline)

Ignore
1480935218
Reply with quote  #2

1480935218
Report to moderator
knightmb
Sr. Member
****
Offline Offline

Activity: 308


Timekoin - Save Electricity, Don't Waste It!


View Profile WWW
August 08, 2010, 06:32:27 PM
 #22

Did you compile it yourself? There's a define in makefile.unix. Something like -DCRYPTOPP_DISABLE_SSE2. Remove that. Else the SHA256_Transform will return the initstate. I had the same problem when switchting to 0.3.6.
This works for the 64bit builds, strange that it has no affect on the 32bit builds? Should it be disabled for 32bit builds as well?

tcatm
Sr. Member
****
qt
Offline Offline

Activity: 337


View Profile
August 08, 2010, 06:49:15 PM
 #23

I don't really know what it changes. I wonder why the define was made in the first place. The code should be able to determine whether it's running on a SSE2 CPU or not. I discovered it while comparing my 4xSSE2 hash function to the original one in 0.3.6 so it really means, that no 64bit build since 0.3.6 was able to generate any coins. Maybe satoshi can tell us why he put the define in the makefile.
ArtForz
Sr. Member
****
Offline Offline

Activity: 406


View Profile
August 09, 2010, 12:31:45 AM
 #24

Just had a "fun" gdb session with the official 0.3.8 linux 64 bit binary on debian sid.
Same bug, output state on return from SHA256Transform always == initial state.
So... did someone really generate a block running the official 0.3.8 64 bit linux binary (the one in bin/64)?
Oh, and from a quick glance at the svn changelog, that bug probably has been there since r118 = 0.3.6.
Oh, and who THE FUCK thought stripping the official binary was a good idea? I just wasted half an hour hunting down SHA256Transform in a disassembler.

bitcoin: 1Fb77Xq5ePFER8GtKRn2KDbDTVpJKfKmpz
i0coin: jNdvyvd6v6gV3kVJLD7HsB5ZwHyHwAkfdw
knightmb
Sr. Member
****
Offline Offline

Activity: 308


Timekoin - Save Electricity, Don't Waste It!


View Profile WWW
August 09, 2010, 01:16:31 AM
 #25

Just had a "fun" gdb session with the official 0.3.8 linux 64 bit binary on debian sid.
Same bug, output state on return from SHA256Transform always == initial state.
So... did someone really generate a block running the official 0.3.8 64 bit linux binary (the one in bin/64)?
Oh, and from a quick glance at the svn changelog, that bug probably has been there since r118 = 0.3.6.
Oh, and who THE FUCK thought stripping the official binary was a good idea? I just wasted half an hour hunting down SHA256Transform in a disassembler.


Not on 64bit linux, just 32bit and 64bit everything else in between (Linux/Windows)

I didn't notice until I checked the generation dates against the release dates of the software.

If you don't strip the debug symbols the binary is 8 times it's normal size.

lachesis
Full Member
***
Offline Offline

Activity: 210


View Profile
August 09, 2010, 02:05:51 AM
 #26

Just had a "fun" gdb session with the official 0.3.8 linux 64 bit binary on debian sid.
Same bug, output state on return from SHA256Transform always == initial state.
So... did someone really generate a block running the official 0.3.8 64 bit linux binary (the one in bin/64)?
Oh, and from a quick glance at the svn changelog, that bug probably has been there since r118 = 0.3.6.
Oh, and who THE FUCK thought stripping the official binary was a good idea? I just wasted half an hour hunting down SHA256Transform in a disassembler.
Nice work mate! Time to PM Satoshi.

Sent you ฿5.01 for your troubles.

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
lfm
Full Member
***
Offline Offline

Activity: 196



View Profile
August 09, 2010, 10:04:43 AM
 #27

The 32 bit Linux build seems ok for those who don't care to try to build it themselves. It's only a few percent slower than the 64 when built right.

I guess that flag was put in for old 32 bit machines that might not have sse2. Unfortunatly there is no such thing as a 64 bit x86_64 without sse2 so the conditional compilation produced an empty body which did exactly nothing.
lachesis
Full Member
***
Offline Offline

Activity: 210


View Profile
August 09, 2010, 03:45:39 PM
 #28

I guess that flag was put in for old 32 bit machines that might not have sse2. Unfortunatly there is no such thing as a 64 bit x86_64 without sse2 so the conditional compilation produced an empty body which did exactly nothing.
Yet another argument for cmake or similar.

Bitcoin Calculator | Scallion | GPG Key | WoT Rating | 1QGacAtYA7E8V3BAiM7sgvLg7PZHk5WnYc
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
August 09, 2010, 06:50:41 PM
 #29

I found that SSE2 only added a slight 2% speedup, which didn't seem worth the incompatibility.  I was trying to take the safer option.

It doesn't look to me like Crypto++ could be deciding whether to use SSE2 at runtime.  There's one place where it detects SSE2 for deciding some block count parameter, but the SSE2 stuff is all #ifdef at compile time and I can't see how that would switch at runtime.  Maybe I'm not looking in the right place.

Should we enable SSE2 in all the makefiles?  It seems like we must in case someone compiles with 64-bit.

I will recompile the 64-bit part of the Linux 0.3.8 release.
knightmb
Sr. Member
****
Offline Offline

Activity: 308


Timekoin - Save Electricity, Don't Waste It!


View Profile WWW
August 09, 2010, 07:02:12 PM
 #30

I found that SSE2 only added a slight speedup, about 2%, which didn't seem worth the incompatibility. 
I do the see point because a non-SSE2 machine, the client would crash?
Quote
It doesn't look to me like Crypto++ could be deciding whether to use SSE2 at runtime.  There's one place where it detects SSE2 for deciding some block count parameter, but the SSE2 stuff is all #ifdef at compile time and I can't see how that would switch at runtime.  Maybe I'm not looking in the right place.

Should we enable SSE2 in all the makefiles?  It seems like we must in case someone compiles with 64-bit.

I will recompile the 64-bit part of the Linux 0.3.8 release.
Depends on which is easier really. If you enable something that is going to break compatibility, the only people who will feel the pain are the non-technical users of the client. From their perspective, it just doesn't work for some reason.

I think some builds notes would be better, example (If compiling on a 64bit system, be sure to do this part).

Have one branch of source that cross-compiles across multiple operating systems is always tricky business.  Grin

dkaparis
Jr. Member
*
Offline Offline

Activity: 53


View Profile
August 09, 2010, 07:31:37 PM
 #31

Yet another argument for cmake or similar.

It's a fact.

I intend to eventually sort out all building hassles and have a reliable build procedure across all win/unix 32/64-bit platform combinations.

On that note, I'm currently tackling x64 build for windows and notice that for 64-bit MSVC, the X86_SHA256_HashBlocks function is deferred to an external definition that is not present in the project. In the original CryptoPP library it seems to be in a separate asm module. I wonder how are people building x64 on windows, are they setting defines to use the C-source sha version?
satoshi
Founder
Sr. Member
*
qt
Offline Offline

Activity: 364


View Profile
August 09, 2010, 08:34:06 PM
 #32

I uploaded 0.3.8.1 for Linux with re-built 64-bit.  I ran a difficulty 1 test with it and it has generated blocks.

http://bitcointalk.org/index.php?topic=765.0

Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download
Ground Loop
Member
**
Offline Offline

Activity: 112


View Profile
August 10, 2010, 06:09:27 AM
 #33

In recognition of the sluthiness exhibited by lfm and ArtForz, I will send them the first coins that my healed 64-bit Linux machine discovers.
Nice work guys.  (lfm, post up an address, eh)

It would be great if some future version of bitcoin/bitcoind had an internal self-test, just to confirm that the hashing is working.  As more folks try different options for specialized hardware, it seems all we have today is the indeterminate "difficulty 1" point-to-point test.  A "known good" hardcoded hash seed could make this better.

Bitcoin accepted here: 1HrAmQk9EuH3Ak6ugsw3qi3g23DG6YUNPq
lfm
Full Member
***
Offline Offline

Activity: 196



View Profile
August 10, 2010, 06:56:27 AM
 #34

In recognition of the sluthiness exhibited by lfm and ArtForz, I will send them the first coins that my healed 64-bit Linux machine discovers.
Nice work guys.  (lfm, post up an address, eh)

here: 1HKXYYPCzQptzJsaq2nt8xUgsWNVFRfJWD
or here:  75.158.131.108

Quote
It would be great if some future version of bitcoin/bitcoind had an internal self-test, just to confirm that the hashing is working.  As more folks try different options for specialized hardware, it seems all we have today is the indeterminate "difficulty 1" point-to-point test.  A "known good" hardcoded hash seed could make this better.

Ya a couple "test vectors" at runtime might be nice but then again if they're hacking they might hack out the test vectors cuz "they just slow ya down!" (logical or not)

If there was a well defined hook for the SHA variants it might make it less likely the test code would get hacked out. Not exactly sure how a hook should be designed to work for all the players out there. Stuff like GPU codes and SSE codes where several nonces might be tried in parallel need to be supported.

aceat64
Full Member
***
Offline Offline

Activity: 127



View Profile
August 10, 2010, 07:42:32 AM
 #35

In recognition of the sluthiness exhibited by lfm and ArtForz, I will send them the first coins that my healed 64-bit Linux machine discovers.
Nice work guys.  (lfm, post up an address, eh)

It would be great if some future version of bitcoin/bitcoind had an internal self-test, just to confirm that the hashing is working.  As more folks try different options for specialized hardware, it seems all we have today is the indeterminate "difficulty 1" point-to-point test.  A "known good" hardcoded hash seed could make this better.

ArtForz actually made a patch to check up on BitcoinMiner(), http://pastebin.com/YGUcqPYK

Ground Loop
Member
**
Offline Offline

Activity: 112


View Profile
August 11, 2010, 07:31:17 PM
 #36

My Linux 64-bit machine is provably healed, and all 11,000 khash/sec are being used For Good at last.

ArtForz, lfm, You have incoming coin. Smiley

Bitcoin accepted here: 1HrAmQk9EuH3Ak6ugsw3qi3g23DG6YUNPq
lfm
Full Member
***
Offline Offline

Activity: 196



View Profile
August 12, 2010, 10:19:55 AM
 #37

In recognition of the sluthiness exhibited by lfm and ArtForz, I will send them the first coins that my healed 64-bit Linux machine discovers.
Nice work guys.  (lfm, post up an address, eh)

Note significant clues were also supplied by lechesis and tcatm if you're feeling generous. :-)
Pages: « 1 [2]  All
  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!