Skip to content
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

Import watch only pubkeys to the keypool if private keys are disabled #14075

Merged
merged 5 commits into from Feb 14, 2019

Conversation

@achow101
Copy link
Member

@achow101 achow101 commented Aug 26, 2018

If the wallet has private keys disabled, allow importing public keys into the keypool. A keypool option has been added to importmulti in order to signal that the keys should be added to the keypool.

@@ -467,6 +467,67 @@ def run_test (self):
import_pub2 = self.nodes[0].getaddressinfo(addr2)['pubkey']
assert_equal(pub2, import_pub2)

# Import some public keys to the keypool of a no privkey wallet
Copy link
Member

@promag promag Aug 26, 2018

Commit "Fetch keys from keypool when private keys are disabled"

Could move test to a different commit?

Copy link
Member Author

@achow101 achow101 Aug 28, 2018

Done

@@ -467,6 +467,67 @@ def run_test (self):
import_pub2 = self.nodes[0].getaddressinfo(addr2)['pubkey']
assert_equal(pub2, import_pub2)

# Import some public keys to the keypool of a no privkey wallet
self.log.info("Adding pubkey to keypool of disableprivkey wallet")
self.nodes[1].createwallet("noprivkeys", True)
Copy link
Member

@promag promag Aug 26, 2018

Commit "Fetch keys from keypool when private keys are disabled"

Use named argument disable_private_keys=True?

Copy link
Member Author

@achow101 achow101 Aug 28, 2018

Done

@@ -1198,6 +1219,7 @@ UniValue importmulti(const JSONRPCRequest& mainRequest)
" \"internal\": <true> , (boolean, optional, default: false) Stating whether matching outputs should be treated as not incoming payments\n"
" \"watchonly\": <true> , (boolean, optional, default: false) Stating whether matching outputs should be considered watched even when they're not spendable, only allowed if keys are empty\n"
" \"label\": <label> , (string, optional, default: '') Label to assign to the address (aka account name, for now), only allowed with internal=false\n"
" \"keypool\": <true|false> , (boolean, optional, default: true) If true, adds the pubkeys to the keypool if private keys are disabled for the wallet.\n"
Copy link
Member

@promag promag Aug 26, 2018

Commit "Add option to importmulti add an imported pubkey to the keypool"

Default false.

Copy link
Member Author

@achow101 achow101 Aug 28, 2018

Fixed


// Add to keypool only works with pubkeys
if (add_keypool && pubKeys.size() == 0) {
throw JSONRPCError(RPC_INVALID_PARAMETER, "Only pubkeys be imported to the keypool");
Copy link
Member

@promag promag Aug 26, 2018

Commit "Add option to importmulti add an imported pubkey to the keypool"

... can be ...

Copy link
Member Author

@achow101 achow101 Aug 28, 2018

Fixed

@@ -559,7 +559,7 @@ bool WalletModel::isWalletEnabled()

bool WalletModel::privateKeysDisabled() const
{
return m_wallet->IsWalletFlagSet(WALLET_FLAG_DISABLE_PRIVATE_KEYS);
return m_wallet->IsWalletFlagSet(WALLET_FLAG_DISABLE_PRIVATE_KEYS) && m_wallet->KeypoolCountExternalKeys() == 0;
Copy link
Member

@instagibbs instagibbs Aug 27, 2018

This function should be renamed or called into from a new one.

WalletModel::KeypoolEmptyAndPrivkeysDisabled or something obnoxiously explicit.

Copy link
Member Author

@achow101 achow101 Aug 28, 2018

Done

}

LOCK(pwallet->cs_wallet);
if (!pwallet->IsWalletFlagSet(WALLET_FLAG_DISABLE_PRIVATE_KEYS) && !pwallet->IsLocked()) {
Copy link
Member

@instagibbs instagibbs Aug 27, 2018

Might be time to make a TryToTopUpKeyPool function for when we will continue regardless. We do this in a number of places in the PR and probably elsewhere.

Copy link
Member Author

@achow101 achow101 Aug 27, 2018

TopUpKeypool actually already has this check in it so it won't do anything when the disable private keys flag is set. This is just an extra belt and suspenders check.

src/wallet/wallet.cpp Outdated Show resolved Hide resolved
src/wallet/wallet.cpp Outdated Show resolved Hide resolved
src/wallet/wallet.cpp Outdated Show resolved Hide resolved
@achow101
Copy link
Member Author

@achow101 achow101 commented Aug 28, 2018

Rebased. The first commit is still from #14019

src/interfaces/wallet.h Outdated Show resolved Hide resolved
{
LOCK(cs_wallet);
if (internal) {
return setInternalKeyPool.size() == 0;
Copy link
Member

@instagibbs instagibbs Aug 29, 2018

mu-nit: add commit for KeypoolCountInternalKeys

Copy link
Member Author

@achow101 achow101 Aug 29, 2018

I think that's unnecssary.

@instagibbs
Copy link
Member

@instagibbs instagibbs commented Aug 29, 2018

CWallet::CreateTransaction needs to check for keys in change keypool even if WALLET_FLAG_DISABLE_PRIVATE_KEYS is set.

@achow101 achow101 force-pushed the watch-only-keypool branch 2 times, most recently from 50cff8c to acb05a1 Aug 30, 2018
@Sjors
Copy link
Member

@Sjors Sjors commented Sep 13, 2018

Concept ACK. Lightly tested via your combined branch 3fa968e: I was able to import a bunch of receive and change keys. I was also able to receive coins on a bech32 address and send from it.

For some reason when I composed the transaction it picked change address with index 1 instead of with index 0. Is that an existing rule?

What I also found confusing, though I don't know if that's this PR, or the other two or just existing weirdness, is how dumpwallet shows p2sh-p2wpkh addresses under # addr, even though I launched bitcoind with -addresstype=bech32.

@achow101
Copy link
Member Author

@achow101 achow101 commented Sep 13, 2018

For some reason when I composed the transaction it picked change address with index 1 instead of with index 0. Is that an existing rule?

Maybe your import command was weird? It should be adding them in the order of the import command so you should be getting them in that order too.

src/wallet/rpcdump.cpp Outdated Show resolved Hide resolved
@Sjors
Copy link
Member

@Sjors Sjors commented Oct 4, 2018

What's a good way to inspect the wallet / keypool?

@achow101
Copy link
Member Author

@achow101 achow101 commented Oct 4, 2018

@Sjors You can use dumpwallet

@Sjors
Copy link
Member

@Sjors Sjors commented Oct 5, 2018

@achow101 dumpwallet doesn't contain the bip32 derivation paths though.

I'll try with getaddressinfo.

@achow101
Copy link
Member Author

@achow101 achow101 commented Oct 15, 2018

I will rework this to not require #14019 as soon as I have time (in a few days)

@DrahtBot DrahtBot mentioned this pull request Oct 20, 2018
@achow101 achow101 force-pushed the watch-only-keypool branch from 0f9f035 to 32fd3bb Feb 14, 2019
@instagibbs
Copy link
Member

@instagibbs instagibbs commented Feb 14, 2019

Test fix only change.

reACK 32fd3bb

@achow101 achow101 force-pushed the watch-only-keypool branch from 32fd3bb to 38fbc10 Feb 14, 2019
@instagibbs
Copy link
Member

@instagibbs instagibbs commented Feb 14, 2019

re-ACK 38fbc10

Ordering test fixed, at least locally.

@Sjors
Copy link
Member

@Sjors Sjors commented Feb 14, 2019

utACK a6e2c33 (only adds a test since my last ACK)

@meshcollider
Copy link
Member

@meshcollider meshcollider commented Feb 14, 2019

utACK 38fbc10

achow101 added 3 commits Feb 14, 2019
Introduces AddKeypoolPubkey in order to add a pubkey to the keypool
When private keys are disabled, still fetch keys from the keypool
if the keypool has keys. Those keys come from importing them and
adding them to the keypool.
Adds a new option to importmulti where the pubkeys specified in the import
object can be added to the keypool. This only works if the wallet has
private keys disabled.
@achow101 achow101 force-pushed the watch-only-keypool branch from 38fbc10 to 037e695 Feb 14, 2019
achow101 added 2 commits Feb 14, 2019
Do public key imports in the order that they are specified in the import
or in the descriptor range.
@achow101 achow101 force-pushed the watch-only-keypool branch from 037e695 to f4b00b7 Feb 14, 2019
@meshcollider
Copy link
Member

@meshcollider meshcollider commented Feb 14, 2019

LGTM f4b00b7

@meshcollider meshcollider merged commit f4b00b7 into bitcoin:master Feb 14, 2019
0 of 2 checks passed
meshcollider added a commit to meshcollider/bitcoin that referenced this issue Feb 14, 2019
…ate keys are disabled

f4b00b7 Import public keys in order (Andrew Chow)
9e1551b Test pubkey import to keypool (Andrew Chow)
513719c Add option to importmulti add an imported pubkey to the keypool (Andrew Chow)
9b81fd1 Fetch keys from keypool when private keys are disabled (Andrew Chow)
99cccb9 Add a method to add a pubkey to the keypool (Andrew Chow)

Pull request description:

  If the wallet has private keys disabled, allow importing public keys into the keypool. A `keypool` option has been added to `importmulti` in order to signal that the keys should be added to the keypool.

Tree-SHA512: e88ea7bf726c13031aa739389a0c2662e6b22a4f9a4dc45b042418c692a950d98f170e0db80eb59e9c9063cda8765eaa85b2927d1790b9625744f7a87bad5fc8
@Sjors
Copy link
Member

@Sjors Sjors commented Feb 15, 2019

Post merge utACK f4b00b7

laanwj added a commit that referenced this issue Feb 17, 2019
…ption

a607c9a [Doc] importmulti: add missing description of keypool option (David A. Harding)

Pull request description:

  Option was added in #14075 but not documented there.

  CC: @achow101

Tree-SHA512: dcb6421fa1be3d733d7a00c1b57ffd591fe76c02d1c479e729089c118bec52f53bd7ebdb5454b3b1c7603ab189e91682a688b673a7f6b04fa8610c4249711217
deadalnix added a commit to Bitcoin-ABC/bitcoin-abc that referenced this issue Jun 4, 2020
Summary:
 * Add a method to add a pubkey to the keypool

Introduces AddKeypoolPubkey in order to add a pubkey to the keypool

 * Fetch keys from keypool when private keys are disabled

When private keys are disabled, still fetch keys from the keypool
if the keypool has keys. Those keys come from importing them and
adding them to the keypool.

 * Add option to importmulti add an imported pubkey to the keypool

Adds a new option to importmulti where the pubkeys specified in the import
object can be added to the keypool. This only works if the wallet has
private keys disabled.

 * Test pubkey import to keypool

 * Import public keys in order

Do public key imports in the order that they are specified in the import
or in the descriptor range.

This is a backport of Core [[bitcoin/bitcoin#14075 | PR14075]]

Test Plan:
  ninja all check-all

Reviewers: #bitcoin_abc, majcosta

Reviewed By: #bitcoin_abc, majcosta

Differential Revision: https://reviews.bitcoinabc.org/D6366
Munkybooty added a commit to Munkybooty/dash that referenced this issue Aug 21, 2021
…pool state changing

2bc4c3e Notify the GUI that the keypool has changed to set the receive button (Andrew Chow)
14bcdbe Check for more than private keys disabled to show receive button (Andrew Chow)

Pull request description:

  Currently the Receive button in the GUI is displayed enabled or disabled by the initial state of the wallet when the wallet is first loaded. The button is only enabled or disabled depending on whether the disable private keys flag is set when the wallet is loaded. However, future changes to the wallet means that this initial state and check may no longer be accurate. bitcoin#14938 introduces empty wallets which do not have private keys. An empty wallet that is loaded should have the Receive button disabled, and then it should become enabled once `sethdseed` is used so that a keypool can be generated and new keys generated. Likewise, with bitcoin#14075, a wallet can be loaded with no keypool initially, so the button should be disabled. Later, public keys can be imported into the keypool, at which time the button should become enabled. When the keypool runs out again (no new keys are generated as the keypool only consists of imports), the button should become disabled.

  This PR makes it so that the button becomes enabled and disabled as the keypool state changes. The check for whether to enable or disable the receive button has changed to checking whether it is possible to get new keys. It now checks for whether the wallet has an HD seed and, if not, whether the private keys are disabled. When an action happens which would make it possible for a new address to be retrieved or make it possible for a no more addresses to be retrieved, a signal is emitted which has the GUI recheck the conditions for the Receive button. These actions are setting a new HD seed, topping up the keypool, retrieving a key from the keypool, and returning a key to the keypool.

Tree-SHA512: eff15a5337f4c64ecd7169414fb47053c04f6a0f0130341b6dd9799ac4d79f451e25284701c668971fca33f0909d5352a474a2c12349375bedfdb59b63077d50
Munkybooty added a commit to Munkybooty/dash that referenced this issue Aug 21, 2021
…pool state changing

2bc4c3e Notify the GUI that the keypool has changed to set the receive button (Andrew Chow)
14bcdbe Check for more than private keys disabled to show receive button (Andrew Chow)

Pull request description:

  Currently the Receive button in the GUI is displayed enabled or disabled by the initial state of the wallet when the wallet is first loaded. The button is only enabled or disabled depending on whether the disable private keys flag is set when the wallet is loaded. However, future changes to the wallet means that this initial state and check may no longer be accurate. bitcoin#14938 introduces empty wallets which do not have private keys. An empty wallet that is loaded should have the Receive button disabled, and then it should become enabled once `sethdseed` is used so that a keypool can be generated and new keys generated. Likewise, with bitcoin#14075, a wallet can be loaded with no keypool initially, so the button should be disabled. Later, public keys can be imported into the keypool, at which time the button should become enabled. When the keypool runs out again (no new keys are generated as the keypool only consists of imports), the button should become disabled.

  This PR makes it so that the button becomes enabled and disabled as the keypool state changes. The check for whether to enable or disable the receive button has changed to checking whether it is possible to get new keys. It now checks for whether the wallet has an HD seed and, if not, whether the private keys are disabled. When an action happens which would make it possible for a new address to be retrieved or make it possible for a no more addresses to be retrieved, a signal is emitted which has the GUI recheck the conditions for the Receive button. These actions are setting a new HD seed, topping up the keypool, retrieving a key from the keypool, and returning a key to the keypool.

Tree-SHA512: eff15a5337f4c64ecd7169414fb47053c04f6a0f0130341b6dd9799ac4d79f451e25284701c668971fca33f0909d5352a474a2c12349375bedfdb59b63077d50
Munkybooty added a commit to Munkybooty/dash that referenced this issue Aug 23, 2021
…pool state changing

2bc4c3e Notify the GUI that the keypool has changed to set the receive button (Andrew Chow)
14bcdbe Check for more than private keys disabled to show receive button (Andrew Chow)

Pull request description:

  Currently the Receive button in the GUI is displayed enabled or disabled by the initial state of the wallet when the wallet is first loaded. The button is only enabled or disabled depending on whether the disable private keys flag is set when the wallet is loaded. However, future changes to the wallet means that this initial state and check may no longer be accurate. bitcoin#14938 introduces empty wallets which do not have private keys. An empty wallet that is loaded should have the Receive button disabled, and then it should become enabled once `sethdseed` is used so that a keypool can be generated and new keys generated. Likewise, with bitcoin#14075, a wallet can be loaded with no keypool initially, so the button should be disabled. Later, public keys can be imported into the keypool, at which time the button should become enabled. When the keypool runs out again (no new keys are generated as the keypool only consists of imports), the button should become disabled.

  This PR makes it so that the button becomes enabled and disabled as the keypool state changes. The check for whether to enable or disable the receive button has changed to checking whether it is possible to get new keys. It now checks for whether the wallet has an HD seed and, if not, whether the private keys are disabled. When an action happens which would make it possible for a new address to be retrieved or make it possible for a no more addresses to be retrieved, a signal is emitted which has the GUI recheck the conditions for the Receive button. These actions are setting a new HD seed, topping up the keypool, retrieving a key from the keypool, and returning a key to the keypool.

Tree-SHA512: eff15a5337f4c64ecd7169414fb47053c04f6a0f0130341b6dd9799ac4d79f451e25284701c668971fca33f0909d5352a474a2c12349375bedfdb59b63077d50
Munkybooty added a commit to Munkybooty/dash that referenced this issue Aug 24, 2021
…pool state changing

2bc4c3e Notify the GUI that the keypool has changed to set the receive button (Andrew Chow)
14bcdbe Check for more than private keys disabled to show receive button (Andrew Chow)

Pull request description:

  Currently the Receive button in the GUI is displayed enabled or disabled by the initial state of the wallet when the wallet is first loaded. The button is only enabled or disabled depending on whether the disable private keys flag is set when the wallet is loaded. However, future changes to the wallet means that this initial state and check may no longer be accurate. bitcoin#14938 introduces empty wallets which do not have private keys. An empty wallet that is loaded should have the Receive button disabled, and then it should become enabled once `sethdseed` is used so that a keypool can be generated and new keys generated. Likewise, with bitcoin#14075, a wallet can be loaded with no keypool initially, so the button should be disabled. Later, public keys can be imported into the keypool, at which time the button should become enabled. When the keypool runs out again (no new keys are generated as the keypool only consists of imports), the button should become disabled.

  This PR makes it so that the button becomes enabled and disabled as the keypool state changes. The check for whether to enable or disable the receive button has changed to checking whether it is possible to get new keys. It now checks for whether the wallet has an HD seed and, if not, whether the private keys are disabled. When an action happens which would make it possible for a new address to be retrieved or make it possible for a no more addresses to be retrieved, a signal is emitted which has the GUI recheck the conditions for the Receive button. These actions are setting a new HD seed, topping up the keypool, retrieving a key from the keypool, and returning a key to the keypool.

Tree-SHA512: eff15a5337f4c64ecd7169414fb47053c04f6a0f0130341b6dd9799ac4d79f451e25284701c668971fca33f0909d5352a474a2c12349375bedfdb59b63077d50
Munkybooty added a commit to Munkybooty/dash that referenced this issue Aug 24, 2021
…pool state changing

2bc4c3e Notify the GUI that the keypool has changed to set the receive button (Andrew Chow)
14bcdbe Check for more than private keys disabled to show receive button (Andrew Chow)

Pull request description:

  Currently the Receive button in the GUI is displayed enabled or disabled by the initial state of the wallet when the wallet is first loaded. The button is only enabled or disabled depending on whether the disable private keys flag is set when the wallet is loaded. However, future changes to the wallet means that this initial state and check may no longer be accurate. bitcoin#14938 introduces empty wallets which do not have private keys. An empty wallet that is loaded should have the Receive button disabled, and then it should become enabled once `sethdseed` is used so that a keypool can be generated and new keys generated. Likewise, with bitcoin#14075, a wallet can be loaded with no keypool initially, so the button should be disabled. Later, public keys can be imported into the keypool, at which time the button should become enabled. When the keypool runs out again (no new keys are generated as the keypool only consists of imports), the button should become disabled.

  This PR makes it so that the button becomes enabled and disabled as the keypool state changes. The check for whether to enable or disable the receive button has changed to checking whether it is possible to get new keys. It now checks for whether the wallet has an HD seed and, if not, whether the private keys are disabled. When an action happens which would make it possible for a new address to be retrieved or make it possible for a no more addresses to be retrieved, a signal is emitted which has the GUI recheck the conditions for the Receive button. These actions are setting a new HD seed, topping up the keypool, retrieving a key from the keypool, and returning a key to the keypool.

Tree-SHA512: eff15a5337f4c64ecd7169414fb47053c04f6a0f0130341b6dd9799ac4d79f451e25284701c668971fca33f0909d5352a474a2c12349375bedfdb59b63077d50
Munkybooty added a commit to Munkybooty/dash that referenced this issue Aug 24, 2021
…pool state changing

2bc4c3e Notify the GUI that the keypool has changed to set the receive button (Andrew Chow)
14bcdbe Check for more than private keys disabled to show receive button (Andrew Chow)

Pull request description:

  Currently the Receive button in the GUI is displayed enabled or disabled by the initial state of the wallet when the wallet is first loaded. The button is only enabled or disabled depending on whether the disable private keys flag is set when the wallet is loaded. However, future changes to the wallet means that this initial state and check may no longer be accurate. bitcoin#14938 introduces empty wallets which do not have private keys. An empty wallet that is loaded should have the Receive button disabled, and then it should become enabled once `sethdseed` is used so that a keypool can be generated and new keys generated. Likewise, with bitcoin#14075, a wallet can be loaded with no keypool initially, so the button should be disabled. Later, public keys can be imported into the keypool, at which time the button should become enabled. When the keypool runs out again (no new keys are generated as the keypool only consists of imports), the button should become disabled.

  This PR makes it so that the button becomes enabled and disabled as the keypool state changes. The check for whether to enable or disable the receive button has changed to checking whether it is possible to get new keys. It now checks for whether the wallet has an HD seed and, if not, whether the private keys are disabled. When an action happens which would make it possible for a new address to be retrieved or make it possible for a no more addresses to be retrieved, a signal is emitted which has the GUI recheck the conditions for the Receive button. These actions are setting a new HD seed, topping up the keypool, retrieving a key from the keypool, and returning a key to the keypool.

Tree-SHA512: eff15a5337f4c64ecd7169414fb47053c04f6a0f0130341b6dd9799ac4d79f451e25284701c668971fca33f0909d5352a474a2c12349375bedfdb59b63077d50
UdjinM6 added a commit to UdjinM6/dash that referenced this issue Aug 24, 2021
…pool state changing

2bc4c3e Notify the GUI that the keypool has changed to set the receive button (Andrew Chow)
14bcdbe Check for more than private keys disabled to show receive button (Andrew Chow)

Pull request description:

  Currently the Receive button in the GUI is displayed enabled or disabled by the initial state of the wallet when the wallet is first loaded. The button is only enabled or disabled depending on whether the disable private keys flag is set when the wallet is loaded. However, future changes to the wallet means that this initial state and check may no longer be accurate. bitcoin#14938 introduces empty wallets which do not have private keys. An empty wallet that is loaded should have the Receive button disabled, and then it should become enabled once `sethdseed` is used so that a keypool can be generated and new keys generated. Likewise, with bitcoin#14075, a wallet can be loaded with no keypool initially, so the button should be disabled. Later, public keys can be imported into the keypool, at which time the button should become enabled. When the keypool runs out again (no new keys are generated as the keypool only consists of imports), the button should become disabled.

  This PR makes it so that the button becomes enabled and disabled as the keypool state changes. The check for whether to enable or disable the receive button has changed to checking whether it is possible to get new keys. It now checks for whether the wallet has an HD seed and, if not, whether the private keys are disabled. When an action happens which would make it possible for a new address to be retrieved or make it possible for a no more addresses to be retrieved, a signal is emitted which has the GUI recheck the conditions for the Receive button. These actions are setting a new HD seed, topping up the keypool, retrieving a key from the keypool, and returning a key to the keypool.

Tree-SHA512: eff15a5337f4c64ecd7169414fb47053c04f6a0f0130341b6dd9799ac4d79f451e25284701c668971fca33f0909d5352a474a2c12349375bedfdb59b63077d50
Munkybooty added a commit to Munkybooty/dash that referenced this issue Aug 24, 2021
…pool state changing

2bc4c3e Notify the GUI that the keypool has changed to set the receive button (Andrew Chow)
14bcdbe Check for more than private keys disabled to show receive button (Andrew Chow)

Pull request description:

  Currently the Receive button in the GUI is displayed enabled or disabled by the initial state of the wallet when the wallet is first loaded. The button is only enabled or disabled depending on whether the disable private keys flag is set when the wallet is loaded. However, future changes to the wallet means that this initial state and check may no longer be accurate. bitcoin#14938 introduces empty wallets which do not have private keys. An empty wallet that is loaded should have the Receive button disabled, and then it should become enabled once `sethdseed` is used so that a keypool can be generated and new keys generated. Likewise, with bitcoin#14075, a wallet can be loaded with no keypool initially, so the button should be disabled. Later, public keys can be imported into the keypool, at which time the button should become enabled. When the keypool runs out again (no new keys are generated as the keypool only consists of imports), the button should become disabled.

  This PR makes it so that the button becomes enabled and disabled as the keypool state changes. The check for whether to enable or disable the receive button has changed to checking whether it is possible to get new keys. It now checks for whether the wallet has an HD seed and, if not, whether the private keys are disabled. When an action happens which would make it possible for a new address to be retrieved or make it possible for a no more addresses to be retrieved, a signal is emitted which has the GUI recheck the conditions for the Receive button. These actions are setting a new HD seed, topping up the keypool, retrieving a key from the keypool, and returning a key to the keypool.

Tree-SHA512: eff15a5337f4c64ecd7169414fb47053c04f6a0f0130341b6dd9799ac4d79f451e25284701c668971fca33f0909d5352a474a2c12349375bedfdb59b63077d50
vijaydasmp added a commit to vijaydasmp/dash that referenced this issue Sep 5, 2021
…ypool option

a607c9a [Doc] importmulti: add missing description of keypool option (David A. Harding)

Pull request description:

  Option was added in bitcoin#14075 but not documented there.

  CC: @achow101

Tree-SHA512: dcb6421fa1be3d733d7a00c1b57ffd591fe76c02d1c479e729089c118bec52f53bd7ebdb5454b3b1c7603ab189e91682a688b673a7f6b04fa8610c4249711217
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

10 participants