IMO, people (including me) don't like it if a user only quoted a part their post and replied to it without considering the whole post.
So, the quotation of a small part isn't the issue there: it's the reply; as long as it's proper, it's good.

Sometimes, I even -snip- the whole post but keep the [quote][/quote] tags to show that I'm replying to that particular post.

First of all, you should be working on another PC with its own system disk and just mount a clone of the drive where your deleted wallet/keys are.
Writing or installing anything on it can potentially overwrite the very data that you want to restore, including using it as a system disk.

About cloning the drive, I don't have anything to recommend for Windows, I also don't know if Windows' "System Image" is a clone of the whole drive.
If you can restore your Windows Image Backup to another HDD/SSD, do it and try to use that restored copy instead.
---------

After that, download and extract pywallet.py into the same folder where python.exe is located.
Then you can use it without installing anything aside from python v2.x.

The example command in my first post should work but you should change the parameters based from your drive and directory paths and size.

You can launch python from its install directory by using command prompt's "cd" (change directory) command.

Example: if python is installed in "C:/Python/Python27" and python.exe is in that directory, you can enter: cd "C:/Python/Python27"
to set it as command prompt's working directory, then the python command should now work in that session.

If you already set-up a machine with the necessary GPG tools,
you don't have to set it up all over again so there's not much hassle to verify the new version.

Usually, you'll just have to redo the last step which is the actual verification; in the OP, it's the "Download and Verify Electrum" step.

But ThomasV believes otherwise. (ref.)
Because a channel wont automatically change from an active channel into a "static channel backup".

It may be a wallet backup like he suspected, a wallet restored from seed with 'recoverable channel' or restored static channel backup.
But since it's solved already and the issue in GitHub was closed, there's not much reason for charlie574 to clear this up.

You can also try pywallet's --recover tool: https://github.com/jackjack-jj/pywallet
It works just like keyhunter, it will try to restore deleted keys/wallet from the selected drive.

Here's an example command for recover (tested with python v2.7.17 and latest version of pywallet):
Then you'll be prompted for the to-be-created wallet's passphrase (where the keys will be imported) and the deleted wallets'/keys' possible passphrases.
(characters wont display as you type the passphrases)

The result will be a wallet.dat named "recovered_wallet_<number>.dat" that you can load to Bitcoin Core.

If force-close is used, the channel status should also change into "CLOSED" after 1 confirmation of the closing transaction with the label "Close channel <short channel ID>".
And another local "receive" transaction labeled as "our_ctx_to_local <short channel ID>" will be saved and will be broadcasted after a maximum of 2 weeks (last time I tried, it's just 1day).

Hmm, if it showed a green checkmark before, the transaction should've been proceeded with 6 or more confirmations already.
It's very unlikely for a transaction that was included deeply in the blockchain to get dropped so you must have just mistook the icons before.

Anyway, since it was a "blue computer" before you removed it, that means that it's only locally saved in your wallet
either due to dropped/replaced parent transaction, you haven't broadcast it or it's dropped from the selected server's mempool.

It looks like something weird has happened and it tried to open the channel with Trampoline Routing disabled despite using "Electrum Trampoline" LN node.
And now it only acts as a channel backup based from the right-click options that you're getting (like I previously mentioned).

---

I saw in the 'issue thread' that ThomasV (ecdsa) already closed the channel on his side but your wallet still failed to retrieve the funds.
Anyway, there's nothing else I can add in this thread, Good luck.

Have you checked the icon in front of that transaction if it changed from a "green check" () into a "blue computer" () icon?
Because if it do, you can just "Right-click->Remove" it if you want its locally-locked funds to be spendable again.

Okay, this seems to be the issue, you opened a channel with trampoline routing but it's somehow turned disabled in the settings.
There shouldn't be any major issue in disabling that aside from blocking sending capacity but since you're experiencing this issue, it may be related.
(the timing while opening the channel maybe?)

The possible solution is to re-enable trampoline routing (disable gossip) because based from your screenshot, it's disabled.
After enabling trampoline, the other options in the right-click menu might reappear (if not, restart Electrum after enabling trampoline routing).
If "close channel" became available, use it, otherwise, use "force-close"; or "request force-close" might work now after enabling trampoline routing.

I've checked the other party's "node alias" and it's indeed "Electrum Trampoline" but somehow displayed as the pubKey.
The good news is, if nothing works, you can coordinate with the owner to close the channel which is one of the developers.
You can open an issue in Electrum's Github page or contact the developers: github.com/spesmilo/electrum/issues
But before that, try the options above first.

This is the reply that I wanted to post right before this topic was locked:

In the previous related replies, hosseinimr93 was talking about the virtual size of his 1in-1out transaction which is 140vB, he didn't sent 140 satoshi and didn't used a dust input.
It's just an example which shows that the absolute fee can be lower than the dust limit (which shouldn't be linked together in the first place)

What I'm telling is if the fee rate is @1sat/vB and the outputs aren't dust, the transaction is standard.
Just take note of the thing's I've previously listed.

One more things is, dust limit is by default based from 3sat/vB average equivalent of an input, so if you were to add a 546 sat (legacy) input to a regular 1~3 sat/vB transaction,
usually it can still pay for the additional size that it will add to that transaction.
But since it's only based from the input's size, if both inputs are only 547sats, it may not be enough to pay 2sat/vB (needs computation).
But for 1 sat/vB, it's definitely more than enough.

Here are some examples (testnet):

• 9e3d0c4089ea141ca9f9870985c4bb0e37f05231628454381df92ce56fe1b7d1
  Two 546 sats input (min) sending 752 sats to one output @ 1sat/vB.
• 05ffb639cc25b0c792e9dd075f3e1af5f92e5984260942b9b14b68255327c6cb
  Three 546 sats input (min) sending 1150 sats to one output @ 1sat/vB.

---

Thanks for granting my request to unlock the topic for me clarify my previous post.
Hope this can clear the confusion.

Only assuming? There's a chance that it's not a WIF but a prvKey in different format.
See if there's a similar format on the prvKey formats listed in this thread: [overview] Recover Bitcoin from any old storage format

It seems like the channel wasn't set-up properly and acted like a channel backup based from the right-click menu options.
The "Open channel" transaction isn't labeled in the history either which shouldn't happen.

The issue that I'm seeing is: Since you've mentioned that it's "trampoline", your screenshots don't agree.
First, the channel doesn't have the "kangaroo icon" beside the lightning icon; Next, the node alias isn't one of Electrum's trampoline nodes and lastly, the lightning icon is visible in lower-right which states that trampoline routing is disabled.

All you can do is to use "Request force-close" and the other party should initialize the force-closure of your channel.
For some reason, you can't initialize it yourself so it's up to the other party (not any of the trampoline nodes) if he will force-close the channel.

How can this part clear your confusion while it contradicts the other part? The "other part" that tells fee and dust limit are different which is correct.
The answer for this part is: "it will be processed" since a txn with 1sat/vB fee rate is standard.

To make this even clearer, you'll just have to understand this:

• Don't complicate it since Bitcoin network's "standard" fee rate is @ 1sat/vB, as long as the fee rate is set to 1sat/vB or above, it's standard and will be processed.
  Do not bother with the absolute (total) fee since nodes do not base their txn relay settings from it, it all about the fee rate.
• The "dust limit" is compelled per output, means if you're sending to 10 addresses, the to-be-sent amount of each output should be at least the address type's dust limit.

Or just create the wallet normally... why go to the trouble of using the console.
Even since version 4.1.0, Electrum wont ask the user when creating a new wallet, it will generate a Native SegWit electrum seed phrase by default.

OmegaStarScream suggested the console command to generate a standard electrum seed phrase because it can't be created though the GUI.
When creating SegWit, on the other hand, the console command is unnecessary.

Both of those wallets can use the Electrum Server implementations like "ElectrumX" and "Electrs", etc. which requires a Bitcoin node.
So, you're quite right in your assumption that it's the same thing.

The difference is a 'Server' can "serve" the node's capability to its 'Clients' (like Electrum/Sparrow).

His antique account is way older than that.

He might have registered that "Welte" account in 2016 just to do this:
(The "recovery rules" was posted in 2018, his attempt may be from 2016 after "Welte account" was registered)

If this claim is true, the account was from 2010 or earlier:

That's because Child-Pays-For-Parent transaction is actually just a regular transaction that spent an output from its parent unconfirmed transaction.
There's nothing special about it, it's just a regular transaction that spent an unconfirmed UTXO.
So, if users were to spend their received unconfirmed bitcoins "normally", it will be considered CPFP as long as the fee rate is higher than the parent.

mempool.space (a blockexplorer, not "the mempool") is just flagging similar transactions as CPFP.

Can you post the whole log of the latest session? Or at least the related parts.
Because the recurring "Peer=n is stalling block download, disconnecting" doesn't tell much about the issue.
You can edit-out some parts that you do not want to share of course.

Also, you can also try to enable debugging (-debug=1) to output more information in the logs if there's nothing peculiar in the current entries.

Running Bitcoin Core wont consume that much power, it's as good as idle most of the time.
You can only shutdown the PC's monitor and leave it running in the background.

Closing Core wont cause issues, why do you need it running 24/7?