@s{quotedtext}
@s{quotedtext}
I only half-paid-attention to all the previous deterministic wallet discussions, but isn't it pretty simple?
Start with a random private key and a random nonce.
ECC multiply the key by SHA256(nonce+n) to get the n'th derived key.
(I think you could even get away with using the private key as the nonce) (and, of course, I defer to the expertise of people who know way more about ECC crypto than I do)
@s{quotedtext}
@s{quotedtext}
It seems to me these issues will be the same no matter what solution is implemented.
@s{quotedtext}
@s{quotedtext}
I think the next step is starting to prototype and standardize a protocol for communicating with WPS or escrow services to request new public keys, get keys signed, etc.
Supporting deterministic wallet schemes at the same time makes sense, in my humble opinion.
I imagine an API call that is something like "I'm customer gavin@acm.org. Please use whatever private key you're storing for me and this 256-bit number to derive a new public key, and send it back to me."
(details to be worked out, but note that the WPS wouldn't necessarily have to store that new keypair if the "Please sign" request included the same (gavin@acm.org,256-bit-number) ....)
@s{quotedtext}
@s{quotedtext}
As long as the API is consistent, I don't think the details of the deterministic wallet matter.
@s{quotedtext}
@s{quotedtext}
I don't see the difference: if the WPS becomes unavailable, then either solution requires that the "C" key be transferred from paper (or wherever) to the online client.