That video if for the older Electrum binaries that are signed by ThomasV alone.
The latest now have 3 signatures. Namely; by ThomasV, SomberNight and Stephan Oste (Emzy).

The result that you get is "good enough" for having one valid signature and certified certificate out of the three.
But if you really want a "green result" you should redo the steps to "import" and "certify" the other two developer's PGP key.
You can find their keys here: https://github.com/spesmilo/electrum/tree/master/pubkeys

That would be for your own PGP/GPG key pair, you can leave the email field empty if you want.
For verifying Electrum signatures, it doesn't matter if you've set an email or not.

It's never been a requirement but optional for the users' own safety.

AFAIK, there's no Electrum in the 'App Store', if there's one, it isn't official.
For Electrum downloaded from Android's PlayStore, you should check if it's uploaded by "Electrum Technologies GmbH" since you can't verify an already installed app.
If you want to verify, download the ".apk" and its signature file from electrum.org to verify it in your PC before installing to your device.

Okay as said above, its inputs are already spent.
Your wallet probably able to make and broadcast such transaction because it failed to scan the transaction that spent it.

Using rescanblockchain command (instructions) should update your balance to reflect the correct transactions and available UTXO to spend. (since those're spent, those shouldn't be available)
But if your node is pruned, you wouldn't be able to rescan the whole blockchain but only from the lowest block height that your node has.
After the rescan, it should be dropped from your mempool.

Have you set any configurations related to transaction relay or mempool in your bitcoin.conf file, GUI settings or command line options?
Because it may be broadcasted exclusively to your node due to a setting that allows it (thus the "in mempool" note) but rejected by all your peers for some reason.

Since you already willing to share the transaction via txid which we can't find, it's better if you can share the raw transaction for us to see the actual issue.
Get it from the 'Transaction' tab of the GUI, right-click on it and select "Copy raw transaction" or via getrawtransaction command.
Then put it inside [code][/code] tags so the forum wont mess its format.

In case that you want to abandon it as suggested by others, you'll have to get it out of your mempool first before the "abandon transaction" option can be clicked.
One way is to remove the option that allows it to your mempool which is at the same time allowing you to create transactions that'll have trouble with propagation.
Or the manual removal of mempool.dat (Bitcoin Core must not be running) and temporarily setting walletbroadcast=0 to be able to abandon it.

Yes, that is why I need clarification in that matter.
To see if that weird transaction is actually targeting a bug or just a user playing with rbf.

Mine is just a guess, we can't jump to conclusions because of one wild guess.

You mentioned that it's a "clear pattern", are there a lot of transactions that has that same behavior?

Interesting...
I'm not too familiar in Bitcoin Core's fee estimation algorithm but my initial guess is it's trying to trick the fee estimation by continuously broadcasting high fee replacement transactions with enough delay for the previous transaction to propagate.
Since it's a replacement, each relayed replacement is cheap since it'll only need to add a few satoshi on top of the transaction that it replaced.

But I'm not sure if the fee of the replaced transactions that a node relayed wont be removed from its "bucket" and if those will still be counted to its fee estimation after the last replacement is confirmed though.
If it is, that could be the purpose of those rbf spam.

It used to be possible in the older version but the devs decided to disallow it in v2.0.
Refer to this commit: https://github.com/spesmilo/electrum/commit/4ce699bf2570a4478c1f467f676c46e42f63f2b4

That's probably because it breaks the purpose of the seed phrase backup since the imported keys wont be recoverable from it.
And managing the HD derived keys and the imported keys was a mess.

No problem,
I'd like to also add that there's a chance that the original wallet isn't actually corrupted and the corruption of the restored "bluebird" wallet was just a result of the sudden crash.

If that's the case, you can try to Install Bitcoin Core on a separate "air-gap" PC and restore and load a copy of the original wallet.dat file there.
The wallet isn't actually corrupted if it loads, then you can export its private keys from dumpwallet command
or if it's a descriptor wallet, export its master private key via listdescriptors true

You may also want to consider restoring just the addresses or extended public key (xpub) to Electrum to create a watching-only wallet.
From there, you can create transactions that you can import to the offline Bitcoin Core to sign with your private keys.
Then the signed finalized transaction can be exported back to Electrum to broadcast.
It's a cold-storage setup which is safer than loading (and unlocking) the wallet.dat file on an online PC.

Wallet export or Wallet information?

Wallet export isn't available in Android at the moment,
Wallet information is still accessible in both Desktop and Android versions.

But if it's tracking that you want, you only need the master (extended) public key from the wallet information.
To get to wallet info in Android version: Click the wallet name above then select "Wallet details".
Your master public key should be listed there unless you're using an 'imported wallet'.

The general answer is no, the gained inbound capacity from sending is not permanent.
As you withdraw from Binance to your Electrum via Lightning, your inbound capacity decreases by its amount.

It depends on the amounts though, "sending" increases your inbound capacity while "receiving" decreases it.
So whether it gains or not depends on how much bitcoins over Lighting you send or receive.

Now that's an error unrelated to the previous one.
In my test, restorewallet crashed with the same behavior even if the wallet isn't corrupted.
Upon opening the wallet file, it resulted with the "beyond pruned blocks" error instead but the wallet is intact.

You can try the suggested tool which is located in "daemon" or "bin" folder inside bitcoin's installation directory. (Default: C:/Program Files/Bitcoin)
To use it (make sure that you still have the original wallet.dat file just in case 'salvagewallet' messed-up "bluebird" wallet):

• Browse to the directory where bitcoin-wallet.exe is located.
• Hold SHIFT and right-click on an empty space inside that folder (while nothing is selected); in the drop-down menu, select "Open PowerShell window here".
• In PowerShell, type: ./bitcoin-wallet.exe --wallet="bluebird" salvage and it'll try to salvage that restored wallet.
• If it's successful, the corruption error should be replaced with the prune-related error instead.
• If not successful, I'm afraid that it's a job for data recovery professionals.

Overall, the main issue is: the wallet file that you're trying to restore could be corrupted, -reindex isn't the solution to it.
And even if you successfully salvaged the corrupted wallet, you can't rescan it with a pruned blockchain without re-downloading the blockchain.

Not in Bitcoin Core, rescanning an old wallet requires the blocks to be intact in your drive (no pruning) or if it's not possible to store the whole blockchain due to drive space issue, you should reindex your node while the wallet is loaded.

The other solution is to export its private keys once it's salvaged and loaded on a fresh Bitcoin Core (offline) then import them to other clients.

Seem like it's cut without showing errors in the logs either but the wallet directory is already created.
I tried to reproduce the issue with a pruned node of 2GiB setting and it also crashed but the wallet is restored to the desired wallet directory (wallet name).

Since it's already there, can you see 'bluebird' wallet in "File->Open Wallet" menu in your case?
If it's there, the wallet can be loaded but since your blockchain is pruned and the wallet is very old, it may result with an error related to pruning.
If that's the case, you may have to disable "prune block storage" setting, then --reindex to be able to load and rescan old wallets without those issues.

Your node seems to be running without issues aside from a missing "vb" wallet that is still loaded in your "settings.json" file.

Have you reproduced the crash in this last session? It has a note that the previous session was closed unexpectedly.
If no, find the logs of the session when the issue happened (that would be the logs above it)
Follow these instructions in case it's hard to find the right logs:

• Close Bitcoin Core, rename your debug.log into something like "debug-old.log".
• Start Bitcoin Core and repeat the steps that you've done that'll lead to a crash. (take note of any error that you get)
• Now, a new debug.log file should be in the data directory, and share it.

---

BTW, to fix the warning about "Skipping -wallet path that doesn't exist":
edit your 'settings.json' file and remove the name/path to that missing 'vb' wallet leaving only your available 'test' wallet.
Your settings.json's contents should look like this after removing "vb",:

It also tells that your blockchain is set to be pruned to 2861MiB which could be an issue in case you successfully restored the wallet file.
Disabling it will require you to redownload and verify the blockchain from start.

Don't do that yet if Core didn't warned you about corrupted chainstate or block index.
I hope that you didn't set to "prune" your blockchain because you may have to redownload everything after restoring the wallet depending on how old it is and how much is pruned.

You only need to provide the contents of your debug.log file inside your bitcoin data directory for us to see the possible issue.
If you're using the default, it's in this location: https://en.bitcoin.it/wiki/Data_directory#Default_Location

If it's too long, cut it to the last session - from the last line, then scroll-up to find the first "Bitcoin Core version" that you can find.
Paste it inside [code][/code] tags.

In that case, you might want to consider to "max-out" the motherboard of your choice. (for futureproofing purposes)

Ordinals haven't increased the pace since the maximum block weight is still at 4WU (1vMB) even after TapRoot upgrade.
Maybe a bit because of the more consistent full blocks that's caused by the large transaction volume that we're experiencing since then.
Refer to this chart: https://ycharts.com/indicators/bitcoin_blockchain_size
At that pace, your 4TB SSD should be sufficient enough.

Take note that when bruteforcing Electrum wallet passwords, it'll be limited to --enable-opencl instead of --enable-gpu.
The latter wont work on it and the former is still experimental which will only work in select GPUs.

He also have to use the forked BTCRecover by 3rdIteration that is not older than v1.2.0.

That is correct, but opening a channel requires on-chain balance in Electrum that will be used to open your channel. (all "outbound capacity")
Last time I opened a channel in Electrum, the remote node set a minimum of at least 0.004BTC.

But take note that lightning and on-chain payments are separate; you can't pay a bitcoin address with lightning nor pay a lightning invoice onchain.
So, depending on your goal, this may not be the solution for you.

1. For outstanding balance, No.
But your channel needs "inbound capacity" to be able to receive through lightning.
You can see that in the 'Channels' tab as the "can receive" note above it.

One way to gain inbound capacity is to utilize (reverse) "Submarine Swap" which you can access in 'Channels' tab's setting icon. (maintained by a third-party)
That will transfer your outbound capacity to your on-chain funds, by doing so, your channel will gain inbound capacity from the sent lightning funds.

2. N/A
3. N/A

4. Yes, you can set a different fee slider or even set a custom fee/fee rate of your choice, just enable "Edit fees manually" to have the freedom to manually edit fees.
You can find that option in the settings icon (upper-right) in "New Transaction" window after clicking "Pay...".

That's a good guess;
But if it's an amount higher than his available UTXO(s), the error "Not enough funds" will be shown in the 'Send' tab without the "use a lower fee" note.

Refer to this reply in page1 to see the instance where the error described by OP will appear: /index.php?topic=5477026.msg63305152#msg63305152

He's asking about the wallet application, software or hardware wallet, that's your bitcoin address.
Because unless we know where it's sent, we can only suggest you to "do CPFP" in a general way, not the wallet-specific steps or if it's even possible.

In CashApp, they do that "reversal" when the user's deposit was rejected by their system.
The issue is, they somehow consistently using that low fee rate in their reversal transactions.

Exchange-related topics can be posted in 'Exchanges' sub-board of 'Service Discussion' board.
Here's a direct link to that board: https://bitcointalk.org/index.php?board=223.0

But if you think the main problem is mostly related to the Altcoin that you're trying to withdraw, it should be posted in "Service Discussion (Altcoins)".
Link: https://bitcointalk.org/index.php?board=198.0

BTW, that webpage has 3 hits in Virustotal flagged as a phishing or malicious site.