Bitaddress 1.6 was introduced on 29 July 2012. Nothing was introduced on 11 Jan 2014.

The releases that you see on github was just the date it was published. The actual versions were actually published pretty early: https://github.com/pointbiz/bitaddress.org/commits/master?after=72aefc03e0d150c52780294927d95262b711f602+139&branch=master

Other than the database hack, I don't think having the vulnerabilities is too much of an issue. Most of the vulnerabilities involves sophisticated equipment to glitch the firmware and seems like it came after hours of intensive research to discover. There's nothing much to research on for airgaps wallets because there isn't any incentives to do so. Of course, side channel attacks is not an issue for most but you can never really get too paranoid as well. Kind of helps that their competitors are always trying to hack each other's device as well.

My air-gapped storage before I started to use a HW wallet involves a Raspberry Pi which is much cheaper than even an old laptop. I'd check the signature on the airgapped wallet instead of the online computer, it's not the target computer to run the wallet after all.

Bitcoin Core should be asking you to do -reindex instead of -rescan. -rescan only makes the client run through the blockchain for any transactions associated with the address in the wallet. Running it with reindex simply means that Bitcoin Core attempts to rebuild the block database and the chainstate using the blocks that are already on the disk. It doesn't re-download existing blocks but it will verify and restructure the files instead.

An air-gapped is not malware resistant. It is possible to infect an airgapped wallet though transferring information from an air gap is hard. Hardware wallets are not susceptible to malware attacks. They are designed to not be compromised through any malware as the private keys should never leave the device.

An important note, hardware wallet attacks are often fairly sophisticated, save for a few of the less developed ones. They often take advantage of any sidechannel vulnerabilities which can be evasive or costly and often comes after loads of research. In comparison, the main protection against any attacks is the airgap and the airgap only. Hardware wallets are designed to resist any malware attacks and would be alright to be connected to a computer infected with malware.

Hardware wallets would always have a confirmation before signing such that the user is aware of the addresses that is in the transaction. The similar case can be made for an air gapped wallet if the user doesn't check the transaction properly.

I'm compelled to say yes. Hardware wallets are specifically designed to be secure with convenience at the expense of their price tags. There are also hardware wallets which are able to be airgapped efficiently just like what you can do with Electrum. The only problem that I can see is with the leaks like Ledger's, telling everyone that you own a hardware wallet. I don't send any HW wallet to my residential address so that's fine with me.
Similar. Both can be imported into another wallet easily.
Hardware wallets are mostly hardened against side channel attacks which most computers are not designed specifically for. The secure element present in some of them also prevents people from brute forcing or extracting the seeds out of the hardware wallet in the event that it gets stolen. AFAIK, some has limited attempts which will brick the entire device once that threshold is reached and thus making brute forcing pins ineffective.
No.
Nothing. You can extract the private keys from the HD seed generated with Electrum very easily and just import it into another wallet. It's open source as well so I highly doubt that it would just stop development and not create a fork from it and someone else taking the helm
No. The 12 word seeds is all you need. You can of course do that but you'll be having to secure more things and have to continually update that list if you use your wallet frequently.

You actually can generate compressed keys in v1.6, just not on the paper wallet itself. You'll have to generate it first and then convert it in the wallet details page. Don't think it matters if it's fake or not, unless the person is selling it?

The amount that you have depends on the amount of coins that you have at the point of fork. When did you move your Bitcoin Cash?

BSV was forked on 15/11/18 at the block height of 556766 from Bitcoin Cash. Did you move your Bitcoin Cash before that?

No. 1 Satoshi/vbyte is the absolute minimum for it to be a standard transaction for which Bitcoin nodes are willing to relay. You can obviously make a transaction without fees but that would only work with the participation of a miner.

There are thousands of transactions with 1 sat/vbyte fees right now. The order for which the transactions are confirmed at the same fee rate is unknown and other transactions which are paying the same fees can get confirmed sooner than yours, if you're unlucky. It's likely going to be pushed out of the mempool quite frequently given the current state, would be good for you to rebroadcast it periodically.

They don't. If you think they do, please provide evidence as to how this address (1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa) can do anything other than spending the coins which are not from the genesis block.

I think it's more of an anecdotal statement for me, I've been using my laptop to run Bitcoin Core for a while now and my use case is not always only for the wallet functionality. I think of SPV wallets as a (partial) substitute but not a full replacement for full clients. I was coming from the POV that any reasonable increase in block size to counter the current high fees would result in exponential growth of the blockchain. For which, most users wouldn't really consider purchasing additional disks for that or bother opening up their computer to upgrade.

That Tor version appears to be quite old, I think that was about the time they started incorporating Tor V3 addresses.

You want to download using the guide provided above. APT isn't always up to date and in this case appears to be unmaintained (from 2018).

No. You can't even spend the block rewards from the genesis blocks.
Private keys do not have a nonce.
Blocks do not have private keys and blocks also do not have a public key. The main thing that uses a private-public key pair are your addresses, P2PKH, P2WPKH, etc.

That will negate any benefit of HD wallets. They are designed such that anyone can derive the keys given a HD seed. By making the users manually extract each individual private keys, then they might as well not use HD wallets. Having a known derivation path is indeed useful. You can bruteforce the derivation path given a known address and the seeds though.

Correct. It's in the Coinbase transaction and since it's not a protocol standard, it can be a bit ambiguous, any changes in the transactions will alter the merkle root though I think using an extranonce makes it simpler.
The r and s values are 32 bytes each and located in the signature. If you want to parse it but I imagine that will take sometime, not sure what this can yield though. They're meant to be completely random under normal circumstances.

LoyceV very nicely compiled all of the nonces used in the blocks here: https://loyce.club/blockdata/nonce.txt.

I'm not sure where to find the extra nonce though, they're located in the Coinbase transaction.

Reindexing the chainstate is faster, Bitcoin Core doesn't have to validate and reindex all the blocks in addition to the chainstate. It took me 2 hours to finish reindexing chainstate as opposed to the 6 hours it took for me to do a full reindex. It would depend on your type of corruption to the files to determine which option you should run. Does it throw an error when reading the chainstate or the blocks?
\
Database corruption is the only issue that I have during an unclean shutdown. Nothing else should be affected.

That Tor version is very old, I think it's from 2018. Can you try upgrading your Tor and try again?

Yeah. BTCrecover works as well.

For either, Exodus does use BIP39 seeds. The derivation path for Segwit (bc1) is m/84'/0'/0' and for legacy (1) is m/44'/0'/0'.

Not too big of an issue. What client are you using?

If it's a BIP39 compatible wallet, you can find out it's derivation path and use this program[1] to search for it.

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

The difficulty to compute 1eevee with case sensitive is roughly 264104224. Which makes it 1 in 264104224.

I tried running it with vanitysearch (more optimized than vanitygen) with my 1080TI and I found like 7 of them within 5 seconds. You won't be able to find any of those vanity addresses if you only generate such a small space of addresses.