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 input(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.

Okay, as I thought.

There are actually a few topics here that already addresses that concern and the consensus is:
"it's not currently possible without the help of a trusted cooperating mining pool/solo miner".

Here's to point you to one of the threads: solve key 66 67 Puzzle how to avoid double spends the tx?
AFAIK, there are other discussions that aren't in the first page or posted as a reply to other topics.

Not technically, as explained in the first two replies.
In the Bitcoin Network, those coins aren't deposited to an address but a newly created UTXO, there's no address saved in the network.

That statement only applies to "Bitcoin World" in social media, forums, blockexploreres or wallets where address is a thing.
"Wallets" included because it is a separate feature than the network. It hodls keys, creates transactions and fetches UTXO that its keys can spend; displays addresses.
This is why I've put question to your definition of "the Bitcoin World".

So in that regard, your question is "is an address created once it received bitcoins?" in a sense that 'the Bitcoin World' is what people see.
By disregarding the network, try to type any unused valid address to any blockexplorer and it'll "find" it since addresses have always been existing.

Additionally, the first transaction related to address: 11111111111111111111BZbvjr representing the number '1' was on 2011.
But that doesn't mean that number 1 or 11111111111111111111BZbvjr is created on 2011, number 1 has been existing since humans learn to count;
In that address' case, ever since p2pkh is implemented.
Because every address that represents HASH160 value of 0x01 to 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF have always been existing.

It's "average" block time and not an absolute value.

That is based from the adjusted "difficulty" from the previous 2016 blocks (about 2 weeks).
The harder the difficulty, the harder it is to produce a hash lower than the "target".
So since mining is basically generation of pseudo-random hash, we will never know if miners get lucky enough to generate a valid hash in the next second or unlucky to generate it after an hour.

Is there any particular reason for this?
Because in normal circumstances, this shouldn't be an issue if you're the sole owner of the private key.
Solved puzzle 66 or something?

Incidentally, Sparrow Wallet removed all of its samurai-whirlpool-related features right after that incident,
in this commit: github.com/sparrowwallet/sparrow/commit/1676676e06d8e7774d9eddc2f08663b1a2c49e3a

And even if an older version with whirlpool is used, there'll be no Samurai Whirlpool Coordinator to process it.