You can download the latest version from bitcoincore.org, you've most likely have v22.0 which doesn't have the PR linked in the reply above.

Take note that after "resetting" the settings.json file, your wallet.dat will be unloaded
You'll have to reload it using the menu: "File->Open Wallet" and may need a rescan to update the balance.

No, I only suggested to add -listen=1 but leave -proxy parameter since you need it.
It's just if there's no -listen=1 while -proxy is used, listen will be set to 'disabled'.

There are pre-compiled binaries in the repository's releases link: https://github.com/Coding-Enthusiast/FinderOuter/releases
Those are ready to run aside from the "Source Codes".

Follow step 3 in the 'readme' to learn how to run it:

For better security, run it on an offline machine.

Since there's literally no advantage of using it over SegWit, I don't see why not.

Electrum supported legacy in the GUI for quite a while because of the compatibility issue of bech32 addresses to some services, exchange and wallets.
But now that most of services/exchange support bech32, they decided to remove the ability to create it in the GUI.

For reference, here's the pull-request: https://github.com/spesmilo/electrum/pull/6806

Sorry, it's quite funny that you're always coming-up with assumptions like the "400 hack attempts" and now "Bitcoin used to have different Base58 characters".
I understand that thinking the latter is normal if you do not know Bitcoin's history.
But the former... do the address in question perhaps shows 400+ inbound transactions in blockexplorers?
Because that's normal for old dormant funded addresses, people tend to send dust to them for variety of reasons, but none for hacking attempt.

You can also try to swap the similar valid characters like "u" and "v" or "k" and "x" which look similar in some fonts/handwriting.

You can also use the tool that I've suggested to automate the process, replace the possible wrong characters with "*".

In that part, I'm talking about the "/0/*" in the descriptor.
So for my example Cosigner1's change descriptor, it should be:
sh(wsh(multi(2,tprv8j6Rs3aMoX1iGB9RVgYViW1JDyBrqNF2ZXEc5h8qYdMeJeP8RAZ2JyEBENC69RW8E7KnRS9TcdYytCSwnBmHf5cDtM35UdphibSWFaVvunu/1/*,tpubDF7En6GCnmQYUaVKP69zUFGmHrDmJuiNxJBNdPajoFtnd11TwZLe4a1UX8Pvkf2u6fU5EMjyr65xyuDvq3TumNA8LwU8PtWRaicdzZ6EF2d/1/*)))

Since I'm using BIP48 as an example, the extended keys that I have are already at the "script_type" level,
which is the "1'" in m/48'/0'/0'/1', the next level in the descriptor should be the "change" or "chain" level.
You wont have to change the m/48'/0'/0'/1' path in BIP39 tool if you're going to use the standard path.

createmultisig or addmultisig do not accept xprv and xpub keys, those commands are for single MultiSig address generation.
It's doable but you'll have to use addmultisig for each set of prv/pub keys.

The steps to "workaround" using iancoleman's BIP39 tool and Bitcoin Core will be long and technical, but it's possible.
On the other hand, it's fairly easy in Electrum's GUI.

Here are the steps if you really want to continue:

In BIP39 tool:

• Type your mnemonic seed and BIP39 passphrase, select the correct coin.
• Scroll-down, go to "BIP32" Tab, select "Custom derivation path" in the client drop-down menu.
• Type the correct derivation path up to the "script_type" level of your wallet which has the standard BIP48 path of m/48'/0'/0'/1' for P2SH-P2WSH MultiSig;
  refer to BIP48 and BIP45 for the derivation path of other script types (BIP48 link & BIP45 link) and/or your wallet's derivation path to the extended master keys.
• After that, take note of the "BIP32 Extended Private Key" and "BIP32 Extended Public Key" below.
• Repeat all steps for other cosigner's keys.
  
  

In Bitcoin Core:

• For example, I want a to restore an HD 2-of-2 Nested SegWit MultiSig (P2SH-P2WSH) [RegTest]:
• [1] Create 2 blank Cosigners wallets with "Blank Wallet" and "Descriptor" checkboxes ticked.
• [2] Create 1 Watching-only wallet with "Disable Private Keys", Blank Wallet" and "Descriptor" checkboxes ticked.
  This is for unsigned raw transaction creation in the GUI since you've mentioned it in your other thread and you wont be able to create unsigned transacting using the Cosigner wallets (as of v24.0.0).
• [3] Now the hard part, create the descriptors based from the extended keys that you have.
  
  Sample Cosigner 1's Extended keys
  tprv8j6Rs3aMoX1iGB9RVgYViW1JDyBrqNF2ZXEc5h8qYdMeJeP8RAZ2JyEBENC69RW8E7KnRS9TcdY ytCSwnBmHf5cDtM35UdphibSWFaVvunu
  tpubDFnU1TcbwthP9eBDPLD67ufQnzhnzhRw8pqPNDB8xuA398du3ZNcVTr3QXNfDfGWLC2sB9PBqcb ycszg9P795mm1u56ksDbvs59JyDjPCSn
  Sample Cosigner 2's Extended keys
  tprv8iRCdgDxePisb7TXVSVQ4qceiphq9aXUNzabLsYSNz6PnWkhKAX3t5PcM134tZXkAX6jTxHDujq GDAyEzEdDoRztK3LA6srFcvwMJtMDzLc
  tpubDF7En6GCnmQYUaVKP69zUFGmHrDmJuiNxJBNdPajoFtnd11TwZLe4a1UX8Pvkf2u6fU5EMjyr65 xyuDvq3TumNA8LwU8PtWRaicdzZ6EF2d
  
  The "sh(wsh" multiSig descriptors from those extended keys will be (the keys' arrangement should be the same to your previous wallet):
  
  Cosigner 1 (Cosigner1's xprv, Cosigner2's xpub)
  sh(wsh(multi(2,tprv8j6Rs3aMoX1iGB9RVgYViW1JDyBrqNF2ZXEc5h8qYdMeJeP8RAZ2JyEBENC69RW8E7KnRS9TcdYytCSwnBmHf5cDtM35UdphibSWFaVvunu/0/*,tpubDF7En6GCnmQYUaVKP69zUFGmHrDmJuiNxJBNdPajoFtnd11TwZLe4a1UX8Pvkf2u6fU5EMjyr65xyuDvq3TumNA8LwU8PtWRaicdzZ6EF2d/0/*)))
  Cosigner 2 (Cosigner1's xpub, Cosigner2's xprv)
  sh(wsh(multi(2,tpubDFnU1TcbwthP9eBDPLD67ufQnzhnzhRw8pqPNDB8xuA398du3ZNcVTr3QXNfDfGWLC2sB9PBqcbycszg9P795mm1u56ksDbvs59JyDjPCSn/0/*,tprv8iRCdgDxePisb7TXVSVQ4qceiphq9aXUNzabLsYSNz6PnWkhKAX3t5PcM134tZXkAX6jTxHDujqGDAyEzEdDoRztK3LA6srFcvwMJtMDzLc/0/*)))
  For the Watching-only wallet (Cosigner1's xpub, Cosigner2's xpub)
  sh(wsh(multi(2,tpubDFnU1TcbwthP9eBDPLD67ufQnzhnzhRw8pqPNDB8xuA398du3ZNcVTr3QXNfDfGWLC2sB9PBqcbycszg9P795mm1u56ksDbvs59JyDjPCSn/0/*,tpubDF7En6GCnmQYUaVKP69zUFGmHrDmJuiNxJBNdPajoFtnd11TwZLe4a1UX8Pvkf2u6fU5EMjyr65xyuDvq3TumNA8LwU8PtWRaicdzZ6EF2d/0/*)))
  
  You'll also need descriptors for the change addresses which are basically the same
  except for the trailing "/0" path after the master keys; for the change, it should be "/1"
  
  For reference, read this document about descriptors: https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#examples
  
  
• [4] Get the descriptors' checksums from the command "getdescriptorinfo".
  From the example, the checksums are: "3scferc6", "augnfj7d" and "de92usr9" respectively.
  
• [5] Import the descriptors to the correct wallet using the command "importdescriptors":
  Put the checksum after a "#" next to the descriptor.
  
  Wallet 1 (Cosigner 1):
  importdescriptors "[{\"desc\": \"sh(wsh(multi(2,tprv8j6Rs3aMoX1iGB9RVgYViW1JDyBrqNF2ZXEc5h8qYdMeJeP8RAZ2JyEBENC69RW8E7KnRS9TcdYytCSwnBmHf5cDtM35UdphibSWFaVvunu/0/*,tpubDF7En6GCnmQYUaVKP69zUFGmHrDmJuiNxJBNdPajoFtnd11TwZLe4a1UX8Pvkf2u6fU5EMjyr65xyuDvq3TumNA8LwU8PtWRaicdzZ6EF2d/0/*)))#3scferc6\",\"timestamp\": \"now\",\"active\": true,\"watching-only\": false,\"internal\": false,\"range\": [0,999]}]"
  
  Wallet 2 (Cosigner 2):
  importdescriptors "[{\"desc\": \"sh(wsh(multi(2,tpubDFnU1TcbwthP9eBDPLD67ufQnzhnzhRw8pqPNDB8xuA398du3ZNcVTr3QXNfDfGWLC2sB9PBqcbycszg9P795mm1u56ksDbvs59JyDjPCSn/0/*,tprv8iRCdgDxePisb7TXVSVQ4qceiphq9aXUNzabLsYSNz6PnWkhKAX3t5PcM134tZXkAX6jTxHDujqGDAyEzEdDoRztK3LA6srFcvwMJtMDzLc/0/*)))#augnfj7d\",\"timestamp\": \"now\",\"active\": true,\"watching-only\": false,\"internal\": false,\"range\": [0,999]}]"
  
  Wallet 3 (Watching-only wallet)
  importdescriptors "[{\"desc\": \"sh(wsh(multi(2,tpubDFnU1TcbwthP9eBDPLD67ufQnzhnzhRw8pqPNDB8xuA398du3ZNcVTr3QXNfDfGWLC2sB9PBqcbycszg9P795mm1u56ksDbvs59JyDjPCSn/0/*,tpubDF7En6GCnmQYUaVKP69zUFGmHrDmJuiNxJBNdPajoFtnd11TwZLe4a1UX8Pvkf2u6fU5EMjyr65xyuDvq3TumNA8LwU8PtWRaicdzZ6EF2d/0/*)))#de92usr9\",\"timestamp\": \"now\",\"active\": true,\"watching-only\": true,\"internal\": false,\"range\": [0,999]}]"
  
  Import the descriptors for change as well, aside from the previous "/1" difference in the descriptor, those should be set as "\"internal\": true," in the command as well.
  Without it, you'll have to manually set change addresses in every transaction that needs change.
  
  
• [6] Now, try to request a "Base58 (P2SH-SegWit)" address in the "Receive" tab to see if the Cosigners have matching address.
• To spend, create an unsigned transaction using the watching-only wallet, then the usual: export the txn to the cosigners to sign it one at a time, fully sign it to broadcast.
  
  

Take note that this is more of a workaround and an "official" feature may be implemented in the future.
And the derivation path differs per wallet, my example is based from BIP48.

Better if the signed raw transaction to your cold-storage has higher fee rate enough to replace the other transaction.
But since full-rbf still isn't widely used yet, set the original transaction as 'replaceable' in case you need to replace it with the back-to-cold-storage txn.
That will give you a few minutes to "cancel" that transaction.

The wallet file from your Armory datadir will be deleted in the file system as well.
The file name should be similar to "armory_xxxxxxxx_encrypt.wallet".

Here's a related topic with sufficient answers: Delete/Remove Wallet - shred/overwrite, or merely filesystem delete?

I can't reliably tell based from the available info.
But since you've used -proxy, -listen is automatically disabled which made your node unreachable
So try to add "-listen=1" to the command or "listen=1" to your bitcoin.conf file.

Also, if you decided to try the suggestion above, prioritize "addnode" since "connect" will limit you to the nodes that you've set.

You can try FinderOuter tool by Coding-Enthusiast: https://github.com/Coding-Enthusiast/FinderOuter

Follow these steps to use it to find the possible correct characters:

• Open FinderOuter and go to "Missing Base58" tab.
• Select the options at the right-hand side - "*", "Private Key" and "AddrUnComp".
• On the left-hand side, paste your private key in "Base-58 encoded string" and replace the characters that aren't Base58 with *
  for example: 5J1F7GH*dZG3s*CKHCwg8Jvys9xUbFsj*nGec4H1**Ny1V9n*6V
• In the text box under it, paste your address.
• Then Click "Find!" and it will start to fix your WIF private key; it will use most of your machine's CPU process while working.
• Results will be displayed below.
  
  

Of course, it wont display any result if it can't find any valid private key with the characters that you've given.

You need any implementation of Electrum Server to be able to connect your Bitcoin Core to Electrum.
You can try: https://github.com/spesmilo/electrumx - from the main developer of Electrum.

There's the 'law of supply and demand' in economics but it doesn't entirely rely on that.
In your scenario, you can sell the only accessible bitcoin (that you have) with the price that only you can dictate since there'll be no other seller.
So it's up to you if the price will increase or not; but realistically speaking, having near zero liquidity in exchanges can cause it to drop to zero in a matter of minutes to hours.

Plus Bitcoin's price isn't dictated by Bitcoin, I mean not by the developers nor the code; it's the market.
So having all people (the "market") lose their private keys for whatever silly reason, could drop the price to zero.

Yes to non-custodial wallets since transactions have to be included in the blockchain.
For transactions with unconfirmed parent, the parent has to be confirmed first or together with the child transaction(s).
Bitcoin withdrawals from custodial wallets/exchanges also subjected by this but you do not have the control on the fee rate, their charged "withdrawal fee" wont be directly used as transaction fee.

For transfers between non-custodial wallet (e.g.: Coinbase to Coinbase), it's different;
on-platform transactions wont use the blockchain so there'll be no on-chain fee nor waiting time for confirmation.
The downside is, they own your bitcoins.

Most of the time, this isn't necessary specially if you're using "ETA" fee slider which has quite high recommended fee rate.
As long as it's telling you "In the next block" or "Within the next 2 blocks", the fee is alright.
The issue was: there's an unconfirmed parent transaction.

Go to this thread to see the list of bruteforce tools: https://bitcointalk.org/index.php?topic=5422375.0

Those are designed for the puzzle transaction but you can specify the range if you want the whole keyspace. (which isn't comparable to lottery)

There's a downside to that method though: you can't provide an exact time of the draw since blocks aren't always on schedule.
If the application is not strict to schedule, then it's good.

Also, do not use it if the amount at stake is a lot higher than the block reward (like 10x+) since a pool/solo miner can risk it to try produce another block hash with the winning number.

Transaction is now confirmed: https://www.blockchain.com/btc/tx/945e21d24a152b28602de318b2a05e754468c23b46f0db76a5ca148968ddaa4c

In your next transactions:
If you want to avoid creating transactions with unconfirmed parent, you can enable the option: "Tools->Preference->Transactions->Spend only confirmed coins".
But take note that if you do not have other confirmed "Unspent Transaction Output" (UTXO/Coin),
Electrum wont be able to send until there's a suitable amount that's confirmed. ("View->Show Coins" to see the Coins tab)

With the phrase "whoever invented", I think OP is simply thinking that if someone invented something, he must have the knowledge to reverse-engineer it.
...which is not applicable to every invention.

Quite, those are used when deriving the address from the public key, but not the public key itself.
The public key is computed from the private key through "EC point multiplication" along "secp256k1" curve.

Some resources that cover that topic:

• Book - Mastering Bitcoin: github.com/bitcoinbook/bitcoinbook | Chapter4: Keys, Addresses
• Website - Learnmeabitcoin: learnmeabitcoin.com/technical/ecdsa

It's not deemed irreversible just because no one knows the algorithm; the algorithm is available to the public.
It's irreversible because of the method and the amount of computation required to reverse a SHA256 hash.

If you want to literally see how complex it is, try this demo site: https://sha256algorithm.com/
You'll see the relation to pooya's example where it's extremely hard to guess those "x+y" in every step to reverse because the values have already altered by the previous steps.

SHA256 isn't an encryption algorithm, its hash isn't encrypted.