Convert satoshi wallet.dat to amory X1Y2Z3.wallet

[payb.tc]

sorry i missed the memo, is there an easy conversion tool for importing old wallet.dat files into armory?

the only way i know of currently is dumping keys with pywallet and then importing, but this seems like a pain especially with a very large wallet.

[1715231204]

1715231204

[1715231204]

1715231204

[etotheipi]

sorry i missed the memo, is there an easy conversion tool for importing old wallet.dat files into armory?

the only way i know of currently is dumping keys with pywallet and then importing, but this seems like a pain especially with a very large wallet.

That actually won't work either, because the current wallet format of Armory (and underlying library code) doesn't accommodate compressed public keys.  Trying to import them will just cause errors.  As I keep mentioning the new wallet format:  it will handle compressed public keys -- in fact it will use them by default.  But until then, the support isn't there.

For now you're just going to have to send the funds through the blockchain to get it to the new wallet.  I recognize not everyone finds this solution satisfactory (they'd like to take some addresses with them), but it's the best I can do for you until the new wallets are complete (which unfortunately have become slightly lower priority in favor of upgrading Armory's resource management).

[payb.tc]

sorry i missed the memo, is there an easy conversion tool for importing old wallet.dat files into armory?

the only way i know of currently is dumping keys with pywallet and then importing, but this seems like a pain especially with a very large wallet.

That actually won't work either, because the current wallet format of Armory (and underlying library code) doesn't accommodate compressed public keys.  Trying to import them will just cause errors.  As I keep mentioning the new wallet format:  it will handle compressed public keys -- in fact it will use them by default.  But until then, the support isn't there.

For now you're just going to have to send the funds through the blockchain to get it to the new wallet.  I recognize not everyone finds this solution satisfactory (they'd like to take some addresses with them), but it's the best I can do for you until the new wallets are complete (which unfortunately have become slightly lower priority in favor of upgrading Armory's resource management).

thanks for the quick reply... but what do public keys have to do with anything?

dumping a list of private keys and importing those private keys into armory won't work?

[ErebusBat]

Couldn't you use brainwallet.org to convert the key then import it?   Obviously this wouldn't work with a ton of keys, but for one offs like vanity addresses it should be sufficient.

[etotheipi]

sorry i missed the memo, is there an easy conversion tool for importing old wallet.dat files into armory?

the only way i know of currently is dumping keys with pywallet and then importing, but this seems like a pain especially with a very large wallet.

That actually won't work either, because the current wallet format of Armory (and underlying library code) doesn't accommodate compressed public keys.  Trying to import them will just cause errors.  As I keep mentioning the new wallet format:  it will handle compressed public keys -- in fact it will use them by default.  But until then, the support isn't there.

For now you're just going to have to send the funds through the blockchain to get it to the new wallet.  I recognize not everyone finds this solution satisfactory (they'd like to take some addresses with them), but it's the best I can do for you until the new wallets are complete (which unfortunately have become slightly lower priority in favor of upgrading Armory's resource management).

thanks for the quick reply... but what do public keys have to do with anything?

dumping a list of private keys and importing those private keys into armory won't work?

Since a bitcoin address is the hash of the public key, if you use a compressed public key you get a different address than using the same, uncompressed public key.  As such, the same private key can be associated with two different addresses (one for compressed and uncompressed).  Right now, Armory would compute the wrong address, even if it could uncompress the keys.

The correct behavior is not super-complicated once you have the code to compress and uncompress the keys, it's just that the old wallet format and code/algorithms have been very thoroughly tested and are rock-solid.  I didn't want to risk breaking that to support this... especially when I'm soon going to have a new wallet format that will have to go through all that testing again, anyway... might as well do it all at once.

[payb.tc]

sorry i missed the memo, is there an easy conversion tool for importing old wallet.dat files into armory?

the only way i know of currently is dumping keys with pywallet and then importing, but this seems like a pain especially with a very large wallet.

That actually won't work either, because the current wallet format of Armory (and underlying library code) doesn't accommodate compressed public keys.  Trying to import them will just cause errors.  As I keep mentioning the new wallet format:  it will handle compressed public keys -- in fact it will use them by default.  But until then, the support isn't there.

For now you're just going to have to send the funds through the blockchain to get it to the new wallet.  I recognize not everyone finds this solution satisfactory (they'd like to take some addresses with them), but it's the best I can do for you until the new wallets are complete (which unfortunately have become slightly lower priority in favor of upgrading Armory's resource management).

thanks for the quick reply... but what do public keys have to do with anything?

dumping a list of private keys and importing those private keys into armory won't work?

Since a bitcoin address is the hash of the public key, if you use a compressed public key you get a different address than using the same, uncompressed public key.  As such, the same private key can be associated with two different addresses (one for compressed and uncompressed).  Right now, Armory would compute the wrong address, even if it could uncompress the keys.

hmm... didn't this behaviour change in the satoshi client at some point?

i.e. are you assuming that my wallet.dat is using compressed public keys when in fact it could be from an era before that was the default?

i wouldn't know how to check


also, why would armory be uncompressing anything, if all i'm giving it are private keys.... are private keys compressed?

sorry i'm not getting this yet

[etotheipi]

sorry i missed the memo, is there an easy conversion tool for importing old wallet.dat files into armory?

the only way i know of currently is dumping keys with pywallet and then importing, but this seems like a pain especially with a very large wallet.

That actually won't work either, because the current wallet format of Armory (and underlying library code) doesn't accommodate compressed public keys.  Trying to import them will just cause errors.  As I keep mentioning the new wallet format:  it will handle compressed public keys -- in fact it will use them by default.  But until then, the support isn't there.

For now you're just going to have to send the funds through the blockchain to get it to the new wallet.  I recognize not everyone finds this solution satisfactory (they'd like to take some addresses with them), but it's the best I can do for you until the new wallets are complete (which unfortunately have become slightly lower priority in favor of upgrading Armory's resource management).

thanks for the quick reply... but what do public keys have to do with anything?

dumping a list of private keys and importing those private keys into armory won't work?

Since a bitcoin address is the hash of the public key, if you use a compressed public key you get a different address than using the same, uncompressed public key.  As such, the same private key can be associated with two different addresses (one for compressed and uncompressed).  Right now, Armory would compute the wrong address, even if it could uncompress the keys.

hmm... didn't this behaviour change in the satoshi client at some point?

i.e. are you assuming that my wallet.dat is using compressed public keys when in fact it could be from an era before that was the default?

i wouldn't know how to check

It switched over in satoshi client version 0.6.  That was a about a year ago.

[payb.tc]

It switched over in satoshi client version 0.6.  That was a long time ago

ohhohoho, pretty sure this wallet.dat is from a 0.4.x

[payb.tc]

Right now, Armory would compute the wrong address, even if it could uncompress the keys.

why would armory be uncompressing anything, if all i'm giving it are private keys.... are private keys compressed?

sorry i'm not getting this yet

[etotheipi]

It switched over in satoshi client version 0.6.  That was a long time ago

ohhohoho, pretty sure this wallet.dat is from a 0.4.x

I used to have a "Bitcoin-Qt Wallet Migration Tool".  I finished it and integrated it about a month before the Bitcoin-Qt devs made the change.  I tried to keep the migration tool in there for users who would benefit from it, but I ended up with users complaining about how Armory was broken because it claimed that they could migrate their wallet, but it never worked.  It was much simpler and more-pleasant to just remove it altogether than to try to explain the complex situations in which it will work, and that situation is actually quite rare by now.

[etotheipi]

Right now, Armory would compute the wrong address, even if it could uncompress the keys.

why would armory be uncompressing anything, if all i'm giving it are private keys.... are private keys compressed?

sorry i'm not getting this yet

If your wallet was created after Satoshi client version 0.6, and you export your private key and import it into Armory, you will get a different address. 

In fact, you won't even be able to import it, because the core devs added an extra 0x01 byte to the end of these private keys as a way to distinguish that they are supposed to use compressed public keys (and thus will have a different address).  Armory will not recognize the 33-byte private keys, and will generate the wrong addresses. 

[payb.tc]

Couldn't you use brainwallet.org to convert the key then import it?   Obviously this wouldn't work with a ton of keys, but for one offs like vanity addresses it should be sufficient.

thanks, might try this with bitaddress.org

[etotheipi]

Couldn't you use brainwallet.org to convert the key then import it?   Obviously this wouldn't work with a ton of keys, but for one offs like vanity addresses it should be sufficient.

thanks, might try this with bitaddress.org

Vanitygen should still be using uncompressed keys, and most other programs still use uncompressed public keys.  I noticed in the bitcoinj 0.7 release notes yesterday, that they just started using compressed public keys by default.  All apps will be moving in that direction, they just haven't yet. 

[opentoe]

If you can't import your satoshi wallet with the armory then why does the armory rely on the satoshi client to even run? Why would I want to deal with another program on top of another that already works? I'm a little confused here on what this client is then if it can't run by itself and solely relies on another client. Is that correct?

Because I'm trying out new clients and this was one of them.

[etotheipi]

If you can't import your satoshi wallet with the armory then why does the armory rely on the satoshi client to even run? Why would I want to deal with another program on top of another that already works? I'm a little confused here on what this client is then if it can't run by itself and solely relies on another client. Is that correct?

Because I'm trying out new clients and this was one of them.

Well, take a look around the program.  Especially in "Expert Usermode".  

-- Offline wallet interface
-- Watching-only wallets with offline wallets
-- Intuitive interface for sending from offline wallets
-- Deterministic wallets (only-once-ever-needed backups)
-- Print your backups directly to paper
-- Multiple wallet management
-- Key importing and sweeping (single keys or batches)
-- Coin control
-- Custom Change Addresses
-- Create Clickable Payment Request to copy into emails/webpages

And you turn it into a downside, but the fact that uses Bitcoin-Qt/bitcoind is a good thing if you are looking for ultimate security.  Multibit and Electrum focus on convenience, at the expense of security.  The gap isn't huge, but if you're dealing with large amounts of money, why wouldn't you take an extra step to get the extra security?

[Super T]

Sorry for reviving this - but I was hoping to migrate my bitcoin-qt wallet into armory, just hit the problem described below and found my way here, any update on whether this is now possible?

[justmyname]

Sorry for reviving this - but I was hoping to migrate my bitcoin-qt wallet into armory, just hit the problem described below and found my way here, any update on whether this is now possible?

You can simply send the coins as normal to an Armory address. Just can't import the keys directly. Unless I'm mistaken.   

[payb.tc]

As I keep mentioning the new wallet format:  it will handle compressed public keys -- in fact it will use them by default.  But until then, the support isn't there.

the million dollar question... when is this new wallet format coming out? or when did it come out?

[etotheipi]

As I keep mentioning the new wallet format:  it will handle compressed public keys -- in fact it will use them by default.  But until then, the support isn't there.

the million dollar question... when is this new wallet format coming out? or when did it come out?

Starting a company and overhauling the blockchain engine has pretty much destroyed all the other priorities.  But both those operations are rapidly nearing completion and I'll be able to get back to the wallet development.  I'm looking forward to it as much as others are