The standard paper wallet backup for Bitcoin private keys is "WIF" (wallet import format).
More info: learnmeabitcoin.com/technical/keys/private-key/wif/

For public key, hex with compression prefix (pubKey isn't usually required to write in the backup).
More info: learnmeabitcoin.com/technical/keys/public-key/

However, those base64 strings when decoded don't look right,
Better stick to open-source software/hardware wallets than use the output from that script.

You can still use what you're familiar with (CEX to purchase) or use P2P.

But I would only suggest you to send bitcoin from the Exchange to your cold storage wallet when you accumulate a significant amount.
That's not only to minimize the accumulated fee when sending from exchange, but also to minimize the number of UTXO your wallet will be keeping.
The goal is to keep only a few higher value unspent outputs so that your wallet wouldn't have to use a lot of inputs in your future transactions.
The lower number of inputs, the lower the transaction's size will be; lower the transaction size results to lower absolute fee.

If you want to go P2P, you can use P2P exchanges available in your Country or purchase from users in this forum in Currency Exchange board.
Link: http://bitcointalk.org/index.php?board=53.0 (make use the "Trust system" since this is quite risky)

If so, then please explain the situation more since this'll just aggravate the usual "suspicions" of these kind of topics.
People are rather doubtful of these claims recently.  (not that anyone can directly intervene with the recovery process)

What commands had you been using in 2009?

I don't get the context, is this a reference of a tutorial or the steps that you did?
What's the result or error that it returned?

AFAIK, that is contained in old Electrum transactions export or server synchronization.
Later, renamed into "KeyID".

Do you have a seed or private key backup instead? Because that's what an actual backup is.
What does the file look like when you open it as text?

But don't count on that information alone (it's "As Far As I Know").
If you found no progress in this topic within a few days, it's better to ask the core developers about that matter later.
Link to Electrum's repo issues page: github.com/spesmilo/electrum/issues

Walletexplorer does that but it's mainly for tracing linked addresses, searching with the first few characters of an address is just an added feature.
But for some reason, I can't access the site right now.

BTW, the more popular term for that is "firstbits".

Although confusing for newbies,
It's a given that if a cosigner handed-over the seed phrase to begin with, he's already willing to share access to his private keys to that cosigner.

Besides, the previous window explicitly instructs the user to share the (extended) master public key:

Correct, kangaroo is utilizing ECDLP for secp256k1 curve which computes the private key from its public key pair
so it's not applicable to compute the seed from the public key which doesn't directly involve secp256k1.

The "master private key" derived from the seed is calculated with HMAC-SHA512 which outputs 256-bit private key and 256-bit chain code regardless if the seed is 128bits.
So still an overall of 128-bit security: it requires 128-bit operations to compute the (master) private key from (master) public key via ECDLP or 128-bit operations to blindly bruteforce the seed.

Fair enough, the option doesn't have the same message in "Enter consigner key" where it's explicitly noted that putting a "master private key" will enable you to sign for that particular cosigner.
The "Enter cosigner seed" option is listed as another option without a note.
That may actually confuse someone who's new to Electrum or Bitcoin in general / in terms of safety.

It's noted with the message "Your wallet generation seed is:" because that's created when you make that wallet.
The seed phrases of the second and third cosigners are created by their respective wallets.

Since those are in an "Air-Gap" laptop which should be safe, do this experiment to make sure:

• Open 'Wallet C' and remove its password by setting a blank New Password in "Wallet->Password".
• Then find Wallet C's wallet file in 'wallets' folder inside Electrum's data directory (location), open it as text.
• Find the strings "x1", "x2" and "x3" which represent the three cosigners.
• Check if 'x2' or 'x3' of Wallet C has a seed or xprv key (should be "null") because if it has,
  it can sign the transaction by itself and you've made an error during cosigner setup by providing it with a seed or a private master key.

The "Wallet->Seed" menu only shows the wallet's main seed phrase, the cosigner's seed can be seen in the wallet file (if unencrypted) instead.

Do you mean "new seed"?
Because Electrum doesn't have any feature to generate other script types to existing HD wallets aside from what's set during wallet creation. (defaults to Native SegWit)

If so, you can "force" Electrum to use your existing seed to make a new wallet with P2SH-P2WPKH addresses by toggling "BIP39 seed" option to enable the script type options.
But that's not following the standards so you wont be able to restore it using BIP39 wallets or wallets that supports Electrum seed.
You'll also have to do the exact same steps to restore it and hope that Electrum devs wont "fix" Electrum's behavior to let the user proceed despite having an invalid BIP39 seed phrase.
And since your Electrum seed is restored as a BIP39 seed, it'll restore a different set of private keys even if you use the same derivation path as the original wallet.

It's safer to use a real BIP39 seed created elsewhere if you really need Nested SegWit addresses in Electrum.

Right, but it sounds like more of a "cache" or "display" issue than synchronization since it used the correct inputs to your transaction rather than the set with $70 more amount.
Because otherwise, it should've added an extra output(s) containing those $70 worth of Bitcoins that are already spent.
Anyways, reloading the account to trigger a rescan is useful in cases like this.

Not until descriptors is implemented.
The good news is some of the requirements to implement TapRoot are already in the master branch of Electrum's GitHub repo.
But it doesn't have a specified version in their "Milestones" (TODO List) so it may not be released in v4.5.5.

You can monitor their "TODO list" here: https://github.com/spesmilo/electrum/milestones
Check if "TapRoot Support" in backlog will be moved to v4.6.0 or any future version.

The closest thing that you can do now is: you can create a watching-only "imported" Electrum wallet by importing TapRoot addresses from other wallets.

The directories in the tutorial is geared towards Linux; for Windows, use Windows folder structure.

So, in number 3 (preferred for your use-case), for example.
Your torrc file should have something like this if you want to save your "Bitcoin Onion Service" directory to Drive D:

After you restart Tor, you'll see such folder in D:/ and you can find a "hostname" file containing the onion address that you need to set as --externalip.

I've checked the dates up to page 100 and I can't see why "suddenly" should be applied to that statement since it's showing transactions in regular "healthy" intervals.

Those are mostly people who hodl bitcoins or found (their) lost wallets/keys, cashed-out or used it to pay for something.
Not much of a topic of concern.

Or is there any "interesting" conspiracy going on?

That particular "Use Tor Proxy at port" setting appears if Tor is detected by Electrum, disappears once Electrum failed to detect Tor.
(with a few seconds delay)

If it disappears consistently, your Tor daemon in the machine where Electrum is, may be having issues.
So you might have to troubleshoot Tor rather than Electrum.

Since you've mentioned that your Tor proxy running at port 9050, you must be using 'Tor daemon' instead of 'browser' unless you changed the port from 9150 to 9050.
If you're somehow using Tor Browser, opening and closing the browser window will reproduce that issue; appear and disappear respectively.

I have Bitcoin Core in Windows, I've copied your config to reproduce the issue and the line mentioned by Cricktor shows up in the debug.log:

I have to mention that I set the 3 lines under "Control Port" instructed in the tutorial below, without it, the onion address wont show up:
Try to follow either instruction number 2 or 3 from this tutorial: github.com/bitcoin/bitcoin/blob/master/doc/tor.md
If you decided to follow number 3 instead, your onion address would be the one you set in -externalip.

You can either post in their official thread here in Bitcointalk, link: http://bitcointalk.org/index.php?topic=320959.28760
And/or send a PM to @TheQuin, profile link: http://bitcointalk.org/index.php?action=profile;u=143168

Letting anonymous users send email to you will just attract fake customer support or scammers.
Also, this topic may be moved to "Service Discussion" board by a mod or move it using the small "move" button at the bottom-left.

Even with opt-in RBF flag, you still wont have the authority to use "Increase transaction fee" menu to those transactions since you're the receiver.
Your option is to CPFP that the wallet part of Bitcoin Core can't do directly.
You'll need to use commands and precise computation of amounts and fee: en.bitcoin.it/wiki/Fee_bumping#I_received_the_stuck_transaction

Or do BitMaxz's suggestion to import the address(es) to Electrum to create a CPFP unsigned transaction, export the PSBT file/string via "Share" button.
Import it to Bitcoin Core via "File->Load PSBT from..." menu, sign and broadcast it.

---

You can also ask the sender to replace those once dropped from his mempool. (if he's using the default size and there too many transactions in it)
He can do this if he's using Bitcoin Core: the moment their status turn "0/unconfirmed, not in memory pool", right-click on the transaction and select "Abandon Transaction".
His overall balance should update accordingly. Then 'Enable coin control features' in "Settings->Options", 'Wallet' tab.
In the 'Send' tab, click "Inputs..." select the inputs of the abandoned transactions and send with higher transaction fee.
(this is for the sender, not the receiver)

But it's better if you can share the transaction IDs because these suggestions may not be enough in some cases, like of long chain of large 1sat/vB transactions.

The blockchain is publicly available, so if ever, that mining pool is risking their reputation for a couple more bitcoins.
vjudeu's reply to the linked topic in my previous post has a nice take on that matter: /index.php?topic=5492493.msg63955089#msg63955089

If that's a big mining pool that has a slight chance to do that, the odds that they'll do that is still low.
If a small solo miner who got no reputation to lose, they will need a tremendous luck to pull that off.

Yes, the first incident simply happened because the parents of the parent transaction of your "screwed_TXID"
happened to have a very low transaction fee that got it dropped from your (auto-)selected Electrum server's mempool, that dropped all of its children txns as well.

During that time, the unconfirmed parent should've been dropped as well since it's the reason why the "screwed_TXID" with higher fee rate was dropped.
But now that the average mempool size is low, it's now propagated to the network again that reverted it back to "unconfirmed parent".

If you're talking about 4566c3cfc229a494be03fb2811e4ebdb2052342ddfec0ea720217068d4e546c5:
Manually remove that transaction while offline (you can try it while online using v4.5.4) using the command: wallet.adb.remove_transaction("TXID")
After the transaction is removed, the UTXO list in the 'Coins' tab should be updated to what it was, use 'Coin Control' to select only the confirmed ones then send.

That's normal since if there's no wrong word, it wont show the "Unknown BIP39 wordlist error"
but "BIP39 checksum failed" because the incomplete seed phrase will obviously contain invalid checksum bytes.

Perhaps you've typed a similar word, missing a word, few excess word, jumbled words or something.
Other than that, I can't add anything since importation of valid BIP39 seed to Electrum shouldn't have issues.

Can you show where this error showed up?
Where did you downloaded Electrum? Have you verified its signature before using?

Have you typed the passphrase separately in the next window (by ticking "Extend this seed with custom words") and not directly next to the seed phrase?
Because Samurai's Seed Phrase should be BIP39 compliant which should have the correct checksum bytes.

Are you restoring on an online machine?
If so, just use "Detect Existing Accounts" button and Electrum will search for 'Standard' and 'Mix' derivation paths used by Samurai including succeeding account_index if the first is funded.
Derivation paths that it'll search are listed here: github.com/spesmilo/electrum/blob/master/electrum/bip39_wallet_formats.json

Of course, that'll only find anything if the seed is restored properly.

You'll notice the Network icon (lower-right) if it's a connection issue, it's red if it's not connected to any server.
On Mobile, it's on the upper-right.