<p>It seems like you are trying to import an address with <code>importprivkey</code>, which is absolutely incorrect. An address is not a private key and thus cannot be imported with <code>importprivkey</code>. Addresses have different data and will have different prefix letters than private keys. Looking at your code, the prefix for private keys will be <code>2</code> and those should be able to be imported into your wallet IF they did not already exist in the wallet (i.e. import to another wallet). This has nothing to do with your address prefix.</p>

CC BY-SA 4.0
2018-05-02T21:39:55.343Z
Hi Andrew.Yes i understand and yes the dumped private key from my wallet they start with 2...i have tried to import dumped private keys from other wallets and it does not import .same error..now regarding the paper wallet ..the paper wallet does not generate addresses in WIF format that start with 2 ..the paper wallet WIF format keys start with K L or J..the paper wallet link is here https://www.oracol.mobi/paperwallet/index.html by the way...i noticed the same with Litecoin ..the bumped private keys start with T but the imported privete keys startvwith 6 ...
Adrian Florea
CC BY-SA 4.0
2018-05-02T21:40:38.453Z
.so ho do i get my wallet to import private keys ? the link to the oracol-qt windows wallet is here https://uploadfiles.io/ilu34 ..again i really appreciate taking the time to look into this .I can send you a btc contribution if  you can point me in the right direction or help me solve this .Adrian
Adrian Florea
CC BY-SA 4.0
2018-05-03T00:15:47.180Z
P.S.- I had so far two people with good programming skills look into it and they could not find the solution ...
Adrian Florea
CC BY-SA 4.0
2018-05-03T02:58:24.030Z
Your paper wallet generator is using the wrong prefix, so of course it is wrong. You are using 0x109 which is invalid; the prefix byte is only one byte, this is more than one byte. The issue here is that you are overflowing the one byte, so instead of allowing the default behavior of adding 128 to the address prefix, you should set the prefix byte explicitly in all software.
Ava Chow
CC BY-SA 4.0
2018-05-03T04:34:02.200Z
Yes...so if i may "translate" this in my own terms it  means that because the sum  of 137 (x)  + 128 = 265 (or 0x109)  is > 256 ?? I thought of that but could not fin any reference what is the work around..if 0x109 is wrong what is  the correct way of calculating it or implementing it ( or as you mentioned - you should set the prefix byte explicitly in all software ) I used the info on this bitcointalk thread to calculate the values https://bitcointalk.org/index.php?topic=384093.10  Thanks again for helping with this .You have no idea how many nights i did not sleep trying to fix this thing
Adrian Florea
CC BY-SA 4.0
2018-05-03T04:37:39.957Z
P.S. - i do not expect you to write the set the prefix byte in all software but if you can give me an example of a line in the code and how to correct it using the right prefix byte value it will be enough to start me ..again many thanks!!!
Adrian Florea
CC BY-SA 4.0
2018-05-03T04:42:08.497Z
On https://github.com/OracolXor/Oracol-XOR-Coin/blob/master/src/base58.h#L403, change that line to set an explicit prefix value similar to how it is done above here: https://github.com/OracolXor/Oracol-XOR-Coin/blob/master/src/base58.h#L275. Just choose whatever private key prefix you want that is less than 256.
Ava Chow
CC BY-SA 4.0
2018-05-03T04:44:59.473Z
also am i to understand that because the dumped keys from my qt wallet start with 2 ( you mentioned that is the correct value previously) the only thing to fix really is the paper wallet ?? sorry to ask so many questions ...
Adrian Florea
CC BY-SA 4.0
2018-05-03T04:46:40.300Z
No, you need to fix both your coind/coin-qt and the paper wallet generator. Overflowing value is undefined behavior and it may not always result in the same value.
Ava Chow
CC BY-SA 4.0
2018-05-07T01:55:45.183Z
okay...so i have compiled a new oracol-qt and choose "W" ( base58.h - line 403 - PRIVKEY_ADDRESS = 0X49 )..The newly compiled wallet is syncronizing and dumping private keys that begin with letter "B" wich is consistent with the paper wallet that i modified replacing all ECKey.privateKeyPrefix == 0X49 as well ....i have now a working paper wallet that generates private keys beginning with "3" and privateWIF compressed beginning with "B" and when i sent the private keys to  "Wallet Details" they are showing all details and everything it looks normal on the paper wallet side.
Adrian Florea
CC BY-SA 4.0
2018-05-07T02:01:11.413Z
The problem is..when i try to import the paperwallet keys the oracol-qt wallet is generating a MinGW Runtime Assertion error - Assertion failed ..file src\key.cpp, Line 313   Expression: fValid.
Adrian Florea
CC BY-SA 4.0
2018-05-07T02:03:14.563Z
if i ignore the error it ends up with an error code - Private key outside allowed range (code - 5)
Adrian Florea
CC BY-SA 4.0
2018-05-07T02:07:00.050Z
Line 313 in key.cpp is :      assert(fValid);
Adrian Florea
CC BY-SA 4.0
2018-05-07T02:08:18.123Z
I feel that i am very close to nail it now ..but again i need your expert opinion please.I really appreciate your help again.
Adrian Florea
CC BY-SA 4.0
2018-05-07T03:55:49.003Z
It s working !!! Got it to work finally ..the right value was 201
Adrian Florea
CC BY-SA 4.0
2018-05-02T18:23:28.997Z
2018-05-02T18:23:28.997Z
Ava Chow
<p>I have cloned an older version of Litecoin using a tutorial. I chose the starting letter for the public addresses to be lower case "x". Everything is working fine except for <code>importprivkey</code>. It will always gives <code>error 5 wrong format</code>. I tried using paper wallet generated keys (paper wallet generated private keys starting with addreses K,L and J) while the windows-qt wallet <code>dumprivkey</code> dumps private keys starting with nr 2 but that can not be imported as well. Is it because of letter x? FYI I have compiled a clone using letter "L" (same like Litecoin) and everything works so i doubt there is a coding error.</p>

CC BY-SA 3.0
2018-05-01T19:40:10.967Z
What tutorial did you follow? What code have you changed. This is most definitely a coding error as you probably did not change something that you needed to.
Ava Chow
CC BY-SA 4.0
2018-05-02T16:27:45.510Z
Hi Andrew.The cone process involved generating a new Merkle root,changing network identifiers,etc.As I said everything is working good and up to date about 22 million coins were mined..we have blockchain explorer..mining pool etc..but the importprivkey will not work.However when I changed the letter x with L and started a separate test blockchain importing private keys worked...here is the github code https://github.com/OracolXor/Oracol-XOR-Coin  if you want to have a look.At this point i am prepared to pay for your time if you believe you can solve the problem.Thanks for the reply.Adrian
Adrian Florea
<altcoin><private-key-import>
Importprivkey problem for Litecoin clone
Adrian Florea
# Importprivkey problem for Litecoin clone

(Asked by: username_0 on 2018-05-01)

I have cloned an older version of Litecoin using a tutorial. I chose the starting letter for the public addresses to be lower case "x". Everything is working fine except for `importprivkey`. It will always gives `error 5 wrong format`. I tried using paper wallet generated keys (paper wallet generated private keys starting with addreses K,L and J) while the windows-qt wallet `dumprivkey` dumps private keys starting with nr 2 but that can not be imported as well. Is it because of letter x? FYI I have compiled a clone using letter "L" (same like Litecoin) and everything works so i doubt there is a coding error.

**Tags:** altcoin, private-key-import

> **Comments:**
> **username_1**: What tutorial did you follow? What code have you changed. This is most definitely a coding error as you probably did not change something that you needed to.  
> **username_0**: Hi Andrew.The cone process involved generating a new Merkle root,changing network identifiers,etc.As I said everything is working good and up to date about 22 million coins were mined..we have blockchain explorer..mining pool etc..but the importprivkey will not work.However when I changed the letter x with L and started a separate test blockchain importing private keys worked...here is the github code https://github.com/OracolXor/Oracol-XOR-Coin  if you want to have a look.At this point i am prepared to pay for your time if you believe you can solve the problem.Thanks for the reply.username_0  

---

## 1 answers

### Answer by username_1 on 2018-05-02. Score: 0

It seems like you are trying to import an address with `importprivkey`, which is absolutely incorrect. An address is not a private key and thus cannot be imported with `importprivkey`. Addresses have different data and will have different prefix letters than private keys. Looking at your code, the prefix for private keys will be `2` and those should be able to be imported into your wallet IF they did not already exist in the wallet (i.e. import to another wallet). This has nothing to do with your address prefix.

> **Comments:**
> **username_0**: Hi Andrew.Yes i understand and yes the dumped private key from my wallet they start with 2...i have tried to import dumped private keys from other wallets and it does not import .same error..now regarding the paper wallet ..the paper wallet does not generate addresses in WIF format that start with 2 ..the paper wallet WIF format keys start with K L or J..the paper wallet link is here https://www.oracol.mobi/paperwallet/index.html by the way...i noticed the same with Litecoin ..the bumped private keys start with T but the imported privete keys startvwith 6 ...  
> **username_0**: .so ho do i get my wallet to import private keys ? the link to the oracol-qt windows wallet is here https://uploadfiles.io/ilu34 ..again i really appreciate taking the time to look into this .I can send you a btc contribution if  you can point me in the right direction or help me solve this .username_0  
> **username_0**: P.S.- I had so far two people with good programming skills look into it and they could not find the solution ...  
> **username_1**: Your paper wallet generator is using the wrong prefix, so of course it is wrong. You are using 0x109 which is invalid; the prefix byte is only one byte, this is more than one byte. The issue here is that you are overflowing the one byte, so instead of allowing the default behavior of adding 128 to the address prefix, you should set the prefix byte explicitly in all software.  
> **username_0**: Yes...so if i may "translate" this in my own terms it  means that because the sum  of 137 (x)  + 128 = 265 (or 0x109)  is > 256 ?? I thought of that but could not fin any reference what is the work around..if 0x109 is wrong what is  the correct way of calculating it or implementing it ( or as you mentioned - you should set the prefix byte explicitly in all software ) I used the info on this bitcointalk thread to calculate the values https://bitcointalk.org/index.php?topic=384093.10  Thanks again for helping with this .You have no idea how many nights i did not sleep trying to fix this thing  
> **username_0**: P.S. - i do not expect you to write the set the prefix byte in all software but if you can give me an example of a line in the code and how to correct it using the right prefix byte value it will be enough to start me ..again many thanks!!!  
> **username_1**: On https://github.com/OracolXor/Oracol-XOR-Coin/blob/master/src/base58.h#L403, change that line to set an explicit prefix value similar to how it is done above here: https://github.com/OracolXor/Oracol-XOR-Coin/blob/master/src/base58.h#L275. Just choose whatever private key prefix you want that is less than 256.  
> **username_0**: also am i to understand that because the dumped keys from my qt wallet start with 2 ( you mentioned that is the correct value previously) the only thing to fix really is the paper wallet ?? sorry to ask so many questions ...  
> **username_1**: No, you need to fix both your coind/coin-qt and the paper wallet generator. Overflowing value is undefined behavior and it may not always result in the same value.  
> **username_0**: okay...so i have compiled a new oracol-qt and choose "W" ( base58.h - line 403 - PRIVKEY_ADDRESS = 0X49 )..The newly compiled wallet is syncronizing and dumping private keys that begin with letter "B" wich is consistent with the paper wallet that i modified replacing all ECKey.privateKeyPrefix == 0X49 as well ....i have now a working paper wallet that generates private keys beginning with "3" and privateWIF compressed beginning with "B" and when i sent the private keys to  "Wallet Details" they are showing all details and everything it looks normal on the paper wallet side.  
> **username_0**: The problem is..when i try to import the paperwallet keys the oracol-qt wallet is generating a MinGW Runtime Assertion error - Assertion failed ..file src\key.cpp, Line 313   Expression: fValid.  
> **username_0**: if i ignore the error it ends up with an error code - Private key outside allowed range (code - 5)  
> **username_0**: Line 313 in key.cpp is :      assert(fValid);  
> **username_0**: I feel that i am very close to nail it now ..but again i need your expert opinion please.I really appreciate your help again.  
> **username_0**: It s working !!! Got it to work finally ..the right value was 201  

---

