The problem with blockchain(dot)com is the fiat "value when transacted" is only for the whole transaction so if it has a change, it's included to the value as well.

For anyone who are planning to post to this thread: OP is now Autobanned for plagiarism so further replies are unnecessary.

With all your misunderstandings in everyone's reply, I think this quote is the main issue here.

The first thing you need to learn is: "Bitcoin doesn't work like a bank"
Addresses aren't issued by a main server, it's created by your wallet based from your private keys from your seed phrase.
If you just imported an address and not generate it from a private key or seed, you'll end up with a read-only (watching-only) wallet.
Without the private key of an address, a person cannot spend from that address. (it's labeled "watching-only" for a literal reason)

Your wallet is not like a bank account either, that's only a storage for your private keys/addresses and the necessary features to spend and/or receive bitcoins.
There's no copy of it in any server, it's solely stored in your PC or Phone.
So, the developers don't have access to "your wallet", that means that they can't do anything if you ever lost your funds while using the wallet.

It's currently in the "backlog Milestone" so there's no definite release date: github.com/spesmilo/electrum/milestone/12
Also, ecdsa seems to be annoyed by users asking for Taproot support :/ (reference post)

Yep, the signature file for v4.3.0 only contains two signatures:


Emzy's public key is still in Electrum's Repo: https://github.com/spesmilo/electrum/tree/master/pubkeys; His Github profile is also active: https://github.com/Emzy
It's just the signature file in the website doesn't include his signature but you can still download it from here: github.com/spesmilo/electrum-signatures/tree/master/4.3.0

Judging from the size of the USB-C port at the bottom side of the HW as well as the 'dimensions' indicated in the "Technical Specifications", the form factor is small.
It looks bulky in the pictures since it's scaled with your monitor and it's hard to judge the size of a picture of an object without a reference.

It's not enough since the seed phrase or private keys have been stored in an online machine.

To create a genuine Cold-storage set-up.
Every 'private' data must be set-up in an "air gap" machine, that include the seed/key creation and offline wallet set-up.

It wont work.
By forcing to encode the PubKeyHash with "base58check (-z)" encoding, it will produce a non-standard address.
It will produce an address with the correct code, yes; but the standard clients that use base58 simply wont be able to decode your addresses correctly.

"wallet_1" is the default wallet name of the second wallet that you've created, perhaps that seed phrase is only for the first wallet "default_wallet".
The question is, where did "wallet_1" came from?

An address can't be deleted even from an imported wallet.
And the only reason that a wallet is labeled "watching-only" is if it's created by importing address(es) or 'master public key'.

If your main account is a newbie, you can try to ask a moderator to "nuke" it.
That will wipe all of that account's posts and ban it.

But it's not possible if it's a Jr member or above, only the admin can do that.

Here's how to find moderators or the Admin: /index.php?topic=703657.0

If it's not the transaction fee, it's the block time.
The 10 minutes block time is just an average, it can go up to hours or down to seconds depending on the miners' luck.
Moreover, it can also be affected by miners shutting down/powering up their farms causing a drastic changes in difficulty in the next retarget.

"Double-spend" is loose term, I think you mean reverting an already confirmed transaction and replacing it with another, based form the thread's topic.
Honestly, IDK if there are other ways to do that aside from the mentioned attack, others might know.

Uhm, that's per unit.
You need about 1million units to reasonably do the attack.

51% attack was already discussed multiple times and received great replies in the board that I've mentioned.
I'd suggest you to follow my instructions above to be able to see those topics.

Do you mean 51% attack?
Basically, you need to have 51% of the network's hashrate or more to have a reasonable chance of success.

Currently, the network's total hashrate is (getmininginfo):
Which is roughly 204.257 Ehash/s, half of that is 102.129 Ehash/s
Which is equal to 928,440 units of Antminer S19 Pro (110TH/s advertised hashrate | $4~5k average price)

With that, I think you can get the picture of the cost; not to mention, the availability of the required mining equipment.

For more info, I'd suggest you to go to this board: Development & Technical Discussion
The use the search box at the upper-right side of the page to search for "51% attack".

Yes, it's working.
The "help" result is displayed since you don't added any command-line options.

Those command-line options  should be supplied together or pywallet.py --recover wont proceed (it will tell you what parameter is missing).
And yes, the "recov_size" is the size that you want pywallet to check, it can be lower than the disk's size but checking the disk's full size is recommended.
For the "recov_device" letter, it should be the same as the (clone) Disk's drive letter as seen in your File Explorer or Disk Management.
"recov_outputdir" is where the recovered_wallet.dat will be saved.

After successfully entering a proper command, it will ask you to provide password for the wallet.dat that it will create where the recovered keys will be saved.
Then a bunch of possible passwords of the deleted keys or wallets (one line [password->enter] per password, leave the last one blank [just press enter] to begin the search).
note: characters wont be displayed while you're typing the passwords.

You're probably right (given your post history).

After loading the wallet, instead of getting: Wallet File Version = n
and Keys: n plaintext, n encrypted, n w/ metadata, n total. Unknown wallet records: n

Those are replaced by:

Try to launch Bitcoin Core with -debug=walletdb command-line option to output wallet database-related info or -debug=1 to enable all categories.
Then re-check the logs if you can find an error related to the crash.

You can use -recan in the console as well if you do not know how to launch it with addition command line option.
Just open the console "Window->Console" and type: rescanblockchain to scan from the genesis block up to the tip.

BTW, the latest version of Bitcoin Core is set to prune the blockchain by default. If you haven't unchecked it in the initial setup, your node's blockchain is pruned.
You can see it in the settings: "Settings->Options...->Prune block storage to"

Blockchair (the one LoyceV suggested) is a multi-coin blockexplorer.

That said, which blockchain does your transaction belongs to?
It's indicated at the upper-left hand side of the page, just below blockchair's logo; if it's in Bitcoin's blockchain, it should say "Bitcoin transaction".

Electrum isn't a company, it an open-source client which is being developed by volunteer developers.
For reference, here's their license: github.com/spesmilo/electrum/blob/master/LICENCE
In other words, they aren't liable to any lost funds caused by either a bug or a vulnerability in the client.

Electrum isn't a custodial wallet either so there's no way to verify the cause of lost of funds but the user himself.
The users' seed phrase, password, passphrase, etc. aren't stored in any server; the public "servers" are just there to provide Electrum clients data from the blockchain.
Those servers aren't owned by Electrum either, those are by users who have a public Electrum Server.

[1] I can't find any archive or list with that statistic based from 51% attack since AFAIK there's never any successful 51% attack to the Bitcoin network (CMIIAW).
[2] I can't find any archive or list with that statistic based from orphan blocks either since not every Bitcoin node will receive an orphaned block.
[3] There was an incident when bitcoin had to revert back the blockchain due to a serious bug,
during that time, confirmed transactions after the "bad block" had reverted back to unconfirmed. (more info: Value overflow incident)

Additional info for [2] "orphaned block":
We can assume that if a node accepted an (to-be-)orphaned block and if a transaction is included there but not in the main chain
that particular txn can reverse from '1confirmation' into 'unconfirmed' after that node dropped the orphaned block and accepted the valid block.
But since every node isn't the same (location, internet speed, etc.), it only got 1 confirmation in some nodes (minority of the nodes that received the orphaned block)
and not the majority of the network where it's not confirmed.
If the orphaned block and the valid block both contain that transaction, then the transaction will not reverse even after dropping the orphaned block since it's in the valid block too.
So it's a case-to-case basis.

Plus orphaned blocks are uncommon now.