Please test: Bitcoin v0.3.22 release candidate

[Matt Corallo]

Fedora 13 x64, bitcoin 3.22.rc3. Says "Generating" in bottom right corner and displays a meager hashrate in the left. Moreover, I can't turn it off since the option has been removed from the menu. Using up CPU, so not just a UI bug.

I'm assuming you built yourself...are you sure you sure you are running the latest version and are you sure you didnt link some stale outputs?  Also, -gen will still turn on generation, and yes, you won't be able to turn it off via GUI.  Don't specify -gen for your client (it is assumed if you are able to turn that one, you can also turn it off).

[1714106883]

1714106883

[1714106883]

1714106883

[1714106883]

1714106883

[1714106883]

1714106883

[1714106883]

1714106883

[theboos]

Fedora 13 x64, bitcoin 3.22.rc3. Says "Generating" in bottom right corner and displays a meager hashrate in the left. Moreover, I can't turn it off since the option has been removed from the menu. Using up CPU, so not just a UI bug.

I'm assuming you built yourself...are you sure you sure you are running the latest version and are you sure you didnt link some stale outputs?  Also, -gen will still turn on generation, and yes, you won't be able to turn it off via GUI.  Don't specify -gen for your client (it is assumed if you are able to turn that one, you can also turn it off).

Did not build it myself; I downloaded bitcoin-0.3.22rc3-linux.tar.gz from sourceforge, extracted, and updated my shortcut. It is running the correct version because the option has been removed.

[allinvain]

This is just a suggestion, but wouldn't it be a good idea if development now focuses also on the usability and appearance of the client software? Maybe a slicker interface, make it as dummy proof as possible? I dunno. I'm thinking out loud.

[marcus_of_augustus]

This is just a suggestion, but wouldn't it be a good idea if development now focuses also on the usability and appearance of the client software? Maybe a slicker interface, make it as dummy proof as possible? I dunno. I'm thinking out loud.

You mean like linux packages in a repository somewhere?

(I got it built in fedora but god, what a mission, maybe a bounty is in order here?)

[AltPluzF4]

Hmm.
Windows 7 Pro x64
When I start my local miner, bitcoin.exe goes up to a constant 25% CPU usage (Quad Core) Even after closing phoenix, and bitcoin, the process remains (at 25% CPU) until I manually terminate it.

No issues with 0.3.21 though. Any ideas?

Might you inform us of which/how many threads are using so much cpu (using Process Explorer) as well as any other info you might deam worth sharing.

Just one thread. I don't currently have my pc set up to compile the source, so I can't really give any details of what thread :-/

Anyway, I'm able to cause this issue just by using the RPC getwork command. Calling it once causes the RPC server to just start running full cpu usage (Quad Core, 25%, one thread.) And the only way for me to "fix" it is to force the process to end and restart bitcoin :-/

If there's any more info you need, please elaborate...

[allinvain]

This is just a suggestion, but wouldn't it be a good idea if development now focuses also on the usability and appearance of the client software? Maybe a slicker interface, make it as dummy proof as possible? I dunno. I'm thinking out loud.

You mean like linux packages in a repository somewhere?

(I got it built in fedora but god, what a mission, maybe a bounty is in order here?)

That too, but I was thinking more along the lines of making the interface a bit more pretty and maybe tidying up and ensuring it's as clearly laid out as possible. Any graphical interface specialists/usability experts on the bitcoin development team?

Linux packages for as many distros as possible along with freebsd, openbsd, netbsd, etc packages would also be a huge plus.

[eMansipater]

Excellent job on this one, all!  Next goal--simple tooltips on startup that explain what "xxxx blocks" means in the lower right as the blockchain is downloaded.  Can't tell you how many new users are a) confused about what's happening and b)think they're mining these blocks!

[Matt Corallo]

Just one thread. I don't currently have my pc set up to compile the source, so I can't really give any details of what thread :-/

Anyway, I'm able to cause this issue just by using the RPC getwork command. Calling it once causes the RPC server to just start running full cpu usage (Quad Core, 25%, one thread.) And the only way for me to "fix" it is to force the process to end and restart bitcoin :-/

If there's any more info you need, please elaborate...

Process Explorer will give you an entry point to point out which thread it is...and there is a possibility someone smart than myself can point out which thread it actually is. http://technet.microsoft.com/en-us/sysinternals/bb896653

[xf2_org]

Release candidate #5 source and binaries uploaded to https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.22/test/

Hopefully this is the last one, though TX fee discussions are still ongoing.

Main change:

- TX fee 0.0005 rollout was deemed too aggressive, and was partially rolled back.  See this post for details.

Other changes:

- Translation updates: dutch, spanish, czech, german
- minor bug fixes

[mrb]

I have been running 0.3.22rc3 for ~7 days on Ubuntu 10.04 64-bit. A few miners pointed to it. Solved a block or two. Seems to be solid.

[xf2_org]

Release candidate #6 source and binaries uploaded to https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.22/test/

Gavin seems happy with the current phased TX fee rollout, so barring unforseen last minute bugs, -rc6 should be equivalent to the 0.3.22 release.

Main change in -rc6:

- Fix brown paper bag bug that prevented relaying of free transactions

Other changes:

- Linux and Windows build tweaks.  Enable RPC SSL on Win32.

[gmaxwell]

I think 0.3.22 should be delayed because the software basically does not work correctly for new nodes behind nat / w/o port forwarding.  T

The behavior a typical firewalled new users sees is that they start the software and they see 0 connected. The system may spend hours in this state. Restarting the client repeatedly may make it get connected, but it may not receive any blocks.  Eventually if they are patient enough and/or restart enough they will probably get synced up to the network but it may take then 24 hours. The same problems exist in 0.21 but there are non-merged fixes available.

If they addnode a working node, or forward the port then it will work pretty easily. But thats a lot more work to just get the software going.

I think this gives users an initial impression that the bitcoin technology is unreliable and dampens interest and confidence in bitcoin.

I've written more about this issue in http://forum.bitcoin.org/index.php?topic=11126.0

Failing the delay of .22, I think a .22.1 update should be released quickly— the features planned for 0.4.0 include a number of potentially dangerous changes (like encrypted wallets) which ought not be rushed.

[vuce]

Could you please fix the bug with wallet not having 100 addresses at the beginning.

[xf2_org]

The network is experiencing growing pains, sure, but cries of "Bitcoin doesn't work for new users" are just hyperbolic, considering this is an issue that has been present for years and bitcoin does seem to work for new users.

There are always calls for One More Issue to be stuffed into a release, and this is no different.  Adding anything to 0.3.22 means another round of testing, probably delaying the release at least another 7-10 days.

If you have an important issue, it is easy enough to release a 0.3.23, but further 0.3.22 delays seem unwise.

[gmaxwell]

The network is experiencing growing pains, sure, but cries of "Bitcoin doesn't work for new users" are just hyperbolic, considering this is an issue that has been present for years and bitcoin does seem to work for new users.

Unfortunately I can't go back in time and do careful testing a month ago. What I can tell you is that a month ago I brought up two firewalled nodes and immediately got connections... I was surprised a few weeks later when people started showing up in #bitcoin complaining of being stuck in 0 connections state. And I'm now finding that a configuration which clearly worked before (firewalled hosts) no longer starts up reliably.

While the software hasn't changed in this regard, the composition of the network has.  It's not hard to see how the old situation worked fine when most hosts were accepting connections, but with a super-majority not accepting connections it appears to be failing pretty much completely for a popular configuration.

I don't think thats particularly hyperbolic…

There isn't any particularly compelling reason for most users to upgrade right now, nor do these fixes have big network effects (e.g. a connect() timeout fixed node is still fixed regardless of what the rest of the network runs). So this not making it into .22 may not matter much ultimately, so long as a version with the fixes is quickly forthcoming.

[Cryptoman]

I've been testing the -port option, and it doesn't seem to work.  I set a different port, yet bitcoind seems to still be establishing connections on 8333 (as shown by netstat).  I tried setting the port through both the command line option and in the bitcoin.conf file.  Has anyone else tested this?

[spleeder]

Downloading RC6 now

[Matt Corallo]

I've been testing the -port option, and it doesn't seem to work.  I set a different port, yet bitcoind seems to still be establishing connections on 8333 (as shown by netstat).  I tried setting the port through both the command line option and in the bitcoin.conf file.  Has anyone else tested this?

Bitcoin still has to make a ton of outgoing connections to ...:8333 because that is where remote nodes are listening and thus connections must be made to that port, but, as always, it will connect from ...:[random high-number port].  According to my system, it is listening properly on *:[port i set]

[cypherdoc]

I've been testing the -port option, and it doesn't seem to work.  I set a different port, yet bitcoind seems to still be establishing connections on 8333 (as shown by netstat).  I tried setting the port through both the command line option and in the bitcoin.conf file.  Has anyone else tested this?

Bitcoin still has to make a ton of outgoing connections to ...:8333 because that is where remote nodes are listening and thus connections must be made to that port, but, as always, it will connect from ...:[random high-number port].  According to my system, it is listening properly on *:[port i set]

Matt, can u use Process Explorer to detect specific activity localized to port 8333?

[Matt Corallo]

Matt, can u use Process Explorer to detect specific activity localized to port 8333?

If you double-click on the process, and click the TCP/IP tab, it will show you which connections belong to that process.