Risks of QC on Electrum wallets versus traditional wallet.dat

Isn't it more secure to keep your keys in an old-style wallet.dat where each key has its own private key? That way, they're not tied to a single point of failure like the seed that creates them all. With those modern wallets, you just input your 12-word seed to access everything. But if someone has your public keys, can’t they potentially figure out your master private key? Sure, the old wallet.dat could be a pain since you'd have to back it up manually and it didn’t create an endless list of receiving keys, but isn't it safer since every private key had its own public key? They switched it up, and now wallet.dat uses a seed system where the seed is hidden and isn't easily saved as human-readable words. I’ve heard this method is safer, though I can't tell if that's because it’s more error-proof or what. Still, there's a main xprv key involved now, but with the old setup, there wasn’t a main key. If I'm off base, let me know. Also, let’s think about what the initial impacts would be if a QC exploit happened.

No. Deriving child keys involves hashing the parent key with the index and then adding the public key of that hash to the parent key. The important component in this is knowing the parent key. For hardened derivation, you need to know the parent private key. For unhardned, just the public key. Either way, without knowing information about the parent key, you don't know what points or private keys were added together to form the child key. Quantum computers won't help you with that.

No, a theoretical QC Computer powerful enough for that would need its pair Master Public Key. And it's not available in watch-only nor locked wallets' descriptors but its child "extended public key" derived at m/84h/0h/0h (e.g. for bech32) Since your concern that the entire HD wallet's keypool could be compromised if a child private key is successfully calculated by QC; It'll only work if the hacker also knows its parent extended public key due to the weakness of unhardened derivation of child keys at 'chain_index' and 'address_index'. For that, the attacker also needs to get access to the user's machine to succeed. (like a cold-storage set-up's online watch-only wallet) So, I think the more interesting question is: "Would it be better to go back to hardened address derivation like the old HD wallets?" It will prevent the case I described above but it'll limit the capabilities of the current version that utilizes those unhardened xpub like being able to create HD watch-only wallets for Cold-storage setups. Anyways, if someone can get access to a machine like that, the owner has bigger problem than QC.

Well, from thieves (wether offline where they enter your house or online due hacks in cloud storage where you store encrypted data and potentially wallet files) or state funded actors, like being stopped in an airport or some border control and having your devices cloned, or somehow being a in a situation where they clone your files for some reason like an audit or whatever, in that case they would have access to your files since they had access to them physically. I think anything that hardens your setup is worth it. Who cares about not being able to have HD watch only wallets if that increases some attack vectors. Just generate a number of receiving addresses and add them as watch only as needed. If I have an old wallet from 2013 then im not sure you should even bother with updating. Will Bitcoin Knots also stop supporting old wallets like Core? Im migrating to Knots due the spam issue anyway.

Isn't this in the same situation as the sentence before it? If the bad actor can get access to the watch-only wallet whether it's HD or not, he'll be able to acquire all of the user's public keys. It closely follows Core when it comes with Protocol. For wallet features, it's lacking with PR that are directly posted and reviewed on its repository. It's mostly posted on Core to be reviewed there so it's not easy to tell. IIRC, I've sent you a link to its discussion that aims to change that. (or was it for someone else?) Here's the link anyways: Enhancing developer involvement and code review visibility #128