Bitcoin Forum

Bitcoin version 0.6.2 is now available for download at:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.2/

This is a bug-fix and code-cleanup release, with no major new features.

Please report bugs using the github issue tracker at:
  https://github.com/bitcoin/bitcoin/issues

NOTABLE CHANGES
===============

Much faster shutdowns. However, the blkindex.dat file is no longer
portable to different data directories by default. If you need a
portable blkindex.dat file then run with the new -detachdb=1 option
or the "Detach databases at shutdown" GUI preference.

Fixed https://github.com/bitcoin/bitcoin/issues/1065, a bug that
could cause long-running nodes to crash.

Mac and Windows binaries are compiled against OpenSSL 1.0.1b (Linux
binaries are dynamically linked to the version of OpenSSL on the system).


CHANGE SUMMARY
==============

Use 'git shortlog --no-merges v0.6.0..' for a summary of this release.

Source codebase changes:
- Many source code cleanups and warnings fixes.  Close to building with -Wall
- Locking overhaul, and several minor locking fixes
- Several source code portability fixes, e.g. FreeBSD

JSON-RPC interface changes:
- addmultisigaddress enabled for mainnet (previously only enabled for testnet)

Network protocol changes:
- protocol version 60001
- added nonce value to "ping" message (BIP 31)
- added new "pong" message (BIP 31)

Backend storage changes:
- Less redundant database flushing, especially during initial block download
- Shutdown improvements (see above)

Qt user interface:
- minor URI handling improvements
- progressbar improvements
- error handling improvements (show message box rather than console exception,
  etc.)
- by popular request, make 4th bar of connection icon green



Thanks to everybody who contributed to this release:

Chris Moore
Dwayne C. Litzenberger
Gavin Andresen
Jeff Garzik
Luke Dashjr
Matt Corallo
Philip Kaufmann
Pieter Wuille
R E Broadley
Timothy Redaelli
Wladimir J. van der Laan
cardpuncher
freewil
graingert
sje397

Kudos to Gavin and the other developers and testers for this release.

Is the crash bug that was fixed likely to be the cause of std::bad_alloc exceptions that I've been receiving on Windows occasionally?  (I'm running a custom build with some code modifications so I wasn't sure if the exceptions were my fault or something wrong in the system.)

Hi guys,

I just upgraded to the new v0.6.2 Mac release directly from v0.6.0.  I'm on the latest version of OSX 10.7.3 and I've never really had any kind of major trouble running any of the recent releases.

I noticed with this new version, after running normally for a few minutes, it pegs one CPU at 100% and basically keeps it there until the program is closed.  I noticed this happening consistently, after multiple open/closes and reboots.  It happens every time.  It starts up running fine (seems to open and close speedier now too) but after a few minutes of running normally at 0-5% CPU utilization, it spikes to 100% and stays there until I close it.  Apart from that, it seems to be running perfectly normal, has not crashed, and I've seen no other major issues.

Is there something this version should be doing that would require that kind of processor power for so long, or is this a bug that can hopefully be quashed?  (or is this the start of stealth CPU mining?   :D )

I watched the debug.log the last few times to see if I could find anything interesting that would correlate with the spike in CPU usage, but no.


Also, one new little visual glitch I noticed since the last version: when you app switch to Bitcoin-Qt using either the task switcher or the Dock icon, the program doesn't jump to the foreground as it should (and used to).


Please me know if there's anything further I can tell you that would help diagnose these, and thanks for the help.

I have the same configuration as toffoo, and am also experiencing the same issue: Bitcoin-QT 0.6.2 keeps 1 CPU stuck at 100% utilization for no reason.

There is indeed a problem with the OSX version, resulting in 100% usage. We're working on a fix.

May I ask why wasn't the new language pt_PT included in the release? It's 100% complete for 2 weeks already.
Also there should be some quality control on the translations. pt_Br, for instance, says in transifex to be 77% translated when in reality more than 50% of the text is still in english. It shows as translated because the strings aren't empty, but they are only a copy of the english source.

Also, there is a small bug in Ubuntu. No menus and no sys tray icon. Ubuntu 12.04 using Unity
I should add that it's not really a small bug as now I have no other way to close my client besides terminating it on the console by it's process ID. Had the minimize to tray on close selected :P

Because when I was a young child a Portuguese family lived across the street from me and their oldest child bullied me mercilessly, making fun of my haircut and my funny Australian accent.

(KIDDING!  JUST KIDDING!)

Somebody to do translation quality assurance is a great idea. Want to volunteer?

I can only do it on languages I understand, and more eyes would be needed. Who controls the quality controlers, after all? :D I can have a look at the languages I don't understand and remove the english strings, if they exist, so at least the project in Transifex shows the correct percentage of what is done.

Thanks much Gavin and team for the new release, again am wondering if I can just shutdown my v0.6.0.7 beta release under windows, install the new exe and bring the client back online without any problems?

Thanks for the quick feedback on this guys.

Is it possible to swap the binary back to v0.6.0 or v.0.6.1 without messing anything up until a fix comes out ... so I can continue running the client without my laptop scorching my crotch?

Kudos to you all.

Worked flawlessly on Win 7 32bit.

Working fine here.

Pieter fixed the "100% usage on OSX bug" and I created and uploaded a fixed version 0.6.2.2 especially for the Mac.

RE: upgrading:  the best upgrade practice is to:

1) Backup your wallet someplace safe (if you're running an 0.6 release then use the Backup Wallet menu item).
2) Shutdown. Make sure Bitcoin isn't still in your system tray-- don't just close the window, shut it down.
3) Wait a minute or two (it can take older versions a minute or two to completely shut down)
4) Install and run the new version.

I know the new version is "faster" to shut down, but how much faster should I expect it to be? I haven't really timed it, but the old version seemed to take between 30 sec and 1 min to shut down completely.

It depends on what caused the slowdown. While not syncing the chain, with no caches to write at shutdown, I often get shutdowns close to a second or less now. During chain download, it can be significantly more.

Just during normal operation. I always figured it was doing some kind of shutdown sync, but that didn't really make sense because of my fast SSD and stuff. But the new version does shut down within 0.5 seconds for me now.

Could someone explain the differences with a portable and non-portable blkindex.dat?

Portable means you can move/copy it to another data directory.

If changes have been made to a .dat file (except blk0001.dat, which isn't really a database), an "lsn_reset pass" is necessary before the file can be used in another data directory (or the same, if its logfiles are deleted). Versions prior to 0.6.1 would always perform this pass at shutdown - which could take up to a minute on some systems. Since 0.6.1, this process is made optional for addr.dat and blkindex.dat. Wallets are always made portable at shutdown.

Thanks guys, I can confirm the v0.6.2.2 Mac version fixed the CPU bug.  However, the "switch to foreground" issue I mentioned looks like it's still there for the next version to fix.

@Toffoo - Yes seeing some inappropriate switching to foreground behavior too.  Running 3 different Windows 0.6.xx versions here, no change in that which I've noticed.  Was trying to figure out how to document that just yesterday, somewhat hard to describe.

Just wanted to add...

Gavin's recommended upgrade path went smoothly, no problems to report there, although while reviewing which files had changed, was surprised to find that in windows explorer, under the Program Files/bitcoin subdirectory as well as the bitcoin/src (plus subs) & bitcoin/daemon folders, all the files date/time stamps remain the same, stuck on 1/29/2011.  Both the date modified and the date created fields, odd that I can't look at those quickly and be able to tell which files have been modified recently.  Mostly it would be nice to at least see the bitcoin-qt.exe file has a newer time stamp on it, before running....

My initial install was back one April 2nd 2012, can clearly see that as the folders dates modified & created are working fine, it's just the files themselves which aren't changing....

GR

Needs to be mate into a t-shirt..and sold for Bitcoin.

I'm running into a minor annoyance that is happening on two separate Windows 7 x64 machines.  After exiting bitcoin-qt, the icon remains in the system tray until you move the mouse over it.  I'm not sure if it is a Windows issue or something specific to my display settings, but I don't recall it happening with earlier versions.  Anyone else seeing the same behavior?

I see it on my Win 7 x64 machine. Wasn't like that on version 0.6.1.

Yup.  I think I see it on my XP laptop as well. 

I was wrong. Tried version 0.6.0, 0.6.1 and 0.6.2 now.

0.6.0 = OK
0.6.1 = icon remains in system tray
0.6.2 = icon remains in system tray

I see that too on W7 x64, and additionally another display anomaly: Clicking the icon once pops the window into the foreground, and clicking again puts it back down in the tray. This isn't a bad thing, but it is different from how it used to work. It used to require a double click to open, and X it out to minimize to tray.

Hey, I didn't have time to check the thread if this already has been reported, but after installing, running it for the first time I get a "Runaway exception" error. It says "EXCEPTION: NSt8ios_base7failurE" and "CDataStream::()read : end of data" on the last line it says "C:\Program Files\Bitcoin\Bitcoin-qt.exe in runaway exception"

I'm running windows 7 and 0.6 worked fine. I already uninstalled 0.6 before installing 0.6.2 but still the same error.

When sending coins from one of your addresses to another one of your addresses, the client only displays an entry saying "transaction to yourself" without listing the amount or the from/to address.
While this isn't a bug, it makes keeping track of your coins difficult. Blockchain.info for example lists the transaction just like every other one; I suggest that the client should do the same.

bitcoin-qt has a flaw when you have thousands of transactions It starts to be a CPU and memory hog. Plus it looks like it was done in VB6. The GUI is crap, please go back to one of the beta designs as it was far superior.

I'm running this on windows, setting the priory to low, and setting the affinity to only using 2 CPU's on bitcoin-qt.exe. No real change, still a hog.

The client started to become a more of a resource whore around the ~1000 transactions mark... not sure 100% tho. I'm a little over 11k transactions.. and doing more and more everyday.

I've tried multibit, and Electrum.. both sux imho...  May give multibit another try, but hate running java.. *sigh*

I know of a few other users with the same issue... From my conclusion it seems that the bitcoin client does not like to have thousands and thousands of transactions

Any suggestions?

lol VB6. It's called Qt and it's from Nokia: http://qt.nokia.com/
If you really have 11,000 transactions, why are you even using the GUI?

And if you know how to program in wx, you are welcome to maintain the old version. Luke-Jr will even help you set it up.

And that's why it sucks :P

Looks far better than most Java stuff, you must admit.

It's actually not from Nokia... Nokia bought out it's creator (Trolltech) in 2008 and hasn't changed much since.

Happy I got some lol's out of the VB6 comment. :D

So, run bitcoind instead of GUI you're saying?

Thanks!

It would definitely be more efficient, especially if you have some way of automating your process (sounds high volume). It requires you to send it commands and get a response, like most daemon applications, so it won't be like clicking a bunch of buttons and away you go. But it will run with your existing wallet with no problems.

Just curious, care to explain why you didn't like Electrum and MultiBit? Have you tried both recently?

This will be fixed with the next version, I created a patch for this. Was related to how Bitcoin-Qt was exit until 0.6.2.

Dia

That's a new feature and intended! Should have been mentioned in the changelog, perhaps it was in and you didn't see it ;)?

Dia

You should perhaps create an issue ticket directly on Github.

Dia

I think it would be more useful, for people like me who don't keep the client running all the time, to display the date and time for when transactions are added to the blockchain and not when my client happens to catch up and notices those transactions. 

For instance I might do several transactions over the week but when I start my client up at the end of the week - today for example - it makes it appear all those transactions happened just today. 

I know I could investigate using blockchain.info to find this information but it would more convenient if the client could display proper transaction times. 

For people who do keep the client running all the time they wouldn't even notice a change if this was implemented. 

From the client's perspective, there isn't any way to tell except with the block timestamps which I doubt it will trust.

I don't have an account there, maybe someone could push it to github?

In the freebsd port tree (/usr/ports/net-p2p/bitcoin) there is still the v0.4.0 version.
Does any of you guys have the skills or know who we can ask to bring this port up to 0.6.2?

Looks like the committer is shaun at freebsd dot org. Strangely he updated the Makefile two days ago.

I thought I read the other day that the blocks are timestamped with the current epoch time according to whoever solved it, using unsigned integer?

Yeah well the "according to who solved it" is what I was thinking about. But I don't know enough about that part of the system to say a whole lot about it.

Ran into another bug:

I sent some coins (using coincontrol) from one of my addresses (A) to another person (B) and decided to send the leftover amount (essentially the change) to one of my addresses (C).
The transaction to the other user just shows up fine in the transactions tab, however the one to myself is missing in the list.
Since the involved balances are all correct (A to B is ok, change went to C, A is empty), I assume it's just not displayed in the transaction list.

This is not a bug, it's a feature. It's not shown since, conceptually, it "never really left your wallet." (Which glosses over all the technical details which you are 100% familiar with, but our target audience will not be.)

Then it's a bug that all others transactions to myself show up? I've been using coincontrol to move around a few of my coins from one address to another (yeah, I shouldn't care about that, but sometimes I'm just like that) and each of those gets listed. Without the sending/receiving address and the amount though, see my bug report a few posts earlier here (well, the amount shows up, but only if you double click a transaction). I understand that automatic coin-change transactions don't need to be displayed, but when I manually create the transaction, I expect it to be listed.

As for coin-change in general: it would be nice if the change would go to the address from which coins are send. Or if there was an option to display all transactions, even automatic change transfers.

;D

To get full developer attention you need to open a ticket for such things on Github :).

Dia

Had the power go out this afternoon, been running the client for the last week 24/7, no problems there.   Now I was lucky today, because had just shut the client down a few hours before the power flicked out, so not asking because of an emergency, just want to be prepared...

What should one do if the client is running (WinXP) when the power fails? 

Not asking about basic computer problems/solutions here, such as lost/bad clusters that might result, strictly asking about recommendations pertaining to the client software and the integrity of it's file system.  Assume no transaction was in progress when the power failed, it was simply open and active at the time. 

1) Should some files in the app data folder be deleted before restarting?

2) Lets say upon restart, the balance remains correct and no errors show up while re-sync, are we good to go?  Should some form of validation be preformed?

3) Are there various errors that might appear, and/or recommendations on how they should be repaired, if encountered?

Thanks much, 6.2 has been working great for me...

GR