# Gavin Andresen
# 2011-12-15 15:47:19
# https://bitcointalk.org/index.php?topic=54416.msg651187#msg651187

@s{quotedtext}
@s{quotedtext}
 @p{brk}
I only half-paid-attention to all the previous deterministic wallet discussions, but isn't it pretty simple? @p{par}

Start with a random private key and a random nonce. @p{brk}
ECC multiply the key by SHA256(nonce+n) to get the n'th derived key. @p{par}

(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) @p{par}


@s{quotedtext}
@s{quotedtext}
 @p{brk}
It seems to me these issues will be the same no matter what solution is implemented. @p{par}


@s{quotedtext}
@s{quotedtext}
 @p{brk}
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. @p{par}

Supporting deterministic wallet schemes at the same time makes sense, in my humble opinion. @p{par}

I imagine an API call that is something like "I'm customer @p{(link}gavin@acm.org@p{link)}.  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." @p{par}

(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 (@p{(link}gavin@acm.org@p{link)},256-bit-number) ....) @p{par}


@s{quotedtext}
@s{quotedtext}
 @p{brk}
As long as the API is consistent, I don't think the details of the deterministic wallet matter. @p{par}


@s{quotedtext}
@s{quotedtext}
 @p{brk}
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. @p{brk}