Bitcoin-Qt, bitcoind version 0.5.3 released

[Luke-Jr]

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

This is a bugfix-only release based on 0.5.1.
It also includes a few protocol updates.

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

Stable source code is hosted at Gitorious:
  http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.3#.tar.gz

PROTOCOL UPDATES

• BIP 30: Introduce a new network rule: "a block is not valid if it contains a transaction whose hash already exists in the block chain, unless all that transaction's outputs were already spent before said block" beginning on March 15, 2012, 00:00 UTC.
• On testnet, allow mining of min-difficulty blocks if 20 minutes have gone by without mining a regular-difficulty block. This is to make testing Bitcoin easier, and will not affect normal mode.

BUG FIXES

• Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all.
• Fix possible buffer overflow on systems with very long application data paths. This is not exploitable.
• Resolved multiple bugs preventing long-term unlocking of encrypted wallets
  (issue #922).
• Only send local IP in "version" messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable.
• Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting.
• Skip splash screen when -min is used, and fix Minimize to Tray function.
• Do not blank "label" in Bitcoin-Qt "Send" tab, if the user has already entered something.
• Correct various labels and messages.
• Various memory leaks and potential null pointer deferences have been fixed.
• Handle invalid Bitcoin URIs using "bitcoin://" instead of "bitcoin:".
• Several shutdown issues have been fixed.
• Revert to "global progress indication", as starting from zero every time was considered too confusing for many users.
• Check that keys stored in the wallet are valid at startup, and if not, report corruption.
• Enable accessible widgets on Windows, so that people with screen readers such as NVDA can make sense of it.
• Various build fixes.
• If no password is specified to bitcoind, recommend a secure password.
• Automatically focus and scroll to new "Send coins" entries in Bitcoin-Qt.
• Show a message box for --help on Windows, for Bitcoin-Qt.
• Add missing "About Qt" menu option to show built-in Qt About dialog.
• Don't show "-daemon" as an option for Bitcoin-Qt, since it isn't available.
• Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0.
• Add checkpoint at block 168,000.

Thanks to everybody who contributed code or helped test this release:

Pieter Wuille
Luke Dashjr
Wladimir J. van der Laan
Gavin Andresen
Matt Corallo
Lars Rasmusson
Janne Pulkkinen
Gregory Maxwell
Daniel Folkinshteyn
Chris Moore

[cypherdoc]

why does the Sourceforge link say 0.5.2 for win 32?

the choices below don't indicate a 0.5.3 win 64 bit version as far as i can see.

[Luke-Jr]

why does the Sourceforge link say 0.5.2 for win 32?

Fixed.

the choices below don't indicate a 0.5.3 win 64 bit version as far as i can see.

Win64 is not, never has been, and is not planned to ever be, supported... Win32 builds should run fine, since Win64 isn't really pure 64-bit (it's hybrid; both 32-bit and 64-bit)

[triplehelix]

Win64 is not, never has been, and is not planned to ever be, supported... Win32 builds should run fine, since Win64 isn't really pure 64-bit (it's hybrid; both 32-bit and 64-bit)
[/quote]

why?  isn't bitcoin something that could really benefit from the jump to 64-bit?

[Luke-Jr]

why?  isn't bitcoin something that could really benefit from the jump to 64-bit?

In short, no. The only benefit to 64-bit userspace is large virtual machines (over 2-4 GB RAM) and applications where a small boost in performance matters more than memory usage (64-bit uses ~twice as much memory). Also, no Bitcoin developers actually use Windows, and I don't think Ubuntu supports targeting Win64.

[Hal]

File this one under "you can't win."

I fired up the new client after several days, the progress bar immediately went to 99%, and stayed there for the next ten minutes. I guess some people found the old behavior confusing, but of what use is this behavior?

[chungy]

why?  isn't bitcoin something that could really benefit from the jump to 64-bit?

In short, no. The only benefit to 64-bit userspace is large virtual machines (over 2-4 GB RAM) and applications where a small boost in performance matters more than memory usage (64-bit uses ~twice as much memory). Also, no Bitcoin developers actually use Windows, and I don't think Ubuntu supports targeting Win64.

mingw64 should work fine on Ubuntu, but whether the Bitcoin client/daemon actually build for 64-bit Windows is another matter... and as you've already explained, a 64-bit Windows build is fairly pointless at this time, and it'd remain pointless until Microsoft drops 32-bit support (maybe in 10 years )

[Meni Rosenfeld]

File this one under "you can't win."

I fired up the new client after several days, the progress bar immediately went to 99%, and stayed there for the next ten minutes. I guess some people found the old behavior confusing, but of what use is this behavior?

I should call you "Lazarus".

Welcome back.

[cypherdoc]

File this one under "you can't win."

I fired up the new client after several days, the progress bar immediately went to 99%, and stayed there for the next ten minutes. I guess some people found the old behavior confusing, but of what use is this behavior?

I should call you "Lazarus".

Welcome back.

Isn't lazarus the pizza guy?

[istar]

Great work guys!

[Matoking]

The progress bar behavior was changed again? I personally found the older behavior more useful, since it actually showed progress elsewhere besides the initial download.

Maybe the progress bar could be hidden entirely/set to busy instead of showing a percentage of 99% if it only needs to download less than 1% of blocks?

[N12]

I would like the old progress bar back. This one is just useless.

[ThePok]

Make the Progressbar show more details: not only 99%  but 99.67% That number would climb visible

[evoorhees]

I would like the old progress bar back. This one is just useless.

Yeah definitely a regression.

[Luke-Jr]

There's a bug in the new testnet mining code, so I'm running 0.5.4 now with that and a few other fixes. (Sorry guys, the progress bar is not reverted in 0.5.4.)

Edit: Nevermind, Gavin wants to hold off on 0.5.4 until BIP16 is ready, so it'll probably be another week or so. Also, both Wladimir and Gavin disagree with reverting the progress bar fix, sorry.

[N12]

both Wladimir and Gavin disagree with reverting the progress bar fix, sorry.

Why? What sense does it make? A 99% bar is simply useless.

If most of the users do not like it (as is my impression), then I see no reason why it should not be reverted. Maybe vote?

[slothbag]

I agree, the 99% bar is silly. Everytime I load the app it shows 99% for a minute and then disappears.. Makes me think something's broken.

Bring back the useful progress bar!

[rjk]

I agree, the 99% bar is silly. Everytime I load the app it shows 99% for a minute and then disappears.. Makes me think something's broken.

Bring back the useful progress bar!

Next thing we hear will be a call for "democracy" and compromise by including both progress bars. Submit a pull request.

[paraipan]

I agree, the 99% bar is silly. Everytime I load the app it shows 99% for a minute and then disappears.. Makes me think something's broken.

Bring back the useful progress bar!

+1 agree with this

[triplehelix]

i'm new to bitcoin so still learning.  how are things like the progress bar usually addressed?  is it community driven or does gavin get to decide whatever he wants?