so have deterministic wallets been implemented in the reference client?
just wondering how often I have to update my backups ...
Topic: Deterministic wallets - page 3. (Read 48264 times)
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.
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.
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.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
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.
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.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
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.
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
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
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. 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
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
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
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". 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.
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.
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". 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.
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". 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", in this case Peter, can BIP32 be changed to a status of Final on the wiki now?
I've made it 'Accepted' by now, as per BIP 01, 'Final' requires a reference implementation...
What makes an implementation a reference implementation?
I understand the importance of the "reference implementation" for things related to consensus on the ledger.
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.
Peter, can BIP32 be changed to a status of Final on the wiki now?
I've made it 'Accepted' by now, as per BIP 01, 'Final' requires a reference implementation...
What makes an implementation a reference implementation?
Otherwise all the BIP ceremony would not make any sense, since there had been different unofficial deterministic wallet implementations, and pretty 'Active' ones, for like years already.
It's actually quite funny because this topic is already over 2 years old, and let's be serious; implementing a deterministic wallet seems more like a 2 month job. Maybe even 2 days... It's actually easier than the current wallet.
Unless you work for a bank - then of course, you need a flowchart, even for going to a bathroom
It is sort of a bank though, at the current stage. It should be split into independent components, so bugs in one part would not affect the core (meaning: the blockchain protocol) - then it would be faster to improve things.
Peter, can BIP32 be changed to a status of Final on the wiki now?
I've made it 'Accepted' by now, as per BIP 01, 'Final' requires a reference implementation...
What makes an implementation a reference implementation?
I have an implementation here, that passes the test vectors and other tests:
https://github.com/bitsofproof/supernode/blob/1.1/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java
Here is the code running the tests:
https://github.com/bitsofproof/supernode/blob/1.1/api/src/test/java/com/bitsofproof/supernode/api/ExtendedKeyTest.java
Here are the test vectors in JSON format for the above test:
https://github.com/bitsofproof/supernode/blob/1.1/api/src/test/resources/BIP32.json
I've made it 'Accepted' by now, as per BIP 01, 'Final' requires a reference implementation...
Great, thanks! It's not showing up for me yet, but that may just be how the wiki works.
Peter, can BIP32 be changed to a status of Final on the wiki now?
I've made it 'Accepted' by now, as per BIP 01, 'Final' requires a reference implementation...
Peter, can BIP32 be changed to a status of Final on the wiki now?
Now Peter, where are those test vectors!? 
Have a look
Peter and Timo, it was great getting to meet both of you at the conference!
Now Peter, where are those test vectors!?
Now Peter, where are those test vectors!?
Jump to: