Deterministic wallets - page 2. | Bitcointalksearch.org

TierNolan

legendary

Activity: 1232

Merit: 1083

Quote from: piotr_n on August 26, 2013, 09:20:26 AM

Initially I had thought that keeping "B_secret" secret does prevent others from guessing further public keys... but then it came to my mind (though, please correct me if I'm wrong) that just by having two consecutive public keys that came from the same type-2 deterministic wallet, it should be rather simple to calculate the B_secret - shouldn't it?

I mean, if

Code:

B_public_key = A_public_key + B_secret * G

Then:

Code:

B_secret = ( B_public_key - A_public_key ) / G

Right?

Or isn't it possible to do the second math?

Most system use hashing.

The Armory system is that you work out a multiplier based on the chaincode and the current public key.

Multiplier(n) = ChainCode XOR Hash256(PubKey(n))

Public Key(n+1) = multiplier(n) * public key(n)
Private Key(n+1) = multiplier(n) * private key(n)

So, if you have the nth private key, you can work out the nth multiplier and then compute the (n+1)th key pair and by iterating, you get all the later pairs.

It doesn't let you work out the keys from before n (since that would require reversing the hash function).

You need the chain code, which isn't suppose to be public info.

Under your scheme, the private keys are directly generated by the server, so that is the worse than just having the chain code and root public key on the server.

An attacker with public key(0) and the chain-code can obtain all private keys after the first private key they obtain.

If someone hacks a server using your system, they get all the private keys.

piotr_n

legendary

Activity: 2053

Merit: 1354

aka tonikt

Quote from: piotr_n on July 30, 2013, 09:03:04 AM

Quote from: Abdussamad on July 28, 2013, 03:22:38 PM

Quote from: piotr_n on July 28, 2013, 11:52:26 AM

Quote from: simondlr on July 28, 2013, 10:36:44 AM

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.

Yeah, sorry guys - I indeed meant public keys.
Thanks for correcting

BTW, I also had second thoughts about the anonymity issue, with the type-2 wallets.

Initially I had thought that keeping "B_secret" secret does prevent others from guessing further public keys... but then it came to my mind (though, please correct me if I'm wrong) that just by having two consecutive public keys that came from the same type-2 deterministic wallet, it should be rather simple to calculate the B_secret - shouldn't it?

I mean, if

Code:

B_public_key = A_public_key + B_secret * G

Then:

Code:

B_secret = ( B_public_key - A_public_key ) / G

Right?

Or isn't it possible to do the second math?

piotr_n

legendary

Activity: 2053

Merit: 1354

aka tonikt

Quote from: TierNolan on August 25, 2013, 03:40:48 PM

What do you mean by || ? If that is the OR operator, then you are going to set the least significant byte to all 1's, since after 256 values n will have 1 in every possible bit position.

By || I mean appending one byte at the end of the seed_key, that gets hashed later to get the next private key.
So next time you calc a private key, you are hashing what you had hashed before, plus one byte more...

I was worried that maybe this could be somehow exploited, especially when the attacker knows that I append the bytes always with the same sequence (0,1,2,3,...)?

Quote from: TierNolan on August 25, 2013, 03:40:48 PM

One of the big benefits of deterministic wallets is that a public server can generate the public keys without compromising the private keys.

Yeah. That's type-2. I have it implemented in my app, but I personally don't use it, because it allows the "public server" to predict my further public keys and I see more cons than pros with this. It might make a lot of sense for e-commerce apps, but I don't really need such a feature for a private use.

TierNolan

legendary

Activity: 1232

Merit: 1083

Quote from: piotr_n on August 25, 2013, 03:04:19 PM

So in my solution (which I call type-3), I do something like this:

Code:

seed_key = SHA256(seed_password)
for (n=0; n priv_key[n] = SHA256(seed_key)
seed_key = seed_key || (byte)n
}

What do you mean by || ? If that is the OR operator, then you are going to set the least significant byte to all 1's, since after 256 values n will have 1 in every possible bit position.

Quote

Could you please give me any feedback on whether you see any security risks with such an approach?

One of the big benefits of deterministic wallets is that a public server can generate the public keys without compromising the private keys.

The OP in this thread has a way to do it with safety (I think).

Root private key: k
Root public key: K = kG

You can then generate a public key by picking an offset n.

Private key(n): k(n) = k + X(n)
Public key(n): K(n) = (k + X(n))*G = kG + X(n)*G = K + X(n)*G

However, you need to keep the X(n) function secret.

If some obtains

- the X(n) function (available by hacking the server)
- the private key k(n) for a public key K(n) (ECDSA break/implementation error)

They can compute k from

k(n) - X(n) = k + X(n) - X(n) = k

It seems to me that deterministic wallets are inherently less secure than normal wallets.

If a normal address is only used once, then it is protected by both the RIPEMD160 hash and the ECDSA system.

Deterministic wallets are only protected by the ECDSA.

piotr_n

legendary

Activity: 2053

Merit: 1354

aka tonikt

This topic is 15 pages long, so please forgive me it it was discussed already.

Having in mind the recent same K-value problems in the signatures, I have been thinking about a deterministic wallet solution where exposing one private key does not expose all the others, that come after it.

So in my solution (which I call type-3), I do something like this:

Code:

seed_key = SHA256(seed_password)
for (n=0; n priv_key[n] = SHA256(seed_key)
seed_key = seed_key || (byte)n
}

Where SHA256 is actually the double sha256 and my wallet is a brain wallet (based on the seed_password).

Could you please give me any feedback on whether you see any security risks with such an approach?

piotr_n

legendary

Activity: 2053

Merit: 1354

aka tonikt

Quote from: Abdussamad on July 28, 2013, 03:22:38 PM

Quote from: piotr_n on July 28, 2013, 11:52:26 AM

Quote from: simondlr on July 28, 2013, 10:36:44 AM

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.

Yeah, sorry guys - I indeed meant public keys.
Thanks for correcting

Abdussamad

legendary

Activity: 3584

Merit: 1560

Quote from: simondlr on July 29, 2013, 07:49:36 AM

Very very cool! As Bitcoin for Woocommerce shows, it removes third-parties from transactions. Thanks for the links. Amped!

To be fair you still need a way to verify transactions. Bitcoin for woocommerce uses blockexplorer.com with fall back to blockchain.info.

There is a way to get both master public key based address generation and transaction confirmation without relying on third parties. There is an example script called merchant.py in the electrum repository that shows you how to do this:

https://github.com/spesmilo/electrum/blob/master/scripts/merchant.readme

It runs as a daemon and you can configure it to callback your script each time a transaction hits one of your addresses.

But I don't know python so I haven't succeeded in getting it to work.

simondlr

sr. member

Activity: 424

Merit: 250

Quote from: Abdussamad on July 29, 2013, 05:08:19 AM

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

Very very cool! As Bitcoin for Woocommerce shows, it removes third-parties from transactions. Thanks for the links. Amped!

Abdussamad

legendary

Activity: 3584

Merit: 1560

Quote from: simondlr on July 29, 2013, 04:30:57 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.

Quote

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

simondlr

sr. member

Activity: 424

Merit: 250

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

Activity: 3584

Merit: 1560

Quote from: simondlr on July 28, 2013, 10:36:44 AM

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.

Abdussamad

legendary

Activity: 3584

Merit: 1560

Quote from: piotr_n on July 28, 2013, 11:52:26 AM

Quote from: simondlr on July 28, 2013, 10:36:44 AM

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.

chrisrico

hero member

Activity: 496

Merit: 500

Quote from: grau on July 28, 2013, 11:29:58 AM

Quote from: chrisrico on July 28, 2013, 11:27:05 AM

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.

Quote from: piotr_n on July 28, 2013, 11:52:26 AM

Quote from: simondlr on July 28, 2013, 10:36:44 AM

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.

Quote from: piotr_n on July 28, 2013, 11:52:26 AM

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.

piotr_n

legendary

Activity: 2053

Merit: 1354

aka tonikt

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

Pieter Wuille

legendary

Activity: 1072

Merit: 1174

Quote from: simondlr on July 28, 2013, 10:36:44 AM

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.

justusranvier

legendary

Activity: 1400

Merit: 1009

Quote from: piotr_n on July 28, 2013, 11:52:26 AM

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.

piotr_n

legendary

Activity: 2053

Merit: 1354

aka tonikt

Quote from: simondlr on July 28, 2013, 10:36:44 AM

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.

grau

hero member

Activity: 836

Merit: 1021

bits of proof

Quote from: chrisrico on July 28, 2013, 11:27:05 AM

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.

chrisrico

hero member

Activity: 496

Merit: 500

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.

simondlr

sr. member

Activity: 424

Merit: 250

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?

Topic: Deterministic wallets - page 2. (Read 48264 times)