BCCAPI requires the app to manage N+1 key pairs. That is one key for authentication purposes, and N keys for your wallet (one for each Bitcoin address). Knowledge of the authentication private key allows the app to access the API (and add public keys), and the BCCAPI server side then knows which public keys are associated with the authentication public key.
How the app manages keys is entirely its own business, but the BCCAPI provides a number of ways to make this easy. BitcoinSpinner has chosen to have 1+1 keys (one bitcoin address) and a randomly generated seed that allows the app to generate the two keys as required. Going forward BitcoinSpinner could choose to support several Bitcoin addresses, and still be able to do simple backup/restore of the entire wallet using one QR-code.
Ouch. That sounds pretty bad. 32 bytes of randomness can't be used to create 64 bytes of randomness, merely because you seeded a random number generator. It's good enough for video games, but since every private key is derived from those 32 bytes, the subsequent addresses aren't random enough for financially sensitive applications.
I appreciate that it's been done to solve a problem; but I'm not sure I like it.
The attack you are addressing is computationally >= brute forcing a 256 bit EC key. If you are worried that this is feasible you better start looking for the Bitcoin exit signs. As soon as someone is able to do that everyone will panic, and at that time it is too late to exit.
I'm also not sure why the app needs to authenticate to the server at all. The server holds no secret information; the balance on every bitcoin address is public knowledge anyway. Surely the app can just generate N keys, and ask the server about each of the matching public keys in turn? In fact, the grouping together is itself a security risk as it provides a way of associating separate addresses together. All a BCCAPI server really needs to provide is a HTTP interface around transaction broadcasting (the app can create the transaction), and balance monitoring.
The goal of the BCCAPI is to provide an API that allows you to make really light weight clients. Light weight measured in bandwidth, CPU power, storage and battery life. If I chose to make the client asks the server for transactions associated with a number of keys, then the client would have to download, process and store all the transactions, which defeats the purpose of being light weight. Furthermore, the server would be able to deduce the key relationship anyway, as the same device would query the same server.
Another aspect is that if you want a server where you can ask it for transactions related to any key then you need a much more powerful server side, which is able to determine transactions associated with ANY key in existence in real-time. With the BCCAPI the server side only needs to monitor the block chain for well-known public keys. This is a lot cheaper, and one of the reasons why I can keep this as a free service.
You are however right that you loose some of the anonymous properties by letting the server know which public keys a wallet comprises of. However, so far BitcoinSpinner only uses one address.
for Backup/Restore. Speaking of Bitcoin private key formats, I don't think that there is a formal specification. So far I have only seen an unofficial patch that you can apply to the Satoshi client.
Quite so; there isn't an official format. Whatever format is chosen though, it's going to be a way of representing 32 bytes. Since that is the size of the ECDSA secret. It might be that some checksumming and versioning bytes are added (just as for the public address), but those 32 bytes are all you really need.
BCCAPI has a tool that allows you to export keys. The version out there now does it based on passphrases etc, so it just needs to be tailored a bit. However, it does output them in a format compatible with the Satoshi client patch:
http://code.google.com/p/bccapi/source/browse/trunk/src/com/bccapi/tool/WalletExporter.javaI'll ask the BitcoinSpinner if they can add an export function.
As for the other nits I totally agree, and have forwarded them to the devs.
Great.