Core client only generate HD wallet after version 0.16
Please give user the choice to choose security over convenient: random key is more secure than key generated by algorithm.
Please consider to add back support of generating non-HD wallet and restore the "usehd" parameter
There are serval advantages using HD especially how to deal with backups. Core uses only hardened/private child key derivation.
Related: #11582
Since 0.16, Core uses HD for all newly created wallets. If you want a non-hd wallet, I guess the only workaround for now is to use <0.16.0 during wallet creation and then switch back to >=0.16.0
I know the advantages of HD wallet
But imagine the use case of "storing value", e.g. pension
It is reasonable not to put all the eggs in one basket. Therefore, the fund is split into several addresses.
non-HD wallet is more suitable in this scenario because the private keys are random. They are in different baskets as they are unrelated to each other.
Finally, i do not know where to download bitcoin core client 0.15 from bitcoin core website .
non-HD wallet is more suitable in this scenario because the private keys are random. They are in different baskets as they are unrelated to each other.
I guess we go off-topic here.
Randomness is a trick term.
It may be non deterministic, but what if someone get access to your wallet.dat? In both cases, you have lost your pension. In HD, an attacker can only derive all your "private keys", if he/she has access to your master key, which seems to require again access to your wallet.dat.
if you want to have multiple "baskets", you need to use multiple wallets from multiple vendors on multiple system in multiple locations.
Finally, I do not know where to download bitcoin core client 0.15 from bitcoin core website
non-HD wallet is more suitable in this scenario because the private keys are random. They are in different baskets as they are unrelated to each other.
Well all the keys are in the same wallet file anyway. While it's true the keys in an HD wallet are related, this is only observable to someone who knows the secret master key. Nobody has access to this who doesn't have access to your entire wallet file, which will be a total loss of funds regardless, even in non-HD situations.
There is potential downside of HD wallets though: they "unsteal" themselves over time. An attacker who got access to your wallet file but doesn't immediately steal everything and instead waits until the wallet gets funded. In case of random keys, over time he will lose access to the newer keys (though it takes a long time regardless, as the default keypool is 1000 keys now). We plan to make this sort of protection explicit by adding support for rotating out all keys and switching to a new HD master. This isn't implemented right now, though.
It may be non deterministic, but what if someone get access to your wallet.dat? In both cases, you have lost your pension. In HD, an attacker can only derive all your "private keys", if he/she has access to your master key, which seems to require again access to your wallet.dat.
It is the responsibility of user to protect wallet and add encryption password, not the responsibility of developer anyway.
if you want to have multiple "baskets", you need to use multiple wallets from multiple vendors on multiple system in multiple locations.
If addresses are not reused, the chance of breaking multiple non-HD addresses at the same time should be very small. Therefore, i think a non-HD wallet should be a good balance between security and convenient.
The link seems not found in the bitcoin core website, It is hard for other users to download old version
Well all the keys are in the same wallet file anyway. While it's true the keys in an HD wallet are related, this is only observable to someone who knows the secret master key.
I am not intelligent enough to analyse the BIP32 algorithm. Is the algorithm reviewed by crypto experts?
the "quality" of randomness of harden child private key? In the past, weak private keys were broken due to poor randomness [https://www.scmagazine.com/attackers-exploit-android-bugs-to-steal-bitcoins-from-wallet-apps/article/543888/]
difficult to reverse the master and other child keys if one of the harden child private key is reversed.
the "quality" of randomness of harden child private key? In the past, weak private keys were broken due to poor randomness ...
After googling, it seems that secp256k1 gives 128 bits of security (non-HD key), but there is nothing found for harden child key.
When using hardened derivation, child private keys are effectively generated using a stream cipher using the master private key as seed. This is standard practice when generating keys.
To anyone who does not know the seed, the resulting output is indistinguishable from random, and thus has the same security properties as random keys.
When using hardened derivation, child private keys are effectively generated using a stream cipher using the master private key as seed. This is standard practice when generating keys.
To anyone who does not know the seed, the resulting output is indistinguishable from random, and thus has the same security properties as random keys.
Thank you for your kind explanation. Now i understand that the security of HD wallet is comparable with non-HD wallet.
Note that the security is only comparable in your particular use case. There are other use cases (specifically, ongoing regular usage) where HD wallets are indeed less secure (because an old backup can compromise more of the current funds).
(However, in those cases, you can restore a similar level of security in a more controlled manner by regularly rotating the master seed.)