Like I've said above (Post #50), the lightning funds below must be a "bug" and there's no on-chain funds deducted.
And upon deleting the local transaction in the history, your non-spendable UTXO(s) should be available again.

I have tried to tinker the wallet file (testnet), I've found out that you can manually remove those bugged channels by removing the "channel backup" entry in the wallet file.
But that's quite dangerous if you don't know what you're doing so, restoring the seed should be enough if there no active channels in your wallet.

Here's the the important part (quoting myself):

If it's not showing in the blockchain, then perhaps it's saved as a "local transaction"
since the server where you're connected to won't see it in its database nor mempool, it will change into "local" from unconfirmed/others.

The funds should be restored by removing the local transaction from the history (right-click->remove) or read the next sentence.
For the channel (or funds), I still haven't found a way to remove those "bugged channels" that I've created in testnet
but if there's no other active channels in your wallet, you can just create another wallet by restoring your wallet's seed phrase.

Yes, that's why you have to set higher than 10sat/vB if your transaction has Witness data to reach viBTC's requirement of 10sat/B.

Come to think of it, for example (based from an existing SegWit transaction):
If your SegWit transaction has a feerate of 10sat/vB and a virtual size of 166vB, you're paying 1,660satoshi.
If based from the RAW bytes like Viabtc is doing, which is roughly 247B the fee rate would be 6.7sat/B (1,660/247).

I have tried to send SegWit 10sat/B tx to viabtc before and they always result with "not enough fee" error.

The OP best explains what's happening in that transaction  

The "priority transaction fee rate" during your first post is a lot higher than this hour's so 254% or 215% wont matter.
What matters is: with that fee, his transaction should have a lot of inputs to reach that total fee.
Reading the OP will help you solve that kind of issue but! You can't do it now since 1sat/B or one-digit fee rate isn't possible ATM.

It should be higher because wallet supporting SegWit computes based from the virtual bytes while they compute based from the RAW Bytes.
It's their requirement which is (RAW) 10sat/bytes; using that formula, if you set your SegWit transaction's fee to 10sat/vB, they will "see" it as <10sat/B.

During these times, I usually set the fee rate to 10sat/B then paste it on Viabtc's accelerator (higher if SegWit bec. they compute based on the RAW bytes).
Then time the submission right (HH:00) and it should confirm once they mined a block.
That fee is quite good and cheap for 1-input TX anyways, in case I failed to submit it on accelerators.

BTW 254% of 0.0015BTC is 0.00381BTC - he must have used a lot of inputs for that attempted transaction since even at 100sat/B, the transaction's virtual size must be 3.8KB+
You must refer him to this thread's OP  

Assuming OP is always doing the "usual blockchain catch up", then the last time he did, his node had been syncing;
and after it was 100% synced, his node might have received a "will-be" stale block (new tip) then he closed the client right away because "blockchain had caught up".

But there's no much gain in finding the exact cause of the issue since this was solved now  

Probably.

It wouldn't know if it's the tip at that time then the user immediately close his node.

That's because you've opened it using an updated version which also updated your wallet file.
The only way to use that wallet now is to open it with the same or earlier newer versions of Electrum, trying to load it with an old version will result with an error.

Also, read the warnings above since you most likely downloaded a compromised version of Electrum v4.0+.
Or it may have failed to "hack" because of your wallet's previous version, it this case, send the funds to a new wallet immediately.

The difference is "nLocktime" field is in the transaction as a parameter, even TXs w/ non-CLTV outputs have this.
In which the transaction itself can't be broadcast / will be rejected by nodes (as you post's first line said).
Think of it as a stand-alone feature for your question's sake.

So, if you set the nLocktime of the spending transaction at the future block/timestamp, you wont be able to broadcast it right away.

Is all of your funds in that selected wallet "Meine Bitcoin-wallet"?
Because if it's in the other wallets, you need to select them each from the drop-down menu.

Otherwise, it's a common blockchain.com wallet bug which involves "wrong displayed balance".

BTW, this thread will be moved by mods to the right section.

Correct, but the example may have gone over the head of some  

Alternate explanation:

• Yes, RBF will create a replacement for Transaction1 which invalidates the previous outputs and will make Transaction2 invalid for "missing input(s)".
• But, CPFP will not create a replacement, it will just spend the other unconfirmed outputs of Transaction1 [not TX2's input(s)]
  and "anyone" can't CPFP the other outputs but the ones belong to their wallet so it won't invalidate Transaction2 even if they do CPFP.

Forget the intricate stuffs and manual computations, if your wallet/client supports SegWit and showing sat/vByte or sat/B, then use that.
Miners will pick the higher sat/vByte transaction (fee rate) rather than the total paid fees.

That "split" seems normal, the last transaction just spent the "change" of your previous transactions, plus one that's probably from your older transactions.

If it's really not you, then the issue must be there's someone else who've used your seed and passphrase combination to make a wallet (which is highly unlikely)
because why would a hacker send coins to his victim's wallet?
I bet this is just caused by a cloudy memory.

Perhaps your node followed a "stale block" sent by a pool right before you closed Bitcoin core.
Then when you opened to "blockchain catch-up" it was invalidated.

AFAIK, forks with 1-block-long chain happen often because of competing miners.
Previously, we can easily check it here as a chain diagram with height: blockchain.com/btc/orphaned-blocks but the link is now unavailable.
So we can't confirm it.

But it's now solved so, congrats!

That "pending" is from the send tab - when you try to send a transaction and you're offline then cancel it.
The way to send it which is "right-click->pay" is different than the solution posted by ranochigo.

This thread however is an issue with locally saved transaction which was listed in the history tab marked as "Local".
Because after 4.0, users can now save a related unsigned transaction in the wallet which wasn't possible in 3.3.8 before.

Thanks! I've reviewed BIP-0125 and it did said "(0xffffffff - 1)".
It's just I haven't seen a non-RBF transaction with 4294967294 sequence, or I'm not searching hard enough.

For the record, "johoe's bitcoin mempool size chart" also base the transactions in vbytes so those MB are actually "(virtual) MB" and sat/B are "sat/vB".
This is written below the page:

---

Lower virtual size wont matter with the prioritization, miners will use the "fee rate" (n sat/vByte) and lower vbytes means lower total fees to pay.
For legacy, the virtual size and size will be the same since all of its data are all non-Witness.

You might be missing the point of "n sat/vByte", it's as simple as this, example:
3sat/vB of a SegWit transaction with 134 vBytes size. Just multiply it and you'll get the total fee of your transaction = 402 satoshi.
2sat/B of a Legacy transaction with 235 Bytes size = 470 satoshi.
In this case SegWit transaction will be prioritized over the Legacy transaction even though it has lower virtual size and lower total fee since it's paying a higher fee rate.

Sorry to barge in but "redeemed" means that the fund is now spendable not a re-opened channel.
When you force-close a channel, it will create an "our_ctx_to_local" transaction that spends the closing transaction,
it can't be broadcast until a number of blocks (shown in the transaction history) has passed and will automatically broadcast if Electrum is open.

Update to this: I've experienced this just now when I tried to open a channel with another instance of Electrum while another is opening a channel.
The error message is "Assertion error" then a "Disconnected" channel was created with reflected Lightning balance but the on-chain balance wasn't deducted.
There's no "Open channel" transaction either.

When I tried to Close the channel, it just returned with an error (as expected) and the status changed to "shutdown".
When I tried to force-close the "Shutdown" channel, it returns with the same error as yours since there's no valid input.
I tried to reproduce it trice and the "bugged LN funds" reached 0.06 tBTC while my original onchain funds is only 0.02 tBTC and it wasn't spent.

So your LN funds must be a bug to begin with if there's no "Open channel" in your history.

Since you're talking about "Block Header Hash", it's about mining, then that quote from the "decent answer" is the answer.

In case you've missed this info from that link and from this thread as well:
the merkle root is part of the Block header and if you hash the block header, you indirectly hashed all the transactions in that block because the merkle root is the root hash of all the txs in the block.

Usually, you can easily check your client's history or transaction's details for RBF or Replace-by-fee flag as said above.

But if you want it the hard way, you can check the raw transaction (not the hash and txid) and look for "FFFFFFFF" somewhere in the middle,
if there's none, the transaction might be signaled as replaceable.
To make sure, you can decode that raw transaction and look for "sequence", if none is exactly "4294967295", it's replaceable.

Some online tools you can use if you don't have Bitcoin core:

• getrawtransaction to get the raw transaction from txid, select "true" to decode.
• blockcypher - decodetx to decode a raw transaction.