RE: how many free keys are in the pool:

By default, there are at least 100 free keys in the pool, always.

When a key is taken out, if the number of free keys drops below 100 (or the -keypool= number) another is generated.

Keys are put back if they're unused-- for example, a key is needed for every miner hashing thread, so if you're on a 4-core machine and turn on coin generation and then turn it back off you'll wind up with 104 keys in the free pool.

But for most people most of the time there will be exactly 100 free keys.

It is pretty darn hard to make a billion dollars of gold (or paper money) virtually theft-proof, especially if you're worried that your government might decided it 'needs' some of it.

Assuming bitcoins are eventually worth billions of dollars, it will be easy to make a billion dollars of bitcoins virtually theft-proof.  Heck, you could walk around with a billion dollars worth of bitoins on an encrypted memory stick in your pocket.

With a backup in a safe deposit box in Switzerland.  That's MUCH better than gold or paper money.

I'm starting to think that bitcoin as a store-of-value might end up being more attractive than bitcoin as a medium-of-exchange.

So... have clients send back their best N hashes (and the average should be N times better).

RE: detecting server cheating:  Over a very long period of time, clients should be able to figure out approximately how many hash/sec the server's network is generating.  So they should be able to detect blatant cheating.  I should've taken statistics in college, seems like it'd be an interesting problem to work out the chances that a server is lying based on how many blocks it has generated over the last week...

Pass "allwallet" to monitoraddress and you'll get all transactions that put coins in your wallet.

RE: getting the data POSTed in PHP:  Try:

json_string = http_get_request_body();

Also, POSTing to www.postbin.org (create a postbin there first) is really useful for debugging.

I bet you'd get a good approximation of hash rate if clients submitted their best (highest difficulty) hash every N minutes.  Over a period of a few hours the average of all of those best hashes should be proportional to the client's hash rate (unless a client were somehow repeatedly very lucky or unlucky, but that would be extremely unlikely).

svn r167 is a tweaked makefile.unix that Xunie reports allows bitcoind to compile cleanly on Ubuntu 10.04 x86_64.

I tested on my Debian box and it does no harm; let me know if it breaks the build on any other unix flavors.

Sure, there are a couple of tables in the back of Satoshi's bitcoin paper that calculate the chances based on what percentage of CPU work you're contributing.

I don't know what the issues are-- I do Mac/Linux these days (I don't do Windows).  Does the precompiled fedora mingw32-openssl support ECSDA signatures?  Can you give it a try and let us know if it works?  (just add -DUSE_SSL to the Makefile and link with whatever libssl is called under mingw32)

SVN rev 166 (bitcoin version 0.3.13.4) implements secure incoming SSL JSON-RPC connections to bitcoind or bitcoin -server on Linux and OSX.

I've created a wiki page with detailed instructions on how to configure bitcoin.conf for SSL JSON-RPC connections.

SSL support is enabled at compile time with the USE_SSL #define, and is not enabled in the Windows makefiles because I'm told there are... issues... compiling full OpenSSL libraries on Windows (core bitcoin uses the openssl libcrypto library, this change requires the full libssl library).

I automated updating/patching the monitorreceived patch, and just updated to Satoshi's latest:
  http://gist.github.com/604574
(use the "raw" link there for a link to latest version of the patch)

And I fixed the bug reported by doublec.

The only think I can think of is that the php fopen() call is timing out.  Are you trying to generate coins?  Does it get better if you stop generating?

Are you using PHP5 ?  If you are, try creating a stream_context with a longer timeout  (see http://www.php.net/manual/en/context.http.php ).

ByteCoin: cool!  Are you finding alternative public keys for a given ECC private key?  (are there multiple public keys for a given private ECC key???  I know very little about elliptic curve cryptography)

And to all:  I couldn't resist, I updated the patch so it can search for a regular expression and so it starts a separate thread and doesn't monopolize the RPC thread.  My machine is busy looking for a bitcoin address that matches '^1Gavin' right now.

I'm a happy LastPass subscriber... and I hate to say it, but they're right.  At this point there's no way the average consumer will use Bitcoin, even via a website like mybitcoin.com.

I think it will be a few years before bitcoin and bitcoin-related services are reliable and trustworthy enough for the average consumer.  Don't get me wrong, I think bitcoin is a fantastic idea and has a good chance of being Really Important, but it is going to take a long for it to get accepted as a viable alternative to other payment solutions.

But if it supported regular expressions "david.*on.*pda" would probably be found in a reasonable amount of time...

Of course, if you were unlucky it'd find something like  1davidSpoonLApdaDDY13iu8 (not a real bitcoin address)

RE: "wasting" addresses:

caveden is right, this patch generates and throws away lots and lots of potential bitcoin addresses.

But there are 2^160 possible bitcoin addresses, which is a really, really big number.  The chances of BioMike generating an address that matches my "gavin" address before we're all dead is approximately zero.

And davidonpda:  I haven't tried to figure out how long 10 characters would take-- it is exponential in the number of characters, so 10 characters would probably take years...

Attached is a little patch that expands the getnewaddress RPC command so it can try to generate a "vanity" bitcoin address.
E.g. I told it to generate an address with "gavin" in it, and it chugged away for an hour or two and came up with:
  12kUimDnb1a6oAPifgavinAaxMmLe43UR6

This is recommended for fun and experimentation only; it takes a long time, and while it is trying to find an address with the right string in it no other RPC commands are accepted.  Including 'stop'.

It'd be kinda cool (and would speed it up a lot) to make it case-insensitive.  Or to match to an arbitrary regular expression.  Or to make it spin off a separate thread and just return "working...."  (and have the thread add the address to the wallet when it is finally found, labeled with the vanity string).

Maybe we should have a Best Bitcoin Address contest  

I updated most of my git branches to svn rev 161 last night, including monitorreceived.  That's easy:
   git svn fetch   (but you have to have an "svn-remote" setup in your .git/config)
   git merge refs/remotes/svn/trunk    (I could git rebase instead, but merge seems less magical to me)
    ... fix any merge conflicts and test then git commit, if needed  (usually there are none)
   git push   (to push up to github)

Repeated on each branch (I'll try to keep svn, svnTEST and monitorreceived up-to-date).

Keeping the patch file up-to-date is another couple of steps, and I could/should automate it.

doublec: thanks for the bug report, I'll look into it as soon as I get this machine setup.

There's a built-in mechanism for ensuring that this is never a serious problem:  the more coins that are lost, the more valuable the remaining coins become.

And the more valuable something is, the more careful people are not to lose it.  So there's a nice feedback loop that should naturally limit the number of coins lost.

If Bitcoin becomes the world's stable reserve currency then one bitcoin might end up being worth tens of thousands of dollars and we'll all get much more serious about backing up our wallets and keeping them secure.  Or, I think more likely, most people will use a service that they trust to keep their coins backed up and secure...

Today:  a brand-new keypair (address) is created and added to your wallet when you have change.

Soon (I hope; I think satoshi is working on it...) bitcoin will pre-generate a bunch of addresses to use for change, and use one of them (and re-generate a bunch when it runs out).

I'd kind of like an option to put change back into one of the addresses it came from; that'd be simpler, quicker, and would make your wallet smaller...

A half-baked thought that's been bouncing around my head for the last couple of days:

One piece of functionality missing from bitcoin is the ability for somebody to prove that they own a certain bitcoin address.

I'm thinking that if there was a way to ask bitcoin to:
  1) Sign an arbitrary bunch of data with a bitcoin address' private key, and return the signature.
  2) Take a bitcoin address and signed data and verify that the signature is valid.

... then maybe that could function as the building block allowing webs of trust to develop in an application independent of 'core bitcoin'.

And secure, pseudo-anonymous communication between people who know only each other's bitcoin addresses.  And probably a bunch of other interesting things I haven't thought of.