Post
Topic
Board Development & Technical Discussion
Re: What is the rationale behind dropping old wallet.dat support exactly?
by
ertil
on 23/09/2025, 06:10:32 UTC
Quote
it has not been hacked yet/reverted yet, so it's good to go
The whole cryptography is built on top of that assumption. Caesar cipher was also great in the past, as well as Enigma was, not that long time ago. And now, we have computers, so these old ciphers are obsolete.

And the same is true with ECDSA: if one randomly generated key is weak, then all of them are, which are based on the same entropy. Which means, that if you have some legacy wallet, then you also have "HD wallet" in practice, just the input to that wallet is more complex, and it has more bits of entropy, than just some 128-bit or 256-bit seed. But still: it is technically possible to target old wallets, by guessing their entropy. It is impractical now, but can be practical in the future.

Because what happens, when you want to get a random key from a legacy wallet? Your device just grabs some entropy from your Operating System, and then it is often hashed through SHA-256, or processed in other similar way, and then, you have a private key out of it. And what happens, when your OS entropy is too low? Well, then your keys are weak. But they are never "random". They are always based on "something". Even if you flip a coin, or roll a dice, then still, it is not a fully "random" input. It has just bigger entropy, than needed, but all of that, is always simplified to a single 256-bit private key, which always have at most 128-bit security, no matter what you use to generate it.

Which means, that HD wallets are not "weaker". They can only capture your "entropy generator" into something manageable. But if you would replace it with an algorithm, which would take things, that are captured by your OS, then guess what: you will get the same private keys! You can always take some old wallet, even with 0.1.0 version, and run it in some environment, where it will always produce the same keys. It is just a matter of your OS entropy.

Also, while in HD wallets, you need that strong entropy only once, in legacy wallets, you need it every time, when you generate a new key. Which means, that if you have a single, strong HD key, then the whole wallet is strong. But if an attacker can compromise your entropy only for a while, then in legacy wallet, some of your keys could be weak. And if you are unlucky, and you will sweep everything to a weak key, then all of that is gone (while in HD wallet, even if your OS entropy would be weak for a moment, then because of deterministic signatures, the client will never ask the system about entropy, once you fill it with a single, strong seed).

Quote
I will be using P2PKH, you can keep using whatever you want
If your choice is to pay higher fees, enable transaction malleability, and quadratic hashing, then it is your choice. You will just pay higher fees, for making transactions, which are harder to process. Because huge Segwit transaction can be processed faster, than a huge legacy transaction. We could lift transaction size limit, if the whole content would be hashed only once, no matter what Script would be used. But because of FindAndDelete implementation, it cannot be done.

Fortunately, if you use P2PKH, then your blocks would be at least smaller. But when 160-bit hash collisions will be there, then you will be forced to upgrade to something else anyway (we have chainwork around 2^96 for double SHA-256, collisions in RIPEMD-160 require 2^80 hashes, so they may be practical, if there will be enough incentive).