Are there dns servers for testnet or just the production network?

Vladimir,
I'm the guy who submitted the recent peer discovery stuff to bitcoinj and I plan on doing some work on dns discovery this weekend. ([mike] pointed me in the right direction.) It will most likely end up in bitcoinj pretty soon.

Good point.

Both.

I'm using the bitcoin keys to encrypt and decrypt successfully.
Now my hangup is getting the keys gracefully out of bitcoin. Its incredibly difficult at the moment since I'm not writing in c/c++.
I'm using sipa's walletdump branch to get the keys through the rpc interface but I really wish the keys were kept separate so services like this were easier to implement.

The message will be encrypted to the public key of the receiver. I realize that you can only get the public key after money at that address has been spent but thats ok for what I'm after.
All I meant was if the hash of the public key is good enough for transaction addressing anonymity than it should be good enough for message addressing anonymity since it tells you nothing about the identity of the receiver.
I see what you're saying about adding a speculative decrypt for every message in the stream. I'll try to get something basic out first and see what the reaction is then see if that would be useful.

Well then I'll guess we'll just have to agree to disagree.

Ok, I think we're just going to have to come to the conclusion we're talking about different things.

It doesn't matter to me how your wallet communicates with the ui etc.
I'm concerned with how your wallet, the piece of software that you are explicitly giving access to your keys, stores keys.
Its this piece that I think should be standard, secure, and portable. In other words lets say your wallet protocol was widely adopted.
I should still be able to try out different wallet management software. How would you move the keys between providers or ensure that you weren't just putting your keys into some black box that now has you locked in?
A standard key storage format for keys and only keys would be needed.
The format wouldn't be concerned with balances, etc, because the software accessing the key would assume its a lie and verify for itself anyway.
You wouldn't trust the software accessing your key file to only look at the keys you want it to so you would provide the information to decrypt only what you want it to see. That even includes accessing public keys.

Either way I wrote one for my own use for a larger project with the help of sipa's branch. I'll release the dump and load code and the file format after its cleaned up.

Only if the keys are stored unencrypted without selective reveal which is exactly how they are stored now.

I guess thats my point. There needs to be a standard and secure way of allowing access to certain keys that doesn't require toting a processing device around.

At that point you're not talking a plain storage device. You need to be walking around with a full fledged mini computer that the ATM just so happens to have drivers for.

I'm assuming if the hash of the public key is good enough for addressing the transaction then its good enough for addressing the message.

The problem I see with what you propose is that it requires a running program.
In a hypothetical situation where I want to use a bitcoin atm with the keys in my pocket, how would this work? Is the atm going to let me execute a program on its hardware so I can launch a wallet service? Thats assuming I have a compatible program of course.

Good googley moogley thats complex! Nice work.

That appears to be a communication protocol.... I'm just worried about how the keys are stored which should be addressed well below that level.

If you had your wallet protocol up and running on your machine I should be able to walk up to it, plug in my usb stick with my keys and let err rip while only allowing your app to access what I want. What you've outlined has the application layer determining what keys can be accessed. What if I don't want to give your application access to all my keys? Or I trust your application with my business accounts but not the personal accounts? What if there are competing wallet protocols for different specialized purposes? Your keys should still be able to transfer seamlessly between them.

It seems to me with all the great and various development going on there is a glaring hole in portable secure key management which would be relatively easy to solve with a bare minimum, portable, agreed upon key storage format that exists outside the bdb.

In the wallet protocol example you would launch the providing service and give it the key to unlock your mining account but no matter what come hell or high water you don't want it touching your kid's account.

A simple example like the one I outlined above would even be backwards compatible with existing bitcoin client since encryption of keys could be turned off.

Would it make sense to separate the wallet from the bitcoin client? Right now they seem so tightly linked and separating them would enable some pretty cool use cases. I see talk about encrypting the entire wallet.dat but that would seem to give you all or nothing in the case of a shared system or business/personal system.

My little custom format at the moment (after I dump the keys from the client) looks like this:
SQLite (transactional + bindings for most languages)

MasterKey
AccountID (allows multiple users to share a wallet with different keys for each)
AccountName
Version (of the wallet storage format)
Format (Flags for format and usage of private keys) Current options: Public encrypted, Private encrypted
KeyForPublic
KeyForPrivate

Keys
AccountID
PublicKey
PrivateKey

For now everything is just AES but there could be more options.
In the case of the home user you would most likely store the public keys open and the private encrypted.
To decrypt you provide the AES passphrase for the account's KeyForPrivate field which then gives you the key to decrypt the private keys. This would only be necessary when spending or of course key generation.
I could also choose to encrypt the public keys. The wallet could then travel with me in my pocket and when lost would be meaningless even for figuring out which past transactions were yours.
I could also plug the wallet into someone else's machine and just give the key for my public keys to check balances but leave my wife's public keys unknown to the machine.
Have there been any talks about externalizing the storage of the private keys from the bitcoin client? I'm assuming the only time it uses the private keys is for sending and key generation. Is anyone working on something similar at the moment?
It would allow a lot more tools to be written such as custom key generators and backup/restore.

I'm using IRC at the moment but that was just a quick and dirty. Mainly thats just to start the propagation and also because I had never written an IRC bot and wanted to try it.

Can't say about the offending key thing. I hate to say this but I love this for the academic pursuit but have no interest in helping people break the law. I really hope that wouldn't be its use. I just think its cool.
As I have the encryption scheme working right now there is no indication who sent the message. In fact, even once you decrypt it there is no indication who sent it.
Two keys are used to send: the public key of the receiver and an the private part of a one time ephemeral key generated by the sender.
The public part of the one time ephemeral key is sent with the message and decrypted with the private key of the receiver.
Its diffie hellman magic!

edit:
I guess I should clarify after re-reading my first post because it was phrased weird.
The keys in your wallet aren't used to send, only to receive.

I want to share with you guys what I'm working on to get comments and gauge its usefulness/technical feasibility since I don't know all the ins and outs of the protocol.

Its looks like you can send messages in the transactions but it seems like that would seriously clog the tubes if it took of... filling the network with microtransactions just to communicate.

I have a prototype of a system that uses the keys currently in your wallet to send messages perfectly anonymously to other bitcoin users without requiring prior key registration.

The main caveat is that it uses the public key of an address... so messages can only be sent to addresses that have their public key known.
This would work great for receipts, etc, and once you have communicated with someone you can continue to use the same address.

Here's how it works, with a few in the weeds details of how I have it implemented so far.
Sending:
Enter an address. If the public key is available your message is encrypted using ec ies to the public key.
The message is then posted to an IRC channel. (I'm going to leave out a bunch of details about how the load/spamming is handled)
From here the messages can propagate through all sorts channels.

Receiving:
A separate program running on parallel to the client loads your keys into a sqlite database. The private keys are encrypted with a master key stored in the database... which in turn is encrypted with the passphrase of your choosing. This allows for fast rekeying of the db.
The database is separate from the bitcoin server so it is portable. No need for the full thing if you just want messaging on the go.

Clients interested in messaging can attach to the message stream looking for messages addressed to them.
Ones with the correct address are plucked from the stream and stored to disk. To read the message the db passphrase is entered, the private key released, and the message is read.
This would be great for sending back a confirmation or results of a transaction.
Its also assumed only those interested in perfect privacy would query for messages through a service like blockexplorer instead of attaching to a message stream.

I have a plan for load, spam, and communicating with unseen addresses which I'll have to address when I'm not high on a coding binge.

One of the things I'm not totally sure of though that I hope someone can confirm for me since I'm so new to bitcoin:
If I receive a transaction, the public key attached is always that of the sender of the transaction?
I'm making that assumption so please correct me if I'm wrong (and before I spit shine this thing)

You're right. I got it installed and works great. (No small feat since I'm just good enough at linux to be dangerous).
As far as what I'm doing: I'm feeding the keys into an elliptic curve function to encrypt something else.

Oh... I see. So its a full client replacement?
Still not sure thats going to work for me but I appreciate it.
The service I'm developing has an end user component that needs access to the keys. Requiring a different client wouldn't be optimal but if thats the only choice I have I may go that way.

If anyone happens to have a pure java version I'd be willing to pay a small amount from my meager bitcoin collection.

Unfortunately I would need it to work in java.