Are you referring to to the "migrate" command in your other post?

If so, that command will automatically create a backup of the wallet.dat for you, it'll be saved in the same directory of the upgraded wallet.dat file as ".bak" file.
You can also create your own copies before migrating if you prefer.
And it will not touch your blockchain files and settings as well.

The instructions suggests that SLIP39's "Master Secret" is equal to the entropy used to generate BIP39 mnemonic.
Thus it's possible to covert and revert.

But the examples in the repository doesn't restore the same set of keys when restored to Electrum's SLIP39 restore option.
Reproducing it with random BIP39 seed produces the same result as well.
Perhaps an issue with Electrum's implementation?

(Saint-loup's original query is related to Electrum BTW)

You probably meant: "listdescriptors false"
Yes, that's if you already know which descriptors to pick, otherwise you may miss one with associated UTXO if you wont export all.

You can download an old version of Bitcoin Core, start it  with datadir pointing to your preferred temporary test datadir.
Even if it's done in the same machine, that shouldn't interfere with your current setup.

Is there any reference that can back-up this claim?
Perhaps it's related to Electrum's existing seed phrase version number which indicates which script type the wallet should be.
Implementing a multi-script wallet will make that feature obsolete.

Even one of the main developer has this issue opened:
Implement advanced wallet option: multiple xpubs, mixed script types, and similar (maybe with output script descriptors) #6016

What version of Electrum are you using?
If it's as old as v3.3.x, most of the servers will prevent you from connecting.

If not and there's no issue in your network, try to enable logging to check if you can find the issue there.
You can enable it in "Tools->Preferences->Misc->Write logs to file" (restart Electrum and try to connect to a server),
Close Electrum, then check the latest log file in "electrum/logs" directory. (electrum datadir default loc)

Both are true.
It'll set an HD key to be used for its new active HD descriptors (for your new addresses).
And the previous loose keys are converted to single-key descriptors like: pkh(WIF) or combo(WIF).
Of course, the new HD parent descriptors can't be related to your old non-HD keys.

If you're interested on an alternative, there's a way to skip that:
Copy an updated blockchain to the offline machine, reindex your offline Bitcoin Core, rescan for txns, then create, sign & export the transaction to the online node.

To do that, simply copy your own online Bitcoin Node's "blocks" folder (you may exclude the "index" folder inside) to an external drive and paste it to the offline machine's node's datadir.
Then start your offline Node with --reindex and it'll create its own index and chainstate directories. (this will take hours to finish, but it will not fully sync since it's offline).
With an updated blockchain, even offline, you can load and rescan (up to the last available block) your wallet and create a transaction there. (manually set the fee)
Just export it to the online machine once it's signed to be broadcasted.

After you spent the bitcoins from the old wallet, create a new wallet so that you can set-up a normal cold-storage setup.

Both are true.
It'll set an HD key to be used for its new active HD descriptors (for your new addresses).
And the previous loose keys are converted to single-key descriptors like: pkh(WIF) or combo(WIF).
Of course, the new HD parent descriptors can't be related to your old non-HD keys.

If you're interested on an alternative, there's a way to skip that:
Plug an external drive that has an updated blockchain to the offline machine, reindex your offline Bitcoin Core, rescan for txns, then create, sign & export the transaction to the online node.

To do that, simply copy your own online Bitcoin Node's "blocks" folder (you may exclude the "index" folder inside) and paste it to the offline machine's node's datdir.
Then start your offline Node with --reindex and it'll create its own index and chainstate directories. (this will take hours to finish).
With a blockchain, even offline, you can load and rescan your wallet and create a transaction there.
Just export it to the online machine once it's signed.

There's no ETA but it can't be the next major release since the PR containing the change is still in "draft" status.
As of now, I can't see it in v30.0 and v31.0's milestones.

You can bookmark this to know when it'll be released: https://github.com/bitcoin/bitcoin/pull/31974
And here's where the discussions are: https://github.com/bitcoin/bitcoin/issues/31975

Speaking of technical possibilities, you got the wrong answer.
My last "off-topic" reply has a clue on it, I though you'd notice since you seem confident to know the right answers despite being the one who's asking.

You see, I mentioned "standard" there.
Meaning, it's not a "consensus rule" that every Bitcoin node enforce, it's just a policy that's set by a config.
The values that are presented to you are based from the default setting (3000sat/kvB x UTXO's projected input vsize) which is mostly likely used by the majority of the nodes.
The setting is based of: github.com/bitcoin/bitcoin/blob/master/src/policy/policy.h#L59-L64
Which can be set as --dustrelayfee command line arg or dustrelayfee=<sat/kvB> config in bitcoin.conf file to a lower value than the default.
With that, it's a matter of finding the right peers and miners that has lower settings for it to get relayed and mined.
In short, it's not impossible but rather, very hard to achieve.

And there's lightning network where the service can request such dust amount of BTC.

Anyways, I wont be bothering you anymore.
Cheers.

It's just your last post contains rants that could use some clarification.
Disclosing the service's name would also help others to stay away from the service before they even think of using it.

And lastly, the verdict is almost one-sided where it's not known if it's actually asking for on-chain transaction where it's really not "standard" to send lower than dust or something else.

It's just a suggestion though, you can ignore it if you don't want to.

No, just one, let's say "main server" of your choice.
The rest (peers) are just for security purposes since you can't just trust that a random public server is giving you accurate information.

We have a "Reputation" board here in the forum, link: /index.php?board=129.0

If you think that the service deserves a minor stain on their reputation, you may post a new topic in that board including the full detail of the situation.
People there are usually good on judging whether you claims are valid or not.
(or if you post the service's name here, that could shed a light on what's actually happening)

But take note that such issue isn't qualified for a negative rating in case they have a Bitcointalk profile.

Electrum will start without errors since the arg is valid.
But it will only accept the last --server arg because although all were parsed, the first --server arg is overwritten by the next, and so on.

e.g. (command):
e.g.: (logs):
Picked the last --server arg but the others are still random. Switching the last --server will make it the manually selected server.

Same thing happens if you force to edit the config file to have more than one "server":"<server>", line.
Only the last one will be accepted and the rest will be deleted once the config auto-updates.

But for clarification, those "other servers" aren't used like the selected server.
Those are mainly used for fork detection, your client will only request for "block_headers" so they will know know your bitcoin addresses.

Your first reply has a clue on this.

It may say 7.2Gi "available" memory, but that's after the 7.2Gi "buff/cache" are written to your disk.
Given that Core is already using the drive extensively, increasing the database cache doesn't help as much
since it will otherwise require your OS to swap more memory, further increasing the disk usage.

In the console, no.
In your debug.log, if applied, it should show as "Assuming ancestors of block <hash> have valid signatures".
But it wont tell you if the hash you provided is valid (in case of the typo or wrong chain)

Just drop the "--" for it to work in the GUI, use: help

Now that you mentioned it (separate test chains), you can minimize those screw-ups if your put the configs under their respective tags.

Settings exclusively for mainnet can be put under [main] tag. That way, it wont be applied to testnet 3/4 and regtest.
Here's one example conf. applicable to v29.0:

Are you pertaining to your bitcoin.conf file?
If so, those options should work but if you want it to apply to testnet4 only, put it under [testnet4] line.
Else, mainnet and other test chains will try to read the config with hash from the wrong chain.

e.g.:

For clarification, that "test_bitcoin" executable in bin/daemon directory isn't for launching the node in testnet3 nor testnet4.
That's for unit test purposes.
You must run bitcoind or bitcoin-qt with --testnet (testnet3) or --testnet4 arg to launch it in testnet.

If you're also talking about the shortcut in Windows when you used the installer (set-up) version,
It's in testnet3 since the shortcut has --testnet arg when you check its parameters.

And what does the error said?
It could be vague sometimes but the error should be able to point you to the issue.

For example: if it says "Data is not in recognized format", the wallet.dat may be corrupted but it doesn't tell if the keys in it are damaged.
That case might be solved by using "salvage" command of Core's bitcoin-wallet tool if the wallet has intact keys.
Note: if you're going to research how to do that method, please use a copy of your wallet.dat file and not the main backup.

Do this:

• Open Bitcoin Core (GUI)
• Select the wallet in the drop-down menu if you have multiple wallets loaded.
• Check the HD icon on the lower-right-hand side of Bitcoin Core, it's crossed-out if the selected wallet isn't HD.

For non-HD wallet; no, there's not other way but to import each public key to the watch-only wallet since those aren't derived from a single master key.
For HD wallet, you'll just need to import the parent descriptors (that has xpub) to the watch-only wallet.

Haven't you tried it yet since you posted the OP (almost 4 months ago)
And your edit added a note that it's answered already.

If you missed it, my very first reply is applicable for lightweight clients like Feather wallet.
The comparison to Electrum is due to it being one the fastest you can have for Monero without sacrificing your private view key to a third-party, but the speed isn't close to Electrum.
Monero and Bitcoin work differently.