This is a bugfix maintenance release. It is now uploaded to SourceForge. Mac OS X didn't need any fixes so we don't really need to update it, 0.3.0 is still good.
The download links are on bitcoin.org
Changes:
- Added Portuguese translation by Tiago Faria
Windows
- Fix for 22DbRunRecoveryException if your username has non-ascii characters in it
Linux
- Laszlo's fix for lowering generate thread to lowest priority
- Fix for if you're having trouble with libcrypto linkage
- Gavin Andresen's implementation of "start on windowing system startup" option
Re: 0.3.1 release candidate, please test
hi satoshi,
are there any back-ups need to be done before installing?
are there any back-ups need to be done before installing?
Re: 0.3.1 release candidate, please test
Well, it can't hurt to do a backup and it's a good idea to backup regularly, but no, a backup is not required before installing this.
Re: 0.3.1 release candidate, please test
Well, it can't hurt to do a backup and it's a good idea to backup regularly, but no, a backup is not required before installing this.
okey dokey
been crunching away for a couple of days now, don't want to start all over again!!!!
Re: 0.3.1 release candidate, please test
you know you're not actually making 'progress' right? http://bitcointalk.org/index.php?topic=325.msg2935#msg2935
Re: 0.3.1 release candidate, please test
on this end,
hasn't helped.
still same symptoms, but can't set to belownormal. access is denied!!
edit:
strange,
firefox and windows explorer open quickly enough, bit laggy, but the likes of gomez doesn't!
hasn't helped.
still same symptoms, but can't set to belownormal. access is denied!!
edit:
strange,
firefox and windows explorer open quickly enough, bit laggy, but the likes of gomez doesn't!
Re: 0.3.1 release candidate, please test
I don't think you have a particular problem, I think your system is laggy because you're running a lot of things at once and hitting the pagefile because memory is full. You confirmed when you shut off generation that your CPU drops to 0%, so the CPU usage is definitely all idle priority. There's nothing in the 0.3.1 that would affect these things.
Re: 0.3.1 release candidate, please test
I am really scared to lose my wallet due to an install, re-install, or backing up. In another thread a user backed up his wallet only to lose all of his bitcoins, forever.
See this thread: http://bitcointalk.org/index.php?topic=359.0
Maybe we can have a step-by-step procedure to successfully backup and to restore.
See this thread: http://bitcointalk.org/index.php?topic=359.0
Maybe we can have a step-by-step procedure to successfully backup and to restore.
Re: 0.3.1 release candidate, please test
He tried to double spend his coins and the system prevented it. In the process he also lost the coins he didn't spend because he lost one of the wallet files while swapping them around.
It is enough to back up the wallet.dat, try it out with some free coins from the bitcoin faucet.
It is enough to back up the wallet.dat, try it out with some free coins from the bitcoin faucet.
Anonymous#10
Re: 0.3.1 release candidate, please test
This build solved my problem (additional info in this topic http://bitcointalk.org/index.php?topic=373.0).
Re: 0.3.1 release candidate, please test
I don't think you have a particular problem, I think your system is laggy because you're running a lot of things at once and hitting the pagefile because memory is full. You confirmed when you shut off generation that your CPU drops to 0%, so the CPU usage is definitely all idle priority. There's nothing in the 0.3.1 that would affect these things.
possible.
but, and i'm NOT being offensive here, this sort of performance lag has only appeared while i'm running bitcoin.
and BOINC is active, but not running any projects at the moment.
3gig memory,
cached 1524,
available 1573,
free 108.
not going to stop bitcoin, but it does seem a bit strange
anything you would like me to send?
ps...
haven't noticed any extra disk thrashing while bitcoin is running
Re: 0.3.1 release candidate, please test
Are there any errors maybe in dmesg or the syslog (usually /var/log/messages or /var/log/syslog or something like that)? It's hard to diagnose without seeing it first hand, sorry.
Re: 0.3.1 release candidate, please test
Are there any errors maybe in dmesg or the syslog (usually /var/log/messages or /var/log/syslog or something like that)? It's hard to diagnose without seeing it first hand, sorry.
on a windows machine here. sorry!
any better pointers?
i'm re-installing .3
this update isn't quite working lol
Re: 0.3.1 release candidate, please test
Very nice Satoshi. What about the slow block download bug?
Re: 0.3.1 release candidate, please test
Working on 32 bit Slackware 12.2 and 13.0 (with updated gcc-g++). I have not reverted the upgrade to test if it works with the stock gcc.
Re: 0.3.1 release candidate, please test
I should have counted the cores ahead of time
, confirmed NOT to be a bug when testing Windows 2000, XP, Vista 32/64, Windows 7/ 32-64Re: 0.3.1 release candidate, please test
On the Linux client (64 bit), the "minimize on close" will still minimize to tray (causing X server hang after a short while by spawning multiple tray icons).
But, the priority of the threads all seem to be "nice" properly I think. The ones using all the CPU time are nice to 19, so the others that are 0 and 2 aren't using any CPU time so the system seems to be responsive.
I'm not exactly sure what the "Start BitCoin on window system startup" is suppose to do?
On library errors, you get a /usr/lib/libstdc++.so.6 'GLIBCXX_3.4.11' not found on older linux clients (one was only a year old). I checked the file, it's just linked to libstdc++.so.10 but I don't know if that's a high enough version or not.
But, the priority of the threads all seem to be "nice" properly I think. The ones using all the CPU time are nice to 19, so the others that are 0 and 2 aren't using any CPU time so the system seems to be responsive.
Code:
[knightmb@KnightMB ~]$ ps -eflL | grep bitcoin
0 S knightmb 13676 13591 13676 0 9 80 0 - 113704 poll_s 14:52 pts/1 00:00:02 ./bitcoin
1 S knightmb 13676 13591 13681 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13682 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13683 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13685 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13686 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13687 0 9 82 2 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 R knightmb 13676 13591 13689 70 9 99 19 - 113704 - 14:52 pts/1 00:09:34 ./bitcoin
1 R knightmb 13676 13591 13714 71 9 99 19 - 113704 - 14:53 pts/1 00:09:39 ./bitcoin
1 R knightmb 13676 13591 13924 72 9 99 19 - 113704 - 14:53 pts/1 00:08:19 ./bitcoin
1 R knightmb 13676 13591 13314 73 9 99 19 - 113704 - 14:53 pts/1 00:08:19 ./bitcoin
1 R knightmb 13676 13591 13114 74 9 99 19 - 113704 - 14:53 pts/1 00:08:19 ./bitcoin
1 R knightmb 13676 13591 13984 75 9 99 19 - 113704 - 14:53 pts/1 00:09:19 ./bitcoin
1 R knightmb 13676 13591 13214 76 9 99 19 - 113704 - 14:53 pts/1 00:09:09 ./bitcoin
1 R knightmb 13676 13591 13917 77 9 99 19 - 113704 - 14:53 pts/1 00:08:12 ./bitcoin
1 R knightmb 13676 13591 13919 78 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13934 79 9 99 19 - 113704 - 14:53 pts/1 00:08:51 ./bitcoin
1 R knightmb 13676 13591 13114 80 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13624 81 9 99 19 - 113704 - 14:53 pts/1 00:09:11 ./bitcoin
1 R knightmb 13676 13591 13224 82 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13374 83 9 99 19 - 113704 - 14:53 pts/1 00:08:55 ./bitcoin
1 R knightmb 13676 13591 13261 84 9 99 19 - 113704 - 14:53 pts/1 00:09:43 ./bitcoin
1 R knightmb 13676 13591 13171 85 9 99 19 - 113704 - 14:53 pts/1 00:08:55 ./bitcoin
1 R knightmb 13676 13591 13741 86 9 99 19 - 113704 - 14:53 pts/1 00:08:23 ./bitcoin
1 R knightmb 13676 13591 13371 87 9 99 19 - 113704 - 14:53 pts/1 00:09:42 ./bitcoin
1 R knightmb 13676 13591 13690 88 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13234 89 9 99 19 - 113704 - 14:53 pts/1 00:08:33 ./bitcoin
1 R knightmb 13676 13591 13703 90 9 99 19 - 113704 - 14:53 pts/1 00:08:38 ./bitcoin
1 R knightmb 13676 13591 13991 91 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
0 S knightmb 13676 13591 13676 0 9 80 0 - 113704 poll_s 14:52 pts/1 00:00:02 ./bitcoin
1 S knightmb 13676 13591 13681 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13682 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13683 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13685 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13686 0 9 80 0 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 S knightmb 13676 13591 13687 0 9 82 2 - 113704 hrtime 14:52 pts/1 00:00:00 ./bitcoin
1 R knightmb 13676 13591 13689 70 9 99 19 - 113704 - 14:52 pts/1 00:09:34 ./bitcoin
1 R knightmb 13676 13591 13714 71 9 99 19 - 113704 - 14:53 pts/1 00:09:39 ./bitcoin
1 R knightmb 13676 13591 13924 72 9 99 19 - 113704 - 14:53 pts/1 00:08:19 ./bitcoin
1 R knightmb 13676 13591 13314 73 9 99 19 - 113704 - 14:53 pts/1 00:08:19 ./bitcoin
1 R knightmb 13676 13591 13114 74 9 99 19 - 113704 - 14:53 pts/1 00:08:19 ./bitcoin
1 R knightmb 13676 13591 13984 75 9 99 19 - 113704 - 14:53 pts/1 00:09:19 ./bitcoin
1 R knightmb 13676 13591 13214 76 9 99 19 - 113704 - 14:53 pts/1 00:09:09 ./bitcoin
1 R knightmb 13676 13591 13917 77 9 99 19 - 113704 - 14:53 pts/1 00:08:12 ./bitcoin
1 R knightmb 13676 13591 13919 78 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13934 79 9 99 19 - 113704 - 14:53 pts/1 00:08:51 ./bitcoin
1 R knightmb 13676 13591 13114 80 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13624 81 9 99 19 - 113704 - 14:53 pts/1 00:09:11 ./bitcoin
1 R knightmb 13676 13591 13224 82 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13374 83 9 99 19 - 113704 - 14:53 pts/1 00:08:55 ./bitcoin
1 R knightmb 13676 13591 13261 84 9 99 19 - 113704 - 14:53 pts/1 00:09:43 ./bitcoin
1 R knightmb 13676 13591 13171 85 9 99 19 - 113704 - 14:53 pts/1 00:08:55 ./bitcoin
1 R knightmb 13676 13591 13741 86 9 99 19 - 113704 - 14:53 pts/1 00:08:23 ./bitcoin
1 R knightmb 13676 13591 13371 87 9 99 19 - 113704 - 14:53 pts/1 00:09:42 ./bitcoin
1 R knightmb 13676 13591 13690 88 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
1 R knightmb 13676 13591 13234 89 9 99 19 - 113704 - 14:53 pts/1 00:08:33 ./bitcoin
1 R knightmb 13676 13591 13703 90 9 99 19 - 113704 - 14:53 pts/1 00:08:38 ./bitcoin
1 R knightmb 13676 13591 13991 91 9 99 19 - 113704 - 14:53 pts/1 00:08:39 ./bitcoin
I'm not exactly sure what the "Start BitCoin on window system startup" is suppose to do?
On library errors, you get a /usr/lib/libstdc++.so.6 'GLIBCXX_3.4.11' not found on older linux clients (one was only a year old). I checked the file, it's just linked to libstdc++.so.10 but I don't know if that's a high enough version or not.
Re: 0.3.1 release candidate, please test
i'm sorry, but this is mostly ??
i'm not a complete thickie, but most of this is way over my loaf!!
i'm not a complete thickie, but most of this is way over my loaf!!
Re: 0.3.1 release candidate, please test
The listreceivedbyaddress and getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.)
Re: 0.3.1 release candidate, please test
The listreceivedbyaddress and getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.)
yep!
i'm sure they are!!
already said, i haven't a clue!
what on earth are you talking about???
Re: 0.3.1 release candidate, please test
On Windows, the priority of the Coin Generation is still net for normal. If you run BitCoin in Generate Coin mode, then load up something to eat up all the CPU (like CPU hog for example: http://www.microtask.ca/cpuhog.html) you'll see that both BitCoin and CPU hog share the CPU 50/50 instead of CPU Hog taking all the CPU and BitCoin running only on idle/low process. The khash/s is also reduced in half, so further evidence that the threads are not running in a lower than normal prioirty.
I was not able to reproduce this. I have dual-proc, so I ran two memory hogs. Bitcoin got 0% of CPU according to the task manager. The khash/sec meter stayed stuck because it couldn't get any CPU to update it.Do you have dual-proc? Are you sure you weren't running a single processor hog?
Re: 0.3.1 release candidate, please test
On Windows, the priority of the Coin Generation is still net for normal. If you run BitCoin in Generate Coin mode, then load up something to eat up all the CPU (like CPU hog for example: http://www.microtask.ca/cpuhog.html) you'll see that both BitCoin and CPU hog share the CPU 50/50 instead of CPU Hog taking all the CPU and BitCoin running only on idle/low process. The khash/s is also reduced in half, so further evidence that the threads are not running in a lower than normal prioirty.
I was not able to reproduce this. I have dual-proc, so I ran two memory hogs. Bitcoin got 0% of CPU according to the task manager. The khash/sec meter stayed stuck because it couldn't get any CPU to update it.Do you have dual-proc? Are you sure you weren't running a single processor hog?
Re: 0.3.1 release candidate, please test
Yeah, you are right, works just fine. *smacks forehead for not counting cores ahead of time*, so scrap the prioirty bug then, I'll go back and edit my post. Works just fine on Windows 2000, XP, Vista, and 7
Re: 0.3.1 release candidate, please test
On the Linux client (64 bit), the "minimize on close" will still minimize to tray (causing X server hang after a short while by spawning multiple tray icons).
I updated the first post with a link to rc2 for linux with the fix for this. Please check that this is fixed for you. Thanks!http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz
Re: 0.3.1 release candidate, please test
The listreceivedbyaddress and getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.)
Yes a bug. It'll have to be fixed in the next version.Re: 0.3.1 release candidate, please test
On Linux 0.3.0 gets nice 0 when generating but with 0.3.1 the generating thread gets nice 19 while the other threads stay at 0. Looks good.
Re: 0.3.1 release candidate, please test
I'm not exactly sure what the "Start BitCoin on window system startup" is suppose to do?
In Windows, it should put Bitcoin.exe into "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run" for the system registry... or as an alternative into "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
I don't see either happening, although it did get put into the "Startup" folder. That is so Windows 95ish (just kidding..... Microsoft has so screwed this up that it isn't even funny). I would recommend the registry settings for a number of reasons including the fact that most software puts the startup in that location, even though I personally find the startup folder to be more attractive and how most software on Windows should behave.
I haven't done a full forensics with this new version in Windows, but the install seemed to go without a hitch for me... using the Windows install.
Re: 0.3.1 release candidate, please test
But, the priority of the threads all seem to be "nice" properly I think. The ones using all the CPU time are nice to 19, so the others that are 0 and 2 aren't using any CPU time so the system seems to be responsive.
I confirm this. bitcoind is actually nice now.
Re: 0.3.1 release candidate, please test
I don't see either happening, although it did get put into the "Startup" folder. That is so Windows 95ish (just kidding..... Microsoft has so screwed this up that it isn't even funny). I would recommend the registry settings for a number of reasons including the fact that most software puts the startup in that location, even though I personally find the startup folder to be more attractive and how most software on Windows should behave.
It could go either way. The Startup folder has the advantage that the end user can see it and manually remove it with the regular UI (not regedit) if they already blew away the Bitcoin directory and its uninstaller. Bitcoin will not relentlessly keep re-adding it if you delete it manually.OpenOffice is another example of something that puts its link in the Startup folder.
Re: 0.3.1 release candidate, please test
On the Linux client (64 bit), the "minimize on close" will still minimize to tray (causing X server hang after a short while by spawning multiple tray icons).
I updated the first post with a link to rc2 for linux with the fix for this. Please check that this is fixed for you. Thanks!http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz
Re: 0.3.1 release candidate, please test
Run it with the undocumented switch -minimizetotray and the option is available in the options menu.
I don't know how to fix it. It's something wrong deep inside wxWidgets or GTK or Gnome.
I don't know how to fix it. It's something wrong deep inside wxWidgets or GTK or Gnome.
Re: 0.3.1 release candidate, please test
Alright, thanks. That's all I need.
Re: 0.3.1 release candidate, please test
Build 0.3.1 on an x86 gentoo linux system with my own makefile (builds a dynamic client instead of a static one), seems to run more smoothly than 0.3.0.
B.T.W. Why does the standard makefile builds a static version anyway?
B.T.W. Why does the standard makefile builds a static version anyway?
Re: 0.3.1 release candidate, please test
Because of all the dependencies that different systems don't have. It's easier to just static link what we can. It doesn't increase the size by very much.
Re: 0.3.1 release candidate, please test
Anyone notice, that for Windows Clients anyway, when you connect a bunch of other clients to it manually (through the -connect option) that if you go over 8, the windows client ends up cutting out the "outside world" connections and stick with the original 8 or more internal machines thinking that it's the entire network?
I never noticed this since I use a Linux client to funnel all my PCs to the outside world, but I tried it with a Windows client and noticed that at first, it had about 10 connections, then after adding another 50 clients internally that connect directly to it, the number would eventually drop down to just "internal clients" only.
When this happens, the block count doesn't increment anymore, basically the Windows client has separated itself from "the network" and all the other clients all think that they are the entire network now. If I do a "netstat -a -n" on the windows client, I can see it's only connected to the Internal clients and the IRC bootstrap channel and basically doesn't to connect to anyone else on the outside world. You know it's happening because the block count starts to fall behind of what is really going on outside of your local network (Internet for the rest of the world)
It's kind of a self-collapsing loop? Doesn't seem to affect Linux clients though, they will happily connect to and be connected to about as many as it can handle. I could see this is kind of a DoS on windows clients if someone was evil enough.
I never noticed this since I use a Linux client to funnel all my PCs to the outside world, but I tried it with a Windows client and noticed that at first, it had about 10 connections, then after adding another 50 clients internally that connect directly to it, the number would eventually drop down to just "internal clients" only.
When this happens, the block count doesn't increment anymore, basically the Windows client has separated itself from "the network" and all the other clients all think that they are the entire network now. If I do a "netstat -a -n" on the windows client, I can see it's only connected to the Internal clients and the IRC bootstrap channel and basically doesn't to connect to anyone else on the outside world. You know it's happening because the block count starts to fall behind of what is really going on outside of your local network (Internet for the rest of the world)
It's kind of a self-collapsing loop? Doesn't seem to affect Linux clients though, they will happily connect to and be connected to about as many as it can handle. I could see this is kind of a DoS on windows clients if someone was evil enough.
Re: 0.3.1 release candidate, please test
Good point. If you're going to have more than 8 LAN nodes connect to one gateway node, then you'd better have the gateway node set up so it can receive incoming connections. Otherwise, while the gateway node has 8 or more connections, it will not try to add any more outbound connections. As the outside nodes you're connected to come and go, it doesn't make new outbound connections to replace them. You'll be fine if you can accept incoming connections, then there will be plenty of others connecting to you.
Re: 0.3.1 release candidate, please test
Good point. If you're going to have more than 8 LAN nodes connect to one gateway node, then you'd better have the gateway node set up so it can receive incoming connections. Otherwise, while the gateway node has 8 or more connections, it will not try to add any more outbound connections. As the outside nodes you're connected to come and go, it doesn't make new outbound connections to replace them. You'll be fine if you can accept incoming connections, then there will be plenty of others connecting to you.
The Windows Client had it's own static IP with port 8333 open for it, I could see from the gateway device that it was connecting out to other peers and other peers were connecting back in. But after the 8, it's like it quit connecting out to peers and after a while the incoming peers stopped as well since it appeared to only be concerned with the peers on the LAN vs the WAN. The behavior of the Linux client is different though I've noticed, even if 50 people are connected to it, it will still seek outbound connections to other peers and inbound peers continue to trickle in as well.While this will only be a problem for people like me that have hundreds of PCs at their disposal, the reverse is, one could setup PC(s) to connect to a single client 8 or more times and then after a while, the poor windows client would suck itself into it's own matrix world where it thinks it's on the network solving blocks, but it's really trapped back in time.
This is just a theoretical attack of course, I'm not going to lose any sleep over it, but I figured I would throw it out there for the future. The easiest way to negate this would be to put in some self-checking code for IPs. Basically, have to check that is has 8 connections or more that are NOT from the LAN/Same IP Address/etc when it's running as a dual node/client mode.
Re: 0.3.1 release candidate, please test
Because of all the dependencies that different systems don't have. It's easier to just static link what we can. It doesn't increase the size by very much.
I think size (static binary is 8x as big in my case) is not the problem, but security.
Boost, openssl and Berkeley DB are fairly common on unix systems (many things depend on them) and also Wxwidgets (the only argument is that bitcoin uses the current development branch and not the stable branch). Second, static linking doesn't mean you can always run it (in my case it tries to load libpng-1.2, which is not present on my system, libpng-1.4 is, and the static fails to load). Third, openssl hasn't been free of security issues, by statically compiling people keep using the insecure version even if their system provides an updated safe version.
Re: Bitcoin 0.3.1 released
I uploaded windows 0.3.1 rc1 and linux 0.3.1 rc2 to SourceForge and updated the links on the homepage.
You don't need to update to 0.3.1 unless you had one of the problems listed in the first post. If you've got it working already, stay with 0.3.0.
You don't need to update to 0.3.1 unless you had one of the problems listed in the first post. If you've got it working already, stay with 0.3.0.