importing a wallet containing an hdseed overwrites target wallet hdseed

quakemmo commented at 2:36 pm on November 22, 2023: none

Is there an existing issue for this?

I have searched the existing issues

Current behaviour

My basic idea was to have two nodes running with the same keys, if one fails, I can just rescan the blockchain on the other one and failover to it seamlessly.

I made a wallet on Node1, generated a few thousands addresses, saved the dumpwallet. Now I want to import the same keys to Node2, but I want it to be an HD wallet from the same seed, to avoid the headache of sendtoaddress, when out of spare keys, creating a new change privkey that will not be backed up anywhere. With the hdseed those “new” change addresses should still be accessible to whomever owns the hdseed (right?)

This doesn’t seem to work so well as importwallet on Node2 seems to get it rid of the hdseed I set to be the same as on Node1.

I don’t know if the resulting state of Node2 means that it still has an HD wallet. Doesn’t look so from the dumpwallet ouput. Importwallet seems to overwrite hdseed, making it just a regular privkey, no longer being hdseed.

Not sure this is working as intended.

Expected behaviour

Expected behaviour: Node2 keeps its hdseed

Steps to reproduce

Node1: has a wallet with hdseed=X Node1: dumpwallet, grab the hdseed privkey from the output

Node2: createwallet “test” false true Node2: sethdseed to the above-obtained hdseed privkey X Node2: importwallet from the above dump Node2: dumpwallet. Result does not contain an hdseed=1 line. It does contain the private key, but just with a “label=” Node2: sethdseed again to the hdseed privkey fails with the message “either already has an hdseed or it’s a loose private key”

Relevant log output

No response

How did you obtain Bitcoin Core

Pre-built binaries

What version of Bitcoin Core are you using?

v22.0

Operating system and version

Debian 12

Machine specifications

No response

achow101 commented at 5:34 am on November 24, 2023: member

importwallet does not import any metadata, including whether something is the seed. That it overwrites the seed metadata is expected behavior, although it should still work as the seed. You can check whether both wallets use the same seed by looking at hdseedid in getwalletinfo, and also generating some addresses to see if both wallets recognize them with getaddressinfo.

However, the workflow that you are using uses the legacy wallet storage format which is targeted to be removed soon. If there is indeed an issue, it is unlikely that it will be fixed, particularly as the effect that you want to achieve can be done with different methods. I do want to note though that the same wallet on two nodes is not recommended as metadata will not be the same and there can still be discrepancies between the copies of the wallet due to things such as RBF and related issues with unconfirmed transactions.

quakemmo commented at 7:43 am on November 24, 2023: none

@achow101 Thank you for your reply.

Can you please point me to the right direction as far as the “proper workflow” is concerned? My basic need is to have two nodes that I can failover between in case one goes down, with no coin loss (obviously) and reasonable downtime.

The nodes will be used for a classic mechanism of receiving user deposits (each user has its own BTC address), and sending withdrawals using “sendtoaddress” at first, then using raw transactions when I implement that. I pregenerated a number of addresses using “getnewaddress” and backed up the pkeys in addition to the hdseed, just in case. I managed to set the same hdseed on both nodes and imported the pregenerated addresses from node 1 to node 2.

Also can you please elaborate on the “unconfirmed transactions” discrepancies"? If that means that by failing to another node will lose the original node’s mempool, then it’s no big deal as I save the original transactions data (that I get by “getrawtransaction”) and can just propagate them again if needed. Or do you mean something different?

Thanks!

PS: current getwalletinfo on both nodes is:

 0{
 1  "walletname": "main",
 2  "walletversion": 169900,
 3  "format": "bdb",
 4  "balance": 0.00000000,
 5  "unconfirmed_balance": 0.00000000,
 6  "immature_balance": 0.00000000,
 7  "txcount": 0,
 8  "keypoololdest": 1669302186,
 9  "keypoolsize": 1000,
10  "hdseedid": "<stripped>",
11  "keypoolsize_hd_internal": 1000,
12  "paytxfee": 0.00000000,
13  "private_keys_enabled": true,
14  "avoid_reuse": false,
15  "scanning": false,
16  "descriptors": false
17}

The only difference being the keypoololdest field that is higher on node2 (seems logical).

willcl-ark added the label Wallet on Jan 24, 2024

bitchad42 commented at 4:19 am on March 15, 2024: none

“Don’t use the node for wallet” seems to be the proper workflow, it seems.

I find it unacceptable that if the hard drive dies there is a chance to lose coins because the wallet can’t be reliably derived on another device.

I was trying to find out if this is the case, and apparently it is.

furszy commented at 2:25 pm on April 1, 2024: member

@bitchad42 On your first node, create a new descriptors wallet and call gethdkeys true true (it will return the wallet’s active xpriv). Then, on your second node, create a blank wallet and call createwalletdescriptor <address_type> {"hdkey": xpriv} for each output type you are willing to support. While you kept your master xpriv safe and you remember the keypool threshold (in the case you are using a really large keypool), you will always be able to access your funds on any wallet.

Also can you please elaborate on the “unconfirmed transactions” discrepancies"?

There isn’t an unique global view of the mempool, and their entries are ephemeral. Previous tx replacements are dropped from the mempool; different nodes may end up agreeing on the final state but not on the intermediate ones.

bitchad42 commented at 2:56 pm on April 1, 2024: none

@furszy “In contrast to Bitcoin, Elements is not changing the default wallet format from legacy to descriptors, this is because many things (like peg-ins and peg-outs) still work only on legacy wallets.”

furszy commented at 7:50 pm on April 1, 2024: member

In contrast to Bitcoin, Elements is not changing the default wallet format from legacy to descriptors, this is because many things (like peg-ins and peg-outs) still work only on legacy wallets.

We can’t do much at this point. The timeline for the deprecation of the legacy wallet has existed since 2020 (#20160), and it is reaching its final milestone. I would recommend asking there about descriptor support if that is what stops you from upgrading your wallet.

bitchad42 commented at 7:57 pm on April 1, 2024: none

@furszy Nice, thank you, very much.

willcl-ark commented at 11:33 am on July 1, 2024: member

This issue hasn’t had activity in a while and appears to have gone stale so I’m going to close it for now.

Feel free to open a new issue or comment here if you are still experiencing this problem so we can investigate further.

willcl-ark closed this on Jul 1, 2024

importing a wallet containing an hdseed overwrites target wallet hdseed #28927