When the maintainer (Matt) has a little time.
No, not yet. Anybody know if there's a web page that will do the verification?  (would be easy to create one...)
Yes.

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

This release includes more than 20 language localizations.
More translations are welcome; join the
project at Transifex to help:
  https://www.transifex.net/projects/p/bitcoin/

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

Project source code is hosted at github; we are no longer
distributing .tar.gz files here, you can get them
directly from github:
 https://github.com/bitcoin/bitcoin/tarball/v0.6.0  # .tar.gz
 https://github.com/bitcoin/bitcoin/zipball/v0.6.0  # .zip

For Ubuntu users, there is a ppa maintained by Matt Corallo which
you can add to your system so that it will automatically keep
bitcoin up-to-date.  Just type
 sudo apt-add-repository ppa:bitcoin/bitcoin
in your terminal, then install the bitcoin-qt package.


KNOWN ISSUES
------------

Shutting down while synchronizing with the network
(downloading the blockchain) can take more than a minute,
because database writes are queued to speed up download
time.


NEW FEATURES SINCE BITCOIN VERSION 0.5
--------------------------------------

Initial network synchronization should be much faster
(one or two hours on a typical machine instead of ten or more
hours).

Backup Wallet menu option.

Bitcoin-Qt can display and save QR codes for sending
and receiving addresses.

New context menu on addresses to copy/edit/delete them.

New Sign Message dialog that allows you to prove that you
own a bitcoin address by creating a digital
signature.

New wallets created with this version will
use 33-byte 'compressed' public keys instead of
65-byte public keys, resulting in smaller
transactions and less traffic on the bitcoin
network. The shorter keys are already supported
by the network but wallet.dat files containing
short keys are not compatible with earlier
versions of Bitcoin-Qt/bitcoind.

New command-line argument -blocknotify=<command>
that will spawn a shell process to run <command>
when a new block is accepted.

New command-line argument -splash=0 to disable
Bitcoin-Qt's initial splash screen

validateaddress JSON-RPC api command output includes
two new fields for addresses in the wallet:
 pubkey : hexadecimal public key
 iscompressed : true if pubkey is a short 33-byte key

New JSON-RPC api commands for dumping/importing
private keys from the wallet (dumprivkey, importprivkey).

New JSON-RPC api command for getting information about
blocks (getblock, getblockhash).

New JSON-RPC api command (getmininginfo) for getting
extra information related to mining. The getinfo
JSON-RPC command no longer includes mining-related
information (generate/genproclimit/hashespersec).



NOTABLE CHANGES
---------------

BIP30 implemented (security fix for an attack involving
duplicate "coinbase transactions").

The -nolisten, -noupnp and -nodnsseed command-line
options were renamed to -listen, -upnp and -dnsseed,
with a default value of 1. The old names are still
supported for compatibility (so specifying -nolisten
is automatically interpreted as -listen=0; every
boolean argument can now be specified as either
-foo or -nofoo).

The -noirc command-line options was renamed to
-irc, with a default value of 0. Run -irc=1 to
get the old behavior.

Three fill-up-available-memory denial-of-service
attacks were fixed.

NOT YET IMPLEMENTED FEATURES
----------------------------

Support for clicking on bitcoin: URIs and
opening/launching Bitcoin-Qt is available only on Linux,
and only if you configure your desktop to launch
Bitcoin-Qt. All platforms support dragging and dropping
bitcoin: URIs onto the Bitcoin-Qt window to start
payment.


PRELIMINARY SUPPORT FOR MULTISIGNATURE TRANSACTIONS
---------------------------------------------------

This release has preliminary support for multisignature
transactions-- transactions that require authorization
from more than one person or device before they
will be accepted by the bitcoin network.

Prior to this release, multisignature transactions
were considered 'non-standard' and were ignored;
with this release multisignature transactions are
considered standard and will start to be relayed
and accepted into blocks.

It is expected that future releases of Bitcoin-Qt
will support the creation of multisignature transactions,
once enough of the network has upgraded so relaying
and validating them is robust.

For this release, creation and testing of multisignature
transactions is limited to the bitcoin test network using
the "addmultisigaddress" JSON-RPC api call.

Short multisignature address support is included in this
release, as specified in BIP 13 and BIP 16.


Thanks to everybody who contributed to this release:

Alex B
Alistair Buxton
Chris Moore
Clark Gaebel
Daniel Folkinshteyn
Dylan Noblesmith
Forrest Voight
Gavin Andresen
Gregory Maxwell
Janne Pulkkinen
Joel Kaartinen
Lars Rasmusson
Luke Dashjr
Matt Corallo
Michael Ford
Michael Hendricks
Nick Bosma
Nils Schneider
Philip Kaufmann
Pierre Pronchery
Pieter Wuille
Rune K Svendsen
Wladimir J. van der Laan
coderrr
p2k
sje397

Special thanks to Sergio Lerner and Matt Corallo for bringing
potential denial-of-service attacks to our attention.

Thanks for the help sanity testing, I've repackaged the rc6 bits as version 0.6.0.

We updated the translations and fixed two serious-enough-to-be-showstopper bugs, and 0.6 release candidate 6 is available at:
  https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/

The two bugs (both caused by changes between release candidates 4 and 5, of course!) were:

1. Creating over a gigabyte of transaction logs during initial blockchain download. You should now see both a fast download and no more than 120MB of log files created.

2. A few people upgrading from previous releases couldn't get past the 'loading addr.dat' phase of startup.

I hope to repackage this as the final 0.6.0 release tomorrow; if you can help sanity test, please do!

My point was ANY scheme you come up with will eventually come down to "Does this transaction input have a high enough percentage of 'badness' for me to say no, I won't take it."

Whatever percentage you choose, the bad guys will very likely figure out ways to make their transactions just barely pass your purity test.

Which is why I mostly think starting down that road is probably a bad idea.

On the other hand... "security theatre" can be good public relations.  Make the bad guys jump through two hoops and then feel good about how tough you are on crime....

If 'tainted coin tracing' is ever implemented, it would be pretty easy to extend the idea to 'tainted mined coins'.

Mine 75 BTC (50 plus 25 in 'melted, tainted coins') and it'd be considered 33% tainted.

We might re-spin the release with just updated translations.

There is one serious issue affecting a few people (https://bitcointalk.org/index.php?topic=74447.0) but because it is a one-time problem when you upgrade from an older release and has a pretty simple workaround (remove your addr.dat file and re-run), we may release with it as a Known Issue.

If there are any Berkeley DB database experts reading this we could use your help figuring out what the heck is going on...

You mean like:

https://bitcointalk.org/index.php?topic=34562.0
  or
https://bitcointalk.org/index.php?topic=19080.80
  or
http://gavinthink.blogspot.com/2011/06/why-arent-bitcoin-wallets-encrypted.html
  or
https://bitcointalk.org/index.php?topic=2574.0

It has been a while since I wrote a "State of Bitcoin Development" update (too busy...), but wallet security was my second priority, behind network stability, the last time I did one. It is still right at the top of my priority list.

Ummm...

You know when you choose "About Bitcoin-Qt" and it says "Version 0.something BETA" ?

When we've got an implementation that is safe and secure (both from hackers and from accidental loss) out of the box that will change to say "Bitcoin Version 1.something".

Unfortunately, I don't know how to launch Bitcoin in an alternate universe where it will be attacked by highly motivated black-hats and then bring back the battle-tested source code to this universe to be launched as a perfectly secure Version One.

So, to repeat myself:  Bitcoin is experimental software. Do not invest time or money in it that you cannot afford to lose.

Here's the thinking:

Joe Random User finds out about bitcoin, and decides "what the heck, I'll check it out."

They run it.  First thing it does is ask him for a passphrase, with tons of "DO NOT FORGET YOUR PASSPHRASE" and/or "CHOOSE A LONG PASSPHRASE" warnings.  What does he do?  Many users will either:

1. Type "passphrase".

or

2. Bang on the keyboard to create a long, random passphrase: "b;lkaj425[09234kjvfda,nvfd;nkj34toht4"

He gets a little coin from the Faucet, writes me an email asking when they will arrive (because he hasn't yet downloaded the entire blockchain and didn't bother to read the information about that on the Faucet's "Sent!" page), and then shuts down the client.

Time passes.  Eventually the Faucet coins show up.

He decides Bitcoin really doesn't suck as much as he first thought, so he decides to buy some Bitcoin on Mt. Gox.

Time passes while Dwolla verifies his bank account and stuff.

Then he buys Bitcoin, and manages to send them and see them show up in his running Bitcoin.

Yay!

Time passes.  He decides he wants to spend the Bitcoin, and now he has to enter the passphrase that he set a week or three ago.  But back then, wallet security wasn't at all important to him.  He didn't have an Bitcoins to keep secure.

So either he forgot that his passphrase is "passphrase" or he remembers that he typed a bunch or random letters just so he could get past that annoying "enter passphrase" dialog box so he could just try the damn thing.

In short: wallet encryption is not the default because the right time to enter a passphrase to encrypt the wallet is when you KNOW that the wallet is valuable, and will take the steps necessary to protect it.

Barring any last-minute showstopper issues, the plan is for release candidate 5 to become the official 0.6.0 release on Wednesday.

So please help look for last-minute showstopper issues:
  https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/

The major changes from release candidate 4:

• Much faster writing of blkindex.dat during initial blockchain download (by modifying the default bdb environment cache settings)
• A new policy for wallet.dat upgrades: use the old format unless the user either uses a feature that requires an upgrade (encrypts the wallet) or explicitly requests that the wallet be upgraded using the new -upgradewallet option. New wallets will use new features (for 0.6, the only new wallet feature is compressed public keys).
• bugfix introduced in rc4 for an assertion failure that could occur during blockchain reorganizations
• New code for managing the addr.dat file that prevents an attacker from filling it with bogus entries.
  

Start with this stickied thread.

That statement is incorrect.

There are two ways you might waste time hashing:
1) Put a bad BIP16 transaction in your block
2) Building on top of a bad block produced by somebody else

So even if you don't include anybody else's transactions in your blocks you will still almost certainly waste some time hashing by building on top of invalid blocks produced and announced by some other lazy miner running an old version of bitcoind.

That's source code for the kernel, right?

I removed the old binary releases from SourceForge because it was getting annoying to find things like testnet-in-a-box in that very long list, and also getting hard to see what the latest release was. And with our gitian reproducible build process, the windows/linux binaries for recent releases are deterministically reproducible from the source code.

See https://github.com/bitcoin/bitcoin/tags  for the history back to the 0.1.5 release.  Uploading 0.1 to github is a good idea, maybe somebody who knows more about git than I do can suggest the best way to do that.

See this thread for BIP16-compatible-backported release candidates:
  https://bitcointalk.org/index.php?topic=72069.0

A final 0.6 release candidate will be out very soon, the last issues are being resolved now.

Again: if you don't upgrade and are a solo miner, pool operator, or p2pool user you will almost certainly waste time hashing bad blocks after April 1.

I pulled #964 for 0.6 this morning.

I had played with database settings several months ago and saw no speedup because there was another bug causing a bottleneck.  That bug was fixed a while ago, but nobody thought to try tweaking the db settings again until a few days ago.

Pieter and Greg did all the hard work of doing a lot of benchmarking to figure out which settings actually matter.

PS: the database settings are run-time configurable for any version of bitcoin; berkeley db reads a file called 'DB_CONFIG' (if it exists) in the "database environment" directory (aka -datadir).

I'm posting this to both this and the Mining Pools subforum:

To all pool operators, solo miners and p2pool miners; I have an announcement.

As everyone well remembers, we are upgrading the block-validity rule of Bitcoin to support short multisignature addresses. We realize that upgrading the code that you've been using for a long time is at least inconvenient and, for some of you, even painful or scary. But in the case of BIP30, which went into effect with the appropriately safe network support on March 15, it was necessary and in the case of this announcement the long-term benefits will far outweigh the short-term costs of this transition.

Therefore I'd like to announce that support for BIP16 has acquired a majority of mining support needed to prevent a potential permanent fork and will be activated on April 1st as previously planned.

This chart shows support over the last week: http://blockchain.info/P2SH.  Support is well over 70%.

So if you are a pool operator, solo miner, or p2pool miner you need to upgrade your Bitcoin-Qt/bitcoind before April 1st. Running a version of bitcoind earlier than 0.6 release candidate 3 past this date means running the risk of potentially wasting your hashing power mining invalid blocks since earlier versions will accept invalid spends of BIP16 transactions into their memory pools and will put them into blocks considered invalid by the majority.

p2pool users will also need to upgrade to the latest version of p2pool.

If you are a miner connecting to a mining pool, you can ignore this message.

For non-miners: version 0.6 also contains several important bug and denial-of-service fixes, so if you can, upgrade.

Backports of the BIP16 code to earlier releases are available if you are running a patched bitcoind. Patched binaries of older releases will be available soon.

To all pool operators, solo miners and p2pool miners; I have an announcement.

As everyone well remembers, we are upgrading the block-validity rule of Bitcoin to support short multisignature addresses. We realize that upgrading the code that you've been using for a long time is at least inconvenient and, for some of you, even painful or scary. But in the case of BIP30, which went into effect with the appropriately safe network support on March 15, it was necessary and in the case of this announcement the long-term benefits will far outweigh the short-term costs of this transition.

Therefore I'd like to announce that support for BIP16 has acquired a majority of mining support needed to prevent a potential permanent fork and will be activated on April 1st as previously planned.

This chart shows support over the last week: http://blockchain.info/P2SH.  Support is well over 70%.

So if you are a pool operator, solo miner, or p2pool miner you need to upgrade your Bitcoin-Qt/bitcoind before April 1st. Running a version of bitcoind earlier than 0.6 release candidate 3 past this date means running the risk of potentially wasting your hashing power mining invalid blocks since earlier versions will accept invalid spends of BIP16 transactions into their memory pools and will put them into blocks considered invalid by the majority.

p2pool users will also need to upgrade to the latest version of p2pool.

If you are a miner connecting to a mining pool, you can ignore this message.

For non-miners: version 0.6 also contains several important bug and denial-of-service fixes, so if you can, upgrade.

Backports of the BIP16 code to earlier releases are available if you are running a patched bitcoind. Patched binaries of older releases will be available soon.

Great!  Pull requests to fix compiling-on-platform-X problems are always welcome (assuming they don't also break compiling on platform-Y).

Yes.