Topic: Failed import of private key (Read 4220 times)

Ok, thank you.
I think I will try to do a fresh test project on github in the future, just to find out how it all functions.
I don't want to mess up your project.

You don't need experience coding, just know how to fork a repo, modify a couple .md and create a PR. It can all be done from github's webpage, graphically.

I encourage people to PR for 2 reasons:

1) Makes the community aware that the web portal is open source and up for contributions.

2) To get users involved in the process. This is a community project now, after all.

For reference, this is what the PR looked like for this particular change:

https://github.com/goatpig/BitcoinArmory/pull/140/files

Fairly simple. You shouldn't let the lingo deter you. This is a perfect opportunity to learn a little git-fu.

So a person has to have experience in developing to be able to have something added to a To Do list?  Why?

The majority of Bitcoin-clients accepts compressed keys, while Armory does not.

I have no experience in doing a PR.
Can you or somebody else please add this item to the To Do list?

Pull request. The website is open source, the code is available on the gh-pages branch. If you write a patch to modify the page and PR it, I will review it and merge.

What does "PR" mean?
There is no email-address available and I don't use IRC.

Feel free to PR the change to the TODO list.

Can this one be added to the To-Do List?
https://btcarmory.com/contribute/armory-todo/

I have run into the same problem trying to import private keys from Multibit and Blockchain.info

Other topics:
http://bitcoin.stackexchange.com/questions/24632/import-private-keys-from-multibit-into-armory
https://bitcointalksearch.org/topic/error-import-multibit-private-key-680355


The ones from Multibit that fail start with an L or K.
The single one from Multibit that succeeds starts with a 5 and is probably the oldest address I have.
The ones from Blockchain.info all fail and don't start with a L or K or 5.

I could use the software from https://github.com/pointbiz/bitaddress.org to convert the compressed private key to an uncompressed one, but that would render my funds unusable. An uncompressed private key has an uncompressed public address. My funds are at the compressed public address. On the uncompressed address my funds are zero: I tested this by importing the uncompressed private key in Armory and waited for the scan to complete.
Importing the hex-version of the private address reveals yet another public address. Could be an error from bitaddress.org ? 

P.S.: There is some sort of a memory-problem in Armory: Almost all of 16GB physical memory was being taken after the rescan. Returned to normal after shutting down Armory. Another private key import gave the same problem again.

When I enter the private keys from Blockchain.info in the bitaddress.org-software I get an error saying it is not a valid private key.

I was under the impression that the combination "public address / private key" was universal in Bitcoinland. That the same keys could be used in all clients. This is not the case however. 

I could transfer the funds to a new address generated in Armory. However, there is a possibility that Bitcoins will still be send to the old addresses.

Will Armory be able to import compressed private keys in the new version?

I have the same problem.
I used dumpprivkey of RPC API calls
 bitcoind getnewaddress
 bitcoind dumpprivkey

Quote

The private key you have entered is actually not valid for the elliptic curve used by Bitcoin (secp256k1). Almost any 64-character hex is a valid private key except for those greater than:

fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141

Please try a different private key.

bitcoind getinfo
{
    "version" : 90100,
    "protocolversion" : 70002,
    "walletversion" : 60000,
    "balance" : xxxxxxx,
    "blocks" : 333924,
    "timeoffset" : 0,
    "connections" : 3,
    "proxy" : "",
    "difficulty" : 40007470271.27126312,
    "testnet" : false,
    "keypoololdest" : 1416884277,
    "keypoolsize" : 101,
    "paytxfee" : 0.00000000,
    "errors" : ""
}

I believe you will reprodue the error

The only "workaround" is to wait for version 0.92-beta when we implement the new wallets and add native support for compressed keys.  There is just not any good ways to backport the old wallets to use them, that would be easier than just finishing the new wallet format (because there's such exhaustive testing that goes into changing wallet functionality like this, I'd prefer to just do it once).

Sorry, you'll just have to be patient!

Hey, I know this is old, but I'm trying to import a key created by Multibit into Armory, and it seems I have run into this same problem.

Is there a solution or workaround to import compressed keys ??

Cool. I'm looking forward to that new wallet format. Thanks for looking into this!

Yeah, that's more like it.  38 bytes is what I expect for compressed private keys:

0x80 + 32-byte private key + 0x01 + 4-byte checksum

The 0x01 indicates it's a compressed key, and the address is computed differently.  In a way that Armory doesn't understand yet.  Another thing that will be supported in the new wallet format when it's done.

I actually have a chunk of code in the import dialog that detects you put in a compressed private key, but apparently that is malfunctioning.  I just tried it, and it gave the too-big error instead of telling you that it's a format Armory doesn't support yet.  I'll spend a couple minutes looking for that.

Oops, I screwed up with the copy/paste. The real private key is: Kz9Eyg1rL27RnkUmmkofeyxdbWSn7ARQTdCiVKHLKxdhrMGNjTAp
I did some more digging and this is a "private key associated with a compressed public key": "Private keys associated with compressed public keys are 52 characters and start with a capital L or K."

https://en.bitcoin.it/wiki/Private_key

It's because that's not a standard private key format.  In fact, I'm not sure what format it's in, because it's 36 bytes, and unless I did something wrong, it does not look like the last 4 bytes are a checksum.   Therefore, Armory interpretted it as a 36-byte integer, which is clearly larger than that 32-byte integer shown there.

I'm not sure what's going on with that key...

I'm trying to import the private key from a Bitcoin Wallet address. The private key is as follows (don't worry, I'm deleting the address from my wallet): Kz9Eyg1rL27RnkUmmkofeyxdbWSn7ARQTdCiVKHLKxdhrMGNj

When I try to import that into my Armory wallet, I get the error message:


This imports fine into applications such as brainwallet.org, however, and even display the correct public address. The associated public address is: 1N6TrY9HKhwS4G1AmAB1V7BjckqD7BtT2F