Author

Topic: Altcoin branch of Litecoin 16.3 creates new addresses but has no private key (Read 117 times)

jr. member
Activity: 260
Merit: 6
The wallet isn't locked.  Rescan doesn't produce the desired result.

This situation can also be recreated by changing a single line of code in the Litecoin v 16.3:

Code:
base58Prefixes[PUBKEY_ADDRESS] = std::vector(1,47);

If that is changed to, say, "(1,50)" this problem exists there as well.  All it's supposed to do is impact how the public keys are displayed; what number or letter they are preceded by.  Yet, for some reason, changing it results in this other misbehaviour.
legendary
Activity: 1584
Merit: 1280
Heisenberg Design Services
  Then I go to the console and type "dumpprivkey
" and it responds with "Private key for address
is not known".
The function is returned as "private key not found" only when you type the dumpprivkey in console while the wallet is locked. You need to unlock your qt wallet before typing the dumpprivkey in the console. You can unlock your wallet by typing

Code:
walletpassphrase "passphrase" [unlock time in sec]

Once after this function has been executed, you can proceed with dumpprivkey [address] which will give you the private key of the address. 

Note that regarding tracking of transactions, consider my previous reply on your earlier thread to use the --rescan function.
jr. member
Activity: 260
Merit: 6
Branching off litecoin 16.3 I compiled a wallet that seems to work fine until I tell it to make a "new" address.  It appears to creates one.  Then I go to the console and type "dumpprivkey
" and it responds with "Private key for address
is not known".  It also doesn't track any of the transactions for the addresses its claims to create.  If I have the wallet open an existing wallet.dat file, it works fine with existing addresses.  If, even with an existing wallet.dat file I tell it to generate a new address, it doesn't know the private key for that address via "dumpprivkey".  However, "dumpprivkey" does work for the existing addresses in the wallet.dat file.  I don't recall changing any code relevant to this behaviour.  Anyone have any ideas or what I could look at to try and resolve this?
Jump to: