Is the export-import process for descriptors poorly designed?

I think I've stumbled upon a flaw in the workflow. For about a month now, I’ve been trying to set up a system with two laptops, one online and one offline, using the PSBT method for quickly creating transactions via the GUI. I want to utilize Coin Control, select the UTXOs I need for my transaction, generate a PSBT file, sign it offline, and then broadcast it through the online machine. But here's the catch: I'm dealing with an older wallet, so I need to do a wallet migration to convert it. To handle PSBTs, I need the address descriptors from this new wallet format. I’m guessing that choosing "File->Migrate Wallet" will upgrade the old 2013 wallet I have (not sure of the exact version used, but it’s from around 2013) into the new format. Also, I hope this doesn’t mess up my wallet.dat file during the migration. I’d appreciate tips on checking if the migration went smoothly. Then I should be able to use PSBTs with this new wallet, but I’ll also need to create a watch-only wallet for the updated format. Can someone confirm if this process is accurate? I suspect these instructions might have been put together with some AI assistance. I haven’t attempted this yet, but according to the steps, the first action is to use "File->Migrate Wallet". This should give me the new wallet.dat file though I’m unsure if it replaces the old one. After that, I can export the descriptor data from it and import it into the watch-only wallet I just set up on my online laptop.

You can use getaddressinfo on a bunch of your addresses and check that the wallet says "ismine": true for them. You can use listunspent before and after migration to verify that the wallet knows the same UTXOs. You can use listtransactions before and after migration to verify that the wallet knows the same transactions. It overwrites the original wallet.dat file, but a backup of the original is created at the start of the migration process. That backup can be restored manually (by copying the file, or by using restorewallet or File > Restore Wallet), and is also restored automatically if the migration fails so that you don't have a wallet that is partially migrated. I opened a PR a couple weeks ago to produce the watch-only wallet file directly instead of having to do the import stuff: https://github.com/bitcoin/bitcoin/pull/32489. There's a followup PR to add a menu action to the GUI to do that: https://github.com/bitcoin-core/gui/pull/872 This was slightly complicated to do because of the legacy wallet code. But with it removed, the implementation becomes much simpler. There was a PR to add import things to the GUI but it was closed after a couple years of not getting any review. Everything in the "descriptors" field, i.e. everything after the opening square bracket, to the matching close square bracket, including the brackets themselves. The contents of the descriptors do not need to be modified and are intentionally such that the whole thing can be copy-pasted into importdescriptors. Nothing, those are optional fields.

I will try to get it done and see what happens. The only thing im not convinced is deprecating the old wallet format. There's people that are paranoid of using HD-wallets. For instance with the quantum thing, if someone had one of these extended public keys, then who know was kind of derivation attacks could be performed. I generally don't like the idea of "this string of characters gives you access to all existing and future addresses on the wallet". If you have the old wallet, it may be more annoying to use, you need to do constant backups as you generate new keys, and you don't have ease of use features like PSBT, but you don't have that risk, they would need to know each of your public keys separately. This gives you more margin in trying to move funds in for instance, the quantum scenario. You could move your funds to whatever QC resistant solution is out there eventually, with a better peace of mind, since at least, it's one public address-one private key type of deal. So there should be ways to not lock people's funds for those that use older wallets, forcing them to run older software to be able to do anything with the money.

Conversely, a proposed method for spending vulnerable coins post-quantum computers is to provide a zero knowledge proof of the master key and derivation path to the key. HD wallets have these other semi-private info that can make it easier to recover vulnerable funds in the event of a sudden quantum computer. ... You can do that too with HD wallets, it's not as if the people using HD wallets are not going to be able to migrate to a post quantum method. This concern makes no sense to me. Your existing funds aren't locked. You can migrate a non-HD wallet, and while that will change how new addresses are generated, already generated addresses and their associated addresses will still be spendable. Migration does not move any funds.

What I meant is, if you choose to stay with the old wallet format, you are pretty much stuck using older versions forever now, at least if you want to use Core, im not sure what Knots will do with this thing. Btw, what about labels? I always have transactions ordered with a label to know where coins are from, I also do this with sending addresses. Well my question is, when you use listdescriptors false to copypaste this into the .json file, will it include each label for each address? Because if in the watch-only wallet you just get a bunch addresses with no context, then im not sure what is going on there. I need the labels so in Coin Control you know exactly what coins you are moving.

Labels are not included in the listdescriptors output.

Wait so what then? How im supposed to tell which coins im using in a transaction if I have hundreds of addresses there without the labels? I thought "label" on the .json would include the labels but apparently that's something else... so there's no way to do this? Without the labels this is completely useless, I just don't know what im even looking at, just a bunch of addresses with no context, this is so lame. There isn't even a way to do this manually? I'll need to go one by one, what a nightmare. Anyway, hopefully there is a workaround, otherwise I really don't see how im going to use this.

You can apply the labels manually. Not at this time. importdescriptors can take a label, but only for descriptors that map to a single address (i.e. descriptors which can derive multiple addresses because they use BIP 32 cannot take a label). Furthermore, labels are applied to addresses, not to labels, so exporting all of the descriptors will not result in any associated labels. The workaround is the PRs I mentioned earlier. Labels and other metadata are why I implemented a wallet file export rather than an easier way to import descriptors.

Could you please explain what is the correct way to do this manually? Where is the context for each address located? What is at least in Coin Control showing as "Label" that is (not my pic btw because I cannot login to my node now, I was able to find this pic from 2015, hopefully it looks the same now) https://i.sstatic.net/yUXEX.png I don't remember right now what options the right-click dropdown menu gives you, but I reckon there was no way to edit the labels from the GUI in there, so I guess this has to be done before you import things, in this .json file from listdescriptors false I guess? But where does it go? How are is this from being merged? And do you think Knots would be ok with merging these PR's?

Window > Receiving Addresses for the labels on your addresses. No, labels can be edited after the fact, at any time. From the GUI, in the Receiving Addresses window, you can open the context menu (right click) and choose Edit, or double click the label to edit. You can add labels using the setlabel RPC. A few months probably, it is still waiting for more review. The soonest it can be in a release is v31 which is scheduled for 7 months from now. Probably, but I would not expect knots to do a release sooner. Also, Luke generally merges PRs before their final state in Core, and long before they have had sufficient review so I would not necessarily expect everything to work as expected.

Right so what would you recommend? Once I have imported the .json file with importdescriptors (by copy-pasting the output of listdescriptors false contained between [ ... ] as we discuses earlier) then you would go address by address with the GUI and open receiving addresses window on both the watch-only and the offline wallet and then just look at the offline wallet labels, and one by one add the missing labels there? Will the receiving addresses show up in order in both wallets? because there is no "time created" row or something (not my pic) So what I mean is, will it show in order: "Used in coinfaucet.eu" "Test1" "Test2" Or will it be out of order? because then that will be a nightmare, trying to manually find each address that matches with the label of the address on the offline wallet which has the labels to add them on the watch-only wallet. If at least it's just all nicely tied up in order then I guess I could get this done manually. So basically, the Label set on "Receiving addresses" controls the "Label" seen in any other section? Like on the "Sending addresses" window and on the "Coin Control" window? You cannot modify the "Label" anywhere else but on the "Recieving addresses" section so I assume what you put there then it shows up everywhere else that will show a label. What I want is to have the labels showing up on Coin Control. To do this, you have to edit the receiving addresses by adding the labels there one by one? Im just asking what is the best method to get this done because if you've got 100's of payments it's going to be a fun evening doing this manually and triple checking each address has the right label. It just seems like a recipe for disaster. You type the wrong label, make a transaction and now you moved the wrong funds. I sure hope this gets properly implemented because right now it seems like a mess doing this.

I don't think you will be able to add the labels through the GUI. I'm pretty sure addresses without a label won't be shown in the GUI, and all of those addresses after the import won't have a label. Instead, you will have to use the setlabel RPC, which takes the label string, and the address to apply the label to. That also means that the order doesn't matter. Once they are labeled, yes. The sort order is based on the internal representation of the address, not any other metadata.

Why not? Addresses without a label show as (no label) And if you right click on that window, it opens a window that says "Edit receiving address" and allows you to change the label. I put "test" there and it changed it. I deleted the "test" label and went back to (no label). I have not synced this wallet so I don't know if this would have an impact on transactions that have been completed and show on the transaction list or "Sending addresses". Well in any case, this is going to be annoying af. How im supposed to manually enter each label for 100's of addresses that are basically gibberish? Like what would you do with this? No way I don't eventually enter the wrong label on the wrong address. I don't even trust that listdescriptors json import thing is going to list all off my public addresses, I have this paranoid feeling that some BTCs will be missing or something. I may need to put the wallet file in the online node for a moment with no internet and see if all the funds are there, then shred the file. Otherwise I may think that some addresses didn't get properly ported during the migration process and then wrongly translated in this json file or something. Plus the problem of having to match 100's of addresses with no label with the correct label. Im not sure how to go from there.

Those addresses have an address book entry with an empty string as the label. They have an address book entry because they were requested from the wallet through getnewaddress or in the Receive tab of the GUI. When the address was requested, an address book entry was created for it. When you import a descriptor, it does not always create an address book entry for the addresses. For descriptors which involve BIP 32 derivation, address book entries will not be created. For descriptors that specify a single address, an address book entry will be created, and those will either have the label you provide, or an empty string (no label).

So what im supposed to do then? Still haven't heard how does one solve this situation. You've got 100 addresses, each one has it's own label. What do you do? Having a wallet with no labels is useless, since you may mix up 2 addresses that you shouldn't in a transaction and then you are screwed. Plus it's basically useless since you don't know what funds belong to what context. Wtf im supposed to do with this now.

Use the setlabel RPC, as I have explained to you multiple times in this thread. It works on any address, because the address is provided as an argument.

Yeah, not possible to do this manually with 100's of addresses, good luck with that. Definitely badly implemented, hopefully this is improved so it's done automatically, i'll pass on this for now. Btw, im still testing with testnet wallets anyway and importdescriptors doesn't work, it says "Error: invalid syntax." I have used "importdescriptors ["the stuff here after ""descriptors": " until the last ] including the []'s" but it doesn't work.

Not necessarily to the last ], but to the one that matches. The brackets always come in pairs, you're probably missing one or have one extra.

Yes, I have double checked that im copypasting the right ones. This is the listdescriptors false output for my test wallet for testnet where I got some testnet coins in different addresses: Im pasting the green part. "importdescriptors greenpart" Result: the syntax error I was talking about. So what's up with that?

If you're using the RPC console, you need to surround the entire JSON with single quotes ('), otherwise it will have some parsing issues. If you are using a shell, you may need to do the same, or otherwise escape the double quotes (").