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.

That pattern is definitely the faucet.  The big mining pools are already using the new 'sendmany' functionality to pay lots of people with one transaction.

I'm thinking of doing something similar for the Faucet.  Perhaps:

+ Bundle up requests for payments, so instead of sending out payment right away you have to wait a bit (15 minutes or an hour or... something somewhat random and non-predictable).

+ Dropping the Faucet reward AGAIN so there is less incentive to cheat.  I'll need to use sendmany so the faucet isn't paying as much in fees as it is in bitcoins it gives out.

And maybe:

+ Publicly display the queue of waiting requests.  This would be the tricky part-- I don't want to just dump email address and IP address, but I do want to dump enough information so people looking at the information can tell the difference between a cheater and legitimate users.

+ A way of flagging requests as "looks like cheating to me".  This is also hard-- griefers might decide it would be fun to flag lots of legitimate requests.

I've turned off the faucet; somebody is definitely stealing from it.  There were 500 sends queued when I woke up this morning.

They are using a different IP address, different google account, and are even changing the browser ID string on every request-- here are three entries from the request log, for example:

"zqdckyxnhmjj" and "clkjqwbhwefj" are the google account logins, which are obviously bogus.  Well, obvious to humans, anyway...

I can see the GUI not allowing a less-than-CENT to save fat-fingered users from themselves, but I think the RPC should allow it; at the very least it makes it possible for a kind of grass-roots movement to arise between miners and people generating transactions so if we start seeing a lot of transactions with less-than-CENT-per-kbyte-fees then that's a really good indication the default definition of "free" needs to change.

And now that the RPC and GUI allow full-precision amounts for send/move, there is no problem with "I got 50.000001 bitcoins from mining, how do I send ALL of them?"

One address per client is a good idea.

Neat idea-- I've been thinking about how to let people/companies sponsor the Faucet.

The next couple of things on my TODO list are getting the 0.3.21 bitcoin release process started and an API for ClearCoin, but I might tackle Faucet donations after those are done.

That sounds overly complicated.  Does your ruby/json implementation have double-precision (64-bit) floats?  If it does, just multiply by 1.0e8 and rounding to the nearest integer.

Quick way to tell if your ruby implementation does 64-bit floats:  see what you get converting 21000000.00000001*1e8 to an integer.

I'd rather see more non-technical bitcoin-related videos rather then "this is what the block chain looks like" technical videos.

I'm going to brain dump some half-baked thoughts:

So I watched this talk by Jonathan Haidt on the moral roots of liberals and conservatives and started thinking about how it might apply to more mainstream acceptance of Bitcoin.  If Jonathan is right, then I think conservatives will find reasons to hate bitcoin, but liberals might be convinced to love it.

So what are the videos that liberals love?  Well, there's The Story of Stuff, which I think is wrong-headed but is incredibly popular.

I'd like to see a video targeted towards left-leaning people that argues from their world-view-- why the existing monetary system is unfair and benefits a rich elite at the expense of the working masses.  How Bitcoin can change that and be a People-Powered money, backed not by empty promises from rich bankers but by the strength and trust of the person-to-person Bitcoin Community.  How friends and neighbors using Bitcoin can keep money in local communities.  How using Bitcoin lets you interact with people all over the world, promoting peace and understanding.  How it is better for the environment than gold mining or trucking coins and cash to and from stores and banks.

Of course, early adopter libertarian-leaning bitcoiners will probably HATE it, but they wouldn't be the target audience...

I can't see how it could work.  If I knew my LunaCoin balance was going to be reset at midnight and it is 1 minute to midnight, I'd be crazy to accept them.  Reason backwards from there and I don't see how you could possibly have a stable economy, at least not in the last few days leading up to the reset.  People would try like crazy to get rid of their LunaCoins, and it would get harder and harder to find somebody willing to take them.

TiagoTiago asked if anything like "reset everybody's balance at the beginning of every month" has ever been tried, and it reminds me of historical debt relief, where all debts are forgiven every N years, usually by people of a certain religious background.

If I recall correctly, people were very creative about finding ways to get around it, but I don't have any references handy.

In 2009:   Source
All mobile phones will be internet-enabled in 10 years, and I think it is pretty safe to assume that most people on the planet will have some access.  It won't surprise me if bitcoin first goes mainstream in an up-and-coming third-world country or region.

0.3.20.1 -maxsendbuffer was too small for the initial block download-- you were probably just unlucky and connected to a 0.3.20.1 node.   Connect to somebody running either 0.3.20.2 or an earlier release and you won't run into that problem (does bitcoinj re-connect if disconnected during block download?)

Kel'Thuzad, US.  But I haven't played much since my 85 Warlock got the "Explorer" title.

GMT is always +0:00, so why not hardcode that instead of using %z or %Z?

RE: changing locale:  good idea.

Transaction spam is not a high-priority issue, in my humble opinion, and I don't think we need to do anything more right now.

We were running into big free-transaction backlogs because of the rise in popularity of the mining pools, but with the big pools now using the new sendmany feature to pay (with a transaction fee) their users that issue has gone away.

The improved -limitfreerelay and sendmany will both be in the next release, which should further improve the situation.  And I think in the next few months lightweight download-headers-only clients will start to appear.

I would much rather see work on optimizing the network protocol so that hashed of already-spent transactions deep in the block chain aren't sent to (or stored on) new nodes joining the network.

What is meant by "rather inefficient"?  Speed of serializing/deserializing?

I can't imagine that is a significant factor for communicating with bitcoin; if you're running into JSON-RPC bottlenecks (is anybody running into performance bottlenecks due to JSON-RPC yet?  If you are, what are you doing?) then the lack of persistent connections, lack of JSON-RPC-2.0-multicall support, or bitcoin single-threaded RPC are likely much, much bigger issues.

The problem with that idea is if the transaction fee is that low spammers won't notice it either.  They can just invest 0.01 BTC and send millions of "non-free" transactions.