Topic: How to get the xpub key of my armory wallet account? (Read 892 times)
My wallet version is 1.35c. I can see a root key(18 words phrase). Maybe it's the chain code you mentioned.
It is not, that's just the root key. Let me get this straight, are you trying to implement Armory's derivation scheme, or are you under the misconception that a BIP32 compliant implementation can reproduce it? Because it cannot.
I don't know the concept of ChainCode. Can you explain about it?
My wallet version is 1.35c. I can see a root key(18 words phrase). Maybe it's the chain code you mentioned.
It is not, that's just the root key. Let me get this straight, are you trying to implement Armory's derivation scheme, or are you under the misconception that a BIP32 compliant implementation can reproduce it? Because it cannot.
My wallet version is 1.35c. I can see a root key(18 words phrase). Maybe it's the chain code you mentioned.
You could always create a new wallet and gradually migrate your funds there. Maybe that's a feature to think about actually, the ability to designate a wallet as the recipient of change.
Yikes, that doesn't sound like a good trade off. I'll stick with the risk of the toner on my paper backups degrading, I think
Pretty much. You'd have to use the HMAC message field as a nonce to try and hash your private root key into your chaincode. Then you'd have to convince me to replace the current message field with yours (or maintain your own fork for this purpose).
Are you saying I would have to brute force the hashing algorithm of that specific HMAC? I'm getting the picture in which case 
No. In the one case (1.35) the chaincode is just a random number. In the other (1.35c), the chaincode is deterministic.
I guess it's not a hard no if you evaluate that it is economically justifiable to try and break the HMAC function for this purpose. Otherwise, just no =D
I guess it's not a hard no if you evaluate that it is economically justifiable to try and break the HMAC function for this purpose. Otherwise, just no =D
Could a 1.35 wallet be converted to the 1.35c format? Just for the sake of the half length key info. Sounds like a useful change.
Prior to 1.35, the chaincode was a PRNG pull on its own. Alan eventually realized there was no diminishing security in deriving the chaincode deterministically through a HMAC, cutting the backup string length in half, which is why he moved to that format eventually.
Reducing the size of the backup string also reduces the surface for errors (damaged print out, manuscript strings, memorized sequences), so overall it's a good change.
There is no difference in security in either format, and Armory will always support backups from any format it has supported in the past.
Reducing the size of the backup string also reduces the surface for errors (damaged print out, manuscript strings, memorized sequences), so overall it's a good change.
There is no difference in security in either format, and Armory will always support backups from any format it has supported in the past.
I'm showing my age here
Perhaps OT, but is 1.35 ok for at least a few releases? And, that's the only practical difference between 1.35 and 1.35c, right?
Perhaps OT, but is 1.35 ok for at least a few releases? And, that's the only practical difference between 1.35 and 1.35c, right?
Ah, wasn't aware that armoryd uses a different wallet format.
This is the backup format across all iterations of Armory since 0.90.
If you only have 2 lines in your backup, that's a 1.35c. If you have 4, that's a 1.35 and the last 2 lines are your chaincode. The wallet version should be written on the paperback up.
Ah, wasn't aware that armoryd uses a different wallet format.
There's no chaincode apparent on 1.35c wallets, since it is derived deterministically from the root private key in that version:
https://github.com/goatpig/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L3489
https://github.com/goatpig/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L3489
It would be there, if you're doing it right. You must be doing something wrong. "Print Paper Backup" is a very simple, long-term stable function in Armory, and it's very diffcult to get it wrong.
Explain in exhaustive detail exactly what you're doing to achieve the failure.
Explain in exhaustive detail exactly what you're doing to achieve the failure.
The second key on your paper wallet backup is headed with the word "Chain Code". That key is the Chain Code, or extended public key in the BIP32 parlance.
I have no a printer so I output it as a pdf file. And I still cannot found the Chain Code.
The second key on your paper wallet backup is headed with the word "Chain Code". That key is the Chain Code, or extended public key in the BIP32 parlance.
1. It's represented by the Chain Code portion of your wallet backup (not sure how that's represented in the digital wallet, but it's clearly discernible on paper wallets)
2. Currently slated for version 0.97
2. Currently slated for version 0.97
Thanks. But when I tried to backup my wallet using "Make paper backup", I did't found the Chain Code portion you mentioned.
Can you make it clear?
1. It's represented by the Chain Code portion of your wallet backup (not sure how that's represented in the digital wallet, but it's clearly discernible on paper wallets)
2. Currently slated for version 0.97
2. Currently slated for version 0.97
I'm using straight server which is a payment gateway server. It needs a BIP32 xpub key. But I know armory doesn't support
BIP32. But I still want to know:
1.Where the Extended pulick key of my wallet like blockchain wallet or other wallet.
2.When will armory support BIP32 or BIP44?
Thanks.
BIP32. But I still want to know:
1.Where the Extended pulick key of my wallet like blockchain wallet or other wallet.
2.When will armory support BIP32 or BIP44?
Thanks.
Jump to: