Assuming that you're using a BIP39 word list, the number of possible permutation is 2048^12. Which is about 5.444x10^39. The actual security of the keys comes down to about 128bits, after excluding the checksum at the end. If you can bruteforce a million keys a second, it will take you approximately 1.7262811 x 10^26 years to finish the key space or 8.6314055 x 10^25 years for half of the key space.

Using a longer seed phrase is possible and will definitely lower the risk even more. It will just be a hassle to store such a long seed phrase while providing a little extra security.

Is your paper wallet damaged by any chance? Did you try scanning using the QR code?

On Bitaddress.org, there's a wallet details tab. If you were to enter your private key there, does it show your address? Do it offline of course.

Pruned nodes only keeps the information that is relevant to the wallet and discards everything else. You cannot switch wallets when running a pruned node.

I assuming with the reindex that you're currently doing, you have turned the pruning off? If so, you can switch the wallets whenever you like, with a quick rescan of course. You can just replace the wallet.dat in the data directory, or if you have several you can just put all of them in the data directory and naming each of them differently (wallet1.dat, wallet2.dat, etc). You can open them by clicking on the file at the top left and go to Open Wallet in Bitcoin Core. You should be able to switch the wallet.dat as and when you like.

Bitcoin Core should automatically do a rescan and that can take several minutes to an hour. It should show rescanning... with the start up screen.

Electrum allows you to set a request and generates a QR code containing the URI of the payment request. You'll have to enter and select a source for the price reference before the fiat settings will appear.

The ETA feature is like Bitcoin Core's floating fees which estimates the number of blocks it takes before the transaction gets included. It's more expensive than mempool as it takes a more conservative estimates based on the recent trend with the mempool and/or the fees paid by the transactions included by blocks. Mempool is a more up to date method to estimate the fees as it takes the current conditions as it is; each blocks takes 1vMB of the top paying transactions by fees/size and having a transaction with fees that puts it under that 1vMB threshold will probably result in your transaction being included in a block if it a block is mined immediately. Mempool is not the most accurate as it cannot take into account the possibility of blocks having a longer interval, etc.

2700bytes is fairly big. You likely have a lot of inputs which results in a larger transaction. A typical 1 input and 2 output bech32 transaction is about 142 (virtual)bytes. You'd want to consolidate[1] your unspent output often to have a smaller transaction size.

[1] https://bitcointalk.org/index.php?topic=2848987.0

Are you using Electrum's ETA fees estimation? That tends to be quite inaccurate as it does a floating average of the fees in the previous blocks rather than the actual mempool fees.

If you were to switch to mempool, you should be able to see much lower fees. You'd want to set it at about 1vMB for a confirmation within the next two blocks or so. The transaction size is pretty big so if you're not in a hurry. I would wait for the mempool to be less congested and send with much lower fees, possibly by tomorrow or so.

You can see how the condition of the mempool here: https://jochen-hoenicke.de/queue/#0,24h

For the transactions of the same raw size paying the same fees, Segwit transactions are more likely to be included into the next block. Their virtual size is much lower than the legacy transaction despite them having the same raw size. This results in the segwit transaction having a much larger fees/virtual size.
Yes, but that doesn't affect anyone else. The majority of the network and the miners are recognizing segwit addresses right now; this means that segwit transactions will have a good propagation. Having nodes or block explorers that are un-upgraded will not result in miners not accepting segwit transactions. If they can't recognize it, then you shouldn't be using them.

Non-standard transactions are transactions that are not relayed by the nodes but are otherwise perfectly valid and are able to be mined. An example would be a transaction having 10 satoshis as one of it's output. It is a non-standard transaction as that is defined as dust. Another example would be sending a transaction without fees, etc.

Each wallet has their own individual fee estimation and it is impossible to ascertain the accuracy of it. Sudden spikes in transaction volumes are unpredictable and could result in your transaction taking way longer to confirm. More often than not, they are fairly accurate.
1Satoshi/Byte
The transaction fee is independent of the amount of Bitcoins transferred. It is directly affected by the size of the transaction instead.

I have never used Edge wallet. I use Electrum personally and I find it suitable for my use.

Please don't quote my post and take it out of context.

No. Addresses never expire. Electrum has payment requests which 'expires' and stop marking them as paid once the expiry has passed. It's purely for easier bookkeeping and doesn't affect the validity of your addresses. The address used for that request will never expire and be valid whenever you need it.

If you want to see the address, you can go to the address tab or if you didn't enable it, click the View at the top and Click Show Addresses.

Your transaction has 62 satoshis/vbyte which puts you at approximately 3vMB from the tip of mempool. Given no new transactions, which is impossible it'll take 4 blocks. I would be inclined to say that it will be confirmed within the next few hours barring any sudden spike in fees.

You can see the mempool state and the transaction fees here: https://jochen-hoenicke.de/queue/#0,24h.

It will open the last wallet that is closed.

Electrum determines which wallet file to open by checking the config located in the data directory, %appdata%/Electrum if you're using Windows. Unless you're able to edit it after every Electrum shutdown, you can't set the wallet at launch. However, you can make use of a shortcut for this. Create a shortcut for Electrum and edit its target in this format: "C:\Program Files (x86)\Electrum\electrum-4.0.9.exe" -w C:\Users\usr\AppData\Roaming\Electrum\wallets\default_wallet. You would have to specify the exact directory.

Gap limit.

For receiving address, change gap limit like this: changegaplimit('30', 'iknowwhatimdoing')

For change address, change gap limit like this: wallet.gap_limit_for_change = 30

Both are to be entered into the console. A fair warning, you have to remember that you changed the gap limit. If you were to use addresses that were generated 21 receiving addresses ahead, you will have to change the gap limit when restoring the wallet.

If you have BIP38 encryption on your paper wallet with a passphrase, you'll have to go to Bitaddress or something similar for it to be decrypted into something starting with either 5, K or L. After which, you can import the private keys.

I recommending downloading the source code from here: https://github.com/pointbiz/bitaddress.org/releases. Choose the source code zip and extract it. You should see a html file and run it with your internet connection turned off.

Bitcoin Address is a hash of the ECDSA public key. It introduces error detection as well as a shorter key size for normal use. Those are known as P2PKH or P2WPKH (Pay to public key hash/Pay to witness public key hash).

At the earlier stages of Bitcoin, the ECDSA public key was actually used for transactions and not the address that you see today. Public keys are still revealed upon spending anything from that address.

An active node or any node will not help in 51% attacks.

No. The ease of mining a block is independent of the miners there is or the hashrate but it is solely dependent on the difficulty. Even if you were to eliminate all of the miners there is on the network now and start mining, the time taken to mine the next block will not change. You will only be able to generate a block if you can calculate a block header that meets the required target. In a similar vein, having half the hashrate doesn't affect your chances of mining a block; the difficulty remains the same. The profitability (expected time to generate a block/expected earnings) does not change until the difficulty adjusts.

It takes the average. The total time between blocks would be longer. Note that the difficulty can change to either 4X the previous or 1/4 the previous[1]. That is the upper and lower bound of change.

By logic, the time between blocks would be longer. When you approximate it to 2016 blocks, the chances of the blocks in that difficulty period being 10 minutes on average while having the hashrate drop to half is practically zero.
If it drops by half, then the block interval would be 20 minutes on average, etc.
51% attack would be less costly and the unconfirmed transactions would likely increase owing to the longer block times.

The rationale behind the attack is to outpace the entire network. By reducing the hashrate by half, you have to outpace the remaining hashrate of the network, which is basically a little more than the 50% drop in the hashrate. That makes the attack cheaper than trying to outpace the entire 100% of the network without the drop in the hashrate.

[1] https://github.com/bitcoin/bitcoin/blob/c7ad94428ab6f54661d7a5441e1fdd0ebf034903/src/pow.cpp#L54

Segwit removes the signature from the transaction and bundles it separately. This also means that the convention for calculating transaction size has changed. With Segwit, the transaction are cheaper to make due to the method used when calculating the transaction size which makes it much cheaper than legacy transactions. I can't really see any downsides to be using segwit.

There's Bech32 which is also known as native Segwit as well as nested Segwit which is the witness being nested in the P2SH script. The latter starts with 3 and the former starts with bc1, the weight units of bech32 is smaller than nested Segwit but nested Segwit is compatible with all of the wallets and services while bech32 is not compatible with all.

It's spoofed. The email header should indicate that it is not sent from Electrum.org but via something else as it will almost always go through a few hops. Most email services will filter them out. It's entirely possible that the domain is just another that looks similar.

Does the key start with a K or L? If it is, you will want to follow the steps above to update your Electrum and open the wallet using it. It doesn't have a .dat extension, it is just a file.

If you only have the key, create a new wallet and Select the following: Import Bitcoin Address or Private keys and key your private key (K or L) into the box.

It's not. The gist of CPFP is to make another transaction with a higher than proportionate fee to subsidize the "parent" transaction so that the total fee rates for both transaction would be reasonable. It is definitely not bounded by wallet software but doing it in the wallet which you sent from could be simpler.

When importing BIP39 seed phrases, there are specific configuration for the addresses to be generated and can differ greatly between the wallets. IIRC, MyCelium uses BIP44[1] as the standard to generate the addresses. This is transparent to you and should no matter as long as you can do a CPFP within the wallet.
CPFP requires a high fee rate to compensate for the low fees of the parent transaction so that might be where your issue is. In this case, CPFP is not viable either unless you are able to send more funds into the wallet and spend both the change and the Bitcoins added. I don't think this is particularly feasible either.

You can't really tell if it rebroadcasts or someone else rebroadcasts it for you until it reaches the mempool expiry of the nodes. I would advice you to continually check the Blockexplorers and once you get an error from searching the transaction ID, make a new transaction.

Yes. CPFP works as the first transaction has to be confirmed for the miner to collect the fees from both of the transaction.

Unconfirmed transactions are still spendable, it is just that it cannot be confirmed until the transaction from which it is spending from gets a confirmation.

[1] https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki