Bitcoin-Qt / bitcoind version 0.8.0 released

[DannyHamilton]

- snip -
Also it could be great if we are able to select the address that sent btc from.
The client just use all my available addresses! 

blockchain.info grossly misrepresents how Bitcoin works in various ways.
- snip -
Bitcoin does not have "from" addresses.

Perhaps it would be better to respond to what was meant rather than what was said:

It could be great if we were able to select the outputs that were used as inputs. The client just seems to randomly select outputs.

[Tomatocage]

Sorry if this has already been covered, but I can't seem to get the transaction fee setting to "stick" after I close the client.  It only works for as long as the client stays running, and if I shut it down and restart it again the transaction fee to send goes back to .00000000 BTC. Any ideas on this one?

[deepceleron]

Sorry if this has already been covered, but I can't seem to get the transaction fee setting to "stick" after I close the client.  It only works for as long as the client stays running, and if I shut it down and restart it again the transaction fee to send goes back to .00000000 BTC. Any ideas on this one?

Probably paytxfee=0.00 in the bitcoin.conf file.

[Rampion]

In Mac OSX 10.8.2, when I minimize the bitcoin wallet, it doesn't ever show up again, when I click the app in the dock also when I click show all windows it doesn't up. So this is probably a bug, that should be check out it has happened like 4 times to me.

Yep, I already reported that.

[Nerzahd]

In Mac OSX 10.8.2, when I minimize the bitcoin wallet, it doesn't ever show up again, when I click the app in the dock also when I click show all windows it doesn't up. So this is probably a bug, that should be check out it has happened like 4 times to me.

This happens to me too. (tested on 3 different machines)

[GCInc.]

Why does Bitcoin-qt hog 99% of CPU for WinXP, slow down and make itself unusable, when downloading the last 10000 blocks or so? I cannot afford to burn my cpu at 80+ degrees celsius for days for downloading the last gigs of blockchain - where would high cpu resources used anyway, isn't the client doing mainly just download and not processing tasks?

Sorry if a wrong thread, it's frustrating to be unable to use the client since versions from past year or so. I would like to say bad design, but of course won't do it here.

[Mike Hearn]

If you don't have the resources to run Bitcoin-Qt, consider moving to MultiBit or some other lighter weight wallet app.

[Luke-Jr]

Why does Bitcoin-qt hog 99% of CPU for WinXP, slow down and make itself unusable, when downloading the last 10000 blocks or so? I cannot afford to burn my cpu at 80+ degrees celsius for days for downloading the last gigs of blockchain - where would high cpu resources used anyway, isn't the client doing mainly just download and not processing tasks?

Sorry if a wrong thread, it's frustrating to be unable to use the client since versions from past year or so. I would like to say bad design, but of course won't do it here.

No, blockchain download spends most of its time mainly processing the data.
You can thank flooders like SatoshiDice for making 10000 times more transactions than they should.

[GCInc.]

If you don't have the resources to run Bitcoin-Qt, consider moving to MultiBit or some other lighter weight wallet app.

They have their own problems...

If a fair 2GHz Pentium M Thinkpad with 2GB cannot handle the blockchain, it's sure gonna be a turnoff for a billion potential mainstream adopters. Needing a dual or quad core to process blockchain and then transferring it to the laptop (which I doubt will go smoothly) is not exactly user friendly - but who said it would be at this phase  

You can thank flooders like SatoshiDice for making 10000 times more transactions than they should.

I see, the recent blocks contain magnitudes of orders more transactions and thus process very slowly.

At quick thought the only way forward will soon be centralized servers handling the blockchain, and using lightweight clients fetching only wallet related data. This has probably been discussed at great length here somewhere.

[Gabi]

Why does Bitcoin-qt hog 99% of CPU for WinXP, slow down and make itself unusable, when downloading the last 10000 blocks or so? I cannot afford to burn my cpu at 80+ degrees celsius for days for downloading the last gigs of blockchain - where would high cpu resources used anyway, isn't the client doing mainly just download and not processing tasks?

Sorry if a wrong thread, it's frustrating to be unable to use the client since versions from past year or so. I would like to say bad design, but of course won't do it here.

If your cpu is overheating then you have a problem, and blaming bitcoin for that is not the solution. 80+ C°? Your cpu has something wrong, my cpu at 100% runs at 65°, and it's a quadcore with the default cooler!

Bitcoin use the cpu to verify these blocks

[cypherdoc]

Why does Bitcoin-qt hog 99% of CPU for WinXP, slow down and make itself unusable, when downloading the last 10000 blocks or so? I cannot afford to burn my cpu at 80+ degrees celsius for days for downloading the last gigs of blockchain - where would high cpu resources used anyway, isn't the client doing mainly just download and not processing tasks?

Sorry if a wrong thread, it's frustrating to be unable to use the client since versions from past year or so. I would like to say bad design, but of course won't do it here.

If your cpu is overheating then you have a problem, and blaming bitcoin for that is not the solution. 80+ C°? Your cpu has something wrong, my cpu at 100% runs at 65°, and it's a quadcore with the default cooler!

Bitcoin use the cpu to verify these blocks

the reason the later blocks are taking longer is that they are bigger.  which means the verification process takes longer.

[Technomage]

Bitcoin-Qt is very CPU intensive. I wouldn't mind slightly slower processing if it limited how much it uses CPU, or if there was a setting for that. I have a 3ghz Intel Quad core, which is a decent CPU, and my PC becomes very laggy during the phase where Bitcoin-Qt does all the validations. The CPU usage is essentially 90%+ on all cores which leaves little to any other programs.

The new version also corrupts the blockchain more often in my experience. We've had multiple reports to our site of corrupt blockchains with the new version, definitely more than before. I've personally experienced it with my second PC, as I already reported. I've considered reporting these instances in more detail because I think it is quite problematic. It's possible that these are "very rare cases" that I just happened to run to but I've seen similar reports in Bitcointalk by some others as well.

With the earlier versions corrupted blockchain/wallet was actually very rare, now it isn't that rare anymore. Or maybe there just was a random spike in the problems, I don't know.

[Mike Hearn]

There are no known corruption bugs in the software. It's possible that LevelDB punishes the hardware more, especially with the recent uptick in activity, and this is more likely to expose bad hardware (which is a lot more common than you'd think).

Over time people running nodes on their random overclocked/dusty gaming PCs will become less common for this kind of reason. For now it's nice to be able to keep nodes running on desktops rather than servers though.

[dserrano5]

Bitcoin-Qt is very CPU intensive. I wouldn't mind slightly slower processing if it limited how much it uses CPU, or if there was a setting for that. I have a 3ghz Intel Quad core, which is a decent CPU, and my PC becomes very laggy during the phase where Bitcoin-Qt does all the validations. The CPU usage is essentially 90%+ on all cores which leaves little to any other programs.

bitcoind -par=N: Set the number of script verification threads (1-16, 0=auto, default: 0). Set it to e.g. your number of CPU cores minus one so you'll always have an available core for other tasks.

If on Unix, you can also use the "nice" mechanism.

[phatsphere]

If on Unix, you can also use the "nice" mechanism.

nitpicking: and you can also add ioniceness:

nice ionice -c 3 bitcoind [...]

[dserrano5]

nitpicking: and you can also add ioniceness

But he was talking about CPU, not disk, usage.

I just submitted a pull request that would enable users to leave one CPU core free by saying -par=-1, regardless of the number of existing cores.

[malevolent]

Bitcoin-Qt is very CPU intensive. I wouldn't mind slightly slower processing if it limited how much it uses CPU, or if there was a setting for that. I have a 3ghz Intel Quad core, which is a decent CPU, and my PC becomes very laggy during the phase where Bitcoin-Qt does all the validations. The CPU usage is essentially 90%+ on all cores which leaves little to any other programs.

The new version also corrupts the blockchain more often in my experience. We've had multiple reports to our site of corrupt blockchains with the new version, definitely more than before. I've personally experienced it with my second PC, as I already reported. I've considered reporting these instances in more detail because I think it is quite problematic. It's possible that these are "very rare cases" that I just happened to run to but I've seen similar reports in Bitcointalk by some others as well.

With the earlier versions corrupted blockchain/wallet was actually very rare, now it isn't that rare anymore. Or maybe there just was a random spike in the problems, I don't know.

If you're on Windows go to task manager and click on the process to change affinity (number of cores used, set it to 1 or 2) and priority (set it to the lowest value so that it won't take inconveniently lot amount of cpu power while you are working).

[phatsphere]

nitpicking: and you can also add ioniceness

But he was talking about CPU, not disk, usage.

I just submitted a pull request that would enable users to leave one CPU core free by saying -par=-1, regardless of the number of existing cores.

Well, due to the less frequent interrupts, the pipelining works better, smoother experience. And -1 on a single core machine could be fatal ;-)

[Digigami]

There are no known corruption bugs in the software. It's possible that LevelDB punishes the hardware more, especially with the recent uptick in activity, and this is more likely to expose bad hardware (which is a lot more common than you'd think).

Over time people running nodes on their random overclocked/dusty gaming PCs will become less common for this kind of reason. For now it's nice to be able to keep nodes running on desktops rather than servers though.

Emphasis mine.. I'm not over clocked or otherwise tampered with, but it really has been a long time since I ran any stress tests on this machine so maybe that's the case for me.

I'm curious as I actually had a hell of a time with this upgrade. I eventually realized the issues I had were entirely my own doing, so I know my enviroment is unrelated but I'm wondering for future reference if the enviroment I am using could cause more issues down the road. I run this particular client in a Ubuntu/Pinguy OS VM using VMware player on a Win7 host machine. The host machine is a reasonably powerful quad core Intel with HT, and more then enough memory to support itself and so far I've had 5 different VM's running at once, usually allocated 1.5 - 2 GB of memory. I find this offers a significant benefit when syncing a fresh client especially when using a bootstrap.dat to kick things off. As long as I'm not in a big hurry for it to process and finish syncing, this lets me easily dedicate 2 cores to the VM and let me be as productive as normal on a different VM or within the host machine. In this case it was not the cause of my problems, but now I am curious if using a VM enviroment open up more chances for corruption of the block chain or wallets? Less possibly because it is an isolated system? Any thoughts on doing things in this fashion? My goals were security for my coins, portability to move wallets easily (I usually just transfer the whole VM) and easy backup and redundancy. Encrypted wallet residing inside encrypted VM, and host storage of VM's is all encrypted when not in use as well. Perhaps a little redundant, but I feel a little safer this way should one of my backups ever fall into some others hands.

[CIYAM]

Issues that I'd had before with my notebook *freezing* at every new block arrival have *gone*.

It is much smoother and appears to be much quicker (in catching up blocks) also.

Great stuff guys!!