Linux and Windows binary releases are at:
  https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.21/

Changes and new features include:

• Support for Universal Plug and Play to open a port for incoming connections (off by default, turn it on using the -upnp=1 command-line switch or the checkbox on the Options dialog box).
• Sending and displaying arbitrary precision amounts of bitcoins (you can send exactly 1.0001 bitcoins if you like).  Sending less than 0.01 bitcoins requires a 0.01 bitcoin fee, however.
• New rpc command "sendmany" to send bitcoins to more than one person in a single transaction (already being used by some of the mining pools for payouts).
• Several bug fixes, including a serious intermittent bug that would sometimes cause bitcoind to stop accepting rpc requests.

If you find bugs, report them at: https://github.com/bitcoin/bitcoin/issues

This is a single-line change that allows non-standard transactions to get into the transaction memory pool (and, therefore, relayed and written into blocks) on -testnet.

Satoshi suggested this to me in an email a few weeks ago, and I agree it is a good idea-- we should encourage people to experiment on -testnet with new features, or they will figure out less efficient ways of wedging what they want to do into the existing standard transaction types.

The 0.3.21 release (I hope to have a release candidate available today) will support full-precision values-- you will be able to send 1.00123456 BTC, if you like.

Sending less than 0.01 BTC still requires a 0.01 BTC fee, though.  Changing that to "sending less than 0.01 BTC requires a 0.001 BTC fee" might be worth thinking about, but I think there are higher priorities on the core bitcoin TODO list.

It is a Berkeley DB binary database file.

https://github.com/gavinandresen/bitcointools  has fairly easy to read python code for parsing it-- see
https://github.com/gavinandresen/bitcointools/blob/master/wallet.py

Nope, penny-flooder.

Run the gui with the -server switch.

Yup, although I'd like more brains to think it through-- are there any potential denial-of-service attacks if bitcoin is listening for RPC commands by default (note that JavaScript in your web browser CAN access http://localhost:8332/, the same-origin-policy for JavaScript doesn't apply to localhost URLs)?

Does it open up any extra security holes if you're on a multi-user system?

And I don't think it should go into mainline bitcoin until there is a compelling need for it-- and I don't think there will be a need until the 'click on a link, popup payment dialog from bitcoin' functionality is worked out...

It might make more sense to allow non-sensitive RPC commands to function without a password.  Where "non-sensitive" would be getblockcount/getdifficulty maybe getnewaddress/getaccountaddress and a new 'you clicked on a bitcoin: URI so popup a payment confirmation dialog'.

"Making it easier for other applications to integrate with bitcoin" is bad if the other applications are trying to steal your wallet, so I'm reluctant to have bitcoin do things like create passwords for users.

I pulled a patch that makes Linux/Mac bitcoin/bitcoind write a bitcoind.pid file when started with the -daemon switch (and erases it on shutdown).

Next release will have several changes to make startup on Linux/Mac more unix-standard-like.

When you launch your instance, make sure the firewall ("Security Group" in AWS-speak) is setup to allow remote desktop access from your machine's IP address to port 3389.

I run Remote Desktop Client on my Mac, but the process should be the same on PC.

Connect using the "Public DNS" machine name-- something like:   ec2-184-2-91-236.compute-1.amazonaws.com

Login as Administrator, password:    bitcoin development

(I just launched the 0.3.20.2 Windows AMI to get ready to build a 0.3.21 release candidate).

Thanks for the suggestions and comments, everybody; I think a combination of dropping the faucet reward again (I'll start bundling up faucet payments into 'sendmany' transactions, so the transaction fees are lower) and "community watch program" will work.

The 'community watch' will be a web page that anybody can see that shows the last 100 IP addresses that got payments along with an obfuscated version of the email address (I'll obfuscate by randomly turning an email address like 'gavinandresen@gmail.com' into 'gavniadresen23@gmail.com').  And I'll recruit some trusted people and give them access to a master faucet shut-off switch if it starts getting abused again.

It always bothered me that the MySQL's SELECT... LIMIT statement could skip records if the database was changing between calls, but that doesn't seem to bother anybody else.

This patch is very much like MySQL LIMIT, is needed for the same reason (paging through results efficiently in a GUI), is backwards compatible, and looks good to me.

There are actually a few different ways to get a negative account balance.

1. As theymos said, the "" account is special, and can go negative if you use sendtoaddress instead of sendfrom.

2. Other accounts can go negative if they receive coins on a bitcoin address, you send those coins from that account, and then you use setaccount to re-assign those received coins to some other account.

3. They can also go negative by the transaction fee amount if you sendfrom the coins in an account and the send needs a transaction fee.

Also as theymos says, you can never send more coins than are in your total wallet.  And it should ALWAYS be true that the sum of coins in all accounts equals the number of coins you can send.

You're right-- full-precision is in git-head, but wasn't in 0.3.20.  It will be in 0.3.21.

No, they don't.

As of version 0.3.20, the GUI and JSON-RPC both allow full-precision values for sends.  So you can send 1.00123456 BTC if you like.

And the GUI will display full-precision wallet balances/etc (it truncates trailing zeros past .00, so you won't notice unless you have sub-cent BTC in your wallet).

The 'dust spam' rules are still in, so you're expected to pay a fee if you are sending less than 0.01 BTC-- that is, if you try to send 0.00001 BTC it will trigger the fee (sending 1.00001 would not trigger the fee).

RE: paying somebody to monitor the faucet:  good idea, although I like the idea of some kind of "community watch" more.  And monitoring the Faucet is an all-day-and-night, all-the-time kind of job.  And if the scammers are willing to try to drain the faucet slowly then they could create accounts with more realistic-looking names and would be able to sneak by the monitors...

RE: just using testnet coins:  I worry about people starting to trade testnet coins, giving them real value.  Giving lots of newbies who don't really understand bitcoin testnet coins seems like a really good way to make that happen!

RE: proof-of-work before getting coins:  Interesting idea!  Some JavaScript in-the-browser proof-of-work that required keeping the 'get some' page open for a minute or six might make the cost to the scammers high enough that the bitcoin reward wouldn't be worth it.

RE: looking at the google account creation date:  that information isn't available to the Faucet's code (unless I'm missing something in the Google App Engine API).

That fails the fairness test, too-- identical twins won't get their fair share.

If you figure out a cheat-proof, distributed, fair way of doing that please let me know.  I need that magical solution for the Bitcoin Faucet.

I'm not really ugly, am I?  You should have seen me in college when I was too cheap to get a haircut...

So:  bitcoind doesn't ask for confirmation before sending fees with a transaction because it is was much easier to implement that way, and for most uses of bitcoind paying an occasional transaction fee isn't a problem.

If you'd like to help fix it, patches are welcome.  I think a new setting that says "don't pay more than N bitcoins for any transaction without asking me" and a new argument to the send routines to say either "I'm willing to pay up to X bitcoins for this transaction" or "I want to pay X bitcoins in transaction fees with this transaction" is a good idea.