New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
getnewaddress always returns same type #16178
Comments
Your are missing the label argument that goes between the command name and the type parameter. Bitcoin Core is interpreting your type parameter as the label name. Instead try |
@achow101 That worked! Thank you so much! |
Actually this problem is still not resolved. It could be something to do with the config file. If anyone else has this issue please comment. |
Can you explain how it is not resolved? Everything looks correct in the screenshot above. |
The screenshot I originally posted was from my tests on another box on a OSX. The problem we are still experiencing is on a Linux machine. I've posted a more clear description of the problem as it appears on the Linux machine here: |
Thanks to @sipa we resolved this issue by upgrading our wallet.dat and then running getnewaddress a bunch of times. Issue resolved. |
When I run "getnewaddress legacy" I expect to get an address starting with a "1".
When I run "getnewaddress p2sh-segwit" I expect to get an address starting with a "3".
When I run "getnewaddress bech32" I expect to get an address starting with "bc1".
I always get an address starting a "3". Another user I know always gets an address starting with a "1".
This is reproducible both from command line running bitcoind, and also bitcoin-Qt. From bitcoind, I type:
bitcoin-cli getnewaddress legacy
Or from bitcoin-Qt I issue the commands from the debug window console, as shown in the screenshot above.
Running version 0.18 downloaded from https://bitcoin.org/en/download
I'm running on macOS Mojave Version 10.14.5, and I always get an address starting with "3".
The other user I know runs Ubuntu, and always gets an address starting with a "1".
N//a
The text was updated successfully, but these errors were encountered: