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.

... only if the investments are in things that don't make us more productive.

There are really three categories, in order of desirability:

1 Investment in productive activities
2 Savings
3 Investment in non-productive activities

The broken window fallacy is confusing categories 1 and 3.

I'll be in Paris with my family next month, and would like to arrange a meeting or two with other bitcoin-people.  Who is in/near Paris, and what would be a good time/place to meet?

PS: sorry for not writing in French, it has been a very LONG time since high-school French class...

Hundreds of google accounts AND hundreds of IP addresses (the Faucet does still check IP address).  And the patience to solve hundreds of CAPTCHAs...

I'm pretty sure almost all of the bitcoins going out of the Faucet are new people trying out Bitcoin.  We're getting between 500 and 1,000 downloads of bitcoin binaries from the SourceForge site per day (stats here).

PS: Thanks again to everybody who donates to keep the Faucet running!

Limit-per-ip-range is an interesting idea.

I'd like to give the current not-yet-released solution a month or two to work before trying something else.  I see two possible directions:

+ Limit-per-{connection,ip-range}.  Trouble with this is an attacker who has multiple IPs (think botnet operator) can mount a distributed flood attack.

or/and

+ Take transaction priority into account when deciding what to drop.

I'd really like to talk to a p2p network researcher; it seems to me it might be possible to keep some statistics on what "typical" bitcoin network traffic looks like; perhaps nodes could drop neighbors if they notice network traffic from them looks way out of whack (e.g. sending a much-larger-than-typical number of addr messages or free transactions or...).

Huh.  One-to-three day transfer times doesn't seem to have hurt the dollar much: http://www.depositaccounts.com/blog/inside-look-at-ach-transfer-speeds-at.html

"Instant" payments with world currencies is an illusion created by your bank of financial institution based on how much they trust the person or institution sending the money.  There is nothing stopping bitcoin financial institutions from using the same trick, and I think as the bitcoin economy grows and companies start to trust each other instant transfer times will happen.