It's pretty much plastered all over the internet and it is quite unbelievable for it to ever disappear, especially for something so important. If you're scared of it, just write down your derivation path.
No.

It would be misleading and probably quite inaccurate to associate the last trading price to value. Or else, we can simply say any delisted coin has the value of the last trade, even if it is worthless.

The worth of Bitcoin is not determined by the actual market price, the actual worth of the coin is fluid and is inferred regardless of whether trades happens or not. In effect, not being able to trade Bitcoins would be akin to a stock where trading is frozen. If the utility is zero, then the value of that product is zero. Of course, even if you're talking about it in a speculative context, it would be far lower than the actual price.

Bitcoin Core is quite sensitive to database corruption if you're met with an unclean shutdown especially during IBD. However, there are instances where the corruption lies in the chainstate rather than the blocks. In this case, it would be faster than reindexing the blocks from the start.

A lot of the reports were from the earlier versions of Bitcoin Core where the architecture of the leveldb was different and it relied on memory-mapped files for UTXOs. You probably would get a corruption warning if you're actively writing to the database during the point of shutdown. If you only need to reindex the chainstate, you can run --reindex-chainstate which is faster than reindexing all the blocks (and chainstate) with -reindex.

The good thing about anything open source is that it is easy for everything to be replicated and backwards compatibility is hardly an issue. Besides, it is highly unlikely that backwards compatibility would be broken with any well-defined standards. BIP39 is considered a Bitcoin standard and it is likely that it would be supported by wallets far in the future. Storing it in anything other than mnemonics is a hassle and highly unnecessary if you're concerned about compatibility; you'll be able to recover them easily even if they are not supported by Electrum in the future.

Electrum maintains compatibility with even their pre-Electrum 2.0 seeds. I doubt that Electrum would drop the support any time in the future since it doesn't hinder the development, just a nice to have. Tldr; Electrum or BIP39 seeds are both okay.

Anything that is exposed to the internet can be vulnerable and that includes the few seconds that you are connecting to the internet on your phone. I find that air-gapped wallets on phones are not very userfriendly and could cause quite a few user errors. If you don't know what you're doing, I recommend going with a hardware wallet instead. Else, use an airgapped computer or LiveUSB.

You should not be retrieving anything sensitive from anything that is facing the internet, it is just asking for a disaster to happen. The RPC is not allowed because they are not suppose to function like a wallet.

If you want to do so, then you should run your own instance of Bitcoin Core and then use the RPC method as intended. If not, then you should find an online wallet that provides you with an API.

Then Bitcoin is worthless because no blocks can be mined and no transactions would go through. Bitcoin is decentralized and can be considered as having a high redunancy. For a catastrophic failure to happen is nearly impossible, but if it does then Bitcoin would be worthless.

It is not really up for debate. Full nodes are by definition nodes that fully validates the network rules, this was established years ago when it is compared against simplified verification wallets, aka. SPV wallets. Ideally, you don't have to trust anyone, not even the developers because you can read the code and see what goes on during the validation, and the usage of the wallet.

Decentralization is subjective, since you're only having a small portion of the blocks, you are not contributing that much to the network and just marginally. People won't exactly be able to rely on you for IBD for example, though they can still get whatever you've got on the disk. Privacy wise, it would require quite a bit more than running a pruned node and using it. Further setup is required.

You can import keys and addresses without triggering rescan. Afterwards, you can just rescan a portion of the blockchain and it won't require a reindex.

2) No. Most people can do with a SPV node, if they're okay with sacrificing a bit of security and privacy. In fact, SPV clients are safe and secure for everyday use and if you can't run a full node, you can consider running an SPV wallet like Electrum.
3) You can validate every block and have a bit more privacy than SPV clients. It's a tradeoff but you would have to spend more time validating and more storage as well.

Pruned nodes are also full nodes.

Download or Upload speed has never been a factor since Bitcoin Core IBD is parallelized to different peers and it has never been the bottleneck of IBD ever since its introduction. Besides, your bandwidth benchmark would be a naturally inaccurate metric since it also depends on the upload speeds of your peers.

As mentioned previously, Bitcoin Core is heavily dependent on I/O, CPU and RAM. Ideal situation would be to just keep the chainstate in the RAM during IBD, and thereby negating the need to flush them frequently. Signature validation can possibly be a bottleneck on a slow CPU, fast I/O and sufficient ram since secp256k1 lib is quite optimized already. Else, your I/O and your ram are the likely bottlenecks.

The security tradeoff, if implemented correctly wouldn't be worse than signing a message, or sending a transaction on the network. It isn't as much about the exposure of your public key since the security risk is still minimal but its more about the robustness of it.

By organizing transactions in their mempool into different fee buckets and see which transactions or buckets are being mined and use that with a time decay. This allows Core to estimate a confidence rate of fees for recommendation. This gist explains better than I can: https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41. The PR mentioned in that was merged in 0.15.0.

IIRC the rationale of not using mempool as an estimate was to provide a more conservative estimate. I think if you want to, it can be improved but with some tradeoff so I'm not sure if its worth it: https://github.com/bitcoin/bitcoin/issues/27995.

Anyhow, there is a trend with the fees, or at least a pattern in the frequency that people are sending transactions. It'll definitely be a fun ML project to take on. 

Also have to caveat that you shouldn't be using any random tool for this since there's no standard for this. In fact, the original implementation by jackjack had flaws which was only corrected in Electrum after release. It was not suitable for production and cryptography goes beyond simply just implementing it. Between using a well established standard like PGP and an implementation by wallets, I'd prefer PGP.

Not saying that Electrum is bad, but it does help that PGP is more widely established and researched on rather than the implementations by single wallets.

That's including swap I suppose. If you're trying to keep your chainstate in your RAM, then that's the expected behavior (flushing) which is quite different from using your ram as a tmpfs or ramdisk. If you're using /dev/shm as a ram disk, then you can only use half of the RAM, and you'll have to consider the different overheads as well. Likely would require over 32GB of ram, which would probably mean that it's going to be a couple of times more than just adding half a terabyte to your server.

Yeah, that's why mission critical configurations have ECC and not for normal consumers. Even a slight corruption in the chainstate would be bad.

Bitcoin Core only stores as much chainstate on the ram as you allow it. Keeping the entire chainstate on the RAM, permanently and not as a cache, would probably cause more problems than it solves.

---

Regardless, the behavior for the chainstate flushing during IBD of a pruned node should be that the flushing occurs everytime that the blocks are removed from disk. Even if RAM is extremely reliable and that the server is never shutdown, Core would still attempt to flush chainstate to disk as the IBD progresses. Hence, it is necessary for the disk to have sufficient space to accomodate the chainstate, no way around that.

Storage is far cheaper than RAM, and note that since your entire chainstate is in RAM, any corruption to the RAM would result in a catastrophic failure and thus another reindex. I doubt it wouldn't try to reserve the space for chainstate on the disk at all times. So it'll be far easier to just get more storage.

No good reason why you should use this over PGP. PGP is specifically designed for secure encryption and decryption while this is just good enough, having PGP makes everything much more streamlined with its web of trust and the different features specific for such systems. PGP has more development and hardening as compared to this which uses ECIES and requires you to maintain a separate set of keys for encryption and decryption.

Only flaw is that no one would use Testnet unless they are already using Bitcoin. Unless you're trying to fool some ridiculously incompetent adversary, this probably wouldn't work and would essentially be a confirmation that you use Bitcoin. Distraction won't work at all, and a decoy wallet that contains a small amount of Bitcoin would probably be a better idea.

CPUs don't really benefit that much from the entire concept of security by obscurity but they are proprietary because of the significant R&D and stuff that is going into the chips. Asking them to open source their chips would be quite unreasonable from a business perspective and probably would never happen.

I've got no doubt that HSMs already have their inhouse red team to try to attack and crack their own chips and it is unlikely for an adversary, say a state sponsored attacker at worst to be able to understand the inner-workings thoroughly enough to break the HSM. My take is that security by obscurity works, and that open sourcing stuff doesn't exactly benefit manufacturers from a business perspective, considering the amount of money on R&D and certifications as well as the potential threats by doing so. We've had plenty of vulnerabilities from open source codes and notably some of the more serious ones were not disclosed and secretly used to develop their own exploits. I have no doubt that this could happen if given the chance.

Quite significant, I would expect. HSMs are very specialized chips and they are required to withstand various attacks from sidechannels, fault injections, tampering etc. Most of them are certified and hardware wallet manufacturers are generally more keen to use those that are available on the market, which is often proprietary and closed source as compared to open source ones, likely due to the track record and stuff.

They are obscure for a reason, which likely allows it to benefit from security from obscurity, which is especially important for devices which are required to be secure. You don't want people trying to probe around to see what makes it tick.