Ah, so they aren't looking for a signed message to confirm that you're the sender like the SOP for refunds (OP sounds like that).
The OP is vague, but the new reply has some inconsistencies because why would they need you to sign a transaction for them to return your money back?

The question is: who's "they"?
And please describe your goal/issue better since this turned out to be an "XY problem".

---

Anyways, you don't have to export any private key to sign a transaction.
Just load the unsigned transaction as described by pooya "Tools->Load transaction":
Click "Tools", point at "Load Transaction"; then select "From file" or "From text" depending on the format of the transaction that you need to sign.

Those versions are too old and wont be able to connect to the network.
If you need the binaries, try this: /index.php?topic=68121.0 (v0.1) | Read the latest replies for more info.
Or from the old commits: github.com/bitcoin/bitcoin/commits/master?before=25.... (before September 2011; click "<>" to view the repo's state at that time)

Reference for the Berkeley Database version upgrade: https://bitcoin.stackexchange.com/a/81583

Unfortunately, you can't sign a message with your 2-of-3 MultiSig address;
there's also a note that will pop-up if you try to sign a message using your multisig wallet:

---

What you can do is to explain them that it's a Multisig address and it's impossible to comply with their request.
Try to find alternative ways (ask them what they need aside from a signed message).

I missed this reply (posted 19sec before mine).
Then limiting your dbcache to reduce the 'page file' wont really do much because the data directory isn't in the same drive where the 'page file' will be.

"Internal" means that the HDD is inside the PC, while "External" is connected via USB or other external ports.

That's quite a low number of peers but 5 shouldn't be limiting the speed to 0.07%/hr so it must be the HDD or something else.
What I'm thinking is your RAM must not be enough for the dbcache that you've set together with the background processes of Windows10
That will use a lot of "page files" which will further stress your HDD.

Try to reduce your database cache into 512 instead (or lower); then, restart Bitcoin Core and check if it'll improve.

That's indeed slow considering the internet speed and it's a quite capable machine.
However, the most important factor to the initial block download's speed is the Drive which you haven't mentioned.
So, are you using an HDD/SSD, internal or external?

It can also be affected by your connection to the network, How many peers do you have in "Window->Peers"?

I can only guess based from Bitcoin Core's behavior in generating the keypool.

Those timestamps are date & time of each individual keys in your wallet.dat.
Upon creation of the wallet, it will immediately preload thousands of keys for receiving and change addresses to the wallet.dat,
Thus, all those keys' timestamp should be the similar (may differ in a few seconds) so your hypothesis may be correct about the "timestamp" of the unencrypted wallet.

After setting a passphrase, Core will drop the unused keys from the wallet, create a new 'HDSeed' and derive a new keypool from it.
Thus, the new keypool has an updated timestamp based from when the wallet is encrypted;
However, if you just changed the passphrase of an already-encrypted wallet, the 'HDSeed' will remain the same so the timestamp will stay the same for the already-derived keys.

Signing a transaction doesn't require the wallet to be connected, in fact it can be done in an Air-Gap computer.

I'm thinking that it may be more of a hardware wallet issue than Electrum's since it's the Ledger that can't sign.

So all cosigners are using Electrum v4.0.1+ including your Ledger?

"Errors" as in the message you're getting when trying to sign the partially signed transaction.

Logs can be enabled in the setting: "Tools->Preferences->White logs to file", then close Electrum.
It will create a log file in "%appdata%\Electrum\logs" (for Windows) during the next session (try to sign it in that session for the issue to register there).

Probably there are cosigners that are still using versions below 4.0.1.
Because the newer version's unsigned transactions are now in "Partially Signed Bitcoin Transaction" (PSBT) format
which is incompatible with the older version of Electrum or some other clients.

If all are using the same Electrum version, then please add more info like the errors and if possible, the logs.

I've seen some developers suggest that before doing a -reindex but I haven't tried it myself.
Specifically this stackoverflow post: https://bitcoin.stackexchange.com/a/54455

It matches the fingerprint of Emzy' GPG key that I've imported: 9EDA FF80 E080 6596 04F4 A76B 2EBB 056F D847 F8A7
Both public keys from the download page and the repository matches that fingerprint.

Sombernight's is the same as the one in o_e_l_e_o 's reply.

That's because the newer binaries are now signed by three developers: ThomasV, SomberNight and Emzy.
It's mentioned in the download page: https://electrum.org/#download

You may obtain the other two devs' GPG Key, links in the download page or in Github repo: https://github.com/spesmilo/electrum/tree/master/pubkeys

Bitcoin Core will still use the one in the default directory, plus it created one in the custom data directory that you put in it so it's using the config.

Now for the same error,
Hmm, everything now checks-out, getblockchaininfo's result is good, pathing is good and Armory's database is fresh.
At this point, I'd guess it's the blockchain, there may be a corrupted block at the point of the error.

-edit-
In the newer versions of Core, if the custom datadir was set in the 'welcome screen' of the GUI, then it wont use the config in the default datadir.
Anyways, it's pointing to the same datadir so, nothing's changed.

That's only if your hardware already has problem in the first place.
Otherwise, you'll just experience high CPU, HDD, RAM and Network activity while Bitcoin Core is running.

It's common for a computer to run normally if it's idle or just at minimal usage, however if it's pushed to the limit, existing hardware issues may show-up.
The most common "exposed problem" when syncing Bitcoin Core are: HDD or RAM issues that could corrupt the blockchain.

That's the same pathing setting as the previous.

What I want to confirm is: if the correct blocks directory is actually "H:\Bitcoin\data\blocks".
Because it's the one that Armory is using, and it keeps on getting an error that indicates that the blockdir doesn't have the whole blockchain.
But this kinda answered it:
"1 Folders" must be the 'data' folder, so Armory may be using the correct satoshi-datadir "H:\Bitcoin\data" afterall.
(figured because the actual Bitcoin datadir should have more than one folders in it)
So we're back to square one, looking for the issue.

---

Anyways, try these setup

In Bitcoin Core:

• Go to "C:\Users\greyaliens\AppData\Roaming\Bitcoin"
• Find bitcoin.conf file (create one if you don't have it)
• Open it as text, and add the configs datadir=H:\Bitcoin\data and prune=0 (one config per line) then save.
• Start Bitcoin Core, open the console (Window->Console), and enter: getblockchaininfo
• In the result, the line "initialblockdownload" should be false because it indicates that you have the complete blockchain in that datadir;
  you may as well check "blocks": 724826 (value as of now) if the value isn't lower.
  
  

If everything checks-out, continue with Armory.
In Armory:

• Go to "C:\Users\greyaliens\AppData\Roaming\Armory"
• Find armoryqt.conf file (create one if you don't have it)
• Open it as text, and add a line satoshi-datadir="H:\Bitcoin\data" then save.
• Find and rename "database" folder into "database_backup"
• Now open Armory without the start parameters in the shortcut and see if it'll be able to build the database this time.
  
  

BTW, the config files should have the ".conf" as the extension if you have to create them manually by creating a text file and renaming that text file.
Because in Windows, it might display as 'bitcoin.conf' but it's actually 'bitcoin.conf.txt' because of the hidden extension.
In that case, you might need to enable it in Windows File Explorer's setting, tick: "View->File Name Extensions".

Here's a reply from the dev:
Basically, it will broadcast to your node's peers first and if it fails, it'll be sent through RPC.

server=1 is required to use RPC.

For the incoming connection, do you mean listen=1?
If so, disabling it wont affect Armory since you can still connect to the network, it's just the other nodes wont be able to initialize connection to you.
Disabling it will just reduce your connection.

That's good to know.
I thought something was off so I stopped replying after you ignored my question about how the 24-word Electrum seed is created.
(or you just missed it and only seen o_e_l_e_o's follow-up?)

Anyways, if it's a puzzle, try to find a clue that may be a hint to the words' arrangement.
That's how puzzles work, otherwise, no one will be able to win it.
Although you should continue the discussion about the puzzle in a new thread in the correct board (try 'Bitcoin Discussion').

Yes, -reindex checks the local blockchain for blocks to rebuild the 'block index', so if any of the block is corrupted, it'll have to resync the blockchain from that point.
So I think it may just be "pathing issue" in Armory.

Since you've set that directory as "SatoshiDatadir" to Armory, check if Bitcoin Core is using that as datadir as well.
How did you set Drive H as Bitcoin datadir?
What's the exact directory did you set as Bitcoin datadir?

If you decided to browse to "H:\Bitcoin\data" folder instead, you can check if the blockchain's size is appropriate for a full-synced blockchain.
the blockchain that Armory is using is: "H:\Bitcoin\data\blocks", check the blocks folder's properties and see if the size is about 445GB.

That's odd, even old versions have that option; but to be sure, make sure that you're using the latest version 0.96.5.
It's also available for any "User" level setting (Standard~Expert).

Double-clicking the wallet name will display the same wallet properties, try it.

The only wallet type that doesn't have that option is "Watching-Only", which doesn't contain any private keys.
It's indicated under 'Security':