QC threat on electrum "spawnable" type wallets vs old wallet.dat

[takuma sato]

Wouldn't it be safer to have your keys in a wallet.dat of the old format where each key had it's own private key and they were not related to a single point of failure (the seed that spawns all of these) compared to the common "type your 12 word seed to spawn your entire wallet history" wallets? Because if you've got someone's public keys, couldn't you use those to try to derivate the master private key? The old wallet.dat that that was annoying to some because you would need to do backups as it wouldn't generate infinite receiving keys, wouldn't it be safer since each private key had it's own separate public key? Then they changed this and basically wallet.dat also uses this seed system but the seed is hidden and not offered to be safed in the form of human readable words to the user. I've read this is safer (not sure if technically, or simply because there is no risk of screwing up during this process) but nonetheless, there is a main xprv involved, whereas with the old format, there was no main key, correct this if im wrong and let's explore what would the first casualties be in a successful QC exploit.

[achow101]

Because if you've got someone's public keys, couldn't you use those to try to derivate the master private key?

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.

[nc50lc]

-snip- Because if you've got someone's public keys, couldn't you use those to try to derivate the master private key?

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.

[takuma sato]

-snip- Because if you've got someone's public keys, couldn't you use those to try to derivate the master private key?

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.

[nc50lc]

Just generate a number of receiving addresses and add them as watch only as needed.

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.

Will Bitcoin Knots also stop supporting old wallets like Core? Im migrating to Knots due the spam issue anyway.

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