grau
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 22, 2013, 07:38:42 PM |
|
This however is the wallet where we expect to see different implementations. The purpose of the standard here is to enable interoperability across implementations. I think the JSON file I provided is a reusable piece of data for any other implementation's unit test and the algorithm I wrote helps to clarify what is evtl. not obvious in writing. Let me know if more is needed to have "a" reference.
I should probably read a bit more before asking what is the "interoperability across implementations". ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Means being able to transfer keys and key hierarchies from one wallet to an other even if they use different implementations. Now I understand. So you are saying that it should be 'Final' already. OK - I'm with you, assuming that it works, though please don't ask me to test it. ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) You do not need to test mine, but feel free to refer to it. I suggest you to use the JSON parseable test vectors in https://github.com/bitsofproof/supernode/blob/1.1/api/src/test/resources/BIP32.json for your unit test.
|
|
|
|
piotr_n
Legendary
Offline
Activity: 2053
Merit: 1356
aka tonikt
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 22, 2013, 07:42:08 PM |
|
I personally don't see a reason to swap wallet format between different wallets. And even if there was, I'm sure someone can build a converter. So I personally don't really care about a compatibility of my wallet with other wallets - especially that I keep my wallet it simple
|
Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E
|
|
|
grau
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 22, 2013, 07:43:02 PM |
|
I personally don't see a reason to swap wallet format between different wallets. And even if there was, I'm sure someone can build a converter. So I personally don't really care about a compatibility of my wallet with other wallets, especially when I keep it simple
Not wallet formats. Key export and import.
|
|
|
|
piotr_n
Legendary
Offline
Activity: 2053
Merit: 1356
aka tonikt
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 22, 2013, 07:49:26 PM |
|
OK, then sorry. I should had read more ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) May I ask, do you really need such a hi tech for a business? It seems like 100x more sophisticated than MtGox
|
Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E
|
|
|
chrisrico
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 22, 2013, 10:55:04 PM |
|
I personally don't see a reason to swap wallet format between different wallets. And even if there was, I'm sure someone can build a converter. So I personally don't really care about a compatibility of my wallet with other wallets, especially when I keep it simple
Not wallet formats. Key export and import. I think to clarify, in the case of HD wallets, it's less about the individual keys and more about ensuring that all clients, given a seed, will derive the same keys from that seed.
|
|
|
|
grau
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 23, 2013, 02:03:01 AM Last edit: June 23, 2013, 02:17:36 AM by grau |
|
I personally don't see a reason to swap wallet format between different wallets. And even if there was, I'm sure someone can build a converter. So I personally don't really care about a compatibility of my wallet with other wallets, especially when I keep it simple
Not wallet formats. Key export and import. I think to clarify, in the case of HD wallets, it's less about the individual keys and more about ensuring that all clients, given a seed, will derive the same keys from that seed. BIP 32 defines a serialization for extended keys. I meant to exchange those extended keys. This is what the unit tests I mentioned test. A serialized extended key determines all keys derivable from it, and carries its place in the key hierarchy. BIP32 also defines the algorithm to derive extended keys from a seed. This is also implemented in BOP in the class I quoted.
|
|
|
|
chrisrico
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 23, 2013, 01:35:48 PM |
|
BIP 32 defines a serialization for extended keys. I meant to exchange those extended keys. This is what the unit tests I mentioned test. A serialized extended key determines all keys derivable from it, and carries its place in the key hierarchy.
BIP32 also defines the algorithm to derive extended keys from a seed. This is also implemented in BOP in the class I quoted.
Ah, ok. Thank you for the clarification.
|
|
|
|
trout
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 25, 2013, 05:52:04 PM |
|
so have deterministic wallets been implemented in the reference client?
just wondering how often I have to update my backups ...
|
|
|
|
simondlr
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 28, 2013, 02:36:44 PM |
|
Before I start a new topic, I thought I'd ask here first. I'm really excited about the possibility of deterministic wallets. Bear with me here. I understand about 65% of how this works.
As far as I understand BIP 32, it will be possible to derive additional public keys from someones extended public key, right?
So if someone gives me an extended public key, I can generate public keys to addresses that the other person can unlock (by generating the appropriate private key on their side). Is this correct?
What I want to know. Let's say person B has given their extended public key to person A. Person A can now generate additional public keys to send BTC to. If person has not already generated the corresponding private keys, do they still 'receive' the value in their wallet? ie, how does person B's wallet know that the extra public keys that was generated by A, is theirs? Does it check new addresses coming into the blockchain and determines whether they can generate the correct private keys to unlock them?
Am I being clear here?
To put it another way. Can I pay to a person's deterministically generated public addresses without them having had to pre-generate themselves? Is this possible?
|
|
|
|
chrisrico
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 28, 2013, 03:27:05 PM |
|
Current deterministic clients pre-generate a number of private keys in the chain. If you don't have the private (or public) keys generated though, you won't recognize a transaction ad being your own.
|
|
|
|
grau
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 28, 2013, 03:29:58 PM |
|
Current deterministic clients pre-generate a number of private keys in the chain. If you don't have the private (or public) keys generated though, you won't recognize a transaction ad being your own.
You will recognize your own transactions if you use consecutive numbers of keys (with limited gaps if any) and you have a server that supports scanning with a master key. I happen to have such a server.
|
|
|
|
piotr_n
Legendary
Offline
Activity: 2053
Merit: 1356
aka tonikt
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 28, 2013, 03:52:26 PM Last edit: July 30, 2013, 01:03:55 PM by piotr_n |
|
So if someone gives me an extended public key, I can generate public keys to addresses that the other person can unlock (by generating the appropriate private key on their side). Is this correct?
Not quite. You need to give him your public key and the secret. From these two, one can "guess" further private keys. (EDIT: public) But you should also know that this might be dangerous for your privacy. It you make your "public key + the secret", anywhere, anyone can find out that all the further addresses determined from it belong to you.
|
Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E
|
|
|
justusranvier
Legendary
Offline
Activity: 1400
Merit: 1013
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 28, 2013, 04:03:49 PM |
|
But you should also know that this might be dangerous for your privacy. It you make your "public key + the secret", anywhere, anyone can find out that all the further addresses determined from it belong to you. This isn't a problem because you can create an arbitrary number of extended public keys, up to and including a new one for every transaction.
|
|
|
|
Pieter Wuille
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 28, 2013, 04:14:18 PM |
|
So if someone gives me an extended public key, I can generate public keys to addresses that the other person can unlock (by generating the appropriate private key on their side). Is this correct?
Yes, that's correct. If he has an extended private key, and gives you the corresponding extended public key, you will be able to derive all public keys (and thus addresses) that correspond to the private keys generated from his extended private key.
|
I do Bitcoin stuff.
|
|
|
piotr_n
Legendary
Offline
Activity: 2053
Merit: 1356
aka tonikt
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 28, 2013, 04:43:18 PM |
|
so that is why the secret (being part of the extended public key) is basically reveling all your further desposit addresses, for a given branch (customer).
unless you can keep it secret. but assuming that the first reason for anyone would be to use it for non secured environments, keeping it secret seems kind of a problem
|
Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E
|
|
|
chrisrico
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 28, 2013, 06:53:55 PM |
|
Current deterministic clients pre-generate a number of private keys in the chain. If you don't have the private (or public) keys generated though, you won't recognize a transaction ad being your own.
You will recognize your own transactions if you use consecutive numbers of keys (with limited gaps if any) and you have a server that supports scanning with a master key. I happen to have such a server. So like I said, if you pregenerate the private (or public) keys in your chain. Unless you're saying that there is a way to identify the child keys of a extended private key without pregenerating them, but it doesn't sound like it. So if someone gives me an extended public key, I can generate public keys to addresses that the other person can unlock (by generating the appropriate private key on their side). Is this correct?
Not quite. You need to give him your public key and the secret. From these two, one can "guess" further private keys. An extended public key is the public key + secret/chain code. From this you can determine the following public keys in the sequence, not private keys. But you should also know that this might be dangerous for your privacy. It you make your "public key + the secret", anywhere, anyone can find out that all the further addresses determined from it belong to you.
Yes, that is the point of giving someone an extended public key, so that they can generate addresses that you own without having any of your private material.
|
|
|
|
Abdussamad
Legendary
Offline
Activity: 3654
Merit: 1571
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 28, 2013, 07:22:38 PM |
|
So if someone gives me an extended public key, I can generate public keys to addresses that the other person can unlock (by generating the appropriate private key on their side). Is this correct?
Not quite. You need to give him your public key and the secret. From these two, one can "guess" further private keys. The bolded part is incorrect. It might be a typo. You can never derive private keys from public keys. If you could do that it would shake the very foundation of bitcoin and public key cryptography. piotr_n must have meant public key.
|
|
|
|
Abdussamad
Legendary
Offline
Activity: 3654
Merit: 1571
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 28, 2013, 07:26:18 PM |
|
What I want to know. Let's say person B has given their extended public key to person A. Person A can now generate additional public keys to send BTC to. If person has not already generated the corresponding private keys, do they still 'receive' the value in their wallet? ie, how does person B's wallet know that the extra public keys that was generated by A, is theirs? Does it check new addresses coming into the blockchain and determines whether they can generate the correct private keys to unlock them?
I have only used electrum so I will explain what I understand of their implementation. In electrum you configure a "gap limit" which is 5 by default. It basically means how many empty addresses, counting from the used address with the highest "index", should electrum scan for coins. So that is how it determines if you've received coins to one of the addresses derived from your seed. If you expect a lot of transactions you can set the gap limit to a high number like 100 or something.
|
|
|
|
simondlr
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 29, 2013, 08:30:57 AM |
|
I see. I understand now! Thanks.
@chrisrico:
That's what I thought. Thanks! You have to pre-generate your keys in order for your wallet to know from the blockchain that those public keys are yours.
@Abdussamad:
Regarding Electrum's gap limit: Does it keep that gap at 5? So it keeps watching the blockchain for the 5 next set of public keys that belong to you? If someone deterministically generated a public key of yours, you get the BTC. If then, does it generate a new key to keep the gap at 5?
So. If deterministic wallets just keep up to date (keeping a limit ahead), people using an extended public key of yours can generate as many public keys as they want (considering you keep the limit at a reasonable level) and you will receive the funds in your wallet if they pay out to those addresses? And considering your wallet is generating the correct addresses from the extended public key that you shared to another person?
|
|
|
|
Abdussamad
Legendary
Offline
Activity: 3654
Merit: 1571
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 29, 2013, 09:08:19 AM |
|
@Abdussamad:
Regarding Electrum's gap limit: Does it keep that gap at 5? So it keeps watching the blockchain for the 5 next set of public keys that belong to you? If someone deterministically generated a public key of yours, you get the BTC. If then, does it generate a new key to keep the gap at 5?
You can adjust the gap in the settings. The default is 5. Yes to all the other questions. So. If deterministic wallets just keep up to date (keeping a limit ahead), people using an extended public key of yours can generate as many public keys as they want (considering you keep the limit at a reasonable level) and you will receive the funds in your wallet if they pay out to those addresses? And considering your wallet is generating the correct addresses from the extended public key that you shared to another person?
Yep. Cool isn't it ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) The best part is that no one can spend your coins if they get access to the master public key. All they can do is predict the future set of generated addresses. This is not a problem if you use a dedicated wallet for each purpose. You can easily create a new wallet using the -w command line switch when starting up electrum: electrum -w /path/to/mynewwallet.dat There are quite a few projects out there that take advantage of this. There is an ecommerce plugin for woocommerce: http://wordpress.org/plugins/bitcoin-payments-for-woocommerce/Then this concise PHP script by @stick: https://github.com/prusnak/addrgen
|
|
|
|
|