If you want to use /Volumes/Crucial\ X8/bitcoin/Bitcoin/testnet3 dir as your testnet dir;
You should use: bitcoind --datadir=/Volumes/Crucial\ X8/bitcoin/Bitcoin --testnet instead.
Since it's set to -testnet, it will automatically create a "/testnet3" folder in the specified -datadir.

Wallets have to be manually loaded and set to be loaded on startup if you prefer,
Use the command: $ bitcoin-cli --datadir=/Volumes/Crucial\ X8/bitcoin/Bitcoin --testnet loadwallet "walletname" true
Set to "false" if you don't want it to load in the next session.

Why?
Without a valid reason, no one will think about creating a dedicated testnet wallet for you for free.
If you're willing to pay (in bitcoins, not testnet coins), you can post it in the services board: /index.php?board=52.0

What's the difference in using Bitcoin Core: bitcoin-qt --testnet? That should work if you need the whole testnet blockchain and a wallet.
Otherwise, any other wallet that supports testnet will do.

It's not what OP was asking though.
He already did that, thus raised his concern whether his old keys are still in the migrated wallet.
That was already answered "yes".

Also, it's not from "legacy to HD", it's from "legacy to descriptor", even HD legacy wallets can be migrated to a descriptor wallet.
Old non-HD wallets can be converted to HD with sethdseed command even if the user do not want it to be migrated to a descriptor wallet.

Since it from an exchange where the actual error message isn't provided, I can only guess,
My best guesses are the usual reasons that I've already provided.

To expand the "liquidity" issue, even famous Exchanges sometimes experience that issue when there's too much volume flowing in their payment channels.
Their channels' amount simply cannot accommodate the requested amount.
To expand the "routing" issue, it could be a combination of your invoice lacking the necessary "route hint" (issue at your end)
and/or their node simply cannot find a route to your channel (issue at either end).

Switching to "Gossip" and waiting for full lightning network connection could get your Electrum better routing but it wont fix the issue if it's the Exchange's channel's fault.

Unfortunately, the forum stopped collecting donations long since it stopped granting "Donator" and "VIP" title.
You can refer to the forum menu: "More->About donations" for the reason and for more information.

Also, ignore PMs referring to themselves as forum representative or similar who ask for donations/tip.

Since there's high inbound liquidity and there's a previous successful lightning transaction,
This could be a "routing issue" which means that the Exchange's channel cannot find a route to your channel due to liquidity or actual routing.
This may be temporary (at their end) or long term.

Since Electrum uses "trampoline routing" by default and failed at that attempt, try to temporarily disable it in the settings under "Preferences->Trampoline routing".
Then in the main tab, wait for the Lightning icon to get full/quarter yellow, to see its progress, go to 'Network' settings and check the "Gossip" under Lightning.
Once it's fully established (a few minutes), create a new invoice to test a new withdrawal from the Exchange.

BTW, don't close Electrum while waiting for the transaction to finish.
If you did it the first try, then try it again without closing Electrum, and keep trampoline routing since Gossip is quite resource expensive and slow.

Yes, Lightning Transactions "could" be cheap, almost as cheap as 0 to some satoshi depending on the route.

However, to send or receive through lightning in Electrum, you'll need a "Channel",
And that's where the 0.002BTC will be... let's say "transferred", you basically put your on-chain funds to your lightning funds in a form of a channel.
Under the hood, your 0.002BTC is sent (on-chain) to a MultiSig output that you and the remote node control but in a way that either can spend if the other party cheats or unreachable.
Refer to "Mastering Lightning Network" book for more info.

That established channel can't only be used to make "a lightning transaction" but every lightning transaction (to anyone) that you'll make as long as there's enough fund and route.
So this may only need to be done once.

But a slight correction to "minimal transaction fee", I said "could" because there are scenarios when the destination and the source had to take "a lot" of routes to send the intended amount.
Those payment channels that's used to route the transaction, although charge relatively small fee could pile into something expensive if a lot of them are used to route the transaction.
AFAIK, there's someone reported something similar in this board where I replied a workaround.

You misquoted this part.

---

Now that we're at it,
@PepeTalk as for that question, Lightning network doesn't have a blockchain and the transactions are done off-chain in the Lightning Network.
Means that your lightning transactions wont appear in Blockexplorers.
But as _act_ said, Binance knows that you've withdrawn Bitcoins through lightning and if you've opened the channel with their node,
they can directly know your transactions and the on-chain "close channel" transaction once you closed the channel.

That "77 confirmations" amounts to 77 x 10 minutes (average block time) = 770 minutes / 13 hours (average) of being confirmed.
Then it's just about 3 hours since you've posted the OP where you said it's still unconfirmed.
So it's actually confirmed way before this thread is posted.

That said, there may had been an inconsistency in your database or at least in the wallet's transactions that left that transaction's status unconfirmed.
Performing Rebuild may have "corrected" it or at least the Rescan afterwards.

It's been a while since I've used Binance but last time I checked there's a lightning deposit/withdraw option.
Electrum supports lightning as well so if you can confirm that Binance still has lightning options, then, yes it's possible.

Here are the basic steps: Firstly, enable lightning in "Wallet->Information"; Secondly, open a channel which requires about 0.002BTC onchain BTC to fund that channel.
(may be higher depending on the remote node)
Lastly, wait for confirmations until the channel status turns to "open".
After that, your 'Receive' tab will now have the option to create lightning invoice by toggling the "Address/URI/Lighting" button at the right. (desktop Electrum)
And Pasting a lightning invoice in the send tab will automatically send using your channels.

The setback here is "how".
Electrum's lightning isn't custodial so you'll have to manage your channels yourself, that includes its spending and receiving capacity.
And a newly opened channel (by you) wont contain any receiving capacity so you'll have to use your sending capacity first
by sending to Binance or other lightning wallets first to gain as much receiving capacity (minus reserve).
You can check the capacity: "can send/receive" in the 'Channels' tab.

With that, it'll never gonna work if it's just "send from - send to" since the difference in the amounts will be a problem to either receiving and sending capacity.
So, you may have to use a "swap/reverse swap" service to gain enough receiving capacity,
of course swap only the right amount that wont drain your sending capacity.

Hmm, just emphasize the solution that actual solved the issue in your next reply, then check who's the first to provide that solution.
But since your case solved itself overtime (a simple screenshot will confirm it), you can safely conclude that no one actually given the correct solution.

But if you really want to give the reward, give it to someone who deserves it the most or who took the most effort to help you.
Don't count me in the candidates, BTW.

That's because he didn't mentioned that the derivation path will only show once you enabled it in the settings.
It's in "menu (three dots)->Settings", then toggle the setting "Show address path".

It's also worth mentioning that the secondary account's path should be at account_index 1' (starts with 0' for primary) instead of 2' which is for the third.
See that in his screenshot, it's showing "Ethereum 3".

Have you used --passwordlist intead of --token?
If so, it could be the reason for the very small iterations which is as much line as the passwordlist, if not used with certain "typo" args.

Your choices are either:

• Use --token your-tokens.txt ∙ then use the same "your-tokens.txt" in your example.
• Use --passwordlist your-passwordlist.txt --has-wildcards ∙ then use a single line of "your-passwordlist.txt" instead: ASDFGHj12%7,9d

No, as long as you don't compromise even a single private key from your air-gap wallet.
Otherwise, the only risk is your privacy in case the watching-only wallet's extended public keys are compromised.

As a heads-up, Bitcoin Core already taken the necessary precaution against that by disallowing the exportation of individual private key from a descriptor wallet.
There are workarounds to do so but be aware that the "extended private key" pair of the watching-only wallet's "extended public key" can be computed from any of its child private key.
So if you ever require to export a key for whatever reason, do everything exclusively in the same air-gap machine where the offline Core is installed.

That makes sense.

The note will be saved in the wallet file within the "notes_text": "my notes", array (visible if wallet file isn't encrypted)
But unlike transactions and invoices, the notes are only kept in RAM while the wallet is open, it'll only queue an update to the wallet file in disk after the wallet is closed.
It can be seen outside the whole wallet json object, below as: {"op": "replace", "path": "/notes_text", "value": ""}
The next time you open it, the update will be applied to "notes_text".

That's only useful if he has access to the encrypted wallet file.
Without access to the email to authenticate the login, he wont be able to get it using tools that can download it from their server.

What's troubling in Osiris100's case is the fixation of Blockchain's support in the password (unable to reset password) despite him having access to the password.
Perhaps they are misunderstanding your query that leads them to deny any request to reset your associated email address?

As far as what the so called "very way the file encryption is designed" is concerned, the email address isn't involved in that encryption as the "wallet.aes.json" file in their server can exclusively be decrypted by the password (plus second password if set).

Certainly, but not as straightforward as Electrum Cold-Storage but not too complex either.
The procedure are: create the offline wallet, export the descriptors, create the online watching-only wallet, import the descriptors.

You can refer this post for the steps: http://bitcointalk.org/index.php?topic=5392824.0
If you're using v26.0, the first step to select "descriptor" isn't unavailable due to being selected by default; the rest of the steps are still applicable.
But instead of selecting only one script type, I'd suggest to import all 4 script types to the watching-only wallet, that's a total of 8 descriptors.

You said that you've created the wallet, so you just have to remember where the "extended public key" in "keystore 2" came from.
Because a 2-of-2 MultiSig wallet cannot be created without the other cosigner's "Zpub/Ypub" which you must have gotten somewhere.

And since the extended public key format Electrum uses isn't "famous" around other wallets that sticks to "xpub", there's a high chance that it's from another Electrum.

Perhaps it's from the guide that you've followed back then?
Check the article or guide; if so, see if you can ask the author to cooperate with the signing process.

That only applies to exported fully signed raw transactions.
Even the file export (.txn) shows the same hex characters when opened as text.

If unsigned, Electrum will export it in PSBT format, via save to clipboard (base64) or file export (.psbt).

Cold-storage Electrum setup supports QR Code export and scan,
That essentially fulfills your main goal to eliminate the usage of flash drive in your setup.

Is there any particularly reasonable explanation why you must use Bitcoin Core in your Air-Gap machine instead of another offline Electrum?

Even with a total of 16, only the newly generated 8 are the "active" descriptors.
Active ones are the descriptors to be used when requesting addresses in the GUI's receive tab, change address and getnewaddress command.
The inactive descriptors prior to encryption will not be used to generate new keys/addresses but will still be able to track and sign associated transactions.

In your test, you can check each descriptor's active status in listdescriptors command.