
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.


{
    return{{RPCResult::Type::NUM, "confirmations", "The number of confirmations for the transaction. Negative confirmations means the\n"
               "transaction conflicted that many blocks ago."},
           {RPCResult::Type::BOOL, "generated",  true, "Only present if the transaction's only input is a coinbase one."},
           {RPCResult::Type::BOOL, "trusted",  true, "Whether we consider the transaction to be trusted and safe to spend from.\n"
                "Only present when the transaction has 0 confirmations (or negative confirmations, if conflicted)."},
           {RPCResult::Type::STR_HEX, "blockhash",  true, "The block hash containing the transaction."},
           {RPCResult::Type::NUM, "blockheight",  true, "The block height containing the transaction."},
           {RPCResult::Type::NUM, "blockindex",  true, "The index of the transaction in the block that includes it."},
           {RPCResult::Type::NUM_TIME, "blocktime",  true, "The block time expressed in " + UNIX_EPOCH_TIME + "."},
           {RPCResult::Type::STR_HEX, "txid", "The transaction id."},
           {RPCResult::Type::ARR, "walletconflicts", "Conflicting transaction ids.",
           {
               {RPCResult::Type::STR_HEX, "txid", "The transaction id."},
           }},
           {RPCResult::Type::STR_HEX, "replaced_by_txid",  true, "The txid if this tx was replaced."},
           {RPCResult::Type::STR_HEX, "replaces_txid",  true, "The txid if the tx replaces one."},
           {RPCResult::Type::STR, "comment",  true, ""},
           {RPCResult::Type::STR, "to",  true, "If a comment to is associated with the transaction."},
           {RPCResult::Type::NUM_TIME, "time", "The transaction time expressed in " + UNIX_EPOCH_TIME + "."},
           {RPCResult::Type::NUM_TIME, "timereceived", "The time received expressed in " + UNIX_EPOCH_TIME + "."},
           {RPCResult::Type::STR, "comment",  true, "If a comment is associated with the transaction, only present if not empty."},
           {RPCResult::Type::STR, "bip125-replaceable", "(\"yes|no|unknown\") Whether this transaction could be replaced due to BIP125 (replace-by-fee);\n"
               "may be unknown for unconfirmed transactions not in the mempool."}};
}
static RPCHelpMan listtransactions()