1 confirmation means that it's already included in a block, you can now spend it.
The consecutive confirmations are just for safety against double-spend attacks (not that it's usual), the higher the confirmation the safer your bitcoins are;
it'll take approximately 10minutes per confirmation.

But wait, you haven't read my other reply (don't you?),
figures because there's one confirmation, means that you've swept (sweep) it.
But there's no major issue as long as the recipient wallet isn't a "watching-only" wallet and you own the wallet where it was swept.
(the post also has some suggestions for the safety of your funds)

Yes there is.
In your data directory, there's a file named "debug.log", that's the log file.

Windows 10 - Bitcoin Core's default data directory is in: %appdata%/bitcoin
Appdata= Click 'Search' or 'Run' (WinKey+R), type %appdata% then press enter.

I have a reply to your thread. Basically, you just have to remove the "p2pkh:" in front of the private key.
AFAIK, Electrum both supports 22-character and 30-character mini private keys so your series 1 coin's key should work.

If it doesn't work, the other option is to manually convert it into WIF.

Please continue the discussion there.

You cannot import a privKey to a wallet with a seed, you'll need to create a new wallet and select "Import Bitcoin addresses or private keys"
and then paste the mini private key (starts with 'S") there without the script type prefix.

Here's the steps:

• If you have an existing wallet, go to menu "File->New/Restore".
• Type a wallet name, and click "next".
• Select "Import Bitcoin addresses or private keys", click next, paste the mini private key (do not add "p2pkh:").
• Then finish the rest of the setup.

Make sure that you're using the legit "Electrum".
Download only from electrum.org and take your time to verify its signature.

How many "segwit" accounts do you have in Ledger Live, excluding "native-segwit"?
Because if the address that you want to sign is in the second or third+ account, it won't be restored in Electrum using the default derivation path.

Try to create another Electrum wallet but after selecting "p2sh-segwit (p2wpkh-p2sh)";
Change the derivation path below from m/49'/0'/0' to m/49'/0'/1' (for the 2nd account) or m/49'/0'/2' (for the 3rd account) and so forth.

You'll have to remove the prefix "p2pkh:".
For some reason, adding a prefix before a mini-private key will disable the "next" or "sweep" in Electrum's import or sweep private key.

The updated client will update the wallet file to be compatible with that version. But the wallet encryption should be the same.
Depending on the wallet's version, you may have to use an updated fork of BTCRecover.
Just make sure to save a backup of the untouched version of your wallet file, it's in Electrum's data directory (except for the portable version).

Unfortunately, in your case, the 'full wallet contents' is encrypted so you wont be able to find addresses to check for balance before the bruteforce attempt.

Yes, that's the normal thing you'll see for encrypted wallet files, at least it doesn't look corrupted.

I'm not an expert in 'hypnosis' but it's worth the try since bruteforcing the wallet without a clue of the password is pointless.
I'd suggest you to look for files or physical "paper" where you might have saved your seed phrase.

Even if it was upgraded by Electrum 2.8+, the wallet file will still remain unencrypted, just the private portions of the wallet file.
Unless you've changed the password and ticked "Encrypt wallet file" option.

Anyways, if it asks for a password to open the wallet, then it's fully encrypted.
In that case, even the addresses can't be checked from the wallet file.

Nope, if you're talking about something with undefined/unknown gender, it's normal to use "he", not that you're referring to a male.
Moreover, "Satoshi" is a masculine name so it's good.

You wouldn't find anyone who's in for profit.

Those articles are doing it for publicity purposes;
The ones that actually show the process must be doing it to show that it's possible, not for mining profit.
That specific article however, is a bad example because it looks like the PS4s are there to gain "rare FIFA players" rather than mining.
There's no shown evidence that they are mining, the GPUs in that facility must be the ones that are mining.

But technically, it can produce SHA256d hashes but not high enough to mine Bitcoins (even pools wont accept your hashes).
It could mine altcoins though but while playing FIFA (described in the article), still possible but not reasonable.

For Bitcoin core, you can refer to my post above HCP's reply:

(referring to dumpwallet result)

---

For other clients, it depends, but most of them should have a feature to indicate the address' "script type" when importing private keys.

Yes it is (regtest dump):


You might be talking about the "extended private masterkey"?

It will scan after reloading the wallet, but if you want to quickly load the new hdseed's transactions, you can rescan right after the command.

AFAIK, the "hdseed" in the dumpfile is WIF.

But NotATether's suggested command should be sethdseed true "hdseed" - "true" so that the previous unused keys will be flushed and also for it to accept the next argument.
And then, rescanblockchain
If the source wallet contains an "inactive hdseed" (usually set before the wallet was encrypted), I'd suggest to set it first and rescan before setting the active hdseed.

Can you list the things you've tried so far?
That's necessary so users won't suggest what you've already tried.

For the follow-up, since it's seems normal and there's not enough info in armorylog.txt, I honestly can't find the issue.
It couldn't be the blocks based from the logs, that's as far as I can tell.

dbLog.txt contains logs, there nothing to change there.
Upon examining the thread: martyman just posted what was in the command line after running armorydb manually.
I've also noticed that the linked thread was quite chaotic because there were other two posters who claimed to have the "same issue" but didn't seem like it. And they replied after one another.

The "glitch" may have been a "zombie armorydb" process that wasn't terminated after the last Armory session.
In that case, a PC restart, end task or the manual armorydb launch attempt(s) might have fixed the issue.

You can access it via MEW but make sure to do all the necessary safety precautions on using a browser-based wallet.

In Theta wallet, get your ".keystore" file from the settings; if you already have it, directly go to the "old version" of MEW.
For some reason, the new version is throwing error at my end.

The old version has a link above the main page next to the text: "Missing the old version".
To open it, click "Access My Wallet", then "Software" next is "Keystore File", continue.
Browse to your .keystore file's directory and open it, type the password and you should have access to your wallet via MEW.

The steps above is not actually "deposit", you'll just transfer your key to another wallet so it can access the address instead of the previous wallet.
Since the previous wallet doesn't support the token/ETH that you've sent to it, it didn't displayed any balance but in reality it's sent to the address
but the only way to access it is to restore the "key" to a wallet that supports it.
That wont work in custodial wallets and exchanges like Coinbase though so be careful next time.

What version of Armory are you using? You should be using the latest version 0.96.5.

Your log says ArmoryQt couldn't launch ArmoryDB.exe by itself but there are no other useful info.
You may need to check the other log file: "dbLog.txt" for additional info why it's failing to run.

I've also ask a Moderator to move this to Armory board so the developer himself can look at the issue.

If OP is legit, it's surely a non-custodial wallet since he won't be able to "try to send using two wallets" to check the fee if it's a custodial wallet.
There's no way to restore a custodial wallet to another custodial wallet so he can send using the other one.

I've also tried to ask which wallets he had tried, but sadly, he didn't respond.
I expected he'd reply with a custodial wallet :3

Possible but you won't be able to spend from it.
Eg.: P2PKH's locking script contains OP_HASH160 which specifically uses SHA256 and RIPEMD-160.
Clients wont be able to verify a "Public Key Hash" generated from other cryptographic hash functions.

This is worth the read: https://learnmeabitcoin.com/technical/p2pkh | https://en.bitcoin.it/wiki/Script#Crypto