No one even put instructions on how to do it.

Both are possible, but the latter depends on your phone's "share" feature.
And use the latest version with QML UI to follow these instructions.

For copying, it's straightforward, use "Copy" in your invoice: "Receive->Create request->Address->Copy";
or in Addresses list menu: "Click the wallet name->Addresses/Coins->Click an address->Share Icon->Copy"

For sharing to SMS app, do the above but you'll have to use the "Share" button instead of Copy,
but as I've mentioned, it depends on your phone if it enables your SMS app in the list (scroll-down or side if your SMS app isn't there)

But as mentioned by others, there are malwares that can change your clipboard so at least check the first and last 4~8 characters of the copied address.

Those "trophies" are specifically created from private keys with a very small search-space.
e.g.: starting from 0x01, 0x03, 0x07.... 0x236fb6d5ad1f43 (#54) and higher ranges.

They were merely bruteforcing private keys starting from 0x01 to their target range of the puzzle transaction (link) to match the same private key used by the creator of the puzzle.
It has nothing to do with collision.

You can't clean it, it contains the "UTXO set" based from the blocks that you've verified.

If your node is running for a few years now, re-syncing Core or --reindex-chainstate may produce a more "optimized" chainstate
but it wont be a significant change in size, maybe a reduction of 1GB at best.

Your pruned node is a full node too, it needs the chainstate to verify all the transactions that it continuously receiving from its peers.
It's increasing (at a very slow rate) because of UTXOs that are being spent and created.

Skip the steps from the start to the importation and certification of Electrum developers' public keys.
You should go straight to verify Electrum with the signature (.asc) file, of course download the new signature file that's released with that version.

Most of the questions are already covered by the previous replies.

You can send from only those 2

There's no ideal number since it depends on the wallet's use-case, but preferably, I'd go for lower number of coins but with high amount each so consolidation wont be necessary.
That way, Electrum wont have to use two or more UTXO when sending a transaction with high amount.

In case you received a lot transactions with small amounts like 10's of 0.00001BTC each,
all those 10 UTXO will be spent together as inputs if you want to send 0.000091BTC, each input increases the transaction's size significantly.
The higher the transaction's size, the higher the fee will be.

Electrum has a fee estimation algorithm; "mempool" (based from mempool size) or "ETA" (default, based on Bitcoin Core's) slider.
Select mempool and slide down near the cheapest, it'll show that it's high when... it's high, low if it's low.

I don't know either, is there any difference in "transferring" and "sending"?
I have no idea what you're talking about, perhaps you're mixing-up the earlier replies about "HD wallet" and UTXO.
Please consider reading the articles in this website: learnmeabitcoin.com/technical/

Not much since the log before the restart isn't included for comparison.
But there are indications that the datadir that it loaded doesn't have the full blockchain,
since it's after the restart from an allegedly fully synced blockchain, it shouldn't be like than unless it's an issue with your Mac or a change in the previous setting.
Plus the date doesn't match, it looks like the logs after following the first few replies. (I see it in the config)

And there are some inconsistencies like this:
That is the blocks directory and should be set as "blocksdir=" if you do not want to save the blocks inside the datadir.
Since you've set it like that, it would use "/Volumes/ext SSD/blocks" as the datadir and save the blockchain in "/Volumes/ext SSD/blocks/blocks".
Yet your node shows that it's using "/Volumes/ext SSD" as the datadir since you've set it in the GUI's welcome screen.
(assuming that there are no lines omitted in the gap in the middle of the shared logs)
Just remove the datadir setting in the bitcoin.conf file since it's incorrect and does nothing.

You can paste it inside the code tags like I've instructed in my earlier reply.
That way, it wont consume a lot of vertical space.

You can also pick the sessions that are relevant like you did in the first log that you shared.

It's syncing and currently at 535936 height.

No, "false" means that descriptors with private keys can't be imported there.
Refer to my first reply regarding that result.

The "xpub" that you were asking is listed in each of the descriptors.
You can get more information about the other data in help listdescriptors command.

Have you sent that transaction to your own address?
Because if it is your change address, Bitcoin Core wont show it in the history but will still be included to your available coins.

- It works but, with Restore, you don't have to place it inside your bitcoin data directory because...

- Because with "Restore", Bitcoin Core will create its own wallet path inside wallets folder, the folder will be named as the wallet name that you've set.
  Then it will make a copy of the wallet file that you've selected, and load it.
  Basically, all you did in post #5, but done automatically.

  With "Open", it skips all the above and proceeds to load the wallet file, but the option can only see wallets in the data directory or wallets folder.
  In this case, pasting the "wallet_fake_008.dat" in the datadir/walletsdir is necessary.
  
- Differs per wallet and machine specs.

It looks similar to my instructions here: http://bitcointalk.org/index.php?topic=5449245.msg62109703#msg62109703

The method is safe as long as it's done in an Air-Gap machine.
However, the exported private key must be kept safe at all cost because it could compromise all of the other child keys of -
its parent extended private key (xprv) if the extended public key from the wallet is compromised with it.

Unlike the legacy wallet.dat with pure hardened derivation path, the new descriptor wallet derives the receiving/change derivation paths and its child keys without "hardened" derivation.
It means that a child private key and its public parent can be used to compute its private parent key, then the rest of the descriptor's private keys with that xprv.

So, only do that if exporting the private key is really necessary.

Like I've mentioned above, checking the logs (debug.log) should point you to the right direction.
It contains command line args, configs, GUI settings that you might not have set correctly and specially errors that caused the issue.
You can post a few sessions inside [code][/code] tags, just remove some lines (for privacy purposes) if you want to.

Guessing the issue would only lead you to do unnecessary things that may even aggravate the problem.

Sorry but if you've included the next sentence in that same bitcoin-wiki article, your question would sound silly.
Since it already provided a good representation of its chance:

And it's not even an overstatement when it comes with collision.

Take note that automatically loading a "wallet.dat" file as default_wallet has these conditions:
if copied in the wallets folder, it will only be automatically loaded after a restart if there are no other wallets already loaded.
if copied in the datadir instead of wallets folder, it will only be automatically loaded after a restart if there are no other loaded wallets or "wallets" folder isn't available.
The Restore option, on the other hand, restores it by creating its own folder (wallet name) inside 'wallets' folder, copy then loads it.

Either option still subject to the same chain check procedure and rescan once Bitcoin Core tries to load it.
So make sure that you have walletcrosschain=1 in your config since it's initially detected as non-mainnet or altcoin wallet.dat.

You can even load it right now so you can see if there are transactions after syncing through year 2013 blocks.

"Restore Wallet" menu can go to any directory and see any ".dat" file, even if it's not a wallet file or an already loaded wallet file.
Being able to select a specific wallet.dat doesn't indicate that there's no issue in the file, the issue shows after it tries to restore and load it.

A single wallet.dat that's restored twice isn't an issue, each restore attempt needs to set a different wallet name anyways.

It will always output "$bitcoin$" even if it's a similar wallet.dat from an altcoin, Bitcoin testnet, regtest, etc.: github.com/openwall/john/blob/bleeding-jumbo/run/bitcoin2john.py#L248

Since you've set your blockchain to be pruned, you'll have to redownload the blockchain.
And since you don't have enough space in your drive, you can't store the entire blockchain, you'll have keep your prune block storage setting.

But only start over once you've successfully loaded the wallet.dat file or you'll have to re-download again if you want to load and scan your wallet later.
Since you're going to re-downloads anyways, try to start with a fresh datadir by renaming your current bitcoin datadir inside %appdata% (use "run" or "windows explorer").
rename it from "bitcoin" to "bitcoin_bk", create a new bitcoin folder and copy your bitcoin.conf (with walletcrosschain=1 setting) and wallet.dat file there.
Then start Bitcoin Core, it'll immediately load the wallet as [default_wallet] and redownload the blockchain.
If you have to scan multiple wallets, it wont be automatically loaded if you pasted more than one in the wallets directory,
instead, you'll have to restore them all immediately or keep network disabled until you're finished restoring all the wallets.

Alternatively, disable pruning and set a custom data directory to a bigger drive in the Welcome menu (start Bitcoin-qt with --choosedatadir arg), then redownload the blockchain to that directory.
That way, you're free to load wallet.dat files without re-downloading the blockchain again and again, it'll only need to rescan the existing blockchain.

Since your mentioned date is 2013, the transactions (if there's any) might show up earlier in the sync process.

Getting the logs may show some hints about the issue.
It's in your data directory, the file named "debug.log", open it as text to view the contents.

For now, if it's an issue with pathing of data directory, you can set it again in the GUI by starting bitcoin-qt with --choosedatadir command line option.
Or if you're using bitcoind, use --datadir=<path to custom 'bitcoin' data directory> arg like instructed above.
Or if you've set the default datadir, set datadir=<path to custom 'bitcoin' data directory> in the bitcoin.conf file inside bitcoin default data directory.

Then, if it started to resync again even after pointing to the correct directory, there may be issue in your blockchain, index or chainstate.
Such issue can be seen in the logs. Telling us your previous settings may help as well.

But to make this clear, does it show that it's downloading from block 0 again and not just catching-up to the tip from the last block height that it has?
Because Bitcoin Core has to do that once it's left closed for hours.

Try it in the GUI's console first:

• Go to "Window->Console".
• Select "wallet: (none)" (not required)
• Then type: loadwallet "wallet_name" true

---

In the command line, use bitcoin-cli with the same command as the above:

• Use Windows Explorer and go to daemon/bin folder inside bitcoin's install directory (default: "C:\Program Files\Bitcoin\daemon")
• Click "File->Open Windows Powershell".
• In Poweshell, type the command: ./bitcoin-cli loadwallet "wallet_name" true

But in order for bitcoin-cli to work with bitcoin-qt, you must use --server arg with your bitcoin-qt or server=1 in 'bitcoin.conf' file.
In case you've set a custom data directory and not using rpc username and password, --datadir= should also be indicated for it to find the ".cookie" file in that directory.

You can change "true" to "false" if you do not want to keep the wallet loaded in the next session. (not recommended if 'prune block storage' is enabled)

You seem to be fixated in getting your address and didn't answer the other replies.

Anyways, you can get it by enabling Addresses tab in "View->Show Addresses" first, and go to the Address tab shown above.
Your addresses that you would get in 'Receive' tab would be the ones tagged with "Receiving".

BTW, is the original wallet contained 'confirmed' transaction or just 'unconfirmed' ones?
Because if those are unconfirmed, the auto-selected server may not have those transactions in its mempool for some reason.
If so, blockexplorers may show those unconfirmed transactions or at least a hint on what happened (e.g.: replaced).

On-chain or Lightning bitcoins?
Because, lightning channels cannot be restored from old seed phrase,
later seed phrase on the other hand can recover static channels but you have to request the other party to force-close the channel to recover the bitcoin in it.

The script type option is only available when restoring a BIP39 seed.
Otherwise, Electrum will automatically detect the script type from the seed phrase itself.

In case you want to follow their advice to generate a new native Electrum wallet and move your funds there,
you can use you next transaction as an opportunity to send the change to the new Electrum wallet.
That way, you'll be able to pay someone and transfer the bitcoins to your new wallet in a single transaction.

To do that, just utilize "pay to many" from the settings icon in the send tab and input the 'addresses' and 'amounts' in the pay to field in this manner:
The "!" amount will tell Electrum to send all of your remaining bitcoins to that address.

- Yes, you can confirm that by checking if private keys are enabled in getwalletinfo command as I've mentioned earlier.

- Yes, it's a descriptor wallet with public descriptors only. You can see each descriptors via listdescriptors command.

- No, if you haven't exported any private key from Sparrow, there'll be no security issue regarding the xpub contained in your cormorant wallet.
That's because even a single child private key can be used together with the (parent) xpub to derive its xprv pair
That could compromise all the other private keys of that wallet. If you did, consider creating another wallet.

As requested, I tested this on my full node Bitcoin Core v26.0.0 and it works if I included the blockhash.
The test node doesn't have txidex=1 in the config and has pruned blockchain.

The errors also work as intended.

• If I provide a non-existing block hash:
  Block hash not found (code -5)
• If I provide the hash of a pruned block:
  Block not available (code -1)
• If I provide a TXID from another block:
  No such transaction found in the provided block. Use gettransaction for wallet transactions. (code -5)

Right, the only for-public-use option is the "Public Server" tab.
The two server options "Bitcoin Core" and "Private Electrum" are meant for private use.

Those public Electrum servers that you can connect to have their own database built from the blockchain that the client Sparrow query to sync.

On the other hand, if you use Bitcoin Core as server, Sparrow needs to use the cormorant wallet that it created with your Sparrow wallets' descriptors to scan the blockchain for transactions.
Then it uses RPC to query the needed data from that wallet or node, some require a loaded wallet to work.