That's caused by a bug in one of the technologies I'm using behind the scenes (Google's App Engine).  If you try again the problem should go away.

I've got a couple of ideas on how to make it more reliable, but I'm still hoping Google finds and fixes the underlying problem...

If it was oil, then it seems to me the country with the largest oil reserves would be the world's reserve currency.

It might be the biggest army, but I think the dollar is the world's reserve currency because the US has the largest productive economy in the world backing it.

Unfortunately, we might be subject to a natural experiment in the next couple of decades that will show us the right answer; I can imagine that in 20 years the US still has the world's biggest army but some other nation has the world's largest economy.

It would be really cool if Bitcoin Nation were the world's largest economy by then...

Thanks!  I'll add the donation address to the bottom of the page.

I'm thinking of keeping the donation address the same, so donations to the Faucet are transparent to anybody who wants to see.  I WANT donations to, and payments from, the Bitcoin Faucet to be NON-anonymous, so anybody can audit that address and see the flow of bitcoins through the Faucet.

(by the way, if anybody is looking for an interesting bitcoin-related coding project I think a website where you enter a Bitcoin address and it shows you a visualization of all the transactions that went to/from that address would be cool... extra credit if it let you browse the web of transactions...  I'd be really curious to see what percentage of bitcoins withdrawn from the Faucet end up donated right back into it...)

Good idea or not, SOMEBODY will try to mess up the network (or co-opt it for their own use) sooner or later.  They'll either hack the existing code or write their own version, and will be a menace to the network.

I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it.  I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel.

That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...

So I'm writing a little tool that dissects the Bitcoin wallet.dat, mainly because I want to understand better exactly how Bitcoin works.

And I see that the outputs of transactions have a value (number of bitcoins) and a bunch of bytes that are run through the little Forth-like scripting language built in to bitcoin.  E.g.:
['TxOut: value: 100.00 Script: DUP HASH160 6fad...ab90 EQUALVERIFY CHECKSIG']

First: it make me a little nervous that bitcoin has a scripting language in it, even though it is a really simple scripting language (no loops, no pointers, nothing but math and crypto).  It makes me nervous because it is more complicated, and complication is the enemy of security.  It also makes it harder to create a second, compatible implementation.  But I think I can get over that.

Looking at the code, new transactions are verified by pushing the signature an then public key on the interpreter's stack and then running the TxOut script (did I get that right?).

Could I write code to create transactions with any valid script in the TxOut?
E.g. could I create a TxOut with a script of:   OP_2DROP OP_TRUE
... to create a coin that could be spent by anybody?

And is flexibility in the types of coins created the reason it is coded this way?

The Bitcoin Faucet now shows how many coins it has available to give out (on the left-hand side of the page).  The number is only moderately accurate-- donations will take 5 or 10 minutes to show up in the balance.

I also implemented another anti-cheating measure that should make casual cheating a little harder (which I don't want to say too much about because that would make it easy for cheaters to know what to do).

I'm very pleasantly surprised at how well freebitcoins is working so far; thanks again to everybody who tried it out and who donated bitcoins to it!

Thanks, lachesis-- ฿50 to you for finding that bug!

I've changed the key and turned off debugging; I'll tighten up its security a little more tomorrow when I'm more awake.

And wobber: no, I didn't send you leet ฿

How many public Tor exit nodes are there these days?  You've essentially blacklisted 10 of them already 

I am going to add a one-donation-per-bitcoin address rule to make it a teeny-tiny bit harder to cheat.  I don't want to blacklist anybody coming from Tor, though-- I think a lot of people using Tor will also be interested in Bitcoin.

I'll implement a CAPTCHA when (if?) the current service starts running low on coins (there are 1,570 bitcoins in the faucet right now!).

Actually, the "label" mechanism gives me what I need to keep the freebitcoins separate from other bitcoins in my server's wallet.

What I'd really like is to store wallets outside of the bitcoin program.  I'd like bitcoind to have these features:
 + Generate a new address, but don't store it in the local wallet file-- return the address and private key
 + Accept a transaction that is already signed; check that it is new/valid, and, if it is, broadcast. (if not, reject it)
 + Let me register a Bitcoin address that I'm interested in, and when it sees payments to that address 'tickle' a URL with details on that transaction.

Or, in other words, allow it to function as just a payment gateway.

App Engine gives me:
 Free bandwidth and data storage (with the option to pay for what I use if I go over a gigabyte)
 Built-in, already-configured-and-tweaked tools like memcache and BigTable
 An architecture where scaling up is built-in (App Engine will automagically replicate my app and distribute it across Google's worldwide content distribution network if it gets a lot of traffic)

And all of that is administered by Google's sysadmins (who are WAY better at that than I am).

But mostly I did it as an experiment and because it was a technical challenge and because lately I'm an App Engine fanboy.  I would've been done a day earlier if I'd run everything on the same server and wrote the front end in PHP+MySQL.

Joozero asked if I'd make the source to freebitcoins.appspot.com available, and I promised to start a thread explaining how I created it-- and here it is.

freebitcoins is running on the Google App Engine.  Well, the part you see is running on App Engine.

There's also a back-end bitcoind server running on a debian VPS that I've had for years.  The App Engine code makes JSON-RPC calls via the App Engine url fetching API.  Making that connection secure was a bit tricky; here's how I did it:

First, I connect to the VPS using https so the traffic is encrypted.

I need a secure connection because I add a secret pre-shared value to the JSON call.  I'm not going to make the full source for freebitcoins fully open source because I don't want to bother with constantly working to keeping that secret value secret.    I should hash the entire request with a secret key and an ever-increasing nonce, but I was lazy and I'm just not very worried about a man-in-the-middle attack between Google and my VPS.

I could have hacked my copy of the bitcoind C++ code to check for the secret value in requests and also modified it so it accepted connections from the Internet... but instead I wrote this little proxy server in Python that runs on the same box as bitcoind:
The other end of the connection is also django+Python code running on App Engine:

I'm happy with how it is working.  My biggest worry is that the bitcoind process might unexpectedly exit, or fill up the disk with debug.log messages, or just generally be flaky.  But so far so good...

I'd be happy to share the interesting bits, but the architecture is... um, unique.  I'll start a thread on the Development forum describing how I built it.

Showing the number of Bitcoins available is on my TODO list.  I just checked and the balance is up to 1,135 (thanks to whoever donated!).

And right now it is 5 bitcoins per IP address (not bitcoin address).  Not per-day-- just 5.  I want to start out conservatively, I will loosen it to 5 per (day?/week?/month?) if people start having lots of trouble because they get a dynamic IP address from their ISP that already got some.

RE: captchas:  yeah, I was gonna start out with a captcha, but I wanted it to be as simple and non-threatening as possible.  I don't think anybody who has access to hundreds or thousands of working public IP addresses would go to the effort of writing a bitcoin-harvesting robot, though I suppose somebody with a botnet might take a crack at it.  To make that tougher I could make it 5 bitcoins per IP AND 5 bitcoins per bitcoin address (so they couldn't have all the bots in the botnet using the same BC address).

For my first Bitcoin coding project, I decided to do something that sounds really dumb:  I created a web site that gives away Bitcoins.   It is at: https://freebitcoins.appspot.com/

Five ฿ per customer, first come first served, I've stocked it with ฿1,100 to start.  I'll add more once I'm sure it is working properly.

Why?  Because I want the Bitcoin project to succeed, and I think it is more likely to be a success if people can get a handful of coins to try it out.  It can be frustrating to wait until your node generates some coins (and that will get more frustrating in the future), and buying Bitcoins is still a little bit clunky.

Please try it out and get some free coins, even if you already have more Bitcoins than you know what to do with.  You can get some and then donate them right back; the address is: 15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC

I'll try to answer what I can:

You either have to run a node or trust somebody else (like MyBitcoin.com) to keep a wallet for you.

Your account balance is stored in a Berkeley DB file called 'wallet.dat' (what directory depends on your operating system; on my Mac it is ~/Library/Application Support/Bitcoin/wallet.dat, on linux it is ~/.bitcoin/wallet.dat, not sure about PCs).

The only application that can read wallet.dat is the bitcoin code, and the database structure isn't documented anywhere besides the bitcoin C++ source code.
Theoretically, no, but the code to do lightweight validation hasn't been written.
Satoshi is planning on encrypting the wallet database, so you'd need to enter a password to read it.  (and they need to get your private keys to generate transactions-- those are what are stored in the wallet.dat)
Dunno.
There's another thread about this in these forums; maybe we should start a "Satoshi's TODO list" thread and get folks to volunteer to help out.
Fewer and fewer coins will be created over the next N years (where N is-- what, 20?).  That's a feature, not a bug...

RE: developing your own version: are you thinking of creating a second bitcoin implementation that is compatible with the existing C++ one  (good idea, in my opinion)?  Or creating a similar-but-not-the-same system (bad idea, in my opinion)?

In another thread venom said:
So the short answer is that BC is backed by mathematics/cryptography and the "wisdom of crowds"; assuming there's no flaw in the algorithms, and assuming that there is no grand conspiracy of more than half of the BC nodes, it is impossible to inflate the currency or make fraudulent payments.

I don't believe in grand conspiracies, so that doesn't worry me.  And I can't see any flaw in the algorithms... but that's where I'm skeptical (there might be bugs in the BC code, but those can and will be easily fixed).

Are there any professional cryptographers looking at Bitcoin?
Or will they only get interested if/when Bitcoin gets popular?

It took me over a week to generate any coins, then I generated two blocks (100 bitcoins) in just a few hours  (running bitcoin on my 2GHZ dual core mac laptop).

While it is fun to see bitcoins generated "out of thin air", it is much more important to figure out how to make them easier to buy and easier to spend.  Since you're not a programmer/developer, I'd like to hear any ideas you have on how to make bitcoin less geeky and more user-friendly.

It took me a while to figure out where to get the wx_gtk2ud-2.9 library needed to compile bitcoind, so I thought I'd share for anybody else who's not a wxWidgets expert:


I'd humbly suggest adding the above to the build-unix.txt file...  Satoshi, is there a preferred way to submit patches?

27 Aug 2010:  This is no longer necessary-- bitcoind doesn't require wxwidgets at all any more.

One Amazon "EC2 compute unit" is, according to them, approximately equal to a 1ghz 2007 Xeon processor (that's a m1.small).

Judging by my laptop generating experience, there's no way an m1.small instance would generate enough ฿ to be profitable.

The heftiest instance you can buy ("large CPU") is 20 units big, and costs $0.231 per hour; with bitcoins selling for about a half a penny each it would have to generate 46 per hour (or about a block an hour) to break even.  Ummm.... no, that does not compute.

RE: how did I get hashes-per-second on my mac:  I applied laszlo's patch to a version I compiled from source code.

Has anybody tried generating bitcoins on Amazon EC2 instances?  If you have, how many coins/day are you getting (and on what type of instance) ?

If nobody has already, I might do some experimenting and get some back-of-the-envelope estimates for $/bitcoin using Amazon EC2 spot instances.

(I've had zero luck generating any coins over the last week on my couple-year-old Macbook Pro, which only does 150-200K hashes per second)