Timeline for HD / Deterministic Wallets and public key
Current License: CC BY-SA 3.0
6 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jun 2, 2014 at 22:59 | vote | accept | Matt | ||
Jun 2, 2014 at 22:27 | comment | added | Tim S. | In the BIP 0032 specification an HD wallet has both "normal" child keys, from which you can generate more public child keys with only the public key, and "hardened" child keys, from which you cannot generate more child keys. If a service used a normal child key to calculate a key that's far down the chain, I'd expect them to tell you just how far down the chain that is. But I see no reason why they would go beyond the last unused address unless you asked them to. If you hand them an address or a hardened child key, they cannot generate subkeys. | |
Jun 2, 2014 at 22:09 | comment | added | Matt | I was under the impression that the public key could be used to generate additional public keys. I.e you could hand off a branch of the hd wallet to a service provider without generating the sub keys. Is that incorrect? | |
Jun 2, 2014 at 22:04 | comment | added | Tim S. | You and the service will generate the same series of public keys: that's what it means to be a deterministic wallet, instead of one like Bitcoin Core where each private key is random. You control all of them in the series, it's just a matter of knowing which have money in them (which is controlled by the 100 pregenerated keys in my example), so you know which you can try to spend with. | |
Jun 2, 2014 at 22:02 | comment | added | Matt | So for example if you hand off an HD public key to a service and it generates public keys on your behalf for payments. You can pay from those public addresses, but how do you know which ones you control? | |
Jun 2, 2014 at 20:58 | history | answered | Tim S. | CC BY-SA 3.0 |