That's the "about" page and it's displaying your installed Electrum version.
What this thread is about is the manual/automatic "Check for updates" function that the android version doesn't have.

---

Looks like ThomasV have posted a reply regarding this issue: https://github.com/spesmilo/electrum/issues/6338#issuecomment-665757716

You cannot delete already broadcast transactions and unfortunately yours was already propagated in the network.
One option you can do is to RFB the transaction if you've set it in the preferences,
try to check if your tx has RBF flag by checking the details (double-click on the transaction date/icon) and see if "Replace-by-fee" is True.
If it is true, you can right-click and use "increase fee".

If not, you can open the receiver wallet and use CPFP  (Right click->Child-Pays-For-Parent) to the receiving transaction and set a high fee that you're willing to pay.

To view the usual fee slider and manual fee input that you've used to, click "advanced" after clicking "pay"
or enable "Advanced preview" in the settings (Tools->Preferences->Transactions tab).

BTW, next time, open your own thread if it's off-topic.

I suggest you to read about "merkle path" in page 167-168 of Andreas M. Antonopoulos's Mastering Bitcoin.
You'll understand how SPV nodes can efficiently verify its transactions using the merkle root which is in the blockheader.

Here's the wiki page with links: https://en.bitcoin.it/wiki/Mastering_Bitcoin

If the locktime (height or time) is still not reached, the error message alongside with the server error should be "non-final".

That looks like a missing input error which was caused by trying to double-spend a already spent output or not-existed at all;
Can you check your wallet for possible closing transaction that wasn't labeled?
Paste the "open channel" transaction's TXID (in a block explorer) and check the non-change address output if it's already spent.
Also check if it was sent to one of your own wallet's addresses.

If there's no "open channel" transaction, perhaps there's no established channel to begin with.

If it didn't see a confirmed closing transaction, it won't transition to "Closed" but rather stay "Open"
and "Reestablishing" is a state based from the other peer of the open channel, means the channel is open but trying to re-connect to the other LN node.

It's 14 days by default but the user can change his node's mempool configuration depending on his preferences.
Bitcoin Conf: mempoolexpiry=360 (hours).

There is also a chance that your transaction will get dropped by most nodes earlier than expected because higher fee transactions were prioritized and their mempool maximum size was reached.
Again, not all nodes would do that since it's also configurable in bitcoin.conf: maxmempool=300 (megabytes).

When it was dropped by all nodes, you can send another transaction again using the same unspent transaction output(s).
But will depend on your client, Electrum for example will keep it as a "local transaction" which wont let you spend those outputs unless you delete it in the history.

2. Before you can even get to that link, you'll see a big warning message on top of the download page:
Plus that direct link to the previous releases isn't endorsed in any other sites aside from forums/articles when pointing to old versions.

1. That "DOS attack" that has been mentioned, it does exactly that, it renders those outdated versions unable to fetch latest balance and broadcast transactions.
So the user might research or update to the latest version.
But the catch is: it requires the client to connect to a "counter-attacking server" to get blocked out of connection; not if it connects to a malicious server and non-patched servers.

You cannot click 'broadcast' while it's unsigned, you must have clicked "save" at the left side of the advanced preview instead.
There's no other way it was saved as an unsigned local transaction.

It's probably the label of the transactions in the history, it's red if the funds is outgoing.
"Open channel" of course is colored red.

You should update your Bitcoin core client, 0.19.0.1 and latest version won't derive an address from P2PK outputs using decoderawtransaction or getrawtransaction "TXID" "true".

If you want to get the address despite the fact that it shouldn't be converted into an address,
you can convert it through any "pub key to address" code that supports uncompressed pub key using the public key which is in that scriptPubKey (highlighted):

41 - push 65 bytes to stack
0496.............58ee - Public key
ac - OP_CHECKSIG

Nope, it depends on the virtual size of the transaction, that's affected by how many inputs (a little bit from outputs) you're going to use, not the value.
If a wallet only has 1 input with $1000 value and want to send $1~999, then he wouldn't have to use $1 fee to send a priority transaction specially with SegWit.

Nope II, it's a local transaction which wasn't broadcast to the network yet as already pointed by others.. twice.

There should be an unconfirmed 'close channel' transaction in your history, you'll get the funds back after it confirms.

But is there an 'open channel' transaction in your history and, was your on-chain balance reduced?
Because the way you described it: there's no opening transaction occurred.

Too bad, kyuupichan's ElectrumX now only supports Bitcoin SV [BSV].
You can check the code itself: https://github.com/kyuupichan/electrumx/blob/master/electrumx/lib/coins.py#L268, there's only BSV and its testnet/regtest there.

You can use the older versions (1.14.0 and below) though: kyuupichan/electrumx/releases or the Altcoin branch: https://github.com/kyuupichan/electrumx/tree/altcoin

There's no fancy formula, all you have to do is to multiply non-Witness data by 4 and Witness data by 1 and that's the Weight of the transaction.
Then divide the weight by four to get the 'vBytes', that's basically the same as what your client (eg. Electrum) is displaying as 'Bytes' if it supports SegWit.
Lastly, compute based from the usual 'n sat/B' fee rate.
Read https://en.bitcoinwiki.org/wiki/Block_weight#Detailed_example to know which parts of the transaction are 'Witness' data.

Outputs wont count with the virtual size reduction since those are non-Witness data.

You mean P2SH-SegWit? It's not the "raw size", but "virtual size".
Because some parts of it is Witness data and as I said, those are counted as '1' Weight unit compared to '4' for non-Witness data.

See it for yourself by checking your Electrum transaction history and check it on blockstream.info, the weight should be four times the 'bytes' displayed in Electrum whether it's SegWit or not.
If you want to see the raw Bytes, use blockchain.com's explorer.

Before you proceed: if you're trying to test "Bitcoin mining", Nicehash isn't the correct testing ground just because it payouts BTC;
It's still mining Altcoins and converts your profit to BTC as default(?) payout method.

No?, try this miner and coin: https://veruscoin.io/get-vrsc - nheqminer (AV may flag it - Download at your own risk!)
I won't vouch for that particular coin and miner but since it's just for testing purposes, you can try that because it's easy to mine with low-end CPU.

Easy steps:
1. Download the zip file and fully extract the files "nheqminer.exe" and "start.bat" in a single folder,
2. Create an Antivirus exception for the folder or files; read the "readme" file (or not).
3. Get yourself a veruscoin address using a random paper wallet generator online.
4. Visit the pool: https://luckpool.net/verus/connect.html, check the pool host for your loc and change the parameters in the bat file depending on your preferred server.
You can edit 'start.bat' using a text editor (texts may not be formatted correctly) or notepad++ (suggested).

These are the only parameters that you should change (highlight):
pool server, port, veruscoin address, put any name, number of CPU threads you want to burn; respectively.

@set PoolHost=na.luckpool.net
@set Port=3956
@set PublicVerusCoinAddress=RGWiTFQc8biW1gBQWp************
@set WorkerName=nc50lc
@set Threads=6

Then, run the .bat file "start.bat".
You can check your miner's status (after a few [1-10] minutes of mining) in the pool webpage by pasting your veruscoin address in the "wallet address".
Change the payout to lower amount under "manage" if you want to test getting paid.

Oh, that's for a non-hardware wallet multisig-setup; you need new seeds for your ledger nano devices since you've exposed your current ones.
Then follow Abdussamad's instructions to correctly set-up a multisig wallet using Ledger nano.

There's a better version of that article with full references of the codes: Google cached version
If the references weren't edited, then it's true.

It's also available in this repo which is a copy of old bitcoin code from this relevant thread:
Code: https://github.com/benjyz/bitcoinArchive/blob/master/bitcoin0.1/src/uibase.cpp#L1573
From this thread: Re: Bitcoin source from November 2008.

Right, @zeycus when you said "ledgers" are you talking about Ledger nano (hardware device)?
If so, the post above is the right setup.

It's just the descriptions and previously done steps in the OP doesn't sound like Electrum set-up with a hardware device.

Just re-create the co-signer wallets with those standard seeds using the options:
Multi-signature wallet->2/3->I already have a seed->paste the cosigner's seed (I will say "standard" but don't mind it)->Paste the other cosigner's master public keys.
Do this to the other two wallets (using the right seed/keys).

After spending the transaction, I suggest you to make a new wallet with a reliable backup using the correct set-up explained by the above post.
If it's just for testing purposes, that wallet is fine.

Well, the unconfirmed transaction itself doesn't contain any timestamp, just 'locktime' if your client set it to the current block height.
If your transaction has a locktime not set to 0x00000000, check that block height's timestamp and that's the original broadcast date of your transaction.
Use other blockexplorer to check the 'locktime'.

My theory: it looks like it was already dropped by most nodes must be because it was way past their mempool size limit and more higher fee transactions were prioritized.
Some nodes must have kept it and blockchain.com and others received it again from them, making the received time the current date.
Blockcypher for example, currently doesn't have the transaction in their mempool/database.

Those timestamps wont lie.
You must have loaded a wallet.dat file from an altcoin which uses a forked version of Bitcoin Core as the full node client.
Because most of those can still be read by Bitcoin core and derive bitcoin addresses based from the data in it.

Because it's saved in the wallet.dat file.
You need to fully sync Bitcoin core to see your real balance.