Topic: Bitcoin-Qt / bitcoind version 0.8.0 released (Read 29438 times)

This went well....

A LOT faster than before, thanks guys!

That's because bitcoin-qt does not create it by default.  You're required to make one only when running bitcoind IIRC.

Just make one in your .bitcoin directory.

Hey thanks for your help.

Finally got the symlink working.

Nice 1.

Hi grondilu, yes I am using an NFS partition, and yes I am talking about moving the data to another computer.
The issue being, I can't mount .bitcoin on another partition, and I don't think that requires an individual entry in fstab, as the folder it is placed in is mounted anyway.

My system does not have a bitcoin.conf anywhere.

You're not very clear.  You're talking about moving your data to an other computer.  Are you trying to use NFS or something?   I doubt so.  I suspect you're talking about mounting your .bitcoin directory on an other partition.  Which is the simplest solution to your problem.  If you do so, you can also use symbolic links to store your wallet somewhere else.

Also, it might be necessary to define the new location for your datadir in bitcoin.conf (which must be present in both destination, I guess).   Though just on command line should be enough, normally.

Hey guys, any idea why I can't get bitcoin-qt to see and use my new data directory?
I am using Linux and the .bitcoin folder is now 13Gb in size. WTF! This must be wrong.
I now only have about 200Mb left on my home drive.
So, I have moved the .bitcoin folder to another computer on my home network, but when I run the
"bitcoin-qt -datadir=/home/*******/BITCOIN/.bitcoin"
from the command line, it launches but opens with an empty wallet, and recreates a new .bitcoin folder in my old Home partition, and
starts to redownload from the internet.

This is not good news.

Any ideas?

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!!

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.

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

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).

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.

nitpicking: and you can also add ioniceness:

nice ionice -c 3 bitcoind [...]

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.

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.

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.

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

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

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  

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.

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.