Deterministic wallets

[grau]

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".

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.

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.

[1714913623]

1714913623

[1714913623]

1714913623

[1714913623]

1714913623

[piotr_n]

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

[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.

[piotr_n]

OK, then sorry.
I should had read more

May I ask, do you really need such a hi tech for a business?
It seems like 100x more sophisticated than MtGox

[chrisrico]

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]

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]

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]

so have deterministic wallets been implemented in the reference client?

just wondering how often I have to update my backups ...

[simondlr]

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]

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]

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]

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.

[justusranvier]

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]

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.

[piotr_n]

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

[chrisrico]

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]

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]

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]

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]

@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 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