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.

Someone asked the same question in February so I'll just link the thread here.
Link: http://bitcointalk.org/index.php?topic=5484654.msg63641742#msg63641742

If you think about it, the warning still make sense because to utilize replace-by-fee to an unconfirmed transaction, you need to set a higher fee.
But if your wallet does not have any other UTXO to spend and the transaction doesn't have change, it wont be able to do so without deducting the output's amount.
So it's just you wont be able to bump it without deducing the intended amount which isn't an option in most cases like payments.

When creating a transaction,
After clicking "Pay...", click the tools (settings) icon and tick "Show inputs and outputs".
Alternatively, click "Preview" too see more info about the transaction. ('sign' and 'broadcast' to send through the preview)

But the first part of the warning is not always due to the size and fee of the transaction, it may also be due to sending relatively small amount.
It's literally what it says.

It's normal though, peers usually disconnect/banned due to some factors like manually shutdown by the node owner, bad connection, misbehaving, etc.

Yes, the time in the 'Information' window is the actual start-up time,
The same timestamp that you can see in the "debug.log" file (in UTC time), your active session starts at the last "Bitcoin Core version" line.

You should read their "Earn" FAQ page to understand that "clickbait" email.
Here's a link to their earn page: https://www.blockchain.com/earn

Since you're asking about the passive reward for simply hodling BTC; your rate will only be 0.65% annually. (readjust per month)
The 8% in passive reward is for some Altcoins.

There is a maximum of 8% rate in BTC but that's for Active Rewards which requires you to do something to reach that highest rate.

Right, 125 if it can "listen".
Still correct otherwise, since you'll only see 10 (max of 11 for a short while) if your node cant establish inbound connections.

In "Network Traffic" window?
It resets in every restart, that's the total for the current session only.

I think you meant to just disable 2fa so you wont have to use the authenticator app,
not necessarily convert the wallet to standard since it's still a 2-of-3 MultiSig, 2fa enabled or not.

If so, that's still not possible in the command line since the only options for restore command are:
text (seed, master key, prvKeys or addresses), passphrase (extension), password, encrypt_file and wallet_path.
Ref: github.com/spesmilo/electrum/blob/master/electrum/commands.py#L281

In an additional note, they also prevent 2fa when creating a wallet in the command line.
e.g.: electrum --o create --seed_type "2fa"
result: Unexpected seed type '2fa'

I'm not the OP but: Bitnode's contact information is in the bottom (number 10) of their Terms of Service, here: bitnodes.io/tos/
Or contact the owner's email in GitHub: github.com/ayeowch

OP's last login was on March 29 after the issue was solved so he might not login again to see your post.

Read this topic for the instructions: http://bitcointalk.org/index.php?topic=5259973.0

As a heads up: You'll basically have to move your on-chain funds to your lightning channel through a transaction (so it involves a tx fee).
Then, after it's established, you can now send by getting the lightning invoice from the recipient.
But you can only send at first since you only have "outbound capacity", you'll gain "inbound capacity" in every BTC that you send via lightning. (search "reverse swap" in case you'll need more)
Check your 'Channels' tab to see the overall liquidity.

But take note that your BTC in your lightning channel(s) can't be used to send on-chain, vice versa.
You'll have to close the channel if you want to use its funds on-chain.
Closing the channel also involves a transaction.

While the description fits, the general example shouldn't mention or display an address because:
Like P2PK, P2MS can't be encoded into an address since the script isn't "wrapped" in P2SH or P2WSH script.

The common term they use for P2MS is "Bare MultiSig" while the wrapped script we use today is commonly called as "MultiSig".
But to be specific, call them: "P2SH-MultiSig" and "P2WSH-MultiSig".

So your example belongs to P2SH.
You can use this example instead: 949591ad468cef5c41656c0a502d9500671ee421fadb590fbc6373000039b693
(notice that it doesn't show an address)

Forget the wallet type, all of those support Opt-in RBF and your transactions are automatically flagged to be replaceable.

If you're looking for the settings, there are small "tool" icon [] in every nook and cranny of Electrum.
Each containing options related to where it's located.
For example, in the upper-right corner of "Send" tab, there's the setting icon containing the 'send-to-many' and other invoice related options;
After you click "Pay...", in the "New Transaction" window, there's a setting icon containing transaction-related options.
You wont find RBF anywhere though but it's enabled by default.

If in doubt and to make sure that you're actually using Electrum, just verify its signature.
Follow this tutorial: bitcoinelectrum.com/how-to-verify-your-electrum-download/

The only "trick" is to exchange your Bitcoins to BTCB then send that to your intended destination,
That's only if the recipient uses BEP20 chain exclusively.

But if it supports real Bitcoin, send from Electrum directly.
It's cheaper than going for those extra steps that doesn't just involve a "transaction fee" but also an "exchange fee".
Now's quite a good time to send bitcoins, while fee isn't too high.

Your transaction didn't went trough any acceleration and it's confirmed normally
since the average fee rate dropped way below 19sat/vB at the timeframe when it got its first confirmation.

Besides, it had an unconfirmed parent so he wont be able to send it to the (well-known) accelerator that he's using. (link, pretty obvious in the OP and some replies)