This might just be a documentation issue, although if signmessage was changed to sign a hash of the passed-in message instead of the message itself then it would be completely safe.

Yes you could paper over the problem by making signmessage use a different hash function or prepend some idiosyncratic but standardized padding to the message before hashing or use >2 rounds of SHA256.

That's true, but I'm still impartial about this. I still think most people would want the system to work as a domain registry. I wish more people gave their opinion about this. So if someone's going to launch a DNS bridge next week, would you recommend them not to include this functionality?

IN      NS      ns0.web-sweet-web.net.
IN      NS      ns1.web-sweet-web.net.
*       IN  A   188.165.40.52
www     IN  A   188.165.40.52

{
  'domain':'mydomain.bit',
  'nameserver':
    [
	"NS0.WEB-SWEET-WEB.NET",
	"NS1.WEB-SWEET-WEB.NET",
	"NS0.XNAME.ORG",
	"NS1.XNAME.ORG",
	"87.98.164.164",
    ]
}

Can you start a forum thread about this? There was some concern about possible attacks revealing private keys if the attacker can send arbitrary data to be signed.

Which ever one is better, neither should ever use HTTP even as a fallback.  SSL should ALWAYS be on and enforced no matter what the user wants.  Sites which allow users to register an account which will be then pushed out via SSL shouldn't be too hard to find (hopefully as a part of online wallet services) but never should and kind of unencrypted/unsigned addresses be used.

A bitcoin user is vulnerable to a MITM attack because of DNS resolution not using DNSSEC (irc connections, dnsseed and dyndns) and TCP connections to ip not using SSL verifiable certificates. Once he controls all connections...
Possibilities for the attacker are :
- make the user believe he has been paid by sending a transaction from already spent coins on the real nodes
- generate fake blocks for confirmations and fake transactions
So, you can't really trust 100% what is displayed by your bitcoin client ?

By fetching addresses in http, it adds an additional risk :
- a user can send coins directly to the attacker
I admit it is a big risk, but it should not block the possibility to fetch an address even if the connection is not secured. However, the user should be warn in this case and decide what to do with a manual action (you won't send 500BTC that way do you ?).

A way to do it securely would be to send the fetch request to connected first level nodes and compare results (or shasum to shorten the message). But, bitcoin network is not ready/designed for trusted nodes.

Another solution is to have a centralized site for address fetching. If a think a centralized solution was good i would already have linked my patch with my domain :p. Maybe, I could fetch both from a direct request to the website and make a second request to one of the trusted ip (declared like bitseed ips) ?

Hey! Great to see you are working on a "Bitcoin address discovery system". That would definitely be cool to have!

I was thinking about that myself and am still unsure, if I would not prefer this to be its on daemon. So let's say you would connect to the domain in question on some well-known port (say 8334) and be connected to a simple daemon which you can then query for those things. Somehow that seems like a good thing to do to me, considering "separation of concerns" and all that.

I guess you went with this route in order to make it much simpler to deploy? That's definitely a big advantage, I agree. So maybe that's the pragmatic thing to do to actually see some adoption of it and some point. If we marry it to the webserver, I would prefer these changes though:

1. Use .json instead of .txt as the file ending
2. Move all the user lookups (user@example.org) to a folder, as to not "clutter up" the root folder too much

So that would mean:

/bitcoin-address.json (instead of /bitcoin-address.txt)
/bitcoin-address/user.json (instead of /bitcoin-address-user.txt)