Bitcoin Forum
December 07, 2016, 04:37:12 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 »  All
  Print  
Author Topic: Deterministic wallets  (Read 39594 times)
grau
Hero Member
*****
Offline Offline

Activity: 836


bits of proof


View Profile WWW
June 22, 2013, 07:38:42 PM
 #261

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

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
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.
1481128632
Hero Member
*
Offline Offline

Posts: 1481128632

View Profile Personal Message (Offline)

Ignore
1481128632
Reply with quote  #2

1481128632
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481128632
Hero Member
*
Offline Offline

Posts: 1481128632

View Profile Personal Message (Offline)

Ignore
1481128632
Reply with quote  #2

1481128632
Report to moderator
1481128632
Hero Member
*
Offline Offline

Posts: 1481128632

View Profile Personal Message (Offline)

Ignore
1481128632
Reply with quote  #2

1481128632
Report to moderator
1481128632
Hero Member
*
Offline Offline

Posts: 1481128632

View Profile Personal Message (Offline)

Ignore
1481128632
Reply with quote  #2

1481128632
Report to moderator
piotr_n
Legendary
*
Offline Offline

Activity: 1498


aka tonikt


View Profile WWW
June 22, 2013, 07:42:08 PM
 #262

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 a bitcoin client written in Go, with some unique features.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
grau
Hero Member
*****
Offline Offline

Activity: 836


bits of proof


View Profile WWW
June 22, 2013, 07:43:02 PM
 #263

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 Offline

Activity: 1498


aka tonikt


View Profile WWW
June 22, 2013, 07:49:26 PM
 #264

OK, then sorry.
I should had read more Smiley

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 a bitcoin client written in Go, with some unique features.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
chrisrico
Hero Member
*****
Offline Offline

Activity: 496


View Profile
June 22, 2013, 10:55:04 PM
 #265

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
Hero Member
*****
Offline Offline

Activity: 836


bits of proof


View Profile WWW
June 23, 2013, 02:03:01 AM
 #266

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
Hero Member
*****
Offline Offline

Activity: 496


View Profile
June 23, 2013, 01:35:48 PM
 #267

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
Sr. Member
****
Offline Offline

Activity: 326


View Profile
June 25, 2013, 05:52:04 PM
 #268

so have deterministic wallets been implemented in the reference client?

just wondering how often I have to update my backups ...
simondlr
Sr. Member
****
Offline Offline

Activity: 424



View Profile
July 28, 2013, 02:36:44 PM
 #269

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?

Tip: BTC 1LbHAZv2mbZZMTu2k4xLcg8p5q4FatgkA7. Doge DFVzezccAsdq1LQwrPTDe1nMXKrL7aEUWY. FUNK: CXfgJPSbY1C5paVwiSHnm942tJPyK9xSfy
The Cypherfunks: a decentralized band & cryptocurrency. https://bitcointalk.org/index.php?topic=469407.0

Bitrated: https://www.bitrated.com/simondlr/
chrisrico
Hero Member
*****
Offline Offline

Activity: 496


View Profile
July 28, 2013, 03:27:05 PM
 #270

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
Hero Member
*****
Offline Offline

Activity: 836


bits of proof


View Profile WWW
July 28, 2013, 03:29:58 PM
 #271

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 Offline

Activity: 1498


aka tonikt


View Profile WWW
July 28, 2013, 03:52:26 PM
 #272

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 a bitcoin client written in Go, with some unique features.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
July 28, 2013, 04:03:49 PM
 #273

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
Legendary
*
qt
Offline Offline

Activity: 1036


View Profile WWW
July 28, 2013, 04:14:18 PM
 #274

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.


aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
piotr_n
Legendary
*
Offline Offline

Activity: 1498


aka tonikt


View Profile WWW
July 28, 2013, 04:43:18 PM
 #275

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 a bitcoin client written in Go, with some unique features.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
chrisrico
Hero Member
*****
Offline Offline

Activity: 496


View Profile
July 28, 2013, 06:53:55 PM
 #276

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 Offline

Activity: 1218



View Profile WWW
July 28, 2013, 07:22:38 PM
 #277

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 Offline

Activity: 1218



View Profile WWW
July 28, 2013, 07:26:18 PM
 #278

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
Sr. Member
****
Offline Offline

Activity: 424



View Profile
July 29, 2013, 08:30:57 AM
 #279

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?

Tip: BTC 1LbHAZv2mbZZMTu2k4xLcg8p5q4FatgkA7. Doge DFVzezccAsdq1LQwrPTDe1nMXKrL7aEUWY. FUNK: CXfgJPSbY1C5paVwiSHnm942tJPyK9xSfy
The Cypherfunks: a decentralized band & cryptocurrency. https://bitcointalk.org/index.php?topic=469407.0

Bitrated: https://www.bitrated.com/simondlr/
Abdussamad
Legendary
*
Offline Offline

Activity: 1218



View Profile WWW
July 29, 2013, 09:08:19 AM
 #280


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

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!