
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.


{RPCResult::Type::OBJ, "", "",
                        {
                            {RPCResult::Type::STR_HEX, "txid", "the transaction id"},
                            {RPCResult::Type::NUM, "vout", "the vout value"},
                            {RPCResult::Type::STR, "address",  true, "the bitcoin address"},
                            {RPCResult::Type::STR, "label",  true, "The associated label, or \"\" for the default label"},
                            {RPCResult::Type::STR, "scriptPubKey", "the script key"},
                            {RPCResult::Type::STR_AMOUNT, "amount", "the transaction output amount in " + CURRENCY_UNIT},
                            {RPCResult::Type::NUM, "confirmations", "The number of confirmations"},
                            {RPCResult::Type::NUM, "ancestorcount",  true, "The number of in-mempool ancestor transactions, including this one (if transaction is in the mempool)"},
                            {RPCResult::Type::NUM, "ancestorsize",  true, "The virtual transaction size of in-mempool ancestors, including this one (if transaction is in the mempool)"},
                            {RPCResult::Type::STR_AMOUNT, "ancestorfees",  true, "The total fees of in-mempool ancestors (including this one) with fee deltas used for mining priority in " + CURRENCY_ATOM + " (if transaction is in the mempool)"},
                            {RPCResult::Type::STR_HEX, "redeemScript",  true, "The redeemScript if scriptPubKey is P2SH"},
                            {RPCResult::Type::STR, "witnessScript",  true, "witnessScript if the scriptPubKey is P2WSH or P2SH-P2WSH"},
                            {RPCResult::Type::BOOL, "spendable", "Whether we have the private keys to spend this output"},
                            {RPCResult::Type::BOOL, "solvable", "Whether we know how to spend this output, ignoring the lack of keys"},
                            {RPCResult::Type::BOOL, "reused",  true, "(only present if avoid_reuse is set) Whether this output is reused/dirty (sent to an address that was previously spent from)"},
                            {RPCResult::Type::STR, "desc",  true, "(only when solvable) A descriptor for spending this output"},
                            {RPCResult::Type::BOOL, "safe", "Whether this output is considered safe to spend. Unconfirmed transactions\n"
                                                            "from outside keys and unconfirmed replacement transactions are considered unsafe\n"
                                                            "and are not eligible for spending by fundrawtransaction and sendtoaddress."},
                        }},
                    }
                },
                RPCExamples{
                    HelpExampleCli("listunspent", "")
            + HelpExampleCli("listunspent", "6 9999999 \"[\\\"" + EXAMPLE_ADDRESS[0] + "\\\",\\\"" + EXAMPLE_ADDRESS[1] + "\\\"]\"")
            + HelpExampleRpc("listunspent", "6, 9999999 \"[\\\"" + EXAMPLE_ADDRESS[0] + "\\\",\\\"" + EXAMPLE_ADDRESS[1] + "\\\"]\"")
            + HelpExampleCli("listunspent", "6 9999999 '[]' true '{ \"minimumAmount\": 0.005 }'")
            + HelpExampleRpc("listunspent", "6, 9999999, [] , true, { \"minimumAmount\": 0.005 } ")