How to get the xpub key of my armory wallet account?

[oldseven]

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.

[Carlton Banks]

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

[oldseven]

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

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?

[Carlton Banks]

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.

[oldseven]

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.

[Carlton Banks]

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.

[goatpig]

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

[Carlton Banks]

Ah, wasn't aware that armoryd uses a different wallet format.

[goatpig]

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.

[Carlton Banks]

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?

[goatpig]

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.

[Carlton Banks]

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.

[goatpig]

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

[Carlton Banks]

Are you saying I would have to brute force the hashing algorithm of that specific HMAC? I'm getting the picture in which case

[goatpig]

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).

[Carlton Banks]

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

[goatpig]

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.

[oldseven]

My wallet version is 1.35c. I can see a root key(18 words phrase). Maybe it's the chain code you mentioned.

[goatpig]

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.

[oldseven]

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?