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.

I should have been clear:  this is a patch against the latest 'vanilla' svn.

I just updated the code/patch:
   monitoraddress allwallet <url>
... gets triggered for all transactions that go into your wallet.  That includes 'change' transactions that can occur when you send somebody coins, which I expect will strike some people as a bug and others as an important feature.

And I combined the getblockby methods into one.  I know I would've never remembered  "is it getblockybycount or getblockbynumber or getblockbyheight or getblockbydepth" -- I will remember "getblock".

Good Idea, and that aught to be easy.

I'm thinking it should be:
  monitoraddress allwallet <url>
... instead of a separate monitor command.

Come to think of it, maybe I should combine the getblockby* routines into one; there's no chance of mistaking a 64-character hex block hash for a 5-digit (or, in many years, a six or seven or ten digit) block number.

This patch adds the following JSON-RPC commands to bitcoin/bitcoind:

• monitoraddress <bitcoinaddress> <url> [monitor=true]
  When coins are sent to <bitcoinaddress> POST JSON transaction info to <url>.
  If <bitcoinaddress> is 'allwallet' then monitor coins sent to all of your addresses.
  Pass false as third param to stop monitoring.
• monitorblocks <url> [monitor=true] [startblockcount=0]
  POST block information to <url> as blocks are added to the block chain.
  [monitor] true will start monitoring, false will stop.
  Pass [startblockcount] to start monitoring at/after block with given blockcount.
• listmonitored
  Returns list describing where blocks and transactions are being POSTed.
• getblock <hash|number>
  Returns details of the block with <hash> (hexadecimal) or <number>.
• gettransaction <hash>
  Returns details of transaction with <hash> (hexadecimal).

This patch also modifies the "sendtoaddress" function so it returns the transaction ID on a successful send (instead of the string "sent").

If you use the monitor* functionality to POST information be sure to think through the security of your application.  For example, if you use monitoraddress to get notified of customer payments you should think about whether or not a customer could fake a payment by POSTing bogus information to your web server.

Full source code is at: http://github.com/gavinandresen/bitcoin-git/tree/monitorreceived
As always, bug reports, suggestions for improvement and feedback is welcome.

---

Updated monitoraddress/getblock commands as discussed below

blkindex.dat contains all the transactions, in records that look like:
  key:  "tx" + HASH_OF_TRANSACTION
  value: serialized CTxIndex

The CTxIndex points to a record in one of the blk000n.dat files.

That does bring up an interesting point, though:  if lightweight clients are implemented, they wouldn't be able to support an arbitrary 'gettransaction'.

I've been working on a "monitoraddress" / "monitorblocks" patch, so bitcoind will POST transaction/block information to an arbitrary URL.

And it seems to me "getblock" should be split into "getblockbycount", "getblockbyhash" and "gettransaction".  I also have some suggestions for making the naming more consistent:

I'd suggest getblockby* return:

Reasoning:
  blockcount instead of 'height' or 'depth' because getinfo returns "blockcount"
  getblockbyhash might return a block not on the "best" chain; return blockcount=-1 in that case?
  version instead of 'ver' because abbrvs shd b avoided (thy cn b hrd to rd/rmbr)
  only return transaction hashes; if you need more transaction details, call gettransaction.
  No n_tx (or n_anything) because it is implicit in length of returned array

(stuff I'm not sure about:  what is 'bits' in the implemented getblock?  Is that difficulty?  Does anybody really need all the detailed merkle tree info?)

I'd suggest gettransaction return:

Reasoning:
  Returning the CScript string seems like it is both too much detail AND not very useful (I want the bitcoin addresses, NOT OP_DUP 0xblahblahblah ...)
  "from" is just a list of pointers to previous transaction "to"s
  confirmations is duplicate info (you could getblockbyhash and then look at its blockcount), but is so useful I think it belongs here.

Separate "accounts" (addresses with labels) to accumulate Jackpots is the right idea.  Users buy tickets, bitcoins are moved to the appropriate Jackpot account.  When a Jackpot is won, transactions flow out of its account back to whoever won.

The "label" mechanism (setlabel / getreceivedbylabel) is supposed to meet this need, but only solves part of the problem.

If the API was extended as I describe below, would it solve the same problems as having multiple wallets?

Proposal:

+ new send method: send TO a given bitcoin address specifically FROM the bitcoins sent to <label>
  (change generated would be automatically tagged with <label>)
+ add optional [label] param to getbalance.
+ new method: listsentbylabel
  (returns array of [ "address" : "bcaddresssentto", "amount" : x.yz, "confirmations": n ])

Each customer "account" would be a bitcoin <label>.  Account handling would look like:

Create account / create new address for account:
  getnewaddress [account_id_label]
   ... tell user "fund your account by sending coins to {the address returned}"

Customer withdraws/spends:
  sendfrom [account_id_label] [address] [amount]
   (FAILS if balance for that account too low)

Show customer their balance:
  getbalance [account_id_label]

Show customer their transactions in/out
  listreceivedbylabel [account_id_label]
  listsentbylabel [account_id_label]

---------

Seems to me this would be a much better direction to go in, rather than having separate wallet.dat files for each customer.  At the very least, backing up thousands of customer's wallet files would be inefficient and error-prone, and constantly switching between them would also be incredibly inefficient.

An irresponsible central bank.

I think that scenario is unlikely for dollars, because the Federal Reserve central bankers already have a lot of dollar-denominated wealth, so have a strong incentive to avoid hyperinflation.

Compare that to the Zimbabwe central banker, who is basically under the thumb of a dictator who most likely holds his wealth in foreign currencies.  Their incentive is to squeeze as much wealth out of the economy before it collapses and they're deposed in the next coup.

For extra credit, give an Object as the return value:

{
  'isvalid' : true,
  'ismine' : true,  # true if isvalid and you have the private key (can spend coins sent to this address)
  'version' : 0,  # ADDRESSVERSION
  'address' : '1frt6531....'    # might as well echo back the address...
}

With just a web browser you can open an account at bitcoinmarket, mybitcoin, or mtgox and send/receive bitcoins.

The only thing you're not able to do is try to generate bitcoins, but you said you don't have a computer at home and it sounds like your employer wouldn't be very... uhh, supportive... of you using their electricity to try to generate bitcoins.

If they would be supportive (long ago I wrote software at a hardware company where they actually LOOKED FOR CPU-intensive applications to run during system burn-in, so they'd ship fewer dead-shortly-after-arrival units) then they'd probably be happy to open up outbound connections to port 8333.

"Mainstream" users want a more-selection, less expensive, just as fast variant of iTunes.  Frankly, I don't think an illegal filesharing site can scratch that itch and stay in business for long (I'm curious to see how long mulve.com lasts).

If it could, I think a bitcoin-revenue-sharing business model would work well-- "We'll give you 50% of the revenue from any downloads of stuff you upload"  (and "we" charge x-bitcoins-per-download).

But I think even if such a service existed there would still be a bunch of people who refuse to pay a bit-penny for downloads.  But I agree with lfm-- I think many of them would be willing to pay indirectly for downloads; you just have to tell them that they're paying for "X gigbytes of premium bandwidth" or something...

I think a big publicity splash should wait until Bitcoin 1.0.  Bitcoin still has way too many rough edges for ordinary folk to use (watch them run away screaming as you try to explain that it is NORMAL for it to take half an hour to download the block chain the first time you start Bitcoin....).

I believe that the statement: "bitcoin is new kind of money" passes the duck test.

Bitcoins function as money (they're a unit of account, a medium of exchange, and a store of value), and if PayPal started allowing Bitcoin transactions tomorrow I'm certain they'd treat them as Just Another Currency.

If you like, call it a commodity, but I think all you'll accomplish is confusing potential users who might think they'll end up getting pork-bellies delivered to their porch if they don't get rid of their bitcoins.

I shoulda been more clear:  I've now got a 1.11 payment to {some random address} in Bitcoin; I want to take that {some random address} and give it to MyBitcoin (or you, the merchant) and see what's up with that payment.  Ideally, it would pick up the payment process as if the PAYMENT TIMED OUT never happened.

And MadHatter:  keep the change.