I finished everything on my list to do for version 0.3. The code on SVN is about ready to release.
Testing at this point is much appreciated.
Re: 0.3 almost ready
It would be nice if the listtransactions RPC method were finished before the next release, though.
My fear is too many programmers would latch onto that for checking for received payments. It can never be reliable that way. The list/getreceivedbyaddress/label functions are the only way to do it reliably.We shouldn't delay forever until every possible feature is done. There's always going to be one more thing to do.
Re: 0.3 almost ready
Here's RC1 for windows for testing:
(removed, see RC2 below)
Please only download this if you're going to test and report back whether everything seems fine or not. Make sure to look through the files in "c:\program files\bitcoin"
(removed, see RC2 below)
Please only download this if you're going to test and report back whether everything seems fine or not. Make sure to look through the files in "c:\program files\bitcoin"
Re: 0.3 almost ready
EXCEPTION: 22DbRunRecoveryException
DBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery
C:\Program Files\Bitcoin\bitcoin.exe in OnInit()
What operating system?DBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery
C:\Program Files\Bitcoin\bitcoin.exe in OnInit()
Normally when it does that it's because the directory where the data directory should go doesn't exist. See if the "%appdata%" directory exists.
Do you get that error with 0.2 also? It's hard to see how you could get that with 0.3 and not with 0.2 since there's nothing different in that regard.
Re: 0.3 almost ready
davidonpda, were you also running laszlo's build previously?
Check if the "%appdata%" directory exists, and "%appdata%\bitcoin"
Try:
rename "%appdata%\bitcoin" bitcoin2
does it work then?
Check if the "%appdata%" directory exists, and "%appdata%\bitcoin"
Try:
rename "%appdata%\bitcoin" bitcoin2
does it work then?
Re: 0.3 almost ready
You figured it out faster than I could post a reply. 
It looks like laszlo's build of Berkeley DB has database/log.* files that are not compatible with ours. The .dat files are fine, their format shouldn't ever change. All data is stored in the .dat files. All your own data is stored in wallet.dat. If you had waited for it to redownload the block chain, your missing transactions and generateds would have appeared as the block chain reached the point where those transactions were recorded.
When you copied the directory except log.0000000002, that's the best solution. You should be good now.
The database/log.* files only contain temporary database data. If you exited bitcoin normally the last time, not exited by forced terminating it or crashing, then the database/log.* files can normally be deleted safely. They're only used so that if the database is in the middle of a transaction when the computer crashes or the program is killed or crashes, then it could recover without losing data.
Please keep running v0.3 if at all possible, don't go back to v0.2.10.
Anyone else who hits this problem, move the database\log.000000000* files somewhere else. (if it works fine after that, you can delete them later)
I'm reluctant to make the installer delete or move those files. If the previous run was stopped by crashing or killed, that would be the wrong thing to do.
It looks like laszlo's build of Berkeley DB has database/log.* files that are not compatible with ours. The .dat files are fine, their format shouldn't ever change. All data is stored in the .dat files. All your own data is stored in wallet.dat. If you had waited for it to redownload the block chain, your missing transactions and generateds would have appeared as the block chain reached the point where those transactions were recorded.
When you copied the directory except log.0000000002, that's the best solution. You should be good now.
The database/log.* files only contain temporary database data. If you exited bitcoin normally the last time, not exited by forced terminating it or crashing, then the database/log.* files can normally be deleted safely. They're only used so that if the database is in the middle of a transaction when the computer crashes or the program is killed or crashes, then it could recover without losing data.
Please keep running v0.3 if at all possible, don't go back to v0.2.10.
Anyone else who hits this problem, move the database\log.000000000* files somewhere else. (if it works fine after that, you can delete them later)
I'm reluctant to make the installer delete or move those files. If the previous run was stopped by crashing or killed, that would be the wrong thing to do.
Re: 0.3 almost ready
Laszlo figured out that enabling some more optimisation increased performance about 20%, so 0.3 hashes 20% faster than 0.2.0, but I assume he used that in his own build.
30khash increase to what total rate? (to figure the % increase)
30khash increase to what total rate? (to figure the % increase)
Re: 0.3 almost ready
Here's RC1 for linux for testing:
(link removed, see below)
It contains both 32-bit and 64-bit binaries.
Recent changes:
build-unix.txt:
- Added instructions for building wxBase, which is needed to compile bitcoind.
- The package libboost-dev doesn't install anything anymore, you need to get libboost-all-dev.
- Updated version numbers.
makefile.unix:
- The libboost libraries have removed the "-mt" from their filenames in 1.40. If you're compiling with Boost 1.38 or lower, like on Ubuntu Karmic, you would need to change it back to boost_system-mt and boost_filesystem-mt.
(link removed, see below)
It contains both 32-bit and 64-bit binaries.
Recent changes:
build-unix.txt:
- Added instructions for building wxBase, which is needed to compile bitcoind.
- The package libboost-dev doesn't install anything anymore, you need to get libboost-all-dev.
- Updated version numbers.
makefile.unix:
- The libboost libraries have removed the "-mt" from their filenames in 1.40. If you're compiling with Boost 1.38 or lower, like on Ubuntu Karmic, you would need to change it back to boost_system-mt and boost_filesystem-mt.
Re: 0.3 almost ready
I don't know. Maybe someone with more Linux experience knows how to install the library it needs.
I built it on Ubuntu 10.04. I hope that wasn't a mistake. Maybe it should have been built on an older version for more backward compatibility. Is this a problem on Linux, that if you build on the latest version, then it has trouble working on older versions? Is there any way I can downgrade to an older version of GCC on 10.04?
The 64-bit version shouldn't be any faster than the 32-bit version, but it would be great if someone could do a side-by-side comparison of the two linux versions and check. SHA-256 is a 32-bit algorithm and nothing in BitcoinMiner uses 64-bit at all.
We don't need to bother with a 64-bit version for Windows. 32-bit programs work on all versions of Windows. It's not like Linux where the 64-bit OS wants 64-bit programs.
I'm also curious if it's a little faster on linux than windows.
Do you think I should make the directories:
/bin32/
/bin64/
instead of
/bin/32/
/bin/64/
I built it on Ubuntu 10.04. I hope that wasn't a mistake. Maybe it should have been built on an older version for more backward compatibility. Is this a problem on Linux, that if you build on the latest version, then it has trouble working on older versions? Is there any way I can downgrade to an older version of GCC on 10.04?
The 64-bit version shouldn't be any faster than the 32-bit version, but it would be great if someone could do a side-by-side comparison of the two linux versions and check. SHA-256 is a 32-bit algorithm and nothing in BitcoinMiner uses 64-bit at all.
We don't need to bother with a 64-bit version for Windows. 32-bit programs work on all versions of Windows. It's not like Linux where the 64-bit OS wants 64-bit programs.
I'm also curious if it's a little faster on linux than windows.
Do you think I should make the directories:
/bin32/
/bin64/
instead of
/bin/32/
/bin/64/
Re: 0.3 almost ready
Thanks virtualcoin, that's a perfect comparison.
The 8% speedup from 32-bit Windows (2310k) to 32-bit Linux (2500k) is probably from the newer version of GCC on Linux (4.4.3 vs 3.4.5).
The 15% speedup from 32-bit to 64-bit Linux is more of a mystery. The code is completely 32-bit.
Hmm, I think the 8 extra registers added by x86-64 must be what's helping. That would make a significant difference to SHA if it could hold most of the 16 state variables in registers.
The 8% speedup from 32-bit Windows (2310k) to 32-bit Linux (2500k) is probably from the newer version of GCC on Linux (4.4.3 vs 3.4.5).
The 15% speedup from 32-bit to 64-bit Linux is more of a mystery. The code is completely 32-bit.
Hmm, I think the 8 extra registers added by x86-64 must be what's helping. That would make a significant difference to SHA if it could hold most of the 16 state variables in registers.
Re: 0.3 almost ready
Lets try using Laszlo's irc.lfnet.org instead of freenode. Here's RC2, that's the only change in it:
(see below for download links)
(see below for download links)
Re: 0.3 almost ready
The first panel of the status bar is shared with the help description of menu items as you hover over them. Since all our menu item descriptions are blank, it replaces it with blank when you're hovering in a menu.
Re: 1.3 almost ready
Changed the version number to 1.3 and removed "Beta".
(links removed, see below)
Uses irc.lfnet.org.
(links removed, see below)
Uses irc.lfnet.org.
Re: 1.3 almost ready
MinGW still only has good old stable 3.4.5. There's not much reason for them to update it.
When I looked at the 3.4.5 compiled SHA disassembly, I couldn't see any room for improvement at all. I can't imagine how 8% more could be squeezed out of it. Is it possible Windows could have 8% more overhead? Not making system calls or anything, just plain busy computational code, could task switching and other housekeeping operations take away that much?
When I looked at the 3.4.5 compiled SHA disassembly, I couldn't see any room for improvement at all. I can't imagine how 8% more could be squeezed out of it. Is it possible Windows could have 8% more overhead? Not making system calls or anything, just plain busy computational code, could task switching and other housekeeping operations take away that much?
Re: 1.3 almost ready
On a related note, is the thing compilable by Visual C++? I'm inclined to give it a try when I get around to it.
It is, but generating is more than twice as slow.Re: 0.3 almost ready
(reverted to rc2)
Links removed, 0.3 is now released, so go to http://www.bitcoin.org to download it.
Links removed, 0.3 is now released, so go to http://www.bitcoin.org to download it.
Re: 0.3 almost ready -- please test the Mac version!
Laszlo's build is going to be our first Mac release so please test it!