Best way to transfer& import listdescriptors to watch only wallet?

[calkob]

I have set up an old wallet.dat that needed migrated to the new format.  after i did that i listeddescriptors and copied them to a notepad on the windows machine.  i then moved them via USB to an online watch only setup.

the formatting seemed all of and Core console kept giving my syntax error, like i could just cut and paste.

I eventually worked out how to add some \ & " &] in certain places with the help of ChatGPT which worked (i did not give it the real descriptors).  but i could only enter each descriptor one at a time. 

I entered all the PKH,WPKH,TR, etc and them the "combo" ones, but after entering them all the wallet showed no funds, i did a rescanblockchain and reboot and still nothing, what am i doing wrong? 

[Cricktor]

What exactly are you trying to achieve? I assume, you want a watch-only wallet from your original hot full wallet?

From your first sentences, I understand it that you successfully migrated your old wallet.dat to a descriptor wallet format. Is this correct?

After that you exported all(?) descriptors and want to import them into another Core watch-only wallet? There you have issues due to some formatting?

When I look at the help output for RPC commands listdescriptors and importdescriptors, it's quite obvious that you can't use the output of listdescriptors verbatim to feed it into importdescriptors. Pay close attention to proper JSON array and objects formatting.

It's hard to tell what you screwed up. If you want to show your output and input to RPC commands, make sure to redact carefully your descriptors in such a way that just the public key data is redacted. Private key descriptors should not be there anyway when you want to import your descriptors to a watch-only wallet. But nobody here knows, if you understand and know what you're doing.

[caawcaaw]

I entered all the PKH,WPKH,TR, etc and them the "combo" ones, but after entering them all the wallet showed no funds, i did a rescanblockchain and reboot and still nothing, what am i doing wrong? 

If the descriptors themselves are correct, maybe the "timestamp" is the only reason why the wallet shows a $0 balance.

if you want to find all wallet balances/old transactions, use "timestamp": 0, so core scans from the beginning of the blockchain.

1. go to the bitcoin core console--> "importdescriptors", change "timestamp":0, ---> import the descriptor again.
2. run "rescanblockchain" (after running you'll see the progress status bar at the bottom of the core, reading "rescanning blockchain...".

once that progress reaches to 100%, your entire fully historical transactions should appear.

[calkob]

What exactly are you trying to achieve? I assume, you want a watch-only wallet from your original hot full wallet?
Yes i am trying to create a watch wallet where i can create PSBT and then sign them on my offline wallet

From your first sentences, I understand it that you successfully migrated your old wallet.dat to a descriptor wallet format. Is this correct?
yes

After that you exported all(?) descriptors and want to import them into another Core watch-only wallet? There you have issues due to some formatting?
yes, which i already worked out

When I look at the help output for RPC commands listdescriptors and importdescriptors, it's quite obvious that you can't use the output of listdescriptors verbatim to feed it into importdescriptors. Pay close attention to proper JSON array and objects formatting.
quite obvious to you, lol.  

It's hard to tell what you screwed up. If you want to show your output and input to RPC commands, make sure to redact carefully your descriptors in such a way that just the public key data is redacted. Private key descriptors should not be there anyway when you want to import your descriptors to a watch-only wallet. But nobody here knows, if you understand and know what you're doing.

i am retrying with an earlyer timestamp

Thanks for the help

I entered all the PKH,WPKH,TR, etc and them the "combo" ones, but after entering them all the wallet showed no funds, i did a rescanblockchain and reboot and still nothing, what am i doing wrong?  

If the descriptors themselves are correct, maybe the "timestamp" is the only reason why the wallet shows a $0 balance.

if you want to find all wallet balances/old transactions, use "timestamp": 0, so core scans from the beginning of the blockchain.

1. go to the bitcoin core console--> "importdescriptors", change "timestamp":0, ---> import the descriptor again.
2. run "rescanblockchain" (after running you'll see the progress status bar at the bottom of the core, reading "rescanning blockchain...".

once that progress reaches to 100%, your entire fully historical transactions should appear.

Going to try that now, thanks

[nc50lc]

1. go to the bitcoin core console--> "importdescriptors", change "timestamp":0, ---> import the descriptor again.
2. run "rescanblockchain" (after running you'll see the progress status bar at the bottom of the core, reading "rescanning blockchain...".

Going to try that now, thanks

If you're going to try that, you can skip the first step (re-import the descriptors).
Because the second step, rescanblockchain with default args will rescan the blocks regardless of the initial timestamp that you've applied on importdescriptors command.
Unless your blockchain in pruned, in this case, you can't scan past through the already pruned blocks.

Also, please post an example command that you've used during import (same syntax with placehodler descriptors)
So that we can check if there's something wrong with it.

[calkob]

1. go to the bitcoin core console--> "importdescriptors", change "timestamp":0, ---> import the descriptor again.
2. run "rescanblockchain" (after running you'll see the progress status bar at the bottom of the core, reading "rescanning blockchain...".

Going to try that now, thanks

If you're going to try that, you can skip the first step (re-import the descriptors).
Because the second step, rescanblockchain with default args will rescan the blocks regardless of the initial timestamp that you've applied on importdescriptors command.
Unless your blockchain in pruned, in this case, you can't scan past through the already pruned blocks.
The offline node/wallet is pruned, that is where i am getting the descriptors from, would that make a differance? The watch only node/wallet has full history

Also, please post an example command that you've used during import (same syntax with placehodler descriptors)
So that we can check if there's something wrong with it.

"[{   \"desc\": \"pkh([527***********48a/44FJYb****************************************wXgyZ/1/*)#g43dxkh8\", \"timestamp\": 1606236840, \"active\": true,  \"internal\": true,      \"range\": [        0,        999      ],      \"next\": 0,      \"next_index\": 0    }]"

[takuma sato]

I made a similar thread about this a while ago. I remember I had to use a script in order to get the transaction labels to show up in the watch-only wallet because when you use importdescriptors it has no info about it, so it's a mess to use, you don't really know what utxos you are using which is not ideal for privacy since you don't know what coins belong to what transaction, it's not really usable imo.

Also it appears that when some transactions were made close to each other in time, they will not show up in proper chronological order. Also remember to use listdescriptors false just in case if you are paranoid but it should do the same as listdescriptors.

https://bitcointalk.org/index.php?topic=5576086.msg66461797#msg66461797

Imo the watch-only wallet is annoying to use if you cannot get a 1:1 copy of what you are seeing on your airgap laptop and may lead to mistakes.

[calkob]

I made a similar thread about this a while ago. I remember I had to use a script in order to get the transaction labels to show up in the watch-only wallet because when you use importdescriptors it has no info about it, so it's a mess to use, you don't really know what utxos you are using which is not ideal for privacy since you don't know what coins belong to what transaction, it's not really usable imo.

Also it appears that when some transactions were made close to each other in time, they will not show up in proper chronological order. Also remember to use listdescriptors false just in case if you are paranoid but it should do the same as listdescriptors.

https://bitcointalk.org/index.php?topic=5576086.msg66461797#msg66461797

Imo the watch-only wallet is annoying to use if you cannot get a 1:1 copy of what you are seeing on your airgap laptop and may lead to mistakes.

Thanks for the reply and link, but i am not getting any UTXOs even showing up.  I managed to get the syntax right and was able to importdescriptors all in one go but i got the output below in Consloe window, something is clearly not right.  I set Timestamp to "0" to make sure i got all dates and still nothing. 



[
  {
    "success": true
  },
  {
    "success": true
  },
  {
    "success": false,
    "error": {
      "code": -4,
      "message": "Cannot expand descriptor. Probably because of hardened derivations without private keys provided"
    }
  },
  {
    "success": false,
    "error": {
      "code": -4,
      "message": "Cannot expand descriptor. Probably because of hardened derivations without private keys provided"
    }
  },
  {
    "success": false,
    "error": {
      "code": -4,
      "message": "Cannot expand descriptor. Probably because of hardened derivations without private keys provided"
    }
  },
  {
    "success": false,
    "error": {
      "code": -4,
      "message": "Cannot expand descriptor. Probably because of hardened derivations without private keys provided"
    }
  },
  {
    "success": true
  },
  {
    "success": true
  },
  {
    "success": true
  },
  {
    "success": true
  },
  {
    "success": true
  },
  {
    "success": true
  },
  {
    "success": true
  },
  {
    "success": true
  }
]

[nc50lc]

The offline node/wallet is pruned, that is where i am getting the descriptors from, would that make a differance? The watch only node/wallet has full history

Then there should be no issue on the rescanning part on the online side.
And the offline node doesn't really need the blockchain or to be synced so having a pruned blockchain on it isn't going to be an problem.

Also, please post an example command that you've used during import (same syntax with placehodler descriptors)
So that we can check if there's something wrong with it.

"[{   \"desc\": \"pkh([527***********48a/44FJYb****************************************wXgyZ/1/*)#g43dxkh8\", \"timestamp\": 1606236840, \"active\": true,  \"internal\": true,      \"range\": [        0,        999      ],      \"next\": 0,      \"next_index\": 0    }]"

This is the descriptor, not the whole command.
But your next reply already got it covered so you don't have to follow-up on this.

I managed to get the syntax right and was able to importdescriptors all in one go but i got the output below in Consloe window, something is clearly not right.

  {
    "success": false,
    "error": {
      "code": -4,
      "message": "Cannot expand descriptor. Probably because of hardened derivations without private keys provided"
 

So I'm guessing that your bitcoins are associated with those failed imports.

That error said that your offline node contains private keys that are derived with "hardened derivation",
it means that it's done in a way that the child (extended) key can't be derived with an xpub, it should be the xprv key.
So you can't use those descriptors in a watch-only setup as is. (new Bitcoin Core wallets do not use hardened keys)

One workaround here is only applicable if those aren't "sh()", "wsh()" or "tr()" descriptors that requires additional script to import.
You'll have to import each addresses or public keys individually as single address descriptors.
But I wouldn't recommend to use that as your permanent air-gap wallet setup since it doesn't utilize your extended public keys.
Only do that to send it all to a proper Air-Gap setup involving creating a new descriptor wallet on your offline Bitcoin Core
And also, use "custom change address" during send in case you're not moving all of your bitcoins because you might have imported an active change address descriptor from somewhere.

e.g. single address descriptors: pkh(pubKey), wpkh(pubKey) or addr(bitcoin_address)
In case it's not one of those types, you'll have to import the scripts properly as specified here: github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md

[calkob]

The offline node/wallet is pruned, that is where i am getting the descriptors from, would that make a differance? The watch only node/wallet has full history

Then there should be no issue on the rescanning part on the online side.
And the offline node doesn't really need the blockchain or to be synced so having a pruned blockchain on it isn't going to be an problem.

Also, please post an example command that you've used during import (same syntax with placehodler descriptors)
So that we can check if there's something wrong with it.

"[{   \"desc\": \"pkh([527***********48a/44FJYb****************************************wXgyZ/1/*)#g43dxkh8\", \"timestamp\": 1606236840, \"active\": true,  \"internal\": true,      \"range\": [        0,        999      ],      \"next\": 0,      \"next_index\": 0    }]"

This is the descriptor, not the whole command.
But your next reply already got it covered so you don't have to follow-up on this.

I managed to get the syntax right and was able to importdescriptors all in one go but i got the output below in Consloe window, something is clearly not right.

  {
    "success": false,
    "error": {
      "code": -4,
      "message": "Cannot expand descriptor. Probably because of hardened derivations without private keys provided"
 

So I'm guessing that your bitcoins are associated with those failed imports.

That error said that your offline node contains private keys that are derived with "hardened derivation",
it means that it's done in a way that the child (extended) key can't be derived with an xpub, it should be the xprv key.
So you can't use those descriptors in a watch-only setup as is. (new Bitcoin Core wallets do not use hardened keys)

One workaround here is only applicable if those aren't "sh()", "wsh()" or "tr()" descriptors that requires additional script to import.
You'll have to import each addresses or public keys individually as single address descriptors.
But I wouldn't recommend to use that as your permanent air-gap wallet setup since it doesn't utilize your extended public keys.
Only do that to send it all to a proper Air-Gap setup involving creating a new descriptor wallet on your offline Bitcoin Core
And also, use "custom change address" during send in case you're not moving all of your bitcoins because you might have imported an active change address descriptor from somewhere.

e.g. single address descriptors: pkh(pubKey), wpkh(pubKey) or addr(bitcoin_address)
In case it's not one of those types, you'll have to import the scripts properly as specified here: github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md

Many thanks for the help and replies.  I created the wallet around 2020 and migrated it only recently so i am guessing it does not migrate perfectly.  All the failed imports are of the "combo" type if that means anything? 

probably easier to just crete a new wallet set up at this point and move them over.  Can anyone advise on the best way of doing this without having to expose my wallet to the internet?  like can i create a PSBT on the offline node and broadcast it on the online one under a differnet wallet? or even via sparrow or something?

[Cricktor]

I've used combo() descriptors with single public keys for watch-only wallets without issues.

• combo(0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798) describes any P2PK, P2PKH, P2WPKH, or P2SH-P2WPKH output with the specified public key.

• combo(KEY) (top level only): an alias for the collection of pk(KEY) and pkh(KEY), defined in BIP 384. If the key is compressed, it also includes wpkh(KEY) and sh(wpkh(KEY)).

I haven't tried it yet and assume that instead of a single public key it's possible to provide a "BIP32 extended pubkey with derivation path" as is described in one of bullet points of https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#features, but this can't be a hardened derivation path according to the error message you got (also mentioned by nc50lc).

Can you provide what's inside your combo() descriptor, of course properly and sufficiently redacted, but leave derivation path details as is if there are any?

Did you use listdescriptors without any argument or did you use listdescriptors true to output your set of descriptors from your pruned (offline) wallet?

[calkob]

I've used combo() descriptors with single public keys for watch-only wallets without issues.

• combo(0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798) describes any P2PK, P2PKH, P2WPKH, or P2SH-P2WPKH output with the specified public key.

• combo(KEY) (top level only): an alias for the collection of pk(KEY) and pkh(KEY), defined in BIP 384. If the key is compressed, it also includes wpkh(KEY) and sh(wpkh(KEY)).

I haven't tried it yet and assume that instead of a single public key it's possible to provide a "BIP32 extended pubkey with derivation path" as is described in one of bullet points of https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#features, but this can't be a hardened derivation path according to the error message you got (also mentioned by nc50lc).

Can you provide what's inside your combo() descriptor, of course properly and sufficiently redacted, but leave derivation path details as is if there are any?

{

      \"desc\": \"combo(xpub**redacted***3a/0h/1h/*h)#q8hvyu4q\",

      \"timestamp\": 1546300800,

      \"active\": false,

      \"range\": [

        0,

        999

      ],

      \"next\": 0,

      \"next_index\": 0

    }]"

This is an example of one, there are 4 of them that failed

Did you use listdescriptors without any argument or did you use listdescriptors true to output your set of descriptors from your pruned (offline) wallet?

I used listdescriptors without argument to get just the XPUB.

[nc50lc]

Many thanks for the help and replies.  I created the wallet around 2020 and migrated it only recently so i am guessing it does not migrate perfectly.  All the failed imports are of the "combo" type if that means anything?  

It's not about the script type, "combo" is just the combination of the common script types used by Bitcoin Core, excluding "tr()".

The actual issue is the derivation path from master private key to the addresses' private keys, which what I've explained earlier.
So those "combo(xpub)" descriptors containing hardened derivation (number followed by h or ') after the xpub key can't be imported to a watch-only wallet.
Only the xprv key can derive those keys.

[Cricktor]

...

IIRC and Google Gemini also confirms that

Bitcoin Core has used a fully hardened hierarchical deterministic (HD) key derivation scheme (traditionally m/0'/0'/k') for its internal deterministic wallets since the feature was introduced in Bitcoin Core 0.13.0 (released in 2016).

Details of Bitcoin Core Derivation

• Derivation Path: Internal HD wallets use the fully hardened path scheme m/0'/0'/k' for receiving keys (and m/0'/1'/k' for change keys).

Here m/0'/0'/k' is the same as m/0h/0h/kh.


I'm a bit surprised that your listdescriptors command might have output an impossible to derive, due to fully hardened derivation path, combo(xpub**redacted***3a/0h/1h/*h)#q8hvyu4q (this particular descriptor is for change addresses and is only working as combo(xprv.../0h/1h/*h)#<checksum tbd>).

Your descriptor timestamp epoch value translates to Tue Jan 01 2019 00:00:00 GMT+0000; looks a bit too rounded, but anyway doesn't really matter here.

[calkob]

Many thanks for the help and replies.  I created the wallet around 2020 and migrated it only recently so i am guessing it does not migrate perfectly.  All the failed imports are of the "combo" type if that means anything?  

It's not about the script type, "combo" is just the combination of the common script types used by Bitcoin Core, excluding "tr()".

The actual issue is the derivation path from master private key to the addresses' private keys, which what I've explained earlier.
So those "combo(xpub)" descriptors containing hardened derivation (number followed by h or ') after the xpub key can't be imported to a watch-only wallet.
Only the xprv key can derive those keys.

Ok so am i to take from this that it is not possible to have a watch only wallet for an old wallet.dat that has been migrated? as you are saying it needs the xprv.

...

IIRC and Google Gemini also confirms that

Bitcoin Core has used a fully hardened hierarchical deterministic (HD) key derivation scheme (traditionally m/0'/0'/k') for its internal deterministic wallets since the feature was introduced in Bitcoin Core 0.13.0 (released in 2016).

Details of Bitcoin Core Derivation

• Derivation Path: Internal HD wallets use the fully hardened path scheme m/0'/0'/k' for receiving keys (and m/0'/1'/k' for change keys).

Here m/0'/0'/k' is the same as m/0h/0h/kh.


I'm a bit surprised that your listdescriptors command might have output an impossible to derive, due to fully hardened derivation path, combo(xpub**redacted***3a/0h/1h/*h)#q8hvyu4q (this particular descriptor is for change addresses and is only working as combo(xprv.../0h/1h/*h)#<checksum tbd>).

Your descriptor timestamp epoch value translates to Tue Jan 01 2019 00:00:00 GMT+0000; looks a bit too rounded, but anyway doesn't really matter here.

Thanks, i am giving up on this now as it is beyond my tech level, thanks for the help.  Regarding the timestamp i changed it to that as i know the wallet received inputs sometime after that date and not before.  Thanks again.


One final question rather than opening a new thread.

I have created a brand new offline core wallet and listed descriptors, transferring them to an online node i have running.  i imported them descriptors as watchonly and checked the 1st receiving address was the same, it wasn't......

The 2nd and 3rd addresses are tho, is there a reason that the online watchonly wallet would ignore the 1st address? is that expected behavior?  i hadn't sent any bitcoin to it so it wasn't ignoring it because it was a used address.  

Thanks again for the help

[Cricktor]

You're not that new to the forum, how about paying attention to not post consecutive posts which is a violation to forum rule #32?

Have you created the new watch-only wallet first empty and then imported the watch-only descriptors?

For the address that you couldn't match, is the output of getaddressinfo "your-1st-bitcoin-address" on your offline wallet and your online watch-only wallet almost the same?

Have you compared that the ranges listed with listdescriptors are the same for your offline and online wallet and especially what the numbers for next and next_index are?

Code:

...
      "range" : [                 (json array, optional) Defined only for ranged descriptors
        n,                        (numeric) Range start inclusive
        n                         (numeric) Range end inclusive
      ],
      "next" : n,                 (numeric, optional) Same as next_index field. Kept for compatibility reason.
      "next_index" : n            (numeric, optional) The next index to generate addresses from; defined only for ranged descriptors
...

Otherwise I've no idea why the first requested receive address didn't match, but the 2^nd and 3^rd did. It's hard to tell because we don't know what exactly you did with the wallets. Sounds like you left the wallets verbatim, but... oh, well...

[nc50lc]

Many thanks for the help and replies.  I created the wallet around 2020 and migrated it only recently so i am guessing it does not migrate perfectly.  All the failed imports are of the "combo" type if that means anything?  

-snip- So those "combo(xpub)" descriptors containing hardened derivation (number followed by h or ') after the xpub key can't be imported to a watch-only wallet.
Only the xprv key can derive those keys.

Ok so am i to take from this that it is not possible to have a watch only wallet for an old wallet.dat that has been migrated? as you are saying it needs the xprv.

Yes, but exclusively to those descriptors with hardened derivation path.

As I've mentioned in my earlier reply, there are workarounds to that and I've explained one which is to import your addresses via addr() descriptors instead.
With the updated info, it's more fitting to use combo(pubKey) of each address_index's public key if you have the time to get them all via getaddressinfo or some other method.

If you want to do the former: You can use a non-migrated copy of the wallet.dat file and open it with Bitcoin Core v0.29.x with --addresstype=legacy and use dumpwallet to dump its addresses (prvKeys included),
Then import those to your watch-only wallet.
(repeat it with --addresstype=bech32 to export your native SegWit addresses)

Or based from you updated info: To include your combo descriptor's Nested SegWit addresses including legacy and SegWit; do the above but you'll only need to dump once.
But instead of address and addr() descriptors, you should get each of the address' (per address_index) public key and use combo(pubKey) to import those instead.
If it's taking a while to import all 1000+1000 reserved pubkeys, do that by 100s per external and internal chains.
(e.g. from m/0'/0'/0' to m/0'/0'/99' and for change m/0'/1'/0' to m/0'/1'/99')

Then, you can use that to create transactions in the online Bitcoin Core that the offline Core can sign to send your bitcoins to a new Bitcoin Core Cold-Storage setup.