Topic: BIP32 wallets and Armorys implementation (Read 2600 times)

Okay. Frist of all, thank you very much for the clear and quick answer. And second: Whoa! I had not understood the chaincode to be public -- but as you explain it, it does make perfect sense.

What I learned here is that one must trade off the ability to generate child public keys from parent public keys against the ability to expose individual private keys (to e.g. import them into a mobile device for daily spending needs). And on a somewhat related note, now I also understand hardened keys in BIP32 a bit better...

Thanks!

To get PrivKey key X+1 from PrivKey X (and thus any X+n), you need, besides the private key, the chaincode, which is XOR'ed with PubKey X to produce the final multiplier. Thus you can compute forward if you have both, but not backwards (need PubKey X-1 to get the previous multiplier). Obviously I'm not considering a factorization breakthrough that weakens secp256k1.

If what you got from my post was that private keys were derived off of themselves without an outside multiplier (the chaincode), then I apologize for the poor wording. Obviously you need the chaincode. As a matter of fact, in older paper wallets, the chaincode was randomly generated (it's derived from the root key now), and thus the backups came with 2 values: the root key and the chaincode. Losing the chaincode then was as bad as losing the root key.

You should still consider your wallet compromised if you reveal a private key from its chain. The chaincode is considered public data. It lays unencrypted in all wallets (WO included), to extend the public key chain. Armory picks a new public key from the top of the chain every transaction as its change address. With enough transactions, your change will hit keys beyond the private key you revealed and your coins will be as good as gone.

As opposed to the original specification for BIP32, revealing an Armory chained private key doesn't give up your entire wallet so you still have time to move all 'em coins out.

Hi Goatpig,


That was a very scary statement from you. But on further inspection, it does not seem to be true?
Looking at https://github.com/etotheipi/BitcoinArmory/blob/master/cppForSwig/EncryptionUtils.cpp#L692 in
ComputeChainedPrivateKey() I see a scalar multiplication of the private key with a mushed-up chaincode value.

Unless the chaincode is disclosed or we figure out the inverse of a scalar multiplication in ECC
private keys should be safe. Would you concur, and lay my fears to rest? 

What I'd like to see in the new wallet format is for the "Receive Bitcoins" button to produce a new xpub, not a single address, and for address book entries to prefer an xpub over a single address.

It would enable the privacy-preserving use case described here: http://bitcoinism.blogspot.com/2013/07/reclaiming-financial-privacy-with-hd.html

Frankly I'm not sure where BIP32 is on todo list currently. What I know is that we won't be delving into that until the new wallet file format is out.


If you mean creating unrelated children seeds from a common root key, as BIP32 specifies, what I can tell you is we don't have a reason to deviate from BIP32 specification for now. As for possible "Armory flavored" features we may add on top of BIP32 wallets, can't tell just yet.

Thank you for your reply.
I believe I understand the current wallet, more or less. My workflow is acceptable, I can wait for some time for BIP32 support.
Will BIP32 be among the next features after the current big changes (memory and "internals"), or is it further down the list? Is it winter/spring, or "probably 2014"?
Yes, I am asking way too long into the future: Any guess if Armory/BIP32 will have several "wallets" from one seed?

Thanks a lot!

Ente

Armory doesn't support BIP32 yet. With that in mind I can answer a few of your questions based on the current version of Armory wallets:

1) For now there's coin control to keep your change addresses in check. Besides that point, can't really talk about something we haven't implemented yet ^_^;;

2) Armory private and public keys are derived from their previous iteration. Private key X is derived from private key X-1 and is used to build private key X+1. This is done through modulo operations and injecting extra entropy, so you cannot go from address X to address X-1, or X-n for that matter. No amount of leaked private keys can reveal an Armory root key.

Same goes with public keys. However, any private key can reveal all private keys beyond it: Since X gives X+1, then X can give X+n.

3) The chain code (root public key) isn't encrypted. I think Alan mentioned something about implementing a separate password to encrypt the public key and address comments in the wallet files. You'd have to confirm with him.

4) Assuming we implement that, 3) should answer it.

Dear Alan, Goatpig, devs and all,

I have a general wallet question which is partly about BIP32, and partly how Armory will implement it.

1) As I understand it, a seed creates a tree, where each branch itself may form a new branch or whole tree, so to speak. With that, will Armory allow to create multiple "wallets" from one single seed?
Right now I use several wallets, for bookkeeping and not mixing up inputs/outputs of different categories. So it would be important that change addresses and inputs only mix within one "wallet" or "wallettree" or whatever it would be called.

With security in mind:
2) From knowing the "public key seed" (or similar) and one single private key, all private keys may be reconstructed. I guess from the "public key seed" and one public address all public addresses may be reconstructed as well then.
Is there anything I have to take care of in reality? As long as I only use regular Armory functions (sending and receiving) and don't export stuff and don't share my wallet file, nothing evil should happen? Is there anything to extract from the wallet file without knowing the encryption password?
3) I.e., is the "public key seed" encrypted too?

And, finally:
4) In case I can haz several "wallets" in one file, from one seed: Can I have several, different passwords for each "wallet"?

To make sense of all this:
Imagine I now have three wallets. One is my unencrypted playmoney, one is my regular funds, one is my long-term savings (with watch-only wallet), one is funds I manage for mom and grandpa. I don't want to lose all of those in case a keylogger steals my one password. I don't want my long-term savings on my online computer altogether.
Will I be able to have all this from one seed, with the new wallet format?

This would be a huge selling point for me, and differentiate Armory even more as a pro wallet, focusing on security and advanced features.

Ente