importprivkey unsets labels set with importaddress and importpubkey #13087

1. 
   harding commented at 9:58 am on April 26, 2018: contributor

   Expected behavior:

   1. importaddress or importpubkey a watching-only address or pubkey with a label
   2. Receive a transaction to that address; observe that the label has been applied to that transaction
   3. importprivkey the private key for that address without specifying any change to the label
   4. Have the previous label still applied to the transaction after the import.

   Observed behavior on 0.15 and current master:

   Steps 1-3 the same. 4. Previous label is replaced with the default empty label ("")

   Problem seems to have occurred on 0.15 and affects the latest master (see subsequent details). I’d suspect all versions are affected, i.e. it’s not a regression.

   Steps to reproduce

    0## For testing
    1ADDRESS=2N6Y2wdhd91mQnZ8qCeH6hT5aZZygXFnNjP
    2PRIVKEY=cQriWp98xU9ghRvDKbzkRcgcecQLezjYwtPUjLNN5kzT8GbdnxQt
    3
    4## Starting a fresh regtest (i.e. ~/.bitcoin/regtest/ previously deleted)
    5$ bitcoind -daemon -regtest
    6Bitcoin server starting
    7
    8## Import the address with a label and no rescan
    9$ bitcoin-cli -regtest importaddress $ADDRESS "Watch-only test" false
   10
   11## Mine a generation tx to the address (regular spending works too)
   12$ bitcoin-cli -regtest generatetoaddress 1 $ADDRESS > /dev/null
   13
   14## Bury the generation tx so it shows up in the wallet
   15$ bitcoin-cli -regtest generate 100 > /dev/null
   16
   17## See that the address label was applied to the tx
   18$ bitcoin-cli -regtest listunspent | jq .[].label
   19"Watch-only test"
   20
   21## Import the private key.  Note the 'label' parameter is not explicitly passed
   22$ bitcoin-cli -regtest importprivkey $PRIVKEY
   23
   24## See that the address label has been set to empty :-(
   25$ bitcoin-cli -regtest listunspent | jq .[].label
   

   Same thing happens if importpubkey is substituted for importaddress. I haven’t tested importmulti for either address/pubkey or privkey import, nor have I tested using named parameters.

   Use case

   I was watching-only addresses from my cold wallet, then moved my coins to new addresses and (after some confirmations) imported the old private keys so that I could sell fork coins. I didn’t realize until now when I was trying to do some bookkeeping that all my old cold wallet labels were reset (happily, I have backups, so nothing is lost but time).

   Possibly related issues

   • #12698 looks related but the poster there says that it works on mainnet. I discovered my problem from actual use on mainnet and reproduced on regtest.
2. fanquake added the label RPC/REST/ZMQ on Apr 26, 2018
3. yuntai referenced this in commit ce5431eaa8 on Jun 1, 2018
4. 
   promag commented at 11:05 pm on June 1, 2018: member

   IIUC this is the intended behaviour:

   0importprivkey "privkey" ( "label" ) ( rescan )
   1...
   22. "label"            (string, optional, default="") An optional label
   

   Are you suggesting to change the default behaviour: default=current label if watch only address otherwise ""?

5. 
   harding commented at 9:40 am on June 2, 2018: contributor

   @promag that’s a good argument for it being the intended behavior, so perhaps this should be considered a feature request rather than a bug. However, it does seem undesirable to me for key import to destroy possibly-important metadata previously entered by the user.
6. 
   promag commented at 9:48 am on June 2, 2018: member

   Yes, either way it should have a way to preserve the current label.
7. 
   marcoagner commented at 3:02 pm on June 3, 2018: contributor

   I’m trying to address this on #13381 Could you, please, check if the approach seems reasonable and the behavior is an improvement for the expected use case? Thanks.
8. jonasschnelli closed this on Nov 13, 2018

   ---

9. jonasschnelli referenced this in commit b60f4e3f09 on Nov 13, 2018
10. DrahtBot locked this on Sep 8, 2021
11. Munkybooty referenced this in commit 51de277607 on Jan 26, 2022
12. Munkybooty referenced this in commit 419bc05ebb on Feb 4, 2022
13. Munkybooty referenced this in commit a304e50797 on Feb 24, 2022
14. Munkybooty referenced this in commit 16876dec18 on Mar 6, 2022
15. Munkybooty referenced this in commit cabaeaa2fc on Mar 8, 2022

Contributors
harding promag marcoagner

Labels
RPC/REST/ZMQ