Do it while the average fee is still low.
You can set it from 5.89sat/vB into 11sat/vB to make it to the next block, or set a little higher for some wiggle room.

Such problem isn't caused by the wallet, it's mainly because of the competition in mempools.
It's as simple as: higher fee rate will get confirmed first.
If the number of transactions with higher fee rate than yours keep piling up, then your 5sat/vB transaction wouldn't make it to the priority.

The only issue caused by the wallet is the fee rate that it suggested but that's an "estimation" of the future state of mempools
so no one can really blame the software for suggesting a quite low fee specially if the user set low/eco priority.

"Node Crash" isn't caused by the higher database cache size, it's to minimize the chance of corruption of the UTXO set if the user is expecting frequent force close.
In general use-case, that isn't even a concern and most would've preferred faster sync speed.

Plus they use "probably" so the conclusion regarding higher dbcache could potentially cause higher chance of corruption on abrupt shutdowns may be debatable.
Because a low dbcache setting that causes frequent flushing of chainstate to disk may also be a factor to consider specially on slow drives.

RBF isn't going to be simple because the channel's remote node need to co-sign the transaction.
And CPFP in Bitcoin Core should be done manually since there's no specific command to directly create a CPFP transaction.
Good news is it supports "coin control" with send command to do that (CPFP).

Example:

• Find the UTXO created by that unconfirmed transaction with: listunspent 0 command. ("0" is important to include unconfirmed coins)
• Create a PSBT using send command with this format:
  bitcoin-cli -rpcwallet=<wallet_name> -named send outputs="{\"<your_own_address>\": <amount>}" inputs="[{\"txid\":\"<txid>\",\"vout\":<vout>,\"sequence\":4294967293}]" fee_rate=30
  Fill up the inputs field <> with the information from your unconfirmed transaction, you can edit the sequence if you want to disable opt-in rbf flag.
  Set the "fee_rate" to your desired value that can bump the child and parent's overall fee rate. (example below)
• Depends on the wallet encryption, the above should be enough to broadcast the CPFP transaction and it'll result with "true" together with the txid.
  If "false" (wallet is locked); sign the PSBT using walletprocesspsbt <PSBT> command. (requires to unlock the wallet to sign either command)
• Lastly, broadcast the signed raw transaction with sendrawtransaction <RAW_Transaction> command.

Sample send (Regtest):

Don't take my word for it,
But you're matching "millimeter" and "inches" which are from different measuring systems that's why you're not getting an exact match.

However, a 1/2 inch garden hose's internal diameter of 12.7mm is pretty close to 12mm, and there's a clamp which should secure the fit.
But as I mentioned, I'm not a plumber so DYOR still.

Confirmed transactions should've "Features" containing the script and flags displayed below the 'Timestamp'.
So you must have kept the page opened waiting for 1 confirmation for that field to show up. (do the same if you want to reproduce)

The image tells that the transaction is already confirmed at that time it was taken since the 'mempool/blockchain position arrow-up pointer' isn't visible
so it's not pointing to the yellow "future" blocks above but to a block in the blockchain on the right.

Anyways (it's a bug): github.com/mempool/mempool/issues/5196

Depends on who's "we".
If the "mainstream", that depends if the plugin will be included to the official repository and the dependencies be shipped in the release binaries.
Otherwise, it'll only be accessible to users who know how to include an Electrum plugin or can follow the given instrcutions.

Current plugin directory does not include "joinstr": github.com/spesmilo/electrum/tree/master/electrum/plugins
So, it's currently only available to power-users.

So the backup isn't unencrypted like you claimed, that could've easily deduced if you mentioned the backup's file name.
Note: The "aes" between wallet and the extension indicates that its payload is encrypted.

Do you have a backup of your account recovery phrase? (various number of words)
That can recover your password and wallet ID, here: https://login.blockchain.com/wallet/forgot-password (do not paste new 12-word BIP39 seed phrase)

If you don't have, you must remember a large portion of the password that you've used so bruteforce would be possible.
In that case, try BTCRecover: https://github.com/3rdIteration/btcrecover
Refer to the link in the reply above for the documentation.

If you do not have the resources and/nor technical skills to do that, you may consider using Dave's "walletrecoveryservices".
Only use the contacts in the official site and do not accept any PM/email who claims that they are affiliated.
link: https://www.walletrecoveryservices.com/

Only if you know the password. Otherwise, that payload will stay encrypted.

OP was asking as if it's necessary to do to receive the transaction to his cold-storage Electrum in tails, which is not.

If it's about creating transactions, then he can just create a watch-only wallet on an online Electrum.
Export the transaction to be signed with that cold-storage Electrum, then export it back to the online Electrum to broadcast.
There's no need for any third-party tool in that "established" way to spend from Electrum cold-storage.

I'll just clarify this part as heads up to those who use BTCRecover.

Yes your hunch is correct.
The only related args are --bip38-enc-privkey which takes a valid BIP38 private key and --bip38-currency which defaults to bitcoin.
BTCRecover can only bruteforce the BIP38 encrypted private key's password with the tokenlist but not the missing characters from the encrypted private key itself.

That doesn't look like "json", more like the "base64" encoded payload.

Theoretically, if it's not encrypted (wallet.json), opening it with any text editor is enough to see the private keys in bare base58 format next to every "priv:" lines.
Since you claimed that there's no password, decoding that base64 string should result with readable text containing the data I mentioned including master keys if the wallet is HD.

You said "I Have", but didn't mentioned where you got it from.
Is it from someone that claimed that it's a blockchain(dot)info backup or you downloaded it from the wallet yourself?

There's no need to import anything there since it's the seed phrase that makes you in control of the transactions you've sent to it.
As long as the address that you used as recipient is correct, it's now safely stored in your cold-storage.

The transactions that you see in your Hot wallet aren't due to being sent from wallet to wallet.
Those are recorded in the Bitcoin Blockchain which is stored in every Bitcoin node, your wallet just shows the ones it can spend with its private keys.
So generally, the transactions that you see in the history are merely for balancing purposes only.

Same principle in your Cold storage, it doesn't hold transactions but private keys derived from your seed.
If you do not want to "see" the transactions, there's no need to populate its history since its private keys can spend the transactions you sent to that wallet.

But if you insist on saving the raw transaction to your Electrum on Tails (which will just be deleted if the wallet file isn't in a persistent storage)
You can export the raw transaction with:

• Double-click the transaction in the history.
• Click "Share->Save to file" save that transaction to a flash drive.
• In your cold-storage, click "Tools->Load transaction->From file" and load that exported txn.
• Click "Save" to save it to your history as a 'local transaction'.

Take note that it isn't necessary to do this since all you need is your seed phrase or private key (for single address paper wallet)

Yes.

Based from the explanation in your previous reply, it looks like those two authenticator apps' data have been cleared.
Have you done any phone "optimization" lately that gone beyond clearing the cache?

Anyways, those cannot be restored without a backup.
If you created a backup of your authenticator app's data after setting up Coinbase 2fa, simply restore it.

If not, just expand and follow the "Don’t have access to your phone/authenticator app" steps in the link provided by logfiles.
That'll reset your 2fa to either authenticator app.

Atomic still use legacy address so it doesn't matter if it shows sat/B since the value would be the same if you compute it to sat/vB.
There's no 'Witness data' in transactions it create so the "Weight Unit" (WU) would be x4 of the entire transaction's size in "Bytes",
Then "vBytes" is WU/4 which will obviously result with the same value as the raw size.

Given that, go to the most recommended fee estimation site and use its recommended sat/vB fee rate even though Atomic shows sat/B.

Hmm, they use "slightly" there.
Maybe it has something to do with "Sybil Attack" where the Tor exit node might able to isolate your node to the rest of the network by connecting you to his 'bad Bitcoin nodes'.
But since it's extremely hard to pull-off since all of your peers has to be the attacker's nodes, it's a "slightly less security" issue.
Your node will still connect/listen to Bitcoin nodes on Tor with the setting ticked.

But for more accurate answers, it's best to ask the ones who wrote the note themselves.
You may ask the actual Umbrel developers with their contact info here: https://github.com/orgs/getumbrel/people

Great, then some of Blockcypher's nodes don't belong to those nodes "that enforce that rule".

I generalized the first part because it's pretty much mandatory to protect the owner's node due to it being a DDOS attack vector.
Plus, I'm not aware of any implementation that accept such transaction to their mempool, some niche or personal Bitcoin client maybe.

Let me add a clarification regarding this for OP.

Transactions with nLocktime field set to future dates/block will be rejected by nodes as "non-final", so it wont make it in any node's mempool that enforce that rule.
so it'll either stay in the wallet locally (not broadcasted); or in text, digital or paper.
Ref: github.com/bitcoin/bitcoin/blob/538363738e9e30813cf3e76ca4f71c1aaff349e7/src/validation.cpp#L797-L802

NotATether must be referring to scripts with CheckLocktimeVerify (OP_CLTV) that prohibits the UTXO to be spent until the set expiration date/block in the script.
In this case, locked UTXO can be included to mempools then the blockchain once "mined" but can't be spent until the right condition is fulfilled.
OP_CLTV (BIP-65): github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
Example use-case: coinb.in/#newTimeLocked

That's a possibility, the second part of the error about "not being able to bump" lowers that possibility though.
Because it means that he's used the entire balance, sending a lower value (3 decimal places lower) than his intended amount should produce change.
With change, the second warning shouldn't appear.

Let's say that he's intended to send 0.01BTC but typed (0.01mBTC) 0.00001BTC instead,
if he got a single UTXO that can cover his intended amount (higher than 0.01BTC), using it as input in that txn will create a change so the second warning shouldn't appear.
if he got multiple UTXO that can cover his intended amount, only the ones needed to pay 0.00001BTC are spent leaving some available UTXO so the second warning shouldn't appear either.

The chance that it's the case is if the input's excess amount is used as fee which is "15.61% of the amount" sent.
Maybe in specific cases where the owner thinks that his 'N mBTC' displayed balance is 'N BTC' and didn't sent a very small amount which otherwise would show higher than 15%.

I think the warning is a heads-up to users that the default options in "increase fee" menu wouldn't work.
But it wouldn't hurt to replace it with a more specific message
Maybe a shorter version of yours, like adding "..without deducing the recipient's amount" to the original message. (still long though)

You may consider making a 'Pull Request' that edits the warning into something similar to the example, if the core developers think it's necessary, they will merge it.
If not, they would post a reply regarding the reason why.

The part to edit is currently in this line: github.com/spesmilo/electrum/blob/83e14794a1e1202ecfd40f0ea779f0b91ccf2032/electrum/gui/qt/confirm_tx_dialog.py#L579

Take note that Electrum isn't designed to use thousands of addresses or transactions since it's an SPV wallet.

At some point when you're receiving hundreds of payments per day, your Hot wallet may not fully sync while connected to public Electrum servers.
Setting your own server and changing the setting related to that limit will work but you may as well use the required full node's wallet that doesn't have that limitation.

Some clarification in BTCPay Server's options:
Number two option is now possible with Electrum or Bitcoin Core.
Useful if you want to keep the wallet Air-Gap to be used for signing purposes only and let BTCPay create the transactions.

Number three option requires you to set the Account Key path in your BTCPay's setting which is equivalent on the "Derivation path"
showed below Electrum's 'Script type and Derivation path' window when you restored it there.
Then the "Master fingerprint" is the first four bytes of the HASH160 (SHA256 then RIPEMD160) of the public key pair (without the chain code) of the master private key.
Electrum doesn't show it, some wallets like Sparrow and Bitcoin Core do.

No SSH to access the node? That would be hit or miss.
Since you'll need to check your Bitcoin node's "debug.log" to point you to the right direction.
There should be something in the last two logged sessions in that file, before and after the restart.

Anyways, ±100 blocks is just less than a day worth so it wouldn't take long to catch-up to the tip.
Silly to mention this but if that "restart" took about half a day, the gap is just right for the number of missing blocks.

This is applicable to most wallets but transactions created by Electrum v4.4.0 and later are always flagged with opt-in RBF true.
He's using version newer than v4.4.0 since he can see that that warning.

Implemented after this commit: github.com/spesmilo/electrum/commit/e1dc7d1e6fb2fc5b88195b62cbe1613b252db388

There's a typo here.