Bitcoin version 0.3.13.05 (svn revision 168) adds the -testnet option to bitcoin/bitcoind, for testing or experimentation with worthless bitcoins on the TEST payment network.

This version is compatible with my old compile-time test network patch.  Stuff you aught to know as you run this:

• A -testnet bitcoin will use the same bitcoin.conf file as regular bitcoin (unless overridden with the -conf= switch).
• The -testnet data directory is a "testnet" subdirectory in the regular data directory.
• A -testnet bitcoin listens for connections on ports 8333/8332, just like regular bitcoin, so you cannot run both -testnet and regular bitcoin at the same time on one machine.
• You can get play bitcoins from the TEST faucet at https://freebitcoins.appspot.com/TEST/
• testnet bitcoin addresses will not work on the regular bitcoin network, so it is impossible to accidently try to send real bitcoins to test address.  However, regular bitcoin addresses are valid testnet addresses; it is possible to try to send testnet bitcoins to a regular bitcoin address (they will effectively be lost if you do that).

This will be very useful for anybody creating a web-based bitcoin service.  You should be able to run bitcoind with the -testnet switch and no code changes to test your service with pretend, instead of real, bitcoins.

This looks pretty interesting (in the US):  http://www.paynearme.com/
Print out a payment slip on a website, walk into a store and finalize payment in cash, website merchant gets immediately notified.

From their Terms of Service:  "Please do not confuse our PayNearMe payment service with use of a credit card, debit card or pre-paid/loaded card. There is no extension of credit. And since there is no credit extended, there is no ability to challenge or cancel the transaction through a chargeback procedure."

Keys in the keypool store when they're generated (and the oldest are always used first).   Asking "what's the oldest key in the key pool" seems reasonable, and I think it would give you what you want-- you could compare that timestamp to the timestamp of your last backup to see if you're covered.

Although if you're going to periodically check to see what the oldest timestamp is (or you're going to periodically check to see if bitcoin has written a new timestamped backup file or periodically check WHATEVER) then it seems simpler to me to just periodically always call backupwallet.  Disk space and bandwidth is cheap these days...

nBits is difficulty in 'compact' format?  (if I recall correctly...)

It should be reported as floating-point 'difficulty', like you get from the 'getinfo' rpc command.

I will add that.

Backup every 30 sendtoaddress or generatenewaddress and you'll be fine-- you should always have at least 3 backup copies of all your keys.

If you're running a very busy service so backing up every 30 is too often, then run with -keypool=1000 and backup at least every 300 sends/generates.

I worry about bitcoin accumulating too many features and not doing any of them very well.  I suppose it wouldn't hurt to add an option so it automatically creates timestamped wallet backups... but should it erase old backups?  (if it doesn't, I KNOW people will forget to erase them and will be upset when their disk fills up with wallet backups and they're left to figure out how to clean up the resulting mess).  Should it encrypt them?  What should it do if an automatic time-stamped wallet backup fails?  When encrypted wallets are implemented, what should happen to old backups if the wallet encryption key is changed?

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...