"Each of their own"
Me, I personally like the current design of the website.

If you're serious on pushing those design changes, you can submit changes in the website's code here: github.com/bitcoin-dot-org/Bitcoin.org
If the website's developers like your design, they may consider it.

Note: bitcoin.org isn't something like an official website of Bitcoin since it's decentralized by nature.

Then the article lacks details when it quoted the message saying that it has to be "tapped on a new device".
By the term "device", it means a new hardware wallet since it started the quote with "If you lose your device", and the phone is mentioned separately.

And it's not a suggestion, it's my opinion based from what's written.

I've read the article and my impression is it's more of a "gimmick" of an existing feature than a new security feature.
You know, to have something fancy to market.
Not to mention, it breaks cross-wallet/platform compatibility of the backup, so, if the device got broken, another one of their device have to be purchased to restore.
(unless there's a way to access the data stored in those cards or if it's compatible with others)

And it isn't mentioned there but I take that the two cards can be used in place of 1 card and the user's phone.
Otherwise, it'll be more risky to lose access than the standard split mnemonic backup available today.

Agreed, the thread is getting towards hardware wallet discussion than Sparrow.

Theoretically, you can create an non-standard old Electrum seed phrase with higher number words by using very old Electrum's "mnemonic.py" script with a very long seed (Hex, 3 words per 32-bit)

E.g. in v0.30's mnemonic.py:

But you can't use that in old nor new Electrum clients, it's not the accepted "old_seed" format.

I doubt that it's an old Electrum seed if it isn't 12 words.

The first sentence in the quote is the answers to your question.

You've set it to a "Solo Mining Pool" so you'll only get a payout once your miner hits a block.
Those calculator result is based from average of when you're not solo mining.

I thought they've already fixed that issue before...
As their customer support would say: Have you checked your "Spam" folder or other inboxes?
Have you tried including their "Authorize Log In" email address (notify@wallet-tx.blockchain.com) to your contacts or whitelist?

In the provided steps by the two replies above,
You may choose to use "Detect Existing Accounts" in the script type selection window so Electrum can look for the possible derivation path and script type that you may have used.
For example, if you created more that one wallet name in "Settings->Wallets and Addresses", Electrum will detect two which should be restored separately.

Also, only your "DeFi Wallet(s)" can be restored in Electrum, the custodial funds have to be access through their App/Website.

If you have the time, I think it'll be trivial to check because there are only 39 commits on top of it.
Some of which are one-line changes and updates to documentary files.

Start here: github.com/spesmilo/electrumx/commits/master/?after=f0707f6457f63fa04a7a5bcbff8cca6b2e8fe280+34
Then proceed to the previous page (there's no related changes in the 4 newer commits in that page, BTW)

According to the commit that removed version 0.22.x from the requirement, it could cause memory leak.

Reference: github.com/spesmilo/electrumx/commit/df390187eeed7c48fda2c94d5ffb04742c722778
There's a url in the comments linking to the related aiorpcX issue opened by the Electrum developer who applied the commit above.

Do you mean "your address" instead of "wallet"?

Use "coin-control" to spend that output specifically, then send it to somewhere or back to the address in the input, spend the other outputs on another transaction as well.
But sending that away will not get rid of its link to the other UTXOs associated with that address,
The heuristics that link addresses or transactions together would still consider that address as one of the recipient of whatever that transaction is for,
All UTXOs associated with that address is obviously considered to be owned by its user (you).

The best solution to that is to simply do not reuse that address anymore and use another address of your wallet.
If your wallet only issue a single Bitcoin address; consider switching to another with better level of privacy.

Do you mean "your address" instead of "wallet"?
Use coin-control to spend that output specifically, then send it to somewhere or back to the address in the input.
But sending that away will not get rid of its link to the other UTXOs associated with that address,
The heuristics that link addresses or transactions together would still consider that address as one of the recipient of whatever that transaction is for.

The best solution to that is to simply do not reuse that address anymore and use another address of your wallet.
If your wallet only issues a single Bitcoin address; consider switching to another with better level of privacy.

There's a possibility of that since WIF isn't a thing back then, but most old tools exports the keys in 64 hex characters.
He should remember the tool that he have used to export or create those.

Or ask around for old tools that people may have used to export private keys from wallet.dat files before this PR.

Just upload it to talkimg.com, then share the img BBCODE in your reply.
Do not screenshot the actual keys though.

None of those resemble any format of a private key;
The 32 character's length and characters isn't recognizable.
The 64 character strings don't look like ECDSA private key for having non-hexadecimal characters.
Or have you replaced the the starting characters with something random?

1/2: Check this thread for the formats and possible ways to recover: /index.php?topic=4959742.0
3: No, it should be in the specific formats that's supported by Electrum: WIF or Mini-Private key.

They intentionally prevented it.
AFAIK, even without Cloudflare, the web wallet will not load completely.
It's for their users' safety since browsing a non-onion / clearnet website via Tor requires it to pass through a Tor Exit Node that could perform a Man-in-the-Middle attack on them.

It could safely work if they have their official onion website though.

Isn't that two-part as well?
The "SHA256SUMS" which contains the SHA256 hashes and "SHA256SUMS.asc" containing the signatures.
AFAIK, it's been 4years since Bitcoin Core separated the hashes from the signatures.

But I get what you want to achieve (too specific for a single tool though)

You can get in touch with developers in GitHub, repository of the official website: github.com/spesmilo/electrum-web, post it as a feature request issue.
This forum board is mainly for technical support of Electrum-related issues or questions.

For Reference to others who may come across the same issue and can't somehow fix the RPC error even with server=1:

They can create an unsigned transaction by ticking the "Create Unsigned" checkbox in the Send screen then, continue.
Copy the Transaction Data and paste it in the next screen (after pressing the next 'continue' button)
Click "Sign" to sign it, then "Copy Raw Tx (Hex)" after it's signed.

That can then be broadcasted to any push/broadcast transaction service (e.g.: blockstream.info/tx/push)
or node/wallet (Bitcoin Core's sendrawtransaction RPC) to send it to the network.

It's fortunate that you didn't experience any issue with that wallet given that you've chosen a web wallet of all things.

Agreed.
It must be because Electrum is widely recommended (for on-chain) and read somewhere that it supports lightning.

Personally, I've used it and I'm pretty much pro-Electrum
But I do not recommend its Lightning feature to newbies unless the person is really interested or insisting.
I just give them thorough explanation of the steps and the necessary "management" of the channel(s) and its liquidity.
This usually causes second-thoughts on using Electrum's lightning, at least, they are now well-informed of what they're trying to get into.

Then its up to them to decide to proceed to not.

I don't have other recommendations though.

Blockchain web wallet didn't issue 12-words BIP39 seed in 2014.
The number of words of their old "Recovery Phrase" exceed that (varies per version) and it's not something that can restore the private keys, it's for recovering the Password.

Have you actually done that or just forgotten?
Since you've used Electrum to restore a BIP39 seed by ticking 'BIP39 seed' option,
It must have showed you options to select the script type (address type) to derive from the seed, unless you've used "Detect Existing Accounts".

For the specifics:
BIP39 doesn't have the capability of identifying the right script type to derive, the client or user has to find or already know it.
e.g.: with BIP39 seed, Electrum asks the user for the script type to derive or it's "Detect Existing Accounts" button uses pre-defined derivation paths and script types to derive and look for associated transactions.

For the derivation from mnemonic to child private keys:
There's a "standard" to it.
Means that wallets should follow that standard in order to have cross-platform compatibility.

So if your wallet follows the standard, other wallets that do the same algorithm to get to the same results.
But if it didn't followed the standard, other wallets cannot reproduce it from the algorithm used by the standard.

I take that as an indirect accusation since I'm the first to reply to this thread.
Unfortunately, it's hard to disprove/prove without admin access.

For someone who's active in this board, I take every opportunity to answer or solve issues posted here whenever I'm online.

Once a mod locks a thread, the original poster wouldn't be able to unlock it.
OP (or whoever puppet it is) wont be able to reply if he decided to.

For the record, I'm not wearing a paid signature when I've posted my reply here.
AFAIK, it's the free Bitcoin signature or eXch's which I was planning to remove until their service's last date.
And for my current campaign, the post isn't counted for the starting week.

The other parts of Loyce's reply already explained it.

Encryption will not get rid of the old used private keys, those stay in the wallet, it'll just generate new set of keys (for non-HD) or create a new HDSeed (for HD).
Bitcoin Core will then issue those new keys / new HDseed when the user request for new addresses.

So, if OP backed-up an old unencrypted wallet.dat but used the wallet after it's encrypted, that backup wont be able to re-create the keys created after encryption.