Is there anything we need to do for robustness against spam/flooding attacks? I thought [mike] had some ideas.

Marketing and education are highest priority. We need more docs to be translated into different languages.

Perhaps really really low priority, but I want to remind you about redundant transmission of transactions with each block. May be it's better to solve this sooner rather than later.

My proposal is to modify 'block' message to contain only transaction hashes. After that, 'getdata' can be used to further acquire missing transactions from block's sender.

Unfortunately I don't see how this can be done without breaking current protocol.

This might be nice but I don't see it as a prerequisite for 1.0.

In the discussion on BitDNS, there was resistance to overloading the main chain as a title registry. Another chain a la BitDNS could be used to map general strings to btc addresses, as well as domain names.

One issue is it pretty much has to be first come first served. Whoever grabs gavin@acm.org first, gets it. There wouldn't be any way to verify ownership of the address.

I think glueing the browser to the node software is a lot easier than coming up with some complicated address mapping scheme.

I'm pretty familiar with how we do DoS resistance at work, but traditional DoS and BitCoin DoS are very different problems. There are just so many ways to do it, and best of all, nobody really knows what the capacity of the network is :-)

By the way, one way to let me send coins to gavin@acm.org is to leverage the old direct-to-IP mechanism. Example:

1) Download EC public key from http://acm.org/bitcoin-transact/gavin. Optionally, if that results in a 404, fall back to http://directory.bitcoin.org/acm.org/gavin

2) Create a transaction with <pubkey> OP_CHECKSIG as the output, broadcast

3) Gavin claims it by sending a tx with just a signature in the scriptSig.

All clients should still be able to recognize these sorts of transactions. All we've done is replace the direct IP-to-IP connectivity with a well-known HTTP endpoint. Supporting this scheme is as simple as creating a directory on a web server.

It can be extended to include not just an EC key but an RSA key in the downloaded file too. Then you can send a message by encrypting it, POSTing it somewhere (like back to the acm.org server if the downloaded file advertises that it supports that), and including the hash in the transaction before an OP_DROP. This way even though you only advertise a single key, you can still find out who sent you coins.

I'm not claiming this is easier or better than having some simple web browser integration mind you. It'd still require some setup and ultimately copy/pasting a BitCoin address isn't much different to copy/pasting an email address.

I suspect there's various interesting ways you can avoid relying on base58 addresses using the scripting language.

The solution for sending coins to people is at http://bt.irlbtc.com/view/3427.0
I envision adding a "wallet" tab to the client, which lists every bitcoin bundle in wallet.dat, and if you double click any bundle you can: (1) copy the private key for that bundle so you can email it to someone, (2) split out a different amount, (3) combine with another bundle, (4) reissue. Very similar to that other digital currency ecache.

For click-to-pay, what about finalizing details for a bitcoin:// uri scheme, and letting the client handle those requests? Any idea of an easy way to get that to work with an online wallet, though?

define click-to-pay?