“Can’t generate a change-address key. No keys in the internal keypool and can’t generate any keys.” #16091

issue redblade7 openend this issue on May 26, 2019
  1. redblade7 commented at 1:54 am on May 26, 2019: none

    Hi,

    I am trying to make a purchase but am unable to. bitcoin-qt gives the error:

    “Can’t generate a change-address key. No keys in the internal keypool and can’t generate any keys.”

    When I try to Google this error, I only come up with mirrors of Bitcoin’s source code. debug.log doesn’t show any additional information.

    No money is sent and there are no new transactions with the wallet.

    The wallet is encrypted and unlocked. Using bitcoin-qt v0.18.0 on Gentoo Linux. Tried both the third-party layman version and compiling the official bitcoincore.org source and both fail to let me make a purchase. The last transaction on the wallet was in December 2018 and whatever the latest version of bitcoin-qt was back then.

  2. redblade7 commented at 7:33 am on May 26, 2019: none

    I was able to do a send and receive just fine with Bitcoin Testnet, same version.

    If this helps, the Bitcoin Testnet uses an HD wallet, while the mainnet wallet I’m having problems with is older and non-HD. Both are encrypted.

  3. MarcoFalke commented at 1:49 pm on May 26, 2019: member
    Can you do a keypoolrefill RPC in the debug console?
  4. redblade7 commented at 7:47 pm on May 26, 2019: none
    I ran keypoolrefill (no parameters) on Testnet and Mainnet and both return “null” so I guess so
  5. redblade7 commented at 5:33 pm on May 27, 2019: none
    After downgrading to 0.17.1 I was able to make a purchase with no errors.
  6. promag commented at 9:23 pm on June 11, 2019: member
    So you couldn’t create the transaction with 0.18.0 even after keypoolrefill?
  7. redblade7 commented at 9:53 pm on June 11, 2019: none
    No, I wasn’t able to.
  8. byt3farm commented at 8:24 am on June 26, 2019: none

    Hello Same here. Just wanted to send bitcoins and got the “Can’t generate a change-address key. No keys in the internal keypool and can’t generate any keys.” Error Message. keypoolrefill (returned null) but didn’t fix anything. Downgrade to version v0.17.1 (64-bit) fixed the problem.

    To make a transaction is a core feature of this application, right? Quite uncool experience when you really need to do a transfer but you can’t because the latest software is broken somehow, should be fixed asap!

  9. darosior commented at 1:46 pm on July 7, 2019: member

    @byt3farm

    Hello

    Hello

    Just wanted to send bitcoins and got the “Can’t generate a change-address key. No keys in the internal keypool and can’t generate any keys.” Error Message. keypoolrefill (returned null) but didn’t fix anything. Downgrade to version v0.17.1 (64-bit) fixed the problem.

    Which command did you use ? sendtoaddress ? I cannot reproduce using v0.18.0 on testnet, and I cannot inspect efficiently without reproduce instructions.

    To make a transaction is a core feature of this application, right? Quite uncool experience when you really need to do a transfer but you can’t because the latest software is broken somehow, should be fixed asap!

    It is, that’s why we need you to add instructions and details so that we can reproduce and try to fix it. Here are some questions which answers would help for debuging :

    • What RPC command did you use ?
    • Have you been using your wallet for some time ? / Did it happen before ? / Did it work for some time using 0.18 ?
    • Does it works with a fresh wallet ? @redblade7 if you can answer some of the above questions, it could help too
  10. redblade7 commented at 7:41 pm on July 7, 2019: none

    I did not have any problems with a testnet HD wallet (see second comment). The wallet having problems goes back to 2015 and is non-HD.

    To make the transaction, I used the GUI, not an RPC command.

  11. byt3farm commented at 6:25 am on July 8, 2019: none

    Hello

    • I am using an old wallet (maybe from 2011?)
    • I just recently encrypted the wallet (before it was not encrypted at all)
    • My last transaction before this error occured is more than 1 Year ago
    • I never saw this error ever before
    • I did not try with a fresh wallet
    • I did not use any RPC commands, I was using the GUI and didnt do anything special at all
  12. darosior commented at 10:34 am on July 8, 2019: member
    Ok so it seems to be related to pre-HD split : could you try to start v0.18 with -upgradewallet ?
  13. redblade7 commented at 7:45 pm on July 8, 2019: none
    Unfortunately I can’t upgrade my wallet because of bug #14422
  14. darosior commented at 11:04 pm on July 8, 2019: member
    I’ll give a look to make possible to upgrade encrypted wallets.
  15. darosior commented at 12:52 pm on July 9, 2019: member
    Ok, I’ve succesfully reproduced (using v0.11.1 to create the wallet, then v0.18, and encrypted it) and upgraded. :tada:
  16. mattpopovich commented at 5:03 am on August 28, 2019: none

    Can confirm having the same issues as @redblade7 on v0.18.0 and still on v0.18.1. Same error: “Can’t generate a change-address key. No keys in the internal keypool and can’t generate any keys.” And can also not use the -upgradewallet flag due to bug #14422

    Wallet created around v0.11.1 and encrypted some time after that, ~v0.15.0 or so.

    Let me know if you need anything from me to help troubleshoot/reproduce.

  17. Delitants commented at 7:32 pm on September 24, 2019: none
    Still persists same problem.
  18. MarcoFalke commented at 9:00 pm on October 11, 2019: member

    Are there steps to reproduce?

    I tried generating a wallet with 0.11.1, encrypting it with 0.18.1, and then calling getnewaddress and getrawchangeaddress. No issue on my side.

    0wget --no-clobber "https://bitcoincore.org/bin/bitcoin-core-0.11.1/bitcoin-0.11.1-linux64.tar.gz"
    1echo "1e2c16e1dca75112e20f2cfb1acbdc45eb6fd4c6b49919fd64b45d960531abe2  bitcoin-0.11.1-linux64.tar.gz" | sha256sum -c
    2tar -xvf "bitcoin-0.11.1-linux64.tar.gz"
    3mkdir -p $(pwd)/testnet_datadir/
    4echo "Running bitcoind. Hit CTRL+C after the wallet has been generated."
    5bitcoin-0.11.1/bin/bitcoind -testnet -noconnect -nolisten -datadir=$(pwd)/testnet_datadir/ -rpcuser=u -rpcpassword=p -keypool=10
    
    0wget --no-clobber "https://bitcoincore.org/bin/bitcoin-core-0.18.1/bitcoin-0.18.1-x86_64-linux-gnu.tar.gz"
    1echo "600d1db5e751fa85903e935a01a74f5cc57e1e7473c15fd3e17ed21e202cfe5a  bitcoin-0.18.1-x86_64-linux-gnu.tar.gz" | sha256sum -c
    2tar -xvf "bitcoin-0.18.1-x86_64-linux-gnu.tar.gz"
    3echo "Running bitcoind."
    4echo "run 'bitcoin-0.18.1/bin/bitcoin-cli -testnet -rpcuser=u -rpcpassword=p encryptwallet p1' in and then hit CTRL+C after the wallet has been encrypted."
    5bitcoin-0.18.1/bin/bitcoind -testnet -noconnect -nolisten -datadir=$(pwd)/testnet_datadir/ -rpcuser=u -rpcpassword=p -keypool=10
    
  19. bitcoal commented at 10:18 pm on December 30, 2019: none
    Experiencing same issue in v0.19.0.1
  20. p3yot3 commented at 3:40 pm on February 3, 2020: none

    Experiencing same issue in v0.19.0.1

    Same here. Been waiting patiently for a fix for this issue for weeks now - is there any movement on this? What are my options? I’d really like to be able to use my wallet for it’s intended purpose.

  21. darosior commented at 3:53 pm on February 3, 2020: member

    Experiencing same issue in v0.19.0.1

    Same here. Been waiting patiently for a fix for this issue for weeks now

    I’ve closed #16360 (which solved this) 6 months ago in favor of #15761, which unfortunately conflicted with other work from the same author.

    is there any movement on this?

    #15761 has been rebased lately so…

  22. p3yot3 commented at 3:57 pm on February 3, 2020: none
    OK. What are my options as I need to access my BTC - a previous release maybe? If so, what version?
  23. p3yot3 commented at 5:16 pm on February 3, 2020: none

    OK. What are my options as I need to access my BTC - a previous release maybe? If so, what version?

    Anyone?

  24. darosior commented at 5:23 pm on February 3, 2020: member

    OK. What are my options as I need to access my BTC - a previous release maybe? If so, what version?

    Anyone?

    Helping with review maybe ?..

  25. p3yot3 commented at 5:55 pm on February 3, 2020: none

    A review of what exactly?

    After reading what @byt3farm said a few posts up I also downgraded to version v0.17.1 (64-bit) & am now able to use my wallet normally & send payments.

    This issue was reported here on 26 May 2019 - that’s 8 months ago. Since then there have been 3 releases & still the problem persists. I know you guys are busy, but that’s pretty lame. How is a casual user supposed to know about this & how to fix it? Suddenly being unable to send payments from one’s wallet for no apparent reason is enough to scare anyone, especially as there is no mention of this in the release notes of any of those 3 releases.

    Something in the release notes along the lines of “You might suddenly be unable to send coins from your own wallet for no reason if you upgrade to any version above 17.1 - this is a long known about issue” would be appropriate - at least users would then be aware & decide if they want to be locked out of their own wallets - only to get asked for a “review” here when asking for help.

  26. darosior commented at 5:56 pm on February 3, 2020: member

    A review of what exactly?

    The fix … ie #15761

  27. darosior commented at 6:02 pm on February 3, 2020: member

    at least users would then be aware & decide if they want to be locked out of their own wallets - only to get asked for a “review” here.

    I did not meant to be rude at all, that’s just that … We can’t really know what will be merged or not (even less me, I’m just a casual contributor) : nobody decides. PRs get merged if they are reviewed. PRs are reviewed if there are people interesting in doing it (i.e. excited about the improvement, or because they have a stake in it !). Hence my answer.

    Now to be more precise, you could just test the PR and leave a comment saying you did so : that way achow101 would be aware that it’s worth the rebases / fixes !

  28. p3yot3 commented at 6:40 pm on February 3, 2020: none
    I’m a casual user, like most people, not a coder. I found this by googling the problem, because I’d never seen or had this problem before. I do read the release notes before deciding weather to upgrade or not though & as there’s no mention of this in any of the release notes I presumed it would be safe to upgrade, wrongfully it seems. Please ask whoever is capable of doing so to include this problem in the release notes - it would save everyone a lot of wasted time & stress.
  29. adamjonas commented at 3:39 pm on April 24, 2020: member
    closed by #15761
  30. MarcoFalke commented at 4:12 pm on April 24, 2020: member
    Thanks @adamjonas
  31. MarcoFalke closed this on Apr 24, 2020

  32. mattpopovich commented at 11:07 pm on July 26, 2020: none

    Can confirm having the same issues as @redblade7 on v0.18.0 and still on v0.18.1. Same error: “Can’t generate a change-address key. No keys in the internal keypool and can’t generate any keys.” And can also not use the -upgradewallet flag due to bug #14422

    Wallet created around v0.11.1 and encrypted some time after that, ~v0.15.0 or so.

    Let me know if you need anything from me to help troubleshoot/reproduce.

    Reaffirming @adamjonas’ comment as #15761 has fixed this issue for my wallet.

  33. MatthewLM commented at 11:44 am on July 31, 2020: none

    #15761 would have been nice provided in a 0.20.1 release since the inability to use old encrypted wallets is a pretty major bug. I’m not sure if I should temporarily use 0.17.1, or build the master branch to upgrade the wallet. I don’t feel particularly comfortable using pre-release code for mainnet wallets.

    Edit: I did decide to build from master for the purpose of upgrading the wallet only. This went fine though I did have to deplete the keypool by running getnewaddress some 800 times (I did this using a bash for loop) before bech32 addresses would be generated.

    Hopefully in the future more attention will be made towards any wallet upgrades so that they go more smoothly as non-technically minded users wouldn’t be able to resolve this as easily.

  34. ADCJustinH commented at 9:43 pm on November 10, 2020: none

    Hopefully in the future more attention will be made towards any wallet upgrades so that they go more smoothly as non-technically minded users wouldn’t be able to resolve this as easily.

    Really wish this was prioritized. I have a wallet from 2010 that I just recovered and I really don’t want to be building core myself just to upgrade. More and more people willing be digging up old wallets as the price climbs and not all of us ’early adopters’ went into software development…

  35. achow101 commented at 10:08 pm on November 10, 2020: member

    Really wish this was prioritized. I have a wallet from 2010 that I just recovered and I really don’t want to be building core myself just to upgrade. More and more people willing be digging up old wallets as the price climbs and not all of us ’early adopters’ went into software development…

    The PR in question has already been merged and will be in the next major release which should be in ~1 month.

  36. p3yot3 commented at 8:11 pm on November 13, 2020: none
    Can we not have a hotfix release before then? I & others would really like to access our funds & use our wallets before then.
  37. achow101 commented at 8:33 pm on November 13, 2020: member

    Can we not have a hotfix release before then? I & others would really like to access our funds & use our wallets before then.

    At this point in time, a hotfix release would not be much faster than the 0.21 release itself. We are already in the release process for 0.21 itself and this process usually takes ~1 month for the final release. However there will be release candidates published before the final release. The first release candidate should be soon and will contain the fix.

    Additionally, #15761 itself has a few bugs and issues that are being addressed by #18836. This will be merged prior to 0.21 and any release candidates.

  38. daveblack1 commented at 3:07 pm on November 29, 2020: none
    Also experiencing this bug with a 2011 wallet that was not upgraded to HD, but was encrypted. Using v17.1 allowed me to send again, however the transaction is stuck. I transferred alot of trapped Bitcoin into this wallet…
  39. MarcoFalke commented at 9:05 am on December 1, 2020: member

    fyi, 0.21 rc2 is available for testing: https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2020-November/000094.html

    Please use caution when testing a release that is not final.

  40. p3yot3 commented at 5:31 pm on December 1, 2020: none

    fyi, 0.21 rc2 is available for testing: https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2020-November/000094.html

    Please use caution when testing a release that is not final.

    Did anyone try this yet? I’m afraid I don’t have the bottle - too much BTC to lose if it goes south & I’d hate to be in the same position as @daveblack1

  41. p3yot3 commented at 9:49 pm on January 6, 2021: none
    Should I presume that nobody tried it - or no, it doesn’t work?
  42. ADCJustinH commented at 2:51 am on January 7, 2021: none
    I didn’t want to be the first :)
  43. p3yot3 commented at 11:26 am on January 7, 2021: none
    This issue should be opened again until it has been confirmed that the problem is fixed.
  44. MatthewLM commented at 11:51 am on January 7, 2021: none

    @p3yot3 I successfully upgraded the wallet from the pre-release master branch and I’ve had no problems since. I’d be highly surprised if the RC doesn’t work. I upgraded the wallet and then went straight back to using 0.20. I made sure to backup the wallet first of-course. If upgrading take note of my previous comment:

    I did have to deplete the keypool by running getnewaddress some 800 times (I did this using a bash for loop) before bech32 addresses would be generated.

    Hopefully 0.21 will be released soon, so it might be best to simply wait unless access is urgent.

  45. p3yot3 commented at 11:25 am on January 8, 2021: none
    Fixed in RC5 & with the god-like help from @achow101
  46. DrahtBot locked this on Aug 16, 2022

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-17 09:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me