BitcoinTalk

Bitcoin 0.3.1 released

106
Satoshi-only
BitcoinTalk
#1
From:
satoshi
Subject:
Bitcoin 0.3.1 released
Date:
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
BitcoinTalk
#2
From:
andy_3_913
Subject:
Re: 0.3.1 release candidate, please test
Date:
hi satoshi,
are there any back-ups need to be done before installing?
BitcoinTalk
#3
From:
satoshi
Subject:
Re: 0.3.1 release candidate, please test
Date:
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.

BitcoinTalk
#4
From:
andy_3_913
Subject:
Re: 0.3.1 release candidate, please test
Date:
Quote from: satoshi on July 15, 2010, 05:23:48 PM
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 Smiley

been crunching away for a couple of days now, don't want to start all over again!!!!
BitcoinTalk
#5
From:
Insti
Subject:
Re: 0.3.1 release candidate, please test
Date:
you know you're not actually making 'progress' right? http://bitcointalk.org/index.php?topic=325.msg2935#msg2935
BitcoinTalk
#6
From:
andy_3_913
Subject:
Re: 0.3.1 release candidate, please test
Date:
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!
BitcoinTalk
#7
From:
satoshi
Subject:
Re: 0.3.1 release candidate, please test
Date:
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.
BitcoinTalk
#8
From:
jimbobway
Subject:
Re: 0.3.1 release candidate, please test
Date:
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.
BitcoinTalk
#9
From:
laszlo
Subject:
Re: 0.3.1 release candidate, please test
Date:
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.
BitcoinTalk
#10
From:
Anonymous
Subject:
Re: 0.3.1 release candidate, please test
Date:
This build solved my problem (additional info in this topic http://bitcointalk.org/index.php?topic=373.0).
BitcoinTalk
#11
From:
andy_3_913
Subject:
Re: 0.3.1 release candidate, please test
Date:
Quote from: satoshi on July 15, 2010, 05:56:43 PM
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 Smiley

anything you would like me to send?

ps...
haven't noticed any extra disk thrashing while bitcoin is running Smiley
BitcoinTalk
#12
From:
laszlo
Subject:
Re: 0.3.1 release candidate, please test
Date:
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.
BitcoinTalk
#13
From:
andy_3_913
Subject:
Re: 0.3.1 release candidate, please test
Date:
Quote from: laszlo on July 15, 2010, 06:35:21 PM
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 Smiley
BitcoinTalk
#14
From:
lachesis
Subject:
Re: 0.3.1 release candidate, please test
Date:
Very nice Satoshi. What about the slow block download bug?
BitcoinTalk
#15
From:
diven
Subject:
Re: 0.3.1 release candidate, please test
Date:
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.
BitcoinTalk
#16
From:
knightmb
Subject:
Re: 0.3.1 release candidate, please test
Date:
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 should have counted the cores ahead of time  Lips sealed , confirmed NOT to be a bug when testing Windows 2000, XP, Vista 32/64, Windows 7/ 32-64
BitcoinTalk
#17
From:
knightmb
Subject:
Re: 0.3.1 release candidate, please test
Date:
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.
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

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.
BitcoinTalk
#18
From:
andy_3_913
Subject:
Re: 0.3.1 release candidate, please test
Date:
i'm sorry, but this is mostly ??
i'm not a complete thickie, but most of this is way over my loaf!!
Smiley
BitcoinTalk
#19
From:
db
Subject:
Re: 0.3.1 release candidate, please test
Date:
The listreceivedbyaddress and getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.)
BitcoinTalk
#20
From:
andy_3_913
Subject:
Re: 0.3.1 release candidate, please test
Date:
Quote from: db on July 15, 2010, 08:39:08 PM
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???
BitcoinTalk
#21
From:
satoshi
Subject:
Re: 0.3.1 release candidate, please test
Date:
Quote from: knightmb on July 15, 2010, 07:37:10 PM
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?
BitcoinTalk
#22
From:
knightmb
Subject:
Re: 0.3.1 release candidate, please test
Date:
Quote from: satoshi on July 15, 2010, 09:40:34 PM
Quote from: knightmb on July 15, 2010, 07:37:10 PM
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?
LOL, I think you are right. I've got waaaayy too many PCs around me and it's difficult to keep track of which is single core, dual core, quad, 8 core, etc. I'll test it again on the single proc PC and see what happens.
BitcoinTalk
#23
From:
knightmb
Subject:
Re: 0.3.1 release candidate, please test
Date:
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
BitcoinTalk
#24
From:
satoshi
Subject:
Re: 0.3.1 release candidate, please test
Date:
Quote from: knightmb on July 15, 2010, 08:15:46 PM
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
BitcoinTalk
#25
From:
satoshi
Subject:
Re: 0.3.1 release candidate, please test
Date:
Quote from: db on July 15, 2010, 08:39:08 PM
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.
BitcoinTalk
#26
From:
db
Subject:
Re: 0.3.1 release candidate, please test
Date:
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.
BitcoinTalk
#27
From:
RHorning
Subject:
Re: 0.3.1 release candidate, please test
Date:
Quote from: knightmb on July 15, 2010, 08:15:46 PM
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.
BitcoinTalk
#28
From:
adavid
Subject:
Re: 0.3.1 release candidate, please test
Date:
Quote from: knightmb on July 15, 2010, 08:15:46 PM
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.
BitcoinTalk
#29
From:
satoshi
Subject:
Re: 0.3.1 release candidate, please test
Date:
Quote from: RHorning on July 15, 2010, 10:29:28 PM
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.
BitcoinTalk
#30
From:
lachesis
Subject:
Re: 0.3.1 release candidate, please test
Date:
Quote from: satoshi on July 15, 2010, 10:07:35 PM
Quote from: knightmb on July 15, 2010, 08:15:46 PM
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
Satoshi, you didn't fix the bug; you just ripped out the minimize to tray code. Could you possibly make this optional? I wasn't experiencing the original bug, and I very much like the minimize to tray feature.
BitcoinTalk
#31
From:
satoshi
Subject:
Re: 0.3.1 release candidate, please test
Date:
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.
BitcoinTalk
#32
From:
lachesis
Subject:
Re: 0.3.1 release candidate, please test
Date:
Alright, thanks. That's all I need.
BitcoinTalk
#33
From:
BioMike
Subject:
Re: 0.3.1 release candidate, please test
Date:
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?
BitcoinTalk
#34
From:
satoshi
Subject:
Re: 0.3.1 release candidate, please test
Date:
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.
BitcoinTalk
#35
From:
knightmb
Subject:
Re: 0.3.1 release candidate, please test
Date:
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.
BitcoinTalk
#36
From:
satoshi
Subject:
Re: 0.3.1 release candidate, please test
Date:
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.
BitcoinTalk
#37
From:
knightmb
Subject:
Re: 0.3.1 release candidate, please test
Date:
Quote from: satoshi on July 16, 2010, 05:26:17 PM
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.
BitcoinTalk
#38
From:
BioMike
Subject:
Re: 0.3.1 release candidate, please test
Date:
Quote from: satoshi on July 16, 2010, 03:09:59 PM
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.

BitcoinTalk
#39
From:
satoshi
Subject:
Re: Bitcoin 0.3.1 released
Date:
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.