
I have two bitcoin core full nodes. I have one wallet.dat file on both nodes. One node is a master and second node is a reserve. Master signs and sends transactions. Reserve node only receives updates from network. I create new addresses on the master node only and the reserve node derives the same addresses.

I don’t use any other commands on the reserve node. The reserve node creates addresses automatically after receiving a transaction to a new address. This process is possible due to using BIP32 key derivation from one master key.

So, I have constantly synchronized master and reserve nodes. If there are problems with the master, then I switch to the reserve.

I see some strange behavior appear during this process. Some transactions are not shown in the `listtransactions` output. I did a research an found that only "in-wallet" transactions are not shown in the `listransactions`. The "in-wallet" transactions are transactions that were sent with sender’s and receiver’s keys, which are stored in my wallet. I also found that new addresses on the reserve node are created whithout a label.

After adding a label to the address the problem is gone. But adding a label requires additional steps I want to avoid.

**Expected Behavior**

Results of `listtransactions` also shown "in-wallet" transactions to addresses without labels


**Current Behavior**

Results of `listtransactions` doesn’t shown "in-wallet" transactions to addresses without labels

**Possible Solution**

- Automatic adding of a default label to the addresses, derived to the reserve node.

- Print transactions sent to addresses without labels in `listtransactions`.

**Steps to Reproduce**

1.  Run and sync full nodes A and B.

2.  Stop nodes A and B.

3.  Copy wallet.dat from node A to node B.

4.  Run nodes A and B

5.  Use `getnewaddress` method on node A 10 times. Let’s assume the 10-th address is `$ADDRESS`.

6.  Use `sendtoaddress` method on node A. Send 0.001 coins from another address to the `$ADDRESS`. `bitcoin-cli sendtoaddress $ADDRESS 0.001`. Let’s assume the result txid is `$TXID`.

7.  Use `listtransaction "*"` method on node B. You don’t see the `$TXID` transaction in list.

8.  Use `gettransactions`, or `listunspent` methods on node B. You can see the transaction details. Wallet balance changed on node B and is equal to node A.

9.  Use `getaddressinfo $ADDRESS` method on node A. You can see that address had the default label (`""`).

10. Use `getaddressinfo $ADDRESS` method on node B. You can see that the address doesn’t have any label.

**Context (Environment)**

The problem is occured on any version of bitcoin core testnet and mainnet. The problem is also occured on litecoin and any bitcoin-based coins.


* A keypool also allowed encrypted wallets to give out addresses without
 * having to be decrypted to generate a new private key.
 *
 * With the introduction of HD wallets (commit: f1902510), the keypool
 * essentially became an address look-ahead pool. Restoring old backups can no
 * longer definitively lose funds as long as the addresses used were from the
 * wallet's HD seed (since all private keys can be rederived from the seed).
 * However, if many addresses were used since the backup, then the wallet may
 * not know how far ahead in the HD chain to look for its addresses. The
 * keypool is used to implement a 'gap limit'. The keypool maintains a set of
 * keys (by default 1000) ahead of the last used key and scans for the
 * addresses of those keys.  This avoids the risk of not seeing transactions
 * involving the wallet's addresses, or of re-using the same address.
 * In the unlikely case where none of the addresses in the `gap limit` are
 * used on-chain, the look-ahead will not be incremented to keep
 * a constant size and addresses beyond this range will not be detected by an
 * old backup. For this reason, it is not recommended to decrease keypool size
 * lower than default value.
 *
 * The HD-split wallet feature added a second keypool (commit: 02592f4c). There
 * is an external keypool (for addresses to hand out) and an internal keypool
 * (for change addresses).
 *
 * Keypool keys are stored in the wallet/keystore's keymap. The keypool data is
 * stored as sets of indexes in the wallet (setInternalKeyPool,
 * setExternalKeyPool and set_pre_split_keypool), and a map from the key to the
 * index (m_pool_key_to_index). The CKeyPool object is used to
 * serialize/deserialize the pool data to/from the database.
 */
class CKeyPool