No. Hardware wallets mostly do not support importing addresses as it would make recovery of a wallet more complicated due to the fact that it uses HD generation primarily.

Moving the address to a desktop wallet would be more suitable though. The address is already insecure given the fact that it is already exposed to an online service. I would recommend you to just use the vanity address as a hot wallet and send the incoming funds to the walley generated on your Ledger instead.

The rise in the popularity of Bitcoin has made it a lot more attractive for people who are seeking to do illicit activities. I don't think KYC is the panacea to money laundering and terrorist financing but it could help to filter out those who are doing so. Its fairly normal that KYC has increased given the fact that there's a higher adoption of Bitcoin and that there are legislation passed to regulate it.

Exposing your own private key is never and will never be a good idea. Address reuse is still pretty prominent among the community and it would be disastrous if someone decide to send funds to your old addresses again. If there are transactions within those addresses which are somehow included in an orphaned block, an attacker could potentially double spend your transactions with less effort. Airdrops are claimable with used addresses. Addresses could be used as a way to verify identity (bitcointalk).

Tl;dr: You should never expose your own private key, even if you won't use it ever again.

Are you resynchronizing the client? I find that my client doesn't want to connect to peers if I don't completely delete the data directory after a corrupted block. If you want to try, you can try deleting the data directory after backing up your wallet.dat first.

When you try to resync the client, disable anything that could probe your Bitcoin related files for the moment. If possible, try to create an exclusion for the directory. It is possible that your programs was the source of the corruption.

It's not a fake transaction; It is totally possible to have transactions that are perceived to be made after each other.

It's likely that the transactions are made sequentially with them right after one another, the second transaction being orphaned and only confirmed after the first transaction was broadcasted, them being broadcasted simultaneously, etc. As long as it conforms to the protocol rules, it is not a fake transaction.

Most merchants accept transactions with X confirmations depending on the amount of Bitcoins being transacted. It's far more unprofitable trying to reverse transactions with one confirmation unless it is way more than 12.5 BTC (2 Blocks required) and the price of devoting hashpower to try to race the remaining of the network by mining on a fork.

It's actually rather expensive trying to reverse a transaction with a (one) confirmation than an unconfirmed transaction with the participation of a mining pool (as demonstrated before).

The free space won't matter as much if you enable pruning. There are certain constraints with pruned node as opposed to full nodes but if you're running low on space, it would be a viable option to keep the space utilisation constant.

If it runs into the buffer space, it would stop synchronising and it would be reflected in your debug.log.

They aren't similar. Difficulty is a representation of target. They have an inversely proportionate relationship.

A higher target results in a lower difficulty and vice versa. It's less confusing to relate the difficulty of mining a block to the current difficulty instead of the target and that's why its used.

Its called a vanity addresses. Since you can't reverse engineer your public key hash to your ECDSA private and public key, the only way to obtain a vanity address is to bruteforce and generate millions of addresses. That is the main reason.

It gets harder the more letters you specify.

Its not a fix, thats why I say this would be still quite prevalent.

https://mobile.twitter.com/ElectrumWallet/status/1106479573917724672. Most older clients cannot connect to any server because they automatically gets DOS'ed and loads of people have come onto the forum asking for advice.

Hmm.. Didn't the devs execute a DOS attack against the client to prevent them from connecting to the malicious nodes? IMO, it does help with the situation somewhat but this, together with the jsonrpc vulnerability would still be quite prevalent.

Mycelium entropy is a pretty dead relic. It is definitely useful for generating paper wallets but it wouldn't generate any segwit wallets and paper wallets are by design, pretty troublesome to use. I would just keep it as an artifact and buy a hardware wallet instead.

Using a linux live CD with a printer is fairly secure (though slightly more troublesome than a Mycelium entropy). I would recommend you to download it from github instead of just going to the webpage; it's quite easy for the site owner to break the entropy and produce less than secure addresses and it has already happened.

At least with a github repository, you can review the changes that's made to the code. Try https://github.com/pointbiz/bitaddress.org.

You cannot. The difficulty ensures that there is at least an increasing difficulty for mining. Unless you can consistently increase your hashpower AND outpace all the advanced ASICs that there is right now, you'll likely not be able to do so.

QC has not been proven to be able to break RIPEMD160 and SHA256 yet so breaking the keys to all the addresses is a stretch.
Trust me, when it is time, the mitigation would be quick. For now, it's definitely more than sufficient to defend against attacks if we don't reuse addresses. QC is not a magical machine that is able to break everything.
How many of the addresses are lost AND their public keys are not revealed yet?

It's possible to integrate a way for you to only send the transaction with your OTP but that will only be as secure as your current password that protects your wallet.
Which is the main problem; actual 2FA solutions requires a third party to be able to validate the OTP. It's futile for the 2FA keys to be kept inside the client as it'll only protect against the most basic attacks. For full immunity, you'll require the network to validate your code and that's not possible.

You can. Depending on your method of generating it, it could take a reasonably long time for you to crack it.

I highly doubt anyone wold be able to memorize such a confusing passphrase accurately over long periods of time without confusing which of the letters are changed.

BIP39 is actually very useful in terms of the properties that it has. The range of words allows easy correction of the seeds, there is a built in checksum with the seed, it doesn't have to rely on the user's judgement to make a secure password. I bet if people are actually forced to create their own passphrase this way, I would see loads of people asking how to bruteforce their passphrase because they cannot figure out which symbols they inserted. What you've described is basically brainwallet which has been cracked thoroughly and isn't recommended for use. It could be more secure it being salted and it would take a much longer time to bruteforce.

You can certainly keep a passphrase this way, I wouldn't recommend it but it's definitely quite safe if you choose a secure way to generate your private/public keypair.

Bech32 is very well supported by the network and being a native segwit address type, it offers a lot of benefits over traditional addresses. Some companies hasn't implemented it yet.

If you'd like, you can choose to generate addresses which are legacy addresses or Segwit nested in P2SH address. AFAIK, there is no clear cut way to generate the latter so for simplicity, you can just generate a new wallet and select legacy address as your address type.

I assume that the service that you're using has sent the funds (given txid) ? Its not exactly clear from your response. If its in the blockexplorers and confirmed, then it could be a problem with your client or the server.

Are you sure you've downloaded the official version of Electrum and not some other malicious software?

If not, verify that the address is indeed inside your addresses list. If it is, is the small globe on the lower right green?

Yes. As long as you don't share the seeds to someone else, keep your computer secure, your funds won't get stolen.

Segwit. Segwit offers a lot more advantages when it comes to the fees per transaction as compared to legacy wallets. If the service that you're using doesn't support bech32 addresses, you can use P2WSH addresses.

No. Network byte is the distinguishing factor between different coins or mainnet/testnet. It affects the prefix of the address.

No. Bech32 in particular, only works for compressed public keys.

Bech32's address generation is particularly complicated (it involves extra steps after the RIPEMD160 hashing) and I don't think I'm the best person to explain it so I will leave it for someone else. The reference code is located here: https://github.com/sipa/bech32/tree/master/ref.

P2PWSH is just like how a P2SH address is created except the fact that there's a witness program being wrapped inside the redeem script.

Other than what BrewMaster mentioned, each private key can be be used to generate a compressed and uncompressed address which could in turn yield two different addresses.