Why do you trust "the server" (and the person running it, who I assume is not always yourself)?
How do you know you're even talking to "the server" you think you're talking to (no man-in-the-middle)?
I am pretty sure that all client-server models require trust that the server is not lying. I can't think of any that don't. However, there aren't too many things that a malicious server can do.
Why do you trust all of the nodes you connect to? I'm pretty sure that most of the same protections to make sure peers aren't lying to you are available to a thin client.
For example: A transaction's input contains a signature that can't be faked (if they can, we are all f***ed, thin client or not). If a malicious server gave you a fake input, a simple check would show you it is fake.
Since you generate and sign outgoing transactions yourself, there is no chance of the malicious server redirecting your coins to another address unless maybe that address is retrieved from a malicious firstbits resolve where they happen to have a collision. This is a potential problem with firstbits in general and not specifically this protocol.
http://firstbits.com/ could make addresses for the most commonly requested addresses and return those instead of the real ones (if they wanted to be thieves) or if the firstbits were short enough, they could generate a collision on the fly. Not sure what we could do to prevent this problem besides letting people know that for utmost security they need the full address.
One thing I could see a server doing that would be harmful is not relaying it's clients transactions. Right now, thin clients only talk to one server. This wouldn't be too hard to detect as the person you are sending to would probably mention that it hasn't been received. People are also talking about getting thin clients to communicate with multiple servers which would remove this problem. I think transaction broadcast services will be important for anonymity given some of the IP tracing I've seen.
Another problem might be if the server does a double spend against one of it's clients as they could be kept unaware of the real transactions on the network. This problem is also removed once the client can talk to multiple servers.
These are basic, fundamental security questions that have been widely known since before SSL came into use. If the designers of this new protocol don't think they need to be addressed, that concerns me.
Run the protocol over SSL and you don't need to worry about MITM. Then, only a malicious server is the problem.
If we have a network of servers of running this protocol, some of the problems I mentioned above (like holding transactions) would require a 100% attack (which is likely much harder than a 51% attack
). I'm not sure how we should handle what happens when a malicious server is detected. That definitely needs to be figured out soon.
I imagine slush can give a better defense of this proposal as he seems to always write what I am thinking way better than I seem to be able.