#36126 wallet, rpc: Implements set key label functionality

• Help users track which master keys correspond to physical devices or cosigners in multisig setups

This pull request introduces key labeling to the wallet database, mapping master key fingerprints to arbitrary label strings. It adds three new RPCs (setkeylabel, getkeylabel, listkeylabels), exposes key labels in getaddressinfo and gethdkeys, and adds corresponding methods to interfaces::Wallet.

Problem: In multisig setups or setups with multiple signing devices, users and GUIs cannot easily track which master key corresponds to which physical device or cosigner.

P3 · new feature

• P3 because it improves ergonomics for multisig users distinguishing cosigners and hardware keys
• Convenience feature with no fund safety or consensus impact that can be deferred

P3 because key labeling solves a clear ergonomic pain point for users distinguishing cosigners and hardware keys in multisig setups. It is a convenience feature without fund safety or consensus implications, and can reasonably be deferred while higher-priority wallet work proceeds.

Membership: Modifies CWallet, WalletBatch, walletdb records, and wallet RPC commands.

Factors: security/stability 0, bug 0, performance 0, user value 2, leverage 1

• Review premature because author marked PR draft while project decides if labels belong in wallet DB

The author explicitly put the PR in draft and asked to pause until consensus is reached on issue #35645 regarding whether key labels belong in the wallet DB, making current code review premature.

Author status: active; marked PR draft on 2026-09-10 to pause review until project reaches consensus on persisting key labels

Open concerns:

• achow101 NACKed storing key labels in the wallet database and objected that master key fingerprints are 4-byte collidable identifiers
• rkrux expressed Concept ~0/NACK, arguing that key labels add maintenance burden and complicate the guided multisig workflow

Resolved concerns:

• jeanpablojp noted that getaddressinfo did not handle multisig descriptors, resolved by extracting origins for all securing keys
• Eunovo suggested encapsulating m_key_labels inside CWallet, which author implemented

• Blocking objection to storing key labels in wallet DB and using collidable fingerprints (achow101)
• Questions RPC utility and warns of added maintenance burden for guided multisig (rkrux)
• Concept approval for adding key labels (vicjuma, jeanpablojp, Eunovo)

Disputed: achow101 NACKs persisting key labels and using fingerprints; rkrux questions RPC utility.

Core wallet maintainer achow101 posted a blocking NACK against storing key labels in the wallet database and against indexing them by 4-byte key fingerprints due to collision risk. The author paused the PR to resolve the architectural dispute.

• achow101: 'NACK... The key labeling that was discussed is for the GUI only... Also, DO NOT USE FINGERPRINTS, THEY ARE COLLIDABLE.'
• rkrux: 'Concept ~0 (tending towards NACK)... I don't see much benefit in providing RPCs for setting or viewing key labels...'
• vicjuma: 'Approach ACK'
• jeanpablojp: 'Concept ACK'
• Eunovo: 'Concept ACK'
• polespinasa: 'Will mark as draft for now until we decide if we want to include labels or not.'

Review verdicts (DrahtBot): 0 -2

• Approach ACK: vicjuma
• Concept ACK: jeanpablojp, Eunovo
• Concept NACK: achow101, rkrux

Enables:

• #35645 (multisig setup GUI tracking)

156 lines under test/bench/ci.

• test/functional/wallet_keylabels.py +155/-0
• src/wallet/rpc/addresses.cpp +153/-1
• src/wallet/wallet.cpp +39/-0
• src/wallet/walletdb.cpp +26/-0
• src/wallet/wallet.h +20/-0
• src/wallet/interfaces.cpp +16/-0
• src/wallet/rpc/wallet.cpp +13/-0
• doc/release-notes-36126.md +12/-0
• src/interfaces/wallet.h +11/-0
• src/wallet/walletdb.h +4/-0
• test/functional/test_runner.py +1/-0

This PR adds a keylabel record to the wallet database and exposes RPCs (setkeylabel, getkeylabel, listkeylabels) to label master keys by their fingerprint. It aims to improve usability for multisig and hardware wallet setups by identifying cosigners across addresses. achow101 NACKed the PR over the decision to persist labels in the database and the collision risk of 4-byte key fingerprints. Review is paused as the author placed the PR in draft until design consensus is reached.