Topic: Please test: Bitcoin v0.3.22 release candidate - page 2. (Read 15924 times)
Could you please fix the bug with wallet not having 100 addresses at the beginning.
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.
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.
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.
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.
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
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
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 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...
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!
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.
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.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?
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...
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?)
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.
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.
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).
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.
Code:
/usr/include/miniupnpc/miniupnpc.h:53: error: too few arguments to function ‘UPNPDev* upnpDiscover(int, const char*, const char*, int, int, int*)’
huh, sorry :p
my baaad xD
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. 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?
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?
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?
Release candidate #4 source and binaries uploaded.
Changes:
- add chinese, esperanto translations
- update russian, italian translations
- OSX build tweaks
- Windows installer fixes
Changes:
- add chinese, esperanto translations
- update russian, italian translations
- OSX build tweaks
- Windows installer fixes
As a side note, if you wish to attempt to duplicate the builds, you can try using the script at https://gist.github.com/961527.
The Linux ones should end up with hash-identical binaries, but I've never tested the Win32 ones. They might work, but I'd bet there are several small differences (build timestamps and such).
Please don't comment on the build system here, that is best left to another thread and/or direct questions on IRC (I'm BlueMatt).
The Linux ones should end up with hash-identical binaries, but I've never tested the Win32 ones. They might work, but I'd bet there are several small differences (build timestamps and such).
Please don't comment on the build system here, that is best left to another thread and/or direct questions on IRC (I'm BlueMatt).
Got a link to a thread with Redhat derivative (Fedora, CentOS, RH) builds help.
It's just one missing package after another. The file "build-unix.txt" should perhaps be renamed "build-ubuntu.txt" ... not sure what other unix that file helps on but it is next to useless for RH.
As a side note, if you wish to attempt to duplicate the builds, you can try using the script at https://gist.github.com/961527.
The Linux ones should end up with hash-identical binaries, but I've never tested the Win32 ones. They might work, but I'd bet there are several small differences (build timestamps and such).
Please don't comment on the build system here, that is best left to another thread and/or direct questions on IRC (I'm BlueMatt).
The Linux ones should end up with hash-identical binaries, but I've never tested the Win32 ones. They might work, but I'd bet there are several small differences (build timestamps and such).
Please don't comment on the build system here, that is best left to another thread and/or direct questions on IRC (I'm BlueMatt).
Jump to: