Author

Topic: Bitcoin 0.3.1 released (Read 15988 times)

sr. member
Activity: 308
Merit: 258
July 17, 2010, 12:11:43 AM
#40
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
Testing the new release candidate. This resolves the minimize on close accidentally doing a minimize to tray. No X server crashes either, nice! Now only if we could get that tray thing to work again  Wink
founder
Activity: 364
Merit: 7060
July 16, 2010, 09:06:57 PM
#39
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.
legendary
Activity: 1658
Merit: 1001
July 16, 2010, 07:46:39 PM
#38
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.

sr. member
Activity: 308
Merit: 258
July 16, 2010, 05:58:24 PM
#37
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.
founder
Activity: 364
Merit: 7060
July 16, 2010, 05:26:17 PM
#36
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.
sr. member
Activity: 308
Merit: 258
July 16, 2010, 03:27:26 PM
#35
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.
founder
Activity: 364
Merit: 7060
July 16, 2010, 03:09:59 PM
#34
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.
legendary
Activity: 1658
Merit: 1001
July 16, 2010, 05:24:59 AM
#33
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?
full member
Activity: 210
Merit: 104
July 16, 2010, 01:12:26 AM
#32
Alright, thanks. That's all I need.
founder
Activity: 364
Merit: 7060
July 16, 2010, 12:44:32 AM
#31
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.
full member
Activity: 210
Merit: 104
July 16, 2010, 12:03:22 AM
#30
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.
founder
Activity: 364
Merit: 7060
July 15, 2010, 11:23:04 PM
#29
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.
newbie
Activity: 2
Merit: 0
July 15, 2010, 10:39:33 PM
#28
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.
full member
Activity: 224
Merit: 141
July 15, 2010, 10:29:28 PM
#27
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.
db
sr. member
Activity: 279
Merit: 261
July 15, 2010, 10:23:52 PM
#26
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.
founder
Activity: 364
Merit: 7060
July 15, 2010, 10:10:19 PM
#25
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.
founder
Activity: 364
Merit: 7060
July 15, 2010, 10:07:35 PM
#24
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
sr. member
Activity: 308
Merit: 258
July 15, 2010, 09:56:09 PM
#23
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
sr. member
Activity: 308
Merit: 258
July 15, 2010, 09:48:29 PM
#22
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.
founder
Activity: 364
Merit: 7060
July 15, 2010, 09:40:34 PM
#21
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?
newbie
Activity: 42
Merit: 0
July 15, 2010, 09:22:18 PM
#20
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???
db
sr. member
Activity: 279
Merit: 261
July 15, 2010, 08:39:08 PM
#19
The listreceivedbyaddress and getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.)
newbie
Activity: 42
Merit: 0
July 15, 2010, 08:26:01 PM
#18
i'm sorry, but this is mostly ??
i'm not a complete thickie, but most of this is way over my loaf!!
Smiley
sr. member
Activity: 308
Merit: 258
July 15, 2010, 08:15:46 PM
#17
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.
sr. member
Activity: 308
Merit: 258
July 15, 2010, 07:37:10 PM
#16
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
newbie
Activity: 14
Merit: 0
July 15, 2010, 07:29:20 PM
#15
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.
full member
Activity: 210
Merit: 104
July 15, 2010, 06:42:14 PM
#14
Very nice Satoshi. What about the slow block download bug?
newbie
Activity: 42
Merit: 0
July 15, 2010, 06:38:50 PM
#13
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
full member
Activity: 199
Merit: 2383
July 15, 2010, 06:35:21 PM
#12
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.
newbie
Activity: 42
Merit: 0
July 15, 2010, 06:23:17 PM
#11
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
?
Activity: -
Merit: -
July 15, 2010, 06:16:50 PM
#10
This build solved my problem (additional info in this topic https://bitcointalksearch.org/topic/bitcoin-030-runtime-error-373).
full member
Activity: 199
Merit: 2383
July 15, 2010, 06:07:29 PM
#9
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.
legendary
Activity: 1304
Merit: 1015
July 15, 2010, 06:04:30 PM
#8
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: https://bitcointalksearch.org/topic/lost-all-my-bitcoins-359

Maybe we can have a step-by-step procedure to successfully backup and to restore.
founder
Activity: 364
Merit: 7060
July 15, 2010, 05:56:43 PM
#7
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.
newbie
Activity: 42
Merit: 0
July 15, 2010, 05:32:54 PM
#6
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!
sr. member
Activity: 294
Merit: 252
Firstbits: 1duzy
July 15, 2010, 05:32:14 PM
#5
you know you're not actually making 'progress' right? https://bitcointalksearch.org/topic/m.2935
newbie
Activity: 42
Merit: 0
July 15, 2010, 05:25:33 PM
#4
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!!!!
founder
Activity: 364
Merit: 7060
July 15, 2010, 05:23:48 PM
#3
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.

newbie
Activity: 42
Merit: 0
July 15, 2010, 05:11:49 PM
#2
hi satoshi,
are there any back-ups need to be done before installing?
founder
Activity: 364
Merit: 7060
July 15, 2010, 05:05:54 PM
#1
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
Jump to: